Can we trust to sstate-cache?

Can we trust to sstate-cache?

[Marcin Juszkiewicz]

Today I bumped gcc-linaro from 4.7-r5 to 4.7-r6. First version was plain
2012.10 release while second one was tarball from bzr repository with
huge set of ICE related fixes for AArch64 architecture.

To do fast clean build I removed TMPDIR and started new build of
core-image-minimal target.

But then I noticed ugly thing:

0: eglibc-2.16-r18+svnr20393 do_populate_sysroot_setscene (pid 30106)
1: eglibc-2.16-r18+svnr20393 do_package_setscene (pid 30107)
3: eglibc-initial-2.16-r18+svnr20393 do_package_setscene (pid 28921)

Why eglibc was taken from sstate-cache instead of being rebuilt (like it
was with 'db')? This makes me sad as it shows that I cannot trust
sstate-cache so each new build will take hours instead of minutes.

Or maybe I am wrong?

Re: Can we trust to sstate-cache?

[McClintock Matthew-B29882]

On Thu, Oct 18, 2012 at 8:36 AM, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
> Today I bumped gcc-linaro from 4.7-r5 to 4.7-r6. First version was plain
> 2012.10 release while second one was tarball from bzr repository with
> huge set of ICE related fixes for AArch64 architecture.
>
> To do fast clean build I removed TMPDIR and started new build of
> core-image-minimal target.
>
> But then I noticed ugly thing:
>
> 0: eglibc-2.16-r18+svnr20393 do_populate_sysroot_setscene (pid 30106)
> 1: eglibc-2.16-r18+svnr20393 do_package_setscene (pid 30107)
> 3: eglibc-initial-2.16-r18+svnr20393 do_package_setscene (pid 28921)
>
> Why eglibc was taken from sstate-cache instead of being rebuilt (like it
> was with 'db')? This makes me sad as it shows that I cannot trust
> sstate-cache so each new build will take hours instead of minutes.
>
> Or maybe I am wrong?

Did the signatures for eglibc change after making your gcc-linaro
change? You can run bitbake -S before and after and see which ones
have new stamps. Then you can start using bitbake-diffsigs to back
track (or presumably if nothing changed add a proper dependency)

-M

Re: Can we trust to sstate-cache?

[Richard Purdie]

On Thu, 2012-10-18 at 15:36 +0200, Marcin Juszkiewicz wrote:
> Today I bumped gcc-linaro from 4.7-r5 to 4.7-r6. First version was plain
> 2012.10 release while second one was tarball from bzr repository with
> huge set of ICE related fixes for AArch64 architecture.
> 
> To do fast clean build I removed TMPDIR and started new build of
> core-image-minimal target.
> 
> But then I noticed ugly thing:
> 
> 0: eglibc-2.16-r18+svnr20393 do_populate_sysroot_setscene (pid 30106)
> 1: eglibc-2.16-r18+svnr20393 do_package_setscene (pid 30107)
> 3: eglibc-initial-2.16-r18+svnr20393 do_package_setscene (pid 28921)
> 
> Why eglibc was taken from sstate-cache instead of being rebuilt (like it
> was with 'db')? This makes me sad as it shows that I cannot trust
> sstate-cache so each new build will take hours instead of minutes.
> 
> Or maybe I am wrong?

In order to try and stop people going entirely insane and to illustrate
the kind of controls that are possible, we have some default sstate
policy in:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oe/sstatesig.py

which basically stops the sstate sigs at the native/cross to target
boundary.

So in your specific case, it wouldn't rebuild eglibc even though you
changed gcc and this was expected. You could customise sstatesig.py to
change that (remove the isCross() bits).

Cheers,

Richard