examine SSTATE_MIRRORS differences

examine SSTATE_MIRRORS differences

[Bart Jansseune]

Hello,

I'm trying to setup a SSTATE_MIRROR using a fast build server so that a slow virtual machine doesn't have to rebuild everything.
Both are Ubuntu 14.04 64 bit machines and use the same poky release (daisy).
What I notice is that for some components the cache is used eg perl-native but not for others.
I understand that once there is a delta between both machines, all dependent packages also mismatch and need to be rebuilt.

How do you figure out where things start diverging?

Are there requirements on the tools of the build to ensure that SSTATE_MIRROR can be used effectively? E.g. the gcc version on both machines might need to be the same.

Regards, 
Bart

Bart Jansseune

Re: examine SSTATE_MIRRORS differences

[Martin Jansa]

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

On Fri, Aug 01, 2014 at 01:46:40PM +0200, Bart Jansseune wrote:
> Hello,
> 
> I'm trying to setup a SSTATE_MIRROR using a fast build server so that a slow virtual machine doesn't have to rebuild everything.
> Both are Ubuntu 14.04 64 bit machines and use the same poky release (daisy).
> What I notice is that for some components the cache is used eg perl-native but not for others.
> I understand that once there is a delta between both machines, all dependent packages also mismatch and need to be rebuilt.
> 
> How do you figure out where things start diverging?
> 
> Are there requirements on the tools of the build to ensure that SSTATE_MIRROR can be used effectively? E.g. the gcc version on both machines might need to be the same.

Run openembedded-core/scripts/sstate-diff-machines.sh on both machines
and compare list.M files in generated folders.

That will give you pointers to interesting .sigdata files, which you can
compare with bitbake-diffsigs - which will reveal more .sigdata files
and so on until you find root cause.

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

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

Re: examine SSTATE_MIRRORS differences

[Bart Jansseune]

I was having so much differences that comparing the list.M files is still not really feasible to figure out where the diverging starts. Luckily I found when comparing siginfo files that the delta in RDEPENDS was package_qa_check_rdepends.
This made me realize that this cannot be cause by a MACHINE config or the build machine property but instead by the poky revision used. And indeed after a git pull at both sides the SSTATES were in sync.

Nonetheless it could be a useful feature to have an option to the bitbake command to stop when it can't use the SSTATE_MIRROR and would need to fetch/build/install  locally.

Regards, 
Bart

Bart Jansseune

-----Original Message-----
From: Martin Jansa [mailto:martin.jansa@gmail.com] 
Sent: vrijdag 1 augustus 2014 14:59
To: Bart Jansseune
Cc: poky@yoctoproject.org
Subject: Re: [poky] examine SSTATE_MIRRORS differences

On Fri, Aug 01, 2014 at 01:46:40PM +0200, Bart Jansseune wrote:
> Hello,
> 
> I'm trying to setup a SSTATE_MIRROR using a fast build server so that a slow virtual machine doesn't have to rebuild everything.
> Both are Ubuntu 14.04 64 bit machines and use the same poky release (daisy).
> What I notice is that for some components the cache is used eg perl-native but not for others.
> I understand that once there is a delta between both machines, all dependent packages also mismatch and need to be rebuilt.
> 
> How do you figure out where things start diverging?
> 
> Are there requirements on the tools of the build to ensure that SSTATE_MIRROR can be used effectively? E.g. the gcc version on both machines might need to be the same.

Run openembedded-core/scripts/sstate-diff-machines.sh on both machines and compare list.M files in generated folders.

That will give you pointers to interesting .sigdata files, which you can compare with bitbake-diffsigs - which will reveal more .sigdata files and so on until you find root cause.

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