Package: release.debian.org Severity: important User: [email protected] Usertag: britney
Filing as a bug so it's documented somewhere more formal and doesn't get forgotten. On Sun, 2011-04-10 at 10:29 +0000, Cron Daemon wrote: > Traceback (most recent call last): > File "/srv/release.debian.org/britney/code/b2/britney.py", line 2841, in > <module> > Britney().main() > File "/srv/release.debian.org/britney/code/b2/britney.py", line 2836, in > main > self.upgrade_testing() > File "/srv/release.debian.org/britney/code/b2/britney.py", line 2548, in > upgrade_testing > self.do_all() > File "/srv/release.debian.org/britney/code/b2/britney.py", line 2447, in > do_all > (nuninst_end, extra, tundo) = self.iter_packages(upgrade_me, selected, > nuninst=nuninst_end) > File "/srv/release.debian.org/britney/code/b2/britney.py", line 2243, in > iter_packages > pkg_name, suite, affected, undo = self.doop_source(pkg) > File "/srv/release.debian.org/britney/code/b2/britney.py", line 2039, in > doop_source > if binaries[parch][0][binary][SOURCE] != pkg_name: continue > KeyError: 'fixincludes' (and the docvert-openoffice.org and openoffice.org-dmaths crashes from mid-March, which I suspect are other occurrences of the same issue; possibly also related to #618805) >From a bit of debugging, this appears to be an issue with cases where a particular binary package has either moved source packages (as in the "fixincludes" case, from gcc-4.5 to gcc-4.6) or moved from being arch-dependent to arch:all, and the package is considered during multiple phases of the b2 run (either as part of an "easy" and then during the main run, or in the main run and then in a "hint"). When deciding whether to migrate a package, britney removes all of the current binary packages - making an "undo" list - and then adds the binary packages from the new version. If the new version is not accepted then the "undo" list is used to revert things to the previous state. However, in the "fixincludes" case at least, that reversion seems not to be applied correctly. The run in which the above error occurred included an "easy" for gcc-4.5, gcc-4.6 and a few other packages, which failed; when the main run came to consider gcc-4.5 again the sources dict still listed "fixincludes" as being built from gcc-4.5 but the binaries dict included the information for gcc-4.5/unstable, meaning that it was missing the "fixincludes" package. This appears to be "fixable" by disabling the use of the pre_process dict, but at the expense of making the run slower. Regards, Adam -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
