[yocto] systemd Version Going Backwards on Warrior

akuster akuster at mvista.com
Tue Oct 29 04:55:46 PDT 2019



On 10/29/19 11:50 AM, Ross Burton wrote:
> 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]

Isn't this do to the hashes being different and the PR server can't
really tell which one is newer?


>>>>
>>>> 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