[Aptitude-devel] Bug#669093: Bug#669093: Bug#669093: E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for ..., aborting

[David Kalnischkies]

package apt aptitude
reassign 669093 apt 0.9.0
forcemerge 669060 669093
thanks

On Tue, Apr 17, 2012 at 16:56, Vincent Lefevre <vincent at vinc17.net> wrote:
> On 2012-04-17 16:53:15 +0200, Vincent Lefevre wrote:
>> On 2012-04-17 15:32:27 +0200, Axel Beckert wrote:
>> > Vincent Lefevre wrote:
>> > > reported against apt 0.9.0, but I have apt 0.8.15.10 only
>> > > (I haven't upgraded apt itself yet).
>> >
>> > Hrm. Should aptitude 0.6.6-1+b1 work together with the old apt at all?
>>
>> aptitude doesn't depend on apt. The bug might be in a common
>> dependency (libept1.4.12?).
>
> Oops, apt doesn't depend on libept1.4.12. So, that would be
> libapt-pkg4.12 (which has apparently been separated from apt,
> while older apt versions just provided libapt-pkg4.10).

Sorry for the inconvenience. That's a src:apt bug in the ordering code
used by aptitude (and apt-get and all other apt-based frontends).
Nothing wrong with aptitude and no change needed
(nor a rebuild or something, shared libraries for the win ;) )

A fixed version of apt is already uploaded so relax and await mirror sync
(if it hasn't reached your mirror yet). I am therefore doing a partly-
nasty thing, but this time it should be in order:
(force)Merging with an already closed bugreport of another package…


btw: Nice that aptitude picked up the new libapt in the binNMU
flawlessly. I had tried it locally but its good to see that the buildd
managed it nicely, too. One package less to worry about in the
transition. :)


Best regards

David Kalnischkies