Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: chris.laplante@agilent.com,
	"Openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Strange behavior in sstate-diff-machines.sh
Date: Mon, 03 Feb 2025 22:10:31 +0000	[thread overview]
Message-ID: <9c3a268725aa40db3cab0578208017733bd24f57.camel@linuxfoundation.org> (raw)
In-Reply-To: <DM8PR12MB543086C50EF71EBADF83E63D8BF52@DM8PR12MB5430.namprd12.prod.outlook.com>

On Mon, 2025-02-03 at 21:34 +0000, Chris Laplante via lists.openembedded.org wrote:
> We are on Scarthgap, and I am seeing an issue with sstate-diff-
> machines.sh wherein the script claims to see task signature
> differences, but then doesn't report any. For example, I get:
> 
> ERROR: base-files different signature for task
> do_package_write_rpm.sigdata between my-machine-1 and my-machine-2
> NOTE: Starting bitbake server...
> 
> There should be output from bitbake-diffsigs after the 'Note:' lines.
> 
> I did some poking around in tmp/sstate-diff. The 'list.M' file for
> my-machine-1 has:
> 
> MACHINEpoky-linux/base-
> files/3.0.14.do_package_write_rpm.sigdata.af0c3fb3b1b8494fcd7a31ba513
> 495df384fdf25a8eced584e7c71d722b26683
> 
> But the list.M for my-machine-2 has:
> 
> my-machine-1-poky-linux/base-
> files/3.0.14.do_package_write_rpm.sigdata.af0c3fb3b1b8494fcd7a31ba513
> 495df384fdf25a8eced584e7c71d722b26683 
> 
> So interestingly, the hash is the same
> (af0c3fb3b1b8494fcd7a31ba513495df384fdf25a8eced584e7c71d722b26683),
> but in the case of 'base-files' for my-machine-2, it ended up using
> the sstate (I guess?) from my-machine-1. Maybe this has something to
> do with hash equiv? (I have BB_HASHSERVE set to 'auto')
> 
> Can anyone please help explain?

I've never liked that script and personally, I've always wanted to make
bitbake's owm signature "diff" as helpful as we can. There are ton of
different things that conspire against us in doing that and whilst
we've improved, it still isn't ideal.

I'd note that the script predates hash equivalence and that can be a
big factor in things things like this. We've struggled to reconcile
some of the tools with changes like hash equivalence :(

So yes, I can imagine do_package matching between the two machines,
then hashequiv would reuse the later tasks like do_package_write_rpm
from sstate.

Cheers,

Richard





  reply	other threads:[~2025-02-03 22:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03 21:34 Strange behavior in sstate-diff-machines.sh chris.laplante
2025-02-03 22:10 ` Richard Purdie [this message]
2025-02-03 22:19   ` [OE-core] " chris.laplante
2025-02-03 22:29     ` Richard Purdie
2025-02-04 11:25     ` Alexander Kanavin
2025-02-04 14:13       ` chris.laplante

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=9c3a268725aa40db3cab0578208017733bd24f57.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=chris.laplante@agilent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox