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

[Mike Looijmans <mike.looijmans@topic.nl>]

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?

And/Or how do tell the system that this package only depends on the SRCREV and 
MACHINE and nothing else? (I've already set INHIBIT_DEFAULT_DEPS = "1", is 
there more that I can do?)


--
Mike Looijmans - TOPIC Automation