1. Messages
  2. Debugging sstate-cache

Re: 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@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto
Join yocto@lists.yoctoproject.org to automatically receive all group messages.