[yocto] What's this

[Gary Thomas]

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 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.
>>
>> 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
------------------------------------------------------------