Various recipes give errors like this: ERROR: Package version for package gtk-printbackend-lpr went backwards which would break package feeds from (0:2.24.8-r5.2 to 0:2.24.8-r5.0) All recipes seem to have a decimal PR
PR service is now being targetted for 1.4, adapting bug for attention post release of 1.3.
To see these warnings you need to have buildhistory enabled.
Constantin is looking into this and it appears there is a serious bug in the way the comparisions are done with the PR being reset to zero too often. The downside of the current implementation is that it will continue to increment the PR value for each build and will not reset it to zero when for example PV or PE change. An enhancement could be to track the base PE/PV/PR values and then when they increment, zero the PR. The "decimal" PR value is expected since the auto PR is appended to the main recipe PR as an append.
Constantine tested a server setup locally which I've seen working for this package. I also quickly setup something myself and can watch the package counters increasing. We therefore really need further informaiton about how your setup was configured so we can try and figure out how it failed. For example: * Did you switch accidently to a different PR server? * Did the PR server database accientally get wiped? * Did you use data from a sstate feed that was built using a different PR server? I've asked Constantine to pull together some documentation about how PR server works but until we have a way to reproduce this failure we're a bit stuck.
We need info to figure this out, updating status accordingly...
I used the angstrom setup-scripts and added the following to local.conf: PRSERV_HOST = "localhost" PRSERV_PORT = "0" No wiping of TMPDIR happened, but local.conf does have: SSTATE_MIRRORS ?= "\ file://.* http://dominion.thruhere.net/angstrom/sstate-mirror/ \n " So 'foreign' sstate might have crept in.
Assuming you have only one builder (based on the fact you have one TMPDIR), the only way we can see this happening is from "corruption" from the existing sstate directory. If sstate is used, all machines contibuting to the sstate pool need to share the same PR server. Would you be able to retest things and see if the problem occurs without sstate complicating the equation (or using an sstate only generated from builds connected to the same PR server)?
Please reopen if this can be reproduced or more details become available. The only explaination we can find for this is an sstate feed not synced with the PR service.