- Debugging sstate-cache
Re: Debugging sstate-cache
toggle quoted messageShow quoted text
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@...>
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
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?
yocto mailing list
Join email@example.com to automatically receive all group messages.