All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Chen Qi <Qi.Chen@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] sstatesig.py: fix logic in find_siginfo
Date: Wed, 04 Feb 2015 14:47:42 +0000	[thread overview]
Message-ID: <2453761.Od84ObYqIE@peggleto-mobl5.ger.corp.intel.com> (raw)
In-Reply-To: <a6dc870be391940e782eae4a86b0002e764a163a.1420530290.git.Qi.Chen@windriver.com>

Hi Qi,

On Tuesday 06 January 2015 15:47:38 Chen Qi wrote:
> For now, `bitbake-diffsig -t <recipe> <task>' doesn't work. This is
> caused by a small logic mistake in find_siginfo in sstatesig.py.
> 
> The logic should be 'and' instead of 'or', otherwise, we will have
> both siginfo and sigdata files in filedates which have the same checksum.
> e.g.
> /buildarea2/chenqi/sstate-cache/fc/sstate:sysstat:armv5te-poky-linux-gnueabi
> :10.2.1:r0:armv5te:3:fc861bf371c1b843b2843a3415eb5ff3_install.tgz.siginfo
> /buildarea2/chenqi/poky/build-systemd/tmp/stamps/armv5te-poky-linux-gnueabi
> /sysstat/10.2.1-r0.do_install.sigdata.fc861bf371c1b843b2843a3415eb5ff3
> 
> So `bitbake-diffsig -t sysstat install' will output nothing even we actually
> have changed something in do_install task.
> 
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  meta/lib/oe/sstatesig.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index af7617e..c6c85b9 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -234,7 +234,7 @@ def find_siginfo(pn, taskname, taskhashlist, d):
>              except OSError:
>                  continue
> 
> -    if not taskhashlist or (len(filedates) < 2 and not foundall):
> +    if not taskhashlist and (len(filedates) < 2 and not foundall):

I don't think this is the correct fix - if taskhashlist is specified but we 
don't have enough files found in the stamps directory, we still want to look at 
the sstate cache.

It is difficult to tell what's going on in this function, because this code is 
now being used for several different purposes:

 (1) the bitbake-diffsigs -t usage which is intended to be used to find out what 
changed that caused a task to re-execute the last time (so we want the two 
newest signatures).

 (2) the bitbake -S printdiff usage which is intended to be used simply to find 
out why sstate wasn't reused (so we want the two signatures with the smallest 
difference)

 (3) Additionally, as part of (1) and (2) the same function is also called 
with specific task hashes which changes its behaviour.

I think this code should probably be refactored so it makes more sense, but 
the minimal fix for the problem you discovered would be to make the bit that 
looks in sstate-cache ignore hashes it has already found.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


      parent reply	other threads:[~2015-02-04 14:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06  7:47 [PATCH 0/1] sstatesig.py: fix logic in find_siginfo Chen Qi
2015-01-06  7:47 ` [PATCH 1/1] " Chen Qi
2015-02-04  7:12   ` ChenQi
2015-02-04 14:47   ` Paul Eggleton [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=2453761.Od84ObYqIE@peggleto-mobl5.ger.corp.intel.com \
    --to=paul.eggleton@linux.intel.com \
    --cc=Qi.Chen@windriver.com \
    --cc=openembedded-core@lists.openembedded.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.