Bug 8692

Summary: unnecessary rebuilds (gcc-cross-i586)
Product: [Build System, Metadata & Runtime] BitBake Reporter: Patrick Ohly <patrick.ohly>
Component: bitbakeAssignee: Richard Purdie <richard.purdie>
Status: VERIFIED FIXED QA Contact: Bogdan Alexandru Voiculescu <bogdanx.a.voiculescu>
Severity: normal    
Priority: Medium+ CC: bogdanx.a.voiculescu, poky.bs.watcher, poky.watcher
Version: 2.1   
Target Milestone: 2.1 M1   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Patrick Ohly 2015-11-13 16:35:48 UTC 
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.
Comment 1 Patrick Ohly 2015-11-13 16:38:40 UTC 
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.
Comment 2 Richard Purdie 2015-11-16 09:30:12 UTC 
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.
Comment 4 Bogdan Alexandru Voiculescu 2016-01-06 13:13:18 UTC 
Not reproducible using Richard steps on 2cd061a29a94fdcdfec86732e6bcbb71c12c4afc - master.