Re: Cache unihash ... doesn't match BB_UNIHASH ...

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

On Fri, 2020-02-07 at 14:43 +0000, chris.laplante@agilent.com wrote:
> Hi Richard,
> 
> > On Fri, 2020-02-07 at 08:16 +0000, Alex Kiernan wrote:
> > > Hi
> > > 
> > > We've got a couple of multiconfig builds with different
> > > configurations in one bitbake run (whether it needs to be like
> > > this a
> > > different question - I suspect we had something that worked and
> > > stopped there!)
> > > 
> > > However, for sometime we've been seeing errors like this on
> > > master
> > > (the recipes vary):
> > > 
> > > ERROR: mc:forensic:ca-certificates-20190110-r0
> > > do_deploy_source_date_epoch: Cache unihash
> > > 37d2546973a2b7c16fbcb1a8dd4939e4a1bba8c3d6d2dfb6e7204ca08d437ace
> > > doesn't match BB_UNIHASH
> > > 09baf78bd9316acdd308980c42ea4ed1eacea61bcc0d840c36293d1a5a22db69
> > 
> > This is an internal sanity test. It means the hash that it had in
> > the
> > task/worker context didn't match what the server thought the
> > unihash
> > should be. There have been changes in this area to try and fix
> > various
> > things, I'm wondering if we introduced a bug with multiconfig
> > handling.
> > 
> > There are some patches in master-next related to this area so it
> > would
> > be interesting to know if that made things better/worse.
> 
> Anecdotally, we are running Zeus for nightly builds with three
> multiconfigs. I cherry-picked your "bitbake: fix2" and "bitbake:
> fixup" patches and haven't seen any of the BB_UNIHASH errors since.
> Granted it's only been a week. But before that, hash equiv +
> multiconfig was unusable due to the BB_UNIHASH errors.

That is a really helpful data point, thanks. I should probably clean up
those bitbake patches and get them merged then, I couldn't decide if
they were right or not...

Cheers,

Richard