From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Daniel Squires <dan@engineeredarts.co.uk>, poky@lists.yoctoproject.org
Subject: Re: [poky] Unexpected package version going backwards warnings.
Date: Fri, 09 Dec 2022 16:11:46 +0000 [thread overview]
Message-ID: <d73115cd38d439c919ab6fa9448fcdce29545809.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAC+ji7EOT6D35madOZvx6tS8Nj43Tiq-cg06WYO8xue8MnBhiQ@mail.gmail.com>
On Fri, 2022-12-09 at 16:02 +0000, Daniel Squires wrote:
> Hi!
> We're using kirkstone, though not the very latest at present.
> Every now and then a a number of packages will unexpectedly give the
> error re package versions going backwards and teh version may have
> done something like go from git5-######-r0.1 to git3-#######-r0.0.
> We always see this if we've been using devtool for a given recipe and
> then do a devtool reset, it complains about going back from git999 to
> e.g. git5 but this makes sense and we just run the build again and
> forget about it. However sometimes this just seems to happen randomly
> for a given recipe when it picks up a new commit from our repos and
> the git autoinc number will have gone back a few.
> Does anybody know why and if it is a bug or an be fixed?
We probably need to know a bit more about how you're building things.
Do you have a pool of workers building against a common sstate?
Are you using hash equivalence? Are you using a PR server?
I ask the questions as the answer is probably somewhere in the way data
is being shared/reused between builds.
If you're not using package management on device to upgrade them, it
probably isn't a big issue but it is worth understanding the sstate
reuse in this context.
Cheers,
Richard
next prev parent reply other threads:[~2022-12-09 16:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 16:02 Unexpected package version going backwards warnings Daniel Squires
2022-12-09 16:11 ` Richard Purdie [this message]
2022-12-13 9:37 ` [poky] " Daniel Squires
2022-12-09 16:13 ` Alexander Kanavin
2022-12-09 16:19 ` Richard Purdie
2022-12-09 17:37 ` Peter Kjellerstedt
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=d73115cd38d439c919ab6fa9448fcdce29545809.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=dan@engineeredarts.co.uk \
--cc=poky@lists.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.