From: Steffen Sledz <sledz@dresearch-fe.de>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Cc: Lianhao Lu <lianhao.lu@intel.com>
Subject: hash generation/PR service problem with xuser-account and other packages
Date: Tue, 23 Sep 2014 14:07:47 +0200 [thread overview]
Message-ID: <54216293.4040907@dresearch-fe.de> (raw)
As i mentioned in another thread before we're investigating some problems related with package versions going backwards using a PR service.
Now i have some more information. But i'm not able to understand and fix the problem for myself.
Assume we have a clean workspace and i bitbake the xuser-account package with this command:
MACHINE="foo" bitbake xuser-account
This generates these packages (the 207 comes from our PR service).
tmp-eglibc/deploy/ipk/all/xuser-account-dbg_0.1-r0.207_all.ipk
tmp-eglibc/deploy/ipk/all/xuser-account-dev_0.1-r0.207_all.ipk
tmp-eglibc/deploy/ipk/all/xuser-account_0.1-r0.207_all.ipk
If i call the same bitbake command again, the same packages are generated. Fine!
Now i call:
MACHINE="bar" bitbake xuser-account
The generated packages now get a new number from the PR server (so they have a different hash i believe).
tmp-eglibc/deploy/ipk/all/xuser-account-dbg_0.1-r0.208_all.ipk
tmp-eglibc/deploy/ipk/all/xuser-account-dev_0.1-r0.208_all.ipk
tmp-eglibc/deploy/ipk/all/xuser-account_0.1-r0.208_all.ipk
But this package does not seem to be machine dependent!?
If the next build for machine foo is a clean build again (e.g. on our Jenkins continuous integration server which makes clean builds once a week) the PR service generated number wents back to 207 which results in:
"ERROR: QA Issue: Package version for package xuser-account went backwards which would break package feeds"
Can someone confirm this behaviour?
Is this a bug? I think so.
Can someone give some details what went wrong here? Also after studying <http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#checksums> i was not able to fully understand the background, not to speak of fixing something.
BTW: We see the same behaviour for the cpufreq-tweaks, linux-firmware, run-postinsts, and some of our own packages.
Thanx for any help,
Steffen
PS: We're working on the daisy branches using Angstrom with some more own layers.
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
next reply other threads:[~2014-09-23 12:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 12:07 Steffen Sledz [this message]
2014-09-23 13:21 ` hash generation/PR service problem with xuser-account and other packages Richard Purdie
2014-09-23 14:51 ` Steffen Sledz
2014-09-23 16:16 ` Richard Purdie
2014-09-24 13:22 ` Steffen Sledz
2014-09-24 13:34 ` Richard Purdie
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=54216293.4040907@dresearch-fe.de \
--to=sledz@dresearch-fe.de \
--cc=lianhao.lu@intel.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