On 2016-06-08 11:08, Mike Looijmans wrote:
On 08-06-16 00:20, 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.bur...@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.
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?
I have a build machine that every so often runs into "basehash mismatch"
problems (but never when you want it to, such
as now), so getting some information on what might cause it would be
"priceless". I'd happily let the machine run for 10
days straight if at the end I get a message that I can work with.
Which implies that any performance hit is acceptable, if there's a switch to
enable and disable that extra diagnostic.
Oh dear, just what we need, yet another switch...
I wonder if it could be something as simple as an NTP time update
which happens periodically on my build machine? Since I've only
ever seen this message _once_ after literally thousands of builds,
it is a rare bird indeed!
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
