[yocto] systemd Version Going Backwards on Warrior

Ross Burton ross.burton at intel.com
Tue Oct 29 03:50:35 PDT 2019


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.joslyn at 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


More information about the yocto mailing list