There maybe no rpm postinst script (e.g., core-image-minimal), then the
"*" is not expanded, and there would be error:
head: cannot open `rpm-postinsts/*' for reading: No such file or directory
Check whether it exists or not will fix the problem.
[YOCTO #3172]
(From OE-Core rev: 966c72e00c8d378d7d189f0e4b626f6782d23a25)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is used by:
openembedded-core/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
meta-openembedded/meta-oe/recipes-support/maliit/maliit-framework_git.bb
(From OE-Core rev: c67f64e5846bb2a6774e61a4f3719c5f82fc3bd8)
Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While removing packaging data files in rootfs_ipk_do_rootfs use the
remove_packaging_data_files function. By using this function we ensure
that /var/lib/opkg directory is created. opkg needs this directory to
create lock files.
(From OE-Core rev: 1f3300766b827ed73daaa01572017775305105b2)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that xserver provides driver ABI names, all drivers should depend on the ABI
version that they have been built against.
All drivers that include xorg-driver-input.inc or xorg-driver-video.inc will get
these automatically, so this should only impact binary drivers.
(From OE-Core rev: 800b256390b22c3d3d8d6a69f6fb668376a5030b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We seem to be mostly installing modules into vendor_perl nowadays.
Make sure that the .debug data from there is captured appropriately.
Also, expand ${PERLLIBDIRS} at the point of assignment so we don't
call the python again and again.
[RP: Fixup to whitespace]
(From OE-Core rev: ed7690bf5cc964b5cee55f5ef13c10c75d8e3463)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When copying the source files needed for the -dbg package, use hardlinks
where possible. This saves some disk space and hence helps performance
of the builds.
(From OE-Core rev: 6775feb9fe935ab01fd9cae2b2d3fce5824a9a72)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The symlink from uImage-3... to uImage is not created at image creation
time and not properly update on kernel upgrades. This is fixed by removing
the chdir. The other users of update-alternative do not change the directory
before calling it.
(From OE-Core rev: c77ca9ee901468c93570b5264b226f7d17a41c16)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, we'd rerun packaging for every machine since this variable contains
a machine specific component.
(From OE-Core rev: 61131828c59178c923b3d5b5fcacf0dbcba275a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that PACKAGES_DYNAMIC is more standardised, starting with ^ anchors,
the variable manipulations performed by clsextend for multilib don't work.
This patch at least improves it to hack around the problem and enable
mulitlib builds to work again. If this code doesn't do the right thing, the
recipe is free to override the variable with the correct multilib case.
(From OE-Core rev: 593faec6e0155bdd7a43ee84c24de8ee20287681)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now do_package isn't machine specific, we're only left with do_populate_sysroot as a
machine specific task. This change marks only the machine specific manifests as machine
specific, defaulting to PACKAGE_ARCH for everything else.
This means we do less work where there are multiple machines using the same
core package architecture and we can start to clean up the sstate duplicate files
whitelist.
(From OE-Core rev: febeaf3d1b8917b660c7279b008d8b03337568e9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, do_package is machine specific since the shlibs data is installed
into each machine specific sysroot. This change moves the shlibs data to the
pkgdata structure, at the expense of having to iterate over a set of shlibs
directories instead of a single one.
It turns out this isn't any particular hardship for the code and as a result,
do_package stops being machine specific leading to optimisations for builds
that use a common PACKAGE_ARCH.
(From OE-Core rev: cc088489d70fb27d460c3dbe35d6ea382123c134)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These variables correspond to the PACKAGE_ARCH list combined with the TARGET_VENDOR
and TARGET_OS values. These can be used to traverse the pkgdata structure.
Setting these once in base.bbclass stops pkgdata needing to recalculate the values
and is also useful for the reworked shlibs code in a patch that will follow this.
(From OE-Core rev: f91322edc8b9f2a5906f3908bde2508ae97f2816)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-modules is always added to PACKAGES later in python code and
needed to be defined as PACKAGES_DYNAMIC
* add it to PACKAGES directly and set
ALLOW_EMPTY_kernel-modules
FILES_kernel-modules
DESCRIPTION_kernel-modules
outside populate_packages_prepend like for other packages and set only
RDEPENDS_kernel-modules from python code
(From OE-Core rev: 0884bdbbf39f2b3a8a342918812f29ddcd3b1e6f)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake uses PACKAGES_DYNAMIC as regexp
^ could make matching faster (and it will be more clear that we're expecting regexp not glob)
* made all those last '-' optional, use .* (or nothing)
(From OE-Core rev: 2f3ebdfa5f42dae51063b043cc4b0fbe20b40064)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The compilation routine for the kernel has an explicit call to
build version.h, which works fine for most kernels, but the
location of it has recently changes.
commit d183e6f5 [UAPI: Move linux/version.h]
commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]
moves the file to include/generated/linux/version.h and then to
include/generated/uapi/linux/version.h.
As a result kernel builds of 3.7 or bisection builds of intermediate
kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit version.h build conditional on the version, or
via a file test would fix the problem, but it introduces some complexity
to the build.
Even without an explicit call to build version.h, it is always produced
by the kernel build, so it can simply be removed.
This extra make line was originally so that the kernel version could be
determined, so that then different instructions could be executed depending
on whether it was a 2.4 or 2.6 kernel. Since we no longer support 2.4, this
code is no longer needed.
[YOCTO: #3293]
(From OE-Core rev: 4cb20fa89e571ffbc448c579a758db0b9074acf4)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For builds that don't use gettext, config.rpath may not exist in the target
datadir. This change uses the native directory where it will always
be present due to gettext-minimal-native (which allows us to autoreconf
recipes using gettext even if we don't have gettext built).
(From OE-Core rev: 0ea24447842e6b76ccfee0881f557e1a82e89ef1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the link is absolute then we might end up reading from a host binary
or a nonexistent path, neither of which will produce useful results and
may result in objdump failure and python backtrace spew. If the link
does point to a binary within the installation root then we will scan the
pointed-to file at some point anyway so there is no need to do it again.
(From OE-Core rev: 91769af1c1175ac9bb43d16d05fb1c8736dd9287)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various different QA checks are based on essentially the same data from
the ELF program headers. Calling objdump to extract it repeatedly is
inefficient, particularly if the shell is involved. Instead, let's
cache the output from objdump inside the qa.elf object and allow it to
be reused by multiple tests.
Also, using objdump instead of scanelf to check for bad RPATHs (in the
same way that the useless-rpaths check was doing already) allows the
dependency on pax-utils-native to be dropped.
(From OE-Core rev: bf19eeb9f65e91bf2b5d89e7c0b099c55d7c15ff)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise it will fail if these two directories are not the same.
(From OE-Core rev: 491823fdc65d124093f1fed5a56173917443e1d6)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gettext m4 macros don't use the usual versioning/serial mechanism used by
aclocal. It therefore won't update them over and above any local version of
the macro. Equally, we don't run gettextize due to it doing slightly crazy
things to the build.
When we put the aclocal directory as a -I option to aclocal, if this was
found first compared to any recipe provided macros, the correct version
of the gettext macro would still "win". With the switch so correctly override
the system directory, older recipe provided macros may get used.
This patch manually removes the problematic m4 macros in the case we're using
gettext and need to use the correct m4 macros.
This patch also always ensures the gettext manipulations happen, even in the
-native case since missing or stale gettext files could cause build failures.
(From OE-Core rev: e9645d2bbeabaa5251d49edd659ab320fd66d0ee)
(From OE-Core rev: 841ea3c1c18e50e77fccbd5f44d6a79a50913b67)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous steps taken to address races over the aclocal macro directory and the removal
of files hasn't been sufficient since aclocal still looks at that directory as part of its
default search path. This patch passes the aclocal-copy directory into aclocal as its system
directory, removing any chance of it accessing the original aclocal directory.
Hopefully this should therefore fix the race issues once and for all.
In order to do this, cp-noerror needs to not error if the directory already exists.
Its also been noticed that aclocal defaults to using STAGING_DATADIR_NATIVE even when
building for the target. Only using the target directory would cause errors such as
missing pkgconfig macros (since we only depend on pkgconfig-native, not pkgconfig).
This patch processes both sets of macros maintaining existing behaviour. At a future
date we could look into potentially optimsing this.
[YOCTO #3216]
(From OE-Core rev: ad29b331e0d61708e68ef772cdb19154956fa67e)
(From OE-Core rev: f362cc419e5a480acd16c71c802636dbedc932d9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The network tests in sanity.bbclass can now be trigerred explicitly
by firing the NetworkTest event. This is part of the fix for bug #3026.
[YOCTO #3026]
(From OE-Core rev: f1f43d55dbb020a0145c58731d4259fd906d9d1e)
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've noticed failures on the project autobuilders where a shared sstate
directory is used across multiple builders and the clocks become skewed.
Most of the time this causes harmless building but if this happens where
an environment is changed (make install vs make in qt4-x11-free for example),
the build can fail.
This avoids modification times in the future and should make builds safer
in shared environments sstate was designed for.
(From OE-Core rev: 8f1bdb4f4afd7f5f4c121be8ba82f4675f73e300)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This tests for /usr/libexec as we are moving things to /lib/.
the test is ignored if the distro defaults to /usr/libexec.
Currently this test will be disabled by default since the current
value of ${libexecdir} is "/usr/libexec". Also this tests needs
to be enabled in the WARN_QA list.
[YOCTO #2915]
(From OE-Core rev: 4c60c2779dde6962f342f9c9b61713cf2d3a564c)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you wish to change the install/unpack method of the sdk, this can now be done by making
your own create_shar method, and setting a SDK_PACKAGING_FUNC variable to your
new create_shar function.
(From OE-Core rev: 3955c8eced352226bb4c9ceb710dbe02474b9024)
Signed-off-by: Thomas Kristensen <thkriste@cisco.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since e3d7890cac or so, base.bbclass has
considered invalid LICENSE settings to be a fatal error. This means we
will never see them so there is no point checking for that.
(From OE-Core rev: e2d71503847f72f55666143a2a320925838fd26f)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's sometimes useful to have this function available to recipes which
don't wish to use module.bbclass for whatever reason.
(From OE-Core rev: 7632b44e7f487180811d47fbe9c29aa8e58868a2)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The update-modules mechanism is something of a historical relic and it isn't
entirely clear that it has a great deal of value nowadays. Also, it causes a
problem when building a read-only rootfs since update-modules itself refuses
to configure offline.
Allow DISTROs to circumvent this whole thing by declaring (via DISTRO_FEATURES)
that they don't wish to use update-modules. This is backfilled for existing
distributions and will have to be marked as CONSIDERED by those who actually
don't want it.
(From OE-Core rev: 14bf8ed115453077b4d4042b4b70ed6b3bca2a9f)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There seems to be no benefit in having them be different and this
appears to cause a certain amount of confusion about paths for
the native modules.
(From OE-Core rev: 3926a45a26c2d23d9c2fc9c3956f780f607ec7a4)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Just because a recipe uses pkgconfig, it doesn't mean that it's -dev
package should RDEPENDS on pkgconfig. I can understand the thinking
that lead to this but it makes sense to be able to install the package
when pkgconfig hasn't been built.
Currently you can also get failures where pkgconfig wasn't built yet
a -dev package is included that depends on it leading to rootfs failures.
I considered making this a RRECOMMENDS but it should probably be an
RSUGGESTS at best given the tenuous pkgconfig requirement any given
-dev package has.
(From OE-Core rev: 8f41b69578eef5ea750e8f93dcd9d37375ce7d88)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The virtual-locale-* packages are provided by libc which may or
may not have a matching locale for any given recipes's provided locales.
Certainly, we shouldn't get a failure if the locale package isn't
available.
This patch therefore makes the dependency optional rather than
required, allowing the locale packages in question to install. This
resolves errors like:
virtual-locale-eo is needed by bash-locale-eo-4.2-r5.i586
virtual-locale-en+boldquot is needed by bash-locale-en+boldquot-4.2-r5.i586
virtual-locale-en+quot is needed by bash-locale-en+quot-4.2-r5.i586
(From OE-Core rev: 2be67f95abaa7e8655a1ca8f4ffe66b3e099a650)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The names used to generate the binary-localdata packages need to match the location
the dependencies are added. In one case the dash replacement is made, in the other it
is not leading to packages which cannot be installed:
eglibc-binary-localedata-af-za.iso88591 is needed by locale-base-af-za.iso-8859-1-2.16-r22.i586
eglibc-binary-localedata-cs-cz.iso88592 is needed by locale-base-cs-cz.iso-8859-2-2.16-r22.i586
eglibc-binary-localedata-ru-ru.koi8r is needed by locale-base-ru-ru.koi8-r-2.16-r22.i586
eglibc-binary-localedata-pl-pl.iso88592 is needed by locale-base-pl-pl.iso-8859-2-2.16-r22.i586
eglibc-binary-localedata-hu-hu.iso88592 is needed by locale-base-hu-hu.iso-8859-2-2.16-r22.i586
eglibc-binary-localedata-de-at+euro.iso885915 is needed by locale-base-de-at+euro.iso-8859-15-2.16-r22.i586
eglibc-binary-localedata-sv-fi.iso88591 is needed by locale-base-sv-fi.iso-8859-1-2.16-r22.i586
This fixes things so the names are consistent.
(From OE-Core rev: 17e1bfe2b1260add9749b5ff73c72d57c0215fdc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also ensure that we always cleanup the temporary install manifest files,
some of them will cause problems if they exist in multiple install
attempts.
Finally verify that the lists remain uniquely sorted otherwise the
complementary install may install the same files numerous times,
triggering a failure.
(From OE-Core rev: 4f2a290cbcc6c21afbb2a6e6148efdef4d135b41)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids errors where gcc/binutils get installed to the native sysroot
in the same location for multiple package architectures. Ultimately making
these native recipes with ${PACKAGE_ARCH} appended to PN will resolve this
but hide the warnings until this gets sorted out.
Also hide the python and docbook catalog warnings since they're known about,
nothing to worry about and we'll aim to clean them up properly in the 1.4 cycle.
(From OE-Core rev: 5bae58a5b59c04d8947f4842f19837a914c29b52)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, path components like // could break comparisions with the whitelist leading
to warnings being displayed to the user unintentionally.
(From OE-Core rev: d3c46ca56fab2f07bf16b61514f30765543a8747)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
some packages use M4 variable from environment and sometimes
its hardcoded to /usr/bin/m4 if not found in environment. Lets
define it such that it is picked from path
(From OE-Core rev: 06c5593d15f206458b9a5b45ed1229abfee16e95)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order for the RPATHs in 32bit toolchain binaries to be relocated
properly, chrpath >=0.14 is needed.
[YOCTO #3161]
[YOCTO #3201]
(From OE-Core rev: 71c71b972100803d33fbb062a237e8a15167387b)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the distro check functions for the change of nativesdk
being a suffix to a prefix. Also added crosssdk as another
case for converting to PN for matching in the distro_tracking
(From OE-Core rev: ae9dbd0e1e26ba2b35cbd08ec731aee62adedc23)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to iterate over the dictionary pulling out the values, not take the top
level keys. If we don't do this, we end up with dependencies on the values of
PACKAGES, not library dependencies.
(From OE-Core rev: 7219bca11f554fbe2ed30f1537491987d65e9316)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, circular dependencies are found when attempting to build
multilib versions of qt4 (or bitbake world in a multilib enabled build).
(From OE-Core rev: b2e8cc5ae227656211fb7f32260e7dc4e2fb556e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Versions earlier than 0.14 can't cope with 32 bit binaries on a 64 bit
system and vice versa. This results in problems for certain SDKMACHINE
combinations on certain hosts. By ensuring we build
chrpath-replacement-native we avoid this problems and the binaries work
correctly.
[YOCTO #3161]
[YOCTO #3201]
(From OE-Core rev: f89bced26de055817100d0b0e03094b031fcfd48)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
