10275 2016-09-14 01:41:15 +0000 Missing i686 toolchain sdk for 2.2 M3 rc1 2016-09-26 14:25:15 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.2 x86 Multiple RESOLVED FIXED High normal 2.2 M4 1 yi.zhao joshuagloe infras.ab.watcher Infras.watcher jose.perez.carranza meta.mr.watcher meta.watcher pidge yi.zhao --- Regression (Used to work) No (bug/feature does not impact docs) oldest_to_newest 66121 0 yi.zhao 2016-09-14 01:41:15 +0000 There is no i686 toolchain sdk for 2.2 M3 rc1 in autobuilder public directory: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2_M3.rc1/toolchain/i686/ 66253 1 joshuagloe 2016-09-16 16:12:32 +0000 The logic to copy the sdk's looks sound, I wonder if recent buildset configuration changes have resulted in the i686 SDK's not being generated. 66256 2 joshuagloe 2016-09-16 16:20:23 +0000 Hmm, from the logs at https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/961/steps/Publishing%20Artifacts/logs/stdio cp: cannot stat ‘/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/deploy/sdk/poky-*i686-core-image*.sh’: No such file or directory I'm not at all certain how that's the case, however. The sdk was built without error if I look on the worker the path it's trying to cp from is correct. 66358 3 joshuagloe 2016-09-20 13:19:47 +0000 Checking the published output of recent autobuilder runs and the i686 toolchain isn't published for any recent master build. However recent krogoth builds *do* have the toolchain published. This leads me to suspect that a change to OE-Core is the root, rather than a change to the autobuilder… To verify this I tried to reproduce locally. I set SDKMACHINE="i686" and `bitbake core-image-sato && bitbake core-image-sato -c populate_sdk` and an i686 SDK is generated: [joshuagl@tethys poky]$ ls tmp/deploy/sdk/ poky-glibc-i686-core-image-sato-core2-64-toolchain-2.1+snapshot.host.manifest poky-glibc-i686-core-image-sato-core2-64-toolchain-2.1+snapshot.sh poky-glibc-i686-core-image-sato-core2-64-toolchain-2.1+snapshot.target.manifest if I then change SDKMACHINE to SDKMACHINE="x86_64" and `bitbake core-image-sato && bitbake core-image-sato -c populate_sdk` artefacts for the i686 SDK are no longer present, only x86_64 toolchain artefacts: [joshuagl@tethys poky]$ ls tmp/deploy/sdk/ poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.1+snapshot.host.manifest poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.1+snapshot.sh poky-glibc-x86_64-core-image-sato-core2-64-toolchain-2.1+snapshot.target.manifest 66359 4 joshuagloe 2016-09-20 15:00:26 +0000 Patch submitted: http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126707.html 66442 5 joshuagloe 2016-09-21 21:37:48 +0000 Patch merged to OE-Core & Poky master 66522 6 joshuagloe 2016-09-22 21:07:56 +0000 We're still seeing failures like this even with various stamps independence patches made to uninative-tarball and buildtools-tarball. 66546 7 joshuagloe 2016-09-23 13:26:19 +0000 The failure is a little different after recent changes, it's now the x86_64 artefacts which can't be found at PublishArtifacts. Interestingly the order of invocations matter. $ MACHINE=qemux86-64 SDKMACHINE=x86_64 bitbake uninative-tarball $ MACHINE=qemux86-64 SDKMACHINE=i686 bitbake uninative-tarball $ ls tmp/deploy/sdk/ i686-nativesdk-libc.host.manifest i686-nativesdk-libc.tar.bz2 i686-nativesdk-libc.target.manifest but: $ MACHINE=qemux86-64 SDKMACHINE=i686 bitbake uninative-tarball $ MACHINE=qemux86-64 SDKMACHINE=x86_64 bitbake uninative-tarball $ ls tmp/deploy/sdk/ i686-nativesdk-libc.host.manifest x86_64-nativesdk-libc.host.manifest i686-nativesdk-libc.tar.bz2 x86_64-nativesdk-libc.tar.bz2 i686-nativesdk-libc.target.manifest x86_64-nativesdk-libc.target.manifest 66555 8 joshuagloe 2016-09-23 16:00:22 +0000 The determinism is because the SSTATE_ARCH was being set to BUILD_ARCH. We can resolve this determinism issue by setting PACKAGE_ARCH to ${SDK_ARCH}_${SDK_OS} which results in the uninative tarballs for the prior SDK_ARCH being deleted no matter which order we build in. That still leaves the issue of the tarballs for SDKMACHINE other than the current setting being deleted from SDK_DEPLOY when SDKMACHINE changes… A bunch of WIP patches live, transiently, at: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=joshuagl/buildtools 66565 9 richard.purdie 2016-09-23 22:40:45 +0000 I think the second problem was specific to buildtools/uninative and the original toolchain issue should be resolved? We should try a full master build soon and check the artefacts that get published... 66579 10 joshuagloe 2016-09-26 14:25:15 +0000 This indeed appears to be fixed.