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.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]
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 -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
