[yocto] What's this

[Paul Eggleton]

On Tue, 07 Jun 2016 23:20:26 Richard Purdie wrote:
> On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:
> > On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:
> > > On 7 June 2016 at 17:02, Burton, Ross <ross.burton at intel.com>
> > > wrote:
> > > > It means the hash calculated my the bitbake master was different
> > > > to the hash calculated when the worker started up.  This usually means
> > > > that you're using something like ${TIME} in the recipe but not marking 
> > > > it appropriatly so the cache ignores it.  Do you have a base-files
> > > > bbappend that writes a timestamp?
> > > 
> > > The always wise Joshua reminds me that if your DISTRO_VERSION
> > > contains ${DATETIME} then this happens.  If you're doing this then
> > > you'll want to set [vardepsexclude] on DISTRO_VERSION to stop the
> > > DATETIME from getting into the cache (or not put the current date/time
> > > into the distro version).
> > 
> > I think we need to handle this situation better - if it's really
> > worth producing an error about then it's worth producing an error message
> > that people can actually understand, particularly as it's recently added
> > validation.
> 
> It was silently running into problems due to this all along but not
> reporting it. Its now reporting it which is better than silently things
> behaving strangely.

What are the actual consequences in a situation like this where we have 
something like ${DATETIME} in another variable referenced by the task?

I haven't looked at all of the code involved (and that's probably the root of 
my problem) but I don't quite understand how this is coming about. DATE and 
TIME are supposed to be determined at the start of the build and explicitly 
passed to the worker, so they don't change during the build. What am I 
missing?
 
> Its very hard for bitbake to know why the hashes differ, it only knows
> the values afterwards and hence that they've changed, the information
> about how that hash was constructed is not present in any of bitbake's
> caches. That implies to have better messages we need to write out more
> data.
> 
> I did add a patch to make bitbake write out data to allow
> reconstruction of basehash (which is part of taskhash). Sadly the
> parsing performance was diabolical (10 times slower). I think that
> could perhaps be improved if the files don't require an atomic move
> during creation but I haven't had time to look further at it.
> 
> So whilst I do agree, what is the price people are willing to pay to
> have those better messages?

Clearly a 10x slowdown is unacceptable, hopefully we can find another way of 
dealing with this. I guess if we're able to do nothing else a brief 
explanation of what to look for (i.e. variables that might change with time) 
in the error message would be helpful, but I hope we can do better than that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre