[yocto] Debugging sstate-cache

[Martin Jansa]

I'm using oe-core/scripts/sstate-diff-machines.sh script (which calls
bitbake -S) to generate "snapshots" of sstate signatures for interesting
builds (in our case daily official builds) and then every time I notice
something unexpectedly being rebuilt, I can use the same script to create
snapshot of my local build and then compare these 2.

Once it helps you find which recipes were changed, use bitbake-diffsigs to
compare sigdata files from the "snapshots" to see what change in metadata
caused the difference, often it's change in some other dependency, so you
need to traverse the dependency tree a bit until you find the real root
cause of the difference.

On Tue, Dec 19, 2017 at 2:25 PM, Alan Martinovic <alan.martinovic at senic.com>
wrote:

> Hi,
> we have a build server set that is used by multiple
> people all working on the same yocto project each
> having a clone in their working dir.
>
> The core packages (those coming from meta-openembedded)
>  are same of every image we build.
>
> We all share a sstate-cache and a downloads cache.
> The download cache works as expected, I only notice
> new things being fetched when there were actual changes in
> the recipes.
>
> However, all other steps (do_configure, do_compile, do_package)
> seem to be executed arbitrarily without a specific order or cause.
> Lot of things are reused from the sstate-cache, some get redone
> on random, and a few are always build from the ground.
>
> I have synced with everyone and confirmed that we're not stepping
> on each others toes by cleaning package caches.
>
> Is there a way to see on what grounds does bitbake chooses
> to repeat the steps?
>
> Be Well,
> Alan
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171219/a7d049c8/attachment.html>