Created attachment 3438 [details] sigdata for qemux86-64 & qemuarm uninative-tarball:do_populate_sdk When debugging signature related issues with uninative-tarball and buildtools-tarball I observed various tasks for nativesdk recipes being rerun (packagedata, populate_sysroot, write_rpm) resulting in the need to re-run the populate_sdk task due to changed signatures. Reproduction steps: $ MACHINE=qemux86-64 bitbake uninative-tarball $ MACHINE=qemuarm bitbake uninative-tarball $ MACHINE=qemumips64 bitbake uninative-tarball One the initial uninative-tarball build has completed we wouldn't expect any work to be done for the 2nd and 3rd bitbake run, however on the 3rd (qemumips64) we observe nativesdk tasks being run and uninative-tarball:do_populate_sdk being run again. Attached are sigdata files for do_populate_sdk: For qemux86-64 and qemuarm: 1.0-r0.do_populate_sdk.sigdata.f55cc46a5dbc96434e9070615fd01c37 For qemumips64: 1.0-r0.do_populate_sdk.sigdata.c00b68f90b4f6e7997ec6d11c62cd2bf
Created attachment 3439 [details] sigdata for qemumips64 uninative-tarball:do_populate_sdk
This is related to failures we're seeing on the buildtools autobuilder and needs fixing quickly to enable uninative and buildtools tarballs to be built.
We should add a selftest for this case so that we detect the breakage in future.
This is specific to mips machines which include a variable MIPSPKGSFX_ABI in their values for the target TUNE_PKGARCH. bitbake-diffsigs tmp/stamps/x86_64-nativesdk-pokysdk-linux/nativesdk-glibc-initial/2.24-r0.do_install.sigdata.0a4c775cc30ecd9e0484741d12829713 tmp/stamps/x86_64-nativesdk-pokysdk-linux/nativesdk-glibc-initial/2.24-r0.do_install.sigdata.0e50e80f6d1c3ab02c4c61de99b576e5 basehash changed from 18d262a7dd0189dfa8df63a7915417db to 5ef4c25ef31eece9f00f5a670a092182 Variable MIPSPKGSFX_ABI value changed from 'None' to '${@bb.utils.contains('TUNE_FEATURES', 'n32', '-n32', '', d)} TUNE_FEATURES{n32} = Unset' I think we need to set the TUNE_PKGARCH for nativesdk recipes to SDK_ARCH, as is already done for crosssdk recipes, but this alone isn't enough to prevent the signature of nativesdk-glibc-initial:do_install from changing, the same bitbake-diffsigs output is generated with `TUNE_PKGARCH = "${SDK_ARCH}"` added to nativesdk.bbclass
The only way I've been able to prevent MIPSPKGSFX_ABI from influencing do_install of nativesdk recipes is to add it to BB_HASHBASE_WHITELIST. I've yet to determine how to test whether this has any adverse effects.
Thanks to some signature analysis tips from Richard we've discovered that oe_multilib_header depends on the MIPSPKGSFX_ABI variable which changes when the target is mips. multilib_header.bbclass is an empty function for -native variants, because "Dependencies on arch variables like MIPSPKGSFX_ABI can be problematic." We clearly need a similar empty function for nativesdk too.
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/127105.html
Patch merged to OE-Core & Poky: http://git.openembedded.org/openembedded-core/commit/?id=f1c7b4f16dc9a7e5155108641fed8b3d98c931f3 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=debb7bb86fff5e26505bedf6bc7baa05b8a545e7