Re: What's this

[Julien Gueytat <contact@jgueytat.fr>]

I got that taskhash mismatch too and much more often than once per 
million. ;) I'm quite happy that you're discussing it here as I did not 
know what it was.

Re-running the task a second time in a row makes the warning disappearing.

Regards,

Le 08/06/2016 11:18, Gary Thomas a écrit :
> 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.burton@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!
>