Hi Alex, hi Michael,
On 25.10.24 18:20, Alexander Kanavin wrote:
On Fri, 25 Oct 2024 at 15:59, Philip Lorenz <philip.lor...@bmw.de> wrote:
Wouldn't we then see version-going-backwards errors in the validation
builds (as the "mainline" builds which contribute to the shared
buildhistory will have higher PRs from PRserv)? We'd like to maximize
our cache reuse so in a perfect world even the write_package_* tasks
could be reused between the builds (which I believe we could do if we
combine hash equivalence with a non-cached packagedata task).
Right. Then I don't know.
Like I said, I don't know much about PR side effects. When I was
working at a certain car company (that likes to put rotating logos on
buildings), we never enabled PR server, as there was no real need for
it, or for package management on target images for that matter.
Perhaps Michael can chime in, he's the real expert.
I'd like to come back to this as disabling PRserv has turned up another
issue for us (at least when combined with the version-going-backwards QA
check). Recipe updates which only touch SRCREV now (such as [1]) now
lead to `version-going-backwards` issues being raised as without PRserv
AUTOINC always gets replaced by a static value of 0:
ERROR: nativesdk-glibc-2.39+git-r0 do_packagedata: QA Issue: Package
version for package nativesdk-glibc-src went backwards which would break
package feeds (from 0:2.39+git0+e8f5217097-r0 to
0:2.39+git0+84f6bfce2c-r0) [version-going-backwards]
After digging around I found that this is expected behaviour ([2])
although now I'm wondering whether `version-going-backwards` without
PRserv is something that is supported at all. I see several ways to work
around this but I am interested in other opinions whether these are
worthwhile and would be accepted upstream:
* Add INSANE_SKIP for recipes where the issue is raised (notably
version-going-backwards is currently not handled by INSANE_SKIP as the
QA check happens in buildhistory.bbclass rather than insane.bbclass and
INSANE_SKIP is never checked there)
* Maintain a manual allocation of AUTOINC assignments for recipes
triggering the QA check. The general idea is that instead of hardcoding
AUTOINC to 0 when PRserv isn't available another value can be used.
There is some overlap with PRSERV_LOCKDOWN although adaptations would
certainly be required as we'd only want to provide a static PR for some
recipes (and based on the code I am not sure whether PRSERV_LOCKDOWN
currently handles the AUTOINC in PKGV at all).
I am honestly not too fond of either of these but
version-going-backwards is a QA check which in our context rightfully
triggers every once in a while and as such is something we'd like to
keep around.
Thanks,
Philip
[1]
https://git.yoctoproject.org/poky/commit/meta/recipes-core/glibc?h=scarthgap&id=2186202022d16e73f76596bb85c07223d63e61e3
[2] https://www.mail-archive.com/yocto@yoctoproject.org/msg46225.html
--
Philip Lorenz
BMW Car IT GmbH, Software-Plattform, -Integration Connected Company,
Lise-Meitner-Straße 14, 89081 Ulm
-------------------------------------------------------------------------
BMW Car IT GmbH
Management: Chris Brandt, Michael Böttrich, Christian Salzmann
Domicile and Court of Registry: München HRB 134810
-------------------------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#64482): https://lists.yoctoproject.org/g/yocto/message/64482
Mute This Topic: https://lists.yoctoproject.org/mt/109194097/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
