We are not currently running multiple instances of bitbake against the same sstate cache. We are using PR servers, but currently only local to a build, not shared. We do use packages to update targets. Below is the content of local.conf (generated by kas). Cheers Dan # meta-custom PACKAGE_CLASSES ?= "package_deb" LICENSE_FLAGS_ACCEPTED += "commercial" # Number of parrallel bitbake tasks BB_NUMBER_THREADS = "6" # number of parraellel task run by "make" et al PARALLEL_MAKE = "-j 4" # meta-custom-tritium-os BBFILE_PRIORITY_meta-aws = "11" # meta-local PRSERV_HOST = "localhost:0" # It is recommended to activate "buildhistory" for testing the PR service INHERIT += "buildhistory" BUILDHISTORY_COMMIT = "1" MACHINE ??= "containerx86-64" DISTRO ??= "tritium3-container" BBMULTICONFIG ?= "" On Fri, 9 Dec 2022 at 16:11, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Fri, 2022-12-09 at 16:02 +0000, Daniel Squires wrote: > > Hi! > > We're using kirkstone, though not the very latest at present. > > Every now and then a a number of packages will unexpectedly give the > > error re package versions going backwards and teh version may have > > done something like go from git5-######-r0.1 to git3-#######-r0.0. > > We always see this if we've been using devtool for a given recipe and > > then do a devtool reset, it complains about going back from git999 to > > e.g. git5 but this makes sense and we just run the build again and > > forget about it. However sometimes this just seems to happen randomly > > for a given recipe when it picks up a new commit from our repos and > > the git autoinc number will have gone back a few. > > Does anybody know why and if it is a bug or an be fixed? > > We probably need to know a bit more about how you're building things. > Do you have a pool of workers building against a common sstate? > > Are you using hash equivalence? Are you using a PR server? > > I ask the questions as the answer is probably somewhere in the way data > is being shared/reused between builds. > > If you're not using package management on device to upgrade them, it > probably isn't a big issue but it is worth understanding the sstate > reuse in this context. > > Cheers, > > Richard >