Re: sstate breakage with multimachine

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2011-05-17 at 09:14 +0200, Martin Jansa wrote:
> there is also another source of many sstate rebuilds. I've discuessed
> this with RP on IRC already and I'll fill bugs as recommended, sharing
> here just because you have opened this topic.
> 
> If you have package with
> PACKAGE_ARCH = "all"
> then the resulting package is created by run.* scripts with different
> pathsi, *FLAGS etc even when it produces same output (ie some theme).
> 
> So all packages with such PACKAGE_ARCH are rebuilt after machine switch
> (if the machine is ie different arch like om-gta02/nokia900).
> Sstate is reused when you go back to om-gta02 after building nokia900,
> so you have ie populate_sysroot only with as many checksums as you're
> building different archs.
> 
> RP said, that right fix is to introduce something like all.bbclass which
> excludes all variables which shouldn't change the output of such package
> and then checksums will be the same.

I think rather then exclude them, we should zero them out or unexport
them and stop them being present in the task environment. We should file
a bug about this problem in the Yocto bugzilla.

> Here is example with gtk-theme-e17lookalike http://paste.pocoo.org/show/388032/
> 
> And as side-note there is small problem when someone tries to hunt such
> checksum changes, because some tasks which are not directly using sstate
> like do_install do not save their run.* scripts in better place then
> ${WORKDIR}/temp 
> 
> So if your bitbake-diffsigs shows something like this:
> 
> Hash for dependent task
> /OE/shr-core/meta-shr/recipes-shr/shr/gtk-theme-e17lookalike_git.bb.do_install
> changed from 8a0de44f3f238f645eab9509172c2d8b to
> 9d6bf027c5f435498017a652088d7327
> 
> You need to find right ${WORKDIR} for that version, and there in temp
> directory right combination of run.do_install._pid_ scripts, but you
> don't know which _pid_ belongs to which sstate checksum and I guess pid
> cannot be stored in .siginfo because it would be always different.

Just for reference, if you want to generate two trees of all tasks
sigdata to compare you can do something like:

MACHINE=qemuarm bitbake console-image -S
MACHINE=qemux86 bitbake console-image -S

and then look at the tmpdir/stamps/*/* files using bitbake-diffsigs on
the files there to try and do this comparison more directly.

I'm open to other ideas to improving the way we write out the sigdata
pieces to make this kind of analysis easier...

Cheers,

Richard