On 29/10/2019 04:41, Robert Joslyn wrote:
On Mon, 2019-10-28 at 19:06 +0000, Ross Burton wrote:
On 28/10/2019 16:25, robert.jos...@redrectangle.org wrote:
I'm using buildhistory in one of my builds that creates a package
feed, and a recent update to systemd on warrior triggered version-
going-backwards errors:
ERROR: systemd-conf-241+AUTOINC+511646b8ac-r0 do_packagedata: QA
Issue: Package version for package systemd-conf-src went backwards
which would break package feeds from (0:241+0+c1f8ff8d0d-r0 to
0:241+0+511646b8ac-r0) [version-going-backwards]
Should PE have been updated at the same time due to the hash making
the version number go backwards? I can send a patch if that's all
that's missing. Or is a PR server enough to prevent this? My debug
builds do not use a PR server, but my production builds do use a PR
server.
If you're using feeds, you need to use a PR server. This is *exactly*
what they are for.
>
The part I wasn't sure about was if the PR server helped in the case where
PV went backwards. I know it works when PV stays the same but the package
was rebuilt. But if it keeps the versions going forward no matter how PV
changes, then I should be good. I should probably setup a separate PR
server on my debug builds to avoid this kind of error.
If the PV actually goes backwards then the PR service isn't useful, as
PV sorts before PR.
However in this case the problem is that SRCREV should have a
incrementing counter (the +0+ should be +1+ in the rebuild) which I
believe comes from the PR service. I may be wrong...
Ross
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
