First, this is not an autobuilder bug. I could not find a good spot for a "buildhistory" issue but I know the autobuilder folks will know what I am talking about and hopefully easily redirect this to the right people. Apologies for this convolution. I recently started building nightly builds with our kernel being built from the tip of the tree. To accomplish this I am using the AUTOREV feature and then I use the SRCPV value in my PR to help identify the actual commit obtained in the version number of the kernel. Buildhistory does not like this at all and it seems that it does a mathematical comparison with the sha value which, when the next sha value is mathematically less than the previous then the builds will fail as below: ERROR: Package version for package ccd-linux-non-ccd went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package perf-dbg went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package perf went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-base went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-image went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-dev went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-vmlinux went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-misc went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-module-soft-bt-test went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-module-scsi-wait-scan went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9) ERROR: Package version for package kernel-modules went backwards which would break package feeds from (0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git1+1e36f9)
Is the persistent db within the cache (TMPDIR/cache/bb_persist_data.sqlite3) being preserved between builds? That's the way this is normally supposed to work - the system recognises a previous hash was built and should increase the number at the start of SRCPV, i.e. in this example it should have gone from 0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git2+1e36f9. If you aren't touching TMPDIR or the cache between builds and it's behaving like this then we have a problem.
(In reply to comment #1) > Is the persistent db within the cache (TMPDIR/cache/bb_persist_data.sqlite3) > being preserved between builds? That's the way this is normally supposed to > work - the system recognises a previous hash was built and should increase > the number at the start of SRCPV, i.e. in this example it should have gone > from 0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git2+1e36f9. > > If you aren't touching TMPDIR or the cache between builds and it's behaving > like this then we have a problem. Finally I learn more about that LOCALCOUNT ... previously I played around with BB_LOCALCOUNT_OVERRIDE and a custom LOCALCOUNT and also ran into buildhistory issues. Not related to this though. To answer your questions, yes, indeed ... since this is our official builds I precede them with a complete cleanup ("rm -rf tmp sstate-cache downloads") in an attempt to ensure there are no surprises. If I understood correctly a cleanup of TMPDIR precedes the yocto autobuilder builds also.
(In reply to comment #2) > (In reply to comment #1) > > Is the persistent db within the cache (TMPDIR/cache/bb_persist_data.sqlite3) > > being preserved between builds? That's the way this is normally supposed to > > work - the system recognises a previous hash was built and should increase > > the number at the start of SRCPV, i.e. in this example it should have gone > > from 0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git2+1e36f9. > > > > If you aren't touching TMPDIR or the cache between builds and it's behaving > > like this then we have a problem. > > Finally I learn more about that LOCALCOUNT ... previously I played around > with BB_LOCALCOUNT_OVERRIDE and a custom LOCALCOUNT and also ran into > buildhistory issues. Not related to this though. > > To answer your questions, yes, indeed ... since this is our official builds > I precede them with a complete cleanup ("rm -rf tmp sstate-cache downloads") > in an attempt to ensure there are no surprises. If I understood correctly a > cleanup of TMPDIR precedes the yocto autobuilder builds also. Yes, it does, however, and this bit of functionality got left out of the recent upgrade (It's back in now, pending ab restart), the autobuilder takes the old bb_persist_data.sqlite3 and repopulates build/tmp/cache.
See: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?id=0c6a76783d255ca6904963c2bd2b72f9dc21fceb
(In reply to comment #4) > See: > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/ > ?id=0c6a76783d255ca6904963c2bd2b72f9dc21fceb Thank you very much for clearing this up. I will work with you to reproduce this solution in our builds. I proceed to mark this bug as resolved.