The bitbake runqueue passes non-finalized metadata to setscene callbacks, but finalized metadata ends up used when the setscene task is executed. As a result, when using an override with SSTATE_DIR, it can look for setscenes in one location, find them, and then try to extract them from another, or fail to find them in one location even though they're available in the other.
Aside: why do some areas of bb.runqueue reference self.cooker.data directly, while others use self.cfgData?
Test case: $ cat >conf/auto.conf <<END SSTATE_DIR = "${TOPDIR}/sstate-cache.nooverride" SSTATE_DIR_forcevariable = "${TOPDIR}/sstate-cache.override" END $ rm -rf tmp sstate-cache.override sstate-cache.nooverride $ bitbake --no-setscene -c populate_sysroot quilt-native $ rm -rf tmp $ bitbake -c populate_sysroot quilt-native # this builds from scratch, when it shouldn't, as sstate was written to override, but not to the checked path, nooverride
Initial testing indicates https://gist.github.com/kergoth/e9a46893fc4e9f1afaa7 resolves this, doing further testing before upstream submission.
Patch emailed to the bitbake-devel list.
Richard merged this, so resolving.