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

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

uninative: Handle futex hangs caused by glibc version mismatches

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

We've been seeing hangs in smart on the autobuilders where it hangs in pthread futex calls. It appears to happen when some components are installed from sstate (which use the interpreter from uninative) and other components are built natively (and use the host's interpreter). Its primarily affecting software which uses shared memory with futexs in for locking purposes (which bdb does called from librpm from smart). This isn't an issue in pyro and rocko and beyond since they use recipe specific sysroots which included a change to always change to the uninative interpreter. We could backport those changes but they're fairly invasive changes to the sstate code. This patch is a more minimal change which ensures binaries are always using the uninative interpreter regardless of whether they're built locally or installed from sstate. This is only an issue if you're using an sstate mirror and hosts with a variety of different libc versions. It has only become an issue on recent libc versions where there was clearly some forwards compatibility issue introduced. (From OE-Core rev: 6b149a88cd33c65c7f306f785f4d24ee2909809c) Signed-off-by: Richard Purdie

sign_rpm.bbclass: force rpm serial signing

2017-10-10T16:27:39+00:00

Newer versions of gpg (at least 2.1.5 and 2.2.1) have issues when signing occurs in parallel so (unfortunately) the signing must be done serially. Once the upstream problem is fixed, this patch must be reverted, otherwise we loose all the intrinsic parallelism from bitbake. [YOCTO #12022] (From OE-Core rev: 3aced3783b808449cd50f12684c061151861a1a5) Signed-off-by: Leonardo Sandoval Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

kernel.bbclass: fix KERNEL_IMAGETYPE(S) for Image.gz

2017-10-10T16:27:39+00:00

KERNEL_IMAGETYPES lists all the kernel images that we want to build. in cb17b6c2a7 (kernel.bbclass: support kernel image type of vmlinux.gz), some logic was added to support vmlinux.gz which is not a target built by kernel makefiles (only vmlinux). It is clear that the goal of this logic is only to support vmlinux.gz and not others compressed format (such as Image.gz) which are valid target for kernel makefiles. For Image.gz we should rely on the kernel makefiles and not do the compression in kernel class. This patch updates the logic used to filter out non supported kernel target from KERNEL_IMAGETYPES, and make vmlinux.gz a 'special case', instead of *.gz. If more special cases are needed in the future, we could add them in a similar way. This patch should be a no-op for anyone using vmlinux or vmlinux.gz, and on top of that it is fixing the build for Image.gz which was not working until now. (From OE-Core rev: 241cc3083f873743ac3551237acc62e55abbbf05) Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie (cherry picked from commit cfc0c897656fe67e81a6a5dcd936dff785529f41) Signed-off-by: Nicolas Dechesne Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

image.bbclass: Sorted ctypes to avoid basehash error

2017-09-22T16:53:30+00:00

When selected multiple subimages a similar error could happend: Variable do_image_cpio[subimages] value changed \ from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot' To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'. This garantee that 'CONVERSION_CMD_xxx' are always written in tha same order and consequently 'do_image_cpio' have the same hash. (From OE-Core rev: 271f1a5f65b8685a1e3645026876251122ef3974) (From OE-Core rev: 7401ef4d816030bd6844e2e1f1910ac86cdcbe70) Signed-off-by: Gerson Fernando Budke Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel, license, sstate, rootfs.py: Remove deploy directory README

2017-08-29T22:43:50+00:00

It isn't clear that the README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt file in the deploy directory warrants the complexity it brings elsewhere. Let's just remove it entirely. In particular, if two do_image_complete tasks run in parallel they risk both trying to put their image into ${DEPLOY_DIR_IMAGE} at the same time. Both will contain a README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt file. In theory this should be safe because "cp -alf" will just cause one to overwrite the other. Unfortunately, coreutils cp also has a race[1] which means that if one copy creates the file at just the wrong point the other will fail with: cp: cannot create hard link ‘..../tmp-glibc/deploy/images/pantera/README_-_DO_NOT_DELETE_FILES_IN_THIS_D.txt’ to +‘..../tmp-glibc/work/rage_against-oe-linux-gnueabi/my-own-image/1.0-r0/deploy-my-own-image-complete/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt’: File exists [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25680 (From OE-Core rev: 71e9e88847d7000781642ea6187ebd8f40dfdcfe) (From OE-Core rev: 20c39fdbb25c1b1867709c5bfb3ae2baef249be9) Signed-off-by: Mike Crowe Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

insane.bbclass: fix override handling in RDEPENDS QA

2017-08-29T15:50:54+00:00

The package_qa_check_rdepends() in insane.bbclass has incorrectly replace its localdata OVERRIDES value with the package name. Fixing it by appending the package name to the existing OVERRIDES value. This resolves RDEPENDS QA error when setting PACKAGECONFIG using a pn- override at local.conf. Cherry picked from master 60d28dd72daee235150ab6605cbf953f1ea691df and modified to work with older bitbake where 2nd parameter in localdata.getVar was mandatory. [YOCTO #11374] (From OE-Core rev: 15fabf4d6507d2a3f9b98ad56e822eba35950662) Signed-off-by: Gan Yau Wai Signed-off-by: Ross Burton Signed-off-by: Martin Jansa Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

icecc.bbclass: prevent nativesdk builds depending on target specific KERNEL_CC

2017-08-29T15:50:54+00:00

* without this we cause nativesdk-linux-libc-headers to depend on target specific KERNEL_CC (through icecc_get_tool -> icecc_is_kernel -> KERNEL_CC -> HOST_CC_KERNEL_ARCH -> TARGET_CC_KERNEL_ARCH -> TUNE_FEATURES(thumb) as shown by bitbake-diffsigs: OE qemux86@ ~/build/oe-core $ ls /OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemu*/*sdk*/*/*do_configure.sigdata* /OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemuarm/x86_64-nativesdk-oesdk-linux/nativesdk-linux-libc-headers/4.10-r0.do_configure.sigdata.3a9a423878d56524e0ee8e42eba1804f /OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemux86/x86_64-nativesdk-oesdk-linux/nativesdk-linux-libc-headers/4.10-r0.do_configure.sigdata.401071dbaa88903ece37d35a47965ff2 OE qemux86@ ~/build/oe-core $ bitbake-diffsigs /OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemu*/*sdk*/*/*do_configure.sigdata* basehash changed from 39774238b66763c598153132e87a2c1a to aa2d66e770bf533e312536eb0a401c4c Variable TARGET_CC_KERNEL_ARCH value changed from '${@bb.utils.contains('TUNE_FEATURES', 'thumb', '-mno-thumb-interwork-marm', '', d)} TUNE_FEATURES{thumb} = Set' to '' (From OE-Core rev: 6aa5dcc472e6be971a4cef06aab5c1c125367eca) Signed-off-by: Martin Jansa Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

2017-08-29T15:50:54+00:00

When we have more than one CONVERSION_CMD being used, for example ext4.gz.sha256sum we will see errors about "metadata is not deterministic". This is because we do not have a stable order of intermediate files that will be removed in the generated shell command. We fix this by calling sorted() on the set of rm_tmp_images so that we will have a stable hash again. Cc: Patrick Ohly (From OE-Core rev: a786b59a42e6b49229e2e0633728fd7b268438a9) Signed-off-by: Tom Rini Signed-off-by: Richard Purdie (cherry picked from commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

image.bbclass: Correct chaining compression support

2017-08-29T15:50:54+00:00

When chaining of compression/conversion types was added, we had a new way to handle doing things like "ext4.bz2.sha256sum" or "ext2.gz.u-boot". However, because the U-Boot image class isn't included normally, it wasn't properly converted at the time. After the support was added the "clean" argument that the .u-boot code uses no longer functions. The fix for this inadvertently broke chaining compression/conversion. First, correct the u-boot conversion code. Fixes: 46bc438374de ("image.bbclass: do exact match for rootfs type") Cc: Zhenhua Luo Cc: Richard Purdie Cc: Patrick Ohly (From OE-Core rev: e1546856890a438b5ea3763af3cdc13db8e8f236) Signed-off-by: Tom Rini Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703) excluded lz4 and lzo chnages Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie