[OE-core] Hash Equivalency - What this means for developer productivity

Mikko.Rapeli at bmw.de Mikko.Rapeli at bmw.de
Mon Aug 5 07:21:21 UTC 2019


Hi,

On Fri, Aug 02, 2019 at 05:17:21PM +0100, Richard Purdie wrote:
> On Fri, 2019-08-02 at 16:53 +0100, Richard Purdie wrote:
> > With the patches in master-next and this configuration in local.conf:
> > 
> > BB_HASHSERVE = "localhost:0"
> > BB_SIGNATURE_HANDLER = "OEEquivHash"
> > 
> > $ bitbake core-image-sato
> > $ bitbake m4-native -c install -f
> > $ bitbake core-image-sato
> > 
> > will result in do_populate_sysroot of m4-native running, it will see
> > the output matches the previous build and it will then skip to the
> > rootfs generation pulling all the other pieces from sstate.
> > 
> > Note that for this to work, m4-native has to have previously built
> > with the hashserv running, otherwise it has nothing to compare its
> > output to.
> > 
> > I think this should be a "big deal" for many developers, reducing
> > unneeded rebuilds and hence speeding up development.

Awesome, thanks for pushing this!

> I should have mentioned, this code relies on reproducibile builds as
> its comparing the binary output. The more reproducibile builds are, the
> more likely sstate reuse will happen.
> 
> This is one reason reproducibile builds are important!

What else do users need to enable to get more reproducible builds, or
are poky defaults enough?

Are there some tools available to debug build reproducibility issues e.g.
when task hashes suddenly changed?

Cheers,

-Mikko


More information about the Openembedded-core mailing list