[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#624716: marked as done ([britney2] Does not properly undo failed migrations)

Your message dated Mon, 09 May 2011 19:12:46 +0100
with message-id <1304964766.21740.86.camel@hathi.jungle.funky-badger.org>
and subject line Re: Bug#624716: [britney2] Does not properly undo failed migrations
has caused the Debian Bug report #624716,
regarding [britney2] Does not properly undo failed migrations
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
624716: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624716
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: important
User: release.debian.org@packages.debian.org
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

--- End Message ---
--- Begin Message --- 
On Wed, 2011-05-04 at 19:58 +0100, Adam D. Barratt wrote:
> In each of the cases where a binary B has moved from source S1 to S2,
> what ends up happening is that the undo data for S1 is processed first,
> giving us:
> 
>   re-add binary "B", removed from source S1
>   remove binary "B", newly added by source S2
> 
> with the net result that the binary list no longer contains B but the
> sources dict lists it as being built by S1.  Restructuring the undo loop
> so that all removals are processed before any re-introductions fixes the
> crash and seems to produce the same logical result afaics.
> 
> I intend to apply the attached patch within the next few days unless
> someone raises a problem with it.

No-one did, so I pushed the patch earlier today.

Regards,

Adam

--- End Message ---
Reply to: