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

populate_sdk_base: depend on nativesdk-glibc-locale

2018-04-04T10:06:55+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) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

populate_sdk: install UTF-8 locales in SDKs

2018-04-04T10:06:55+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) Signed-off-by: Ross Burton 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

buildstats.bbclass: Avoid index exception in /proc/PID/io parsing

2018-03-14T14:55:53+00:00

There is some probability (depends on system load) to get empty or line containing "0" as the last line while reading /proc/PID/io. Avoid build failure by checking if line contains separator ":" before split. Backport from pyro commit b26feaf51af55f17fad79dbd53dd3ec0a37c38ff (From OE-Core rev: 31a098032eb82eb40eaa3952de4d29ab472e368a) Signed-off-by: Pavel Modilaynen Signed-off-by: Daniel Lublin Signed-off-by: Ross Burton Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

insane: consider INSANE_SKIP without package-specifier too

2018-03-04T11:12:12+00:00

this is needed for the updated linux-firmware as it needs this INSANE_SKIP support (From OE-Core rev: 618093c6b7c919f25094f56b82610bee7c97f99f) (From OE-Core rev: 4c1de18cb5d2bf4067246bf7242abde0f0917a3a) Signed-off-by: Ross Burton (cherry picked from commit 604939186cc08ab0429ebe00f3e32661847f0cf0) Adjusted for pyro context Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie Adjusted for morty contect Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

populate_sdk_ext: Set cleandirs correctly

2018-01-22T10:40:02+00:00

The current conflicting use of SDKDEPLOYDIR causes a race between do_populate_sdk and do_populate_sdk_ext potentially causing the SDK to either go missing or the build to fail. (From OE-Core rev: 39fd8c129e2bff7f2f1649b7f6e036ccc50fd5d8) Signed-off-by: Richard Purdie

lib/oe/package_manager/sdk: Ensure do_populate_sdk_ext and do_populate_sdk repos don't conflict

2018-01-22T10:40:02+00:00

(From OE-Core rev: c9c0927bb6e71253cbdd5b6b780dca829526e1d8) (From OE-Core rev: 04610f713e47cd5fc9e44e258589cb24f27bf1bc) Signed-off-by: Richard Purdie

image: Fix previous broken commit to set expand parameter to getVar

2018-01-21T00:01:03+00:00

(From OE-Core rev: eb5ca672c793e7c2151e7f2fef26e0c25130d840) Signed-off-by: Richard Purdie

image: Expand PV to avoid AUTOREV parsing failures

2018-01-20T22:29:40+00:00

Currently, setting PV to include SRCPV for build-appliance results in: bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export ftp_proxy="http://proxy.yocto.io:5187/"; export FTP_PROXY="http://proxy.yocto.io:5187/"; export PATH="${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/python3-native:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/python3-native:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/python3-native:/home/pokybuild/ yocto-autobuilder/yocto-worker/buildtools/build/scripts:${TMPDIR}/ work/qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/x86_64-poky-linux:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot/usr/bin/crossscripts:${TMPDIR}/work/qemux86_64-poky-linux/ build-appliance-image/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin: ${TMPDIR}/work/qemux86_64-poky-linux/build-appliance-image/ fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/sbin:${TMPDIR}/work/qemux86_64-poky-linux/ build-appliance-image/fetcheravoidrecurse-r0/recipe-sysroot-native/bin:/home/ pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/bitbake/bin:${TMPDIR} /hosttools"; export HOME="/home/pokybuild"; git -c core.fsyncobjectfiles=0 ls-remote git://git.yoctoproject.org/poky failed with exit code 127, output: /bin/sh: 1: git: not found This is because PV is being expanded when TMPDIR is unset. Expand PV in advance to avoid this problem. (From OE-Core rev: 9ce26c121f52d5194732be34f93e86128e1fdeaf) Signed-off-by: Richard Purdie

populate_sdk_ext: Use prebuilt uninative tarball

2017-12-11T21:47:28+00:00

For uninative to work, it relies on it being updated to new versions as newer glibcs are built. This means the uninative generated by the current build may not be as recent as the uninative that is being downloaded by uninative.bbclass. If this occurs, we can get symbol mismatch errors. Ultimately, the sstate and the uninative versions need to match so we should use the same tarball as uninative.bbclass is using, not the one we built. [YOCTO #12405] (From OE-Core rev: 1e6beee55d2bbe40de54c09f7a48fcb1240a426e) Signed-off-by: Richard Purdie