Re: Figuring out why sstate-cache is no longer used for a package

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Tue, Dec 10, 2013 at 07:44:49AM +0100, Mike Looijmans wrote:
> I've been struggling with this for a few days.
> 
> We have a build server that build various images overnight. One of the 
> packages in that image is "fpga-image", which takes more than an hour to build.
> 
> We have been sharing the the build server's sstate-cache via HTTP and this has 
> worked excellently up until yesterday.
> 
> The current situation is that a client will grab everything from the 
> buildserver's HTTP sstate-cache, potentially finishing a build from scratch in 
> about five minutes. However, for some reason, the fpga-image does not fall 
> into this category, and eache machine insists on re-building it from scratch. 
> I've been trying to debug this, but the sstate-cache is on another machine. I 
> tried copying part of the build server's sstate-cache onto my machine, but 
> that only results in "bitbake-diffsigs -t fpga-image .." yielding "ERROR: No 
> sigdata files found matching fpga-image .." so that apparently is a dead end.
> 
> How can I determine what is causing the system to think that it needs to 
> rebuild this package?

I use this script:
openembedded-core/scripts/sstate-diff-machines.sh

to create "backup" of sstate signatures and when some next build
unexpectedly doesn't reuse some sstate packages I use the script again
and compare new and old signatures to see why.

As bonus each build which populates out SSTATE_MIRROR also creates tarball
with these signatures, so I can easily download one tarball and compare
what and why won't be reused from sstate.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]