I recently set up TravisCI testing of meta-intel-iot-security against OE-core and bitbake master: https://github.com/01org/meta-intel-iot-security/commit/97432bbfe65a73fd7735112e56f1969c09389177 In that setup, "bitbake m4" is followed by "bitbake linux-yocto". During the second bitbake invocation, gcc-cross-i586 gets built again, although the only change is the removal of the download directory. Here's a log: https://travis-ci.org/01org/meta-intel-iot-security/builds/90955509 > 2652 NOTE: recipe gcc-cross-i586-5.2.0-r0: task do_compile: Succeeded > ... > 3004 NOTE: recipe gcc-cross-i586-5.2.0-r0: task do_rm_work: Started > ... > 3475 NOTE: recipe gcc-cross-i586-5.2.0-r0: task do_configure: Started To reproduce using the exact same setup (untested): * log into Github, fork meta-intel-iot-security * log into https://travis-ci.org/ using the Github account * find your forked meta-intel-iot-security, enable CI for it * check out the "travis" branch from the forked meta-intel-iot-security * modify something and commit + push To remove the sstate cache, use the "Settings" button in the TravisCI web page. It should also be possible to set up something similar for plain OE-core + bitbake by adding a similar "travis" branch with an adapted .travis.yml and pushing to Github.
This happened to me both with and without initial sstate. Without sstate (= empty cache) it should be a bit more predictable, but also slower to hit, because then "bitbake m4" takes a while.
Turns out to be much simpler to demonstrate: rm tmp/stamps/x86_64-linux/gcc-cross-i586/5.2.0-r0.do_configure.sigdata.* bitbake m4 -S none ls tmp/stamps/x86_64-linux/gcc-cross-i586/5.2.0-r0.do_configure.sigdata.* bitbake virtual/kernel -S none ls tmp/stamps/x86_64-linux/gcc-cross-i586/5.2.0-r0.do_configure.sigdata.* and note that two different checksums appear. This should not happen.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=2cb1aee04840e9ed7dc4a4952e8d883eda1feb90
Not reproducible using Richard steps on 2cd061a29a94fdcdfec86732e6bcbb71c12c4afc - master.