All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Christopher Larson <clarson@kergoth.com>
Cc: bitbake-devel <bitbake-devel@lists.openembedded.org>
Subject: Re: [PATCH] siggen: Ensure taskhash mismatches don't override existing data
Date: Wed, 02 Nov 2016 16:43:28 +0000	[thread overview]
Message-ID: <1478105008.23123.66.camel@linuxfoundation.org> (raw)
In-Reply-To: <CABcZANkNPT+wqHMkUE3z0N_0R=QWYrfPDzU1R+qw31N_WjHdnw@mail.gmail.com>

On Wed, 2016-11-02 at 08:46 -0700, Christopher Larson wrote:
> 
> On Wed, Nov 2, 2016 at 8:07 AM, Richard Purdie <richard.purdie@linuxf
> oundation.org> wrote:
> > We recalculate the taskhash to ensure the version we have matches
> > what we think it should be. When we write out a sigdata file, use
> > the calculated value so that we don't overwrite any existing file.
> > This leaves any original taskhash sigdata file intact to allow a
> > debugging comparison.
> > 
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > 
> Thanks, I ran into this trying to diagnose a mismatch with our
> automated builds a while back. These patches should make those a lot
> easier to debug.

Otavio gave me a reproducible test case which was nearly impossible to
debug with the codebase the way it was. I've been beating it up until
it actually gave good debug output which could be used to debug the
problem. Hopefully it works better than before, which wouldn't take
much. Still not 100% happy with it but it has to be better than it
was...

I'd love to find a way to always write out the sigbasedata but it uses
far too much time and slows down parsing too much :(.

Cheers,

Richard


      reply	other threads:[~2016-11-02 16:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 15:07 [PATCH] siggen: Ensure taskhash mismatches don't override existing data Richard Purdie
2016-11-02 15:46 ` Christopher Larson
2016-11-02 16:43   ` Richard Purdie [this message]

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=1478105008.23123.66.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=clarson@kergoth.com \
    /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.