linux/poky.git/meta/classes, branch morty

sanity.bbclass: Improved error message

2018-04-05T14:23:05+00:00

When a non-existing MACHINE is specified, sanity check issues the following message: Please set a valid MACHINE in your local.conf or environment However, MACHINE can also be set in multiconfig .conf file(s). Hence we may have several different MACHINE settings within one (multiconfig) build, so the present error message is fairly ambiguous. This patch remedies this by explicitly naming the offending MACHINE and by amending the list of places where this erroneous MACHINE definition could have originated. MACHINE=xyz is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file. [YOCTO#10810] (From OE-Core rev: 7b7cbba0bb93893029118e5798ec5831838a5bd9) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie (cherry picked from commit a7cb408dd784178197687a2129e936620bf6a0d3) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie

image/packagegroup/populate_sdk: Drop do_populate_sysroot task properly

2018-04-05T14:13:48+00:00

Setting do_populate_sysroot as noexec means the code keeps thinking it can find a manifest file for it. It also complicates sstate installtion since the code would believe there is an sstate object there it should look for. Instead, delete the task. This causes sdk failures as the dependencies are wrong so fix those as well. (From OE-Core rev: bd7d0314038a4c1a8e8c9ebdb7194f8e17db3fef) (From OE-Core rev: 249feee857735171fc0c289fe18351203d013130) Signed-off-by: Richard Purdie [Fixup for getVar True bit] Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

toolchain-shar-extract: compare SDK and host gcc versions

2018-04-05T14:13:48+00:00

If ext sdk is built by gcc version higher than host gcc version and host gcc version is 4.8 or 4.9 the installation is known to fail due to the way uninative sstate package is built. It's a known issue and we don't have a way to fix it for above mentioned combinations of build and host gcc versions. Detected non-installable combinations of gcc versions and print an installation error. [YOCTO #10881] (From OE-Core rev: bfb9ea2604557804bd8c16adb57ccdd868a4020f) (From OE-Core rev: 44a5277d25da5ab76e4bf8ad3f534a8e9a7b30eb) Signed-off-by: Ed Bartosh Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

populate_sdk_base.bbclass: add documentation packages to SDKs if api-documentation is in DISTRO_FEATURES

2018-04-05T14:13:48+00:00

(From OE-Core rev: d2b7b3fca328449cd87997be7f897b59433a153d) (From OE-Core rev: d4a0da43bc250215083fe413c64b9bef441994af) Signed-off-by: Alexander Kanavin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

buildhistory: fix latest_srcrev in the common case

2018-04-05T14:13:48+00:00

buildhistory was writing srcrevs.values() as SRCREV when only one srcrev/branch exists. This returns a view of the dictionary values in python 3, and used to return a list in python 2, neither of which is an appropriate value for SRCREV. It was resulting in latest_srcrev files like this: # SRCREV = "346584bf6e38232be8773c24fd7dedcbd7b3d9ed" SRCREV = "dict_values(['346584bf6e38232be8773c24fd7dedcbd7b3d9ed'])" Which in turn would result in invalid output in buildhistory-collect-srcrevs. Fix by calling `next(iter())` on the `.values()` (From OE-Core rev: 4243555ab91ab763a098259011dfa72156bfe0b3) Signed-off-by: Christopher Larson Signed-off-by: Ross Burton (cherry picked from commit ef826a395612400924bbe49859d256b237ff59e1) Signed-off-by: Andre McCurdy Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

libc-package.bbclass: split binary localedata even more if asked to

2018-04-05T14:13:48+00:00

If GLIBC_SPLIT_LC_PACKAGES is set to a non-zero value, convert glibc-binary-localedata-XX-YY to be a meta package depending on glibc-binary-localedata-XX-YY-lc-address and so on. This enables saving quite some space if someone doesn't need LC_COLLATE for example. Some regex code was removed from output_locale_binary_rdepends, because legitimize_package_name already converts to lowercase. (From OE-Core rev: 40b4b31092058f8833ada3dfc254d362dd3139c1) (From OE-Core rev: d11222c452d79cc2044a21432336c4a59d08327b) Signed-off-by: Andreas Oberritter Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

archiver: avoid archiving source for glibc-locale

2018-04-05T14:13:48+00:00

Avoid archiving source for glibc-locale as its tasks do_fetch do_unpack and do_patch have already been deleted. (From OE-Core rev: 208f397c0dc48d56bc7900e76eb48406d5865c72) Signed-off-by: Zhenbo Gao Signed-off-by: Ross Burton Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

populate_sdk_base: depend on nativesdk-glibc-locale

2018-04-05T14:13:47+00:00

If we're building a SDK and we're using glibc so may be installing locales, add a build-dependency on natiesdk-glibc-locale so the locales we need will exist. (From OE-Core rev: 8d6869a0a89d8cf3c6e57723fab2750ba2c885db) (From OE-Core rev: bad37bfd766c39efe5a5db95668c855d1c45a059) (From OE-Core rev: 15a8681bcae24da0fd2551a49e4b59b3efb24886) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

populate_sdk: install UTF-8 locales in SDKs

2018-04-05T14:13:47+00:00

As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts using glibc earlier than 2.27 won't be able to find any locales, so bitbake won't start and Python can't use UTF-8. So by default install all locales into the SDK. Special-case Extensible SDKs by installing no locales as they ship glibc in a buildtools, and that will have the locales. Locale installation requires cross-localedef, so add that to DEPENDS. Also remove the explicit en_US addition in buildtools-tarball as it is now redundant. (From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1) (From OE-Core rev: 385dd115d00aabbcd970ef6b62353480d87a5a55) (From OE-Core rev: 065ddf01b914805298fb1ddf83ae32b5018856b3) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

uninative: Add compatiblity version check

2018-03-15T22:48:00+00:00

If glibc is newer on the host than in uninative, the failure mode is pretty nasty for clusters where the sstate is shared, including the Yocto Project autobuilder. This check aborts the use of uninative in such scenarios where a newer glibc version appears and avoids corruption of sstate caches. We use ldd to check the glibc version since that is included in libc-bin (or equivalent) which locales use so it should always be present. (From OE-Core rev: 676d4d91064d4e4f7abb2bd3597a0ddd5b7e2390) Signed-off-by: Richard Purdie