From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Paul Eggleton <paul.eggleton@linux.intel.com>, yocto@yoctoproject.org
Cc: Gary Thomas <gary@mlbassoc.com>
Subject: Re: What's this
Date: Tue, 07 Jun 2016 23:20:26 +0100 [thread overview]
Message-ID: <1465338026.13979.88.camel@linuxfoundation.org> (raw)
In-Reply-To: <2350549.ml0Nc00s8v@peggleto-mobl.ger.corp.intel.com>
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?
Cheers,
Richard
next prev parent reply other threads:[~2016-06-07 22:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-05 16:44 What's this Gary Thomas
2016-06-07 16:02 ` Burton, Ross
2016-06-07 16:20 ` Burton, Ross
2016-06-07 16:58 ` Gary Thomas
2016-06-07 21:29 ` Joshua G Lock
2016-06-07 21:24 ` Paul Eggleton
2016-06-07 22:20 ` Richard Purdie [this message]
2016-06-08 8:59 ` Paul Eggleton
2016-06-08 11:30 ` Richard Purdie
2016-06-08 9:08 ` Mike Looijmans
2016-06-08 9:18 ` Gary Thomas
2016-06-08 11:59 ` Julien Gueytat
2016-06-07 16:24 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1465338026.13979.88.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=gary@mlbassoc.com \
--cc=paul.eggleton@linux.intel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.