Bug 10275

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.

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.

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

Patch submitted: 
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126707.html

Patch merged to OE-Core & Poky master

We're still seeing failures like this even with various stamps independence patches made to uninative-tarball and buildtools-tarball.

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

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

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...

This indeed appears to be fixed.