Note that those who experience this situation can get out by pressing ctrl-c, and then run something like:
apt-get -o Immediate-Configure=false -f install Bernhard Schmidt wrote: > I just experienced the same problem. Attached my typescript (with > the updated module from this bug) and the package list. I'm testing > upgrading Torrus to wheezy in a VM, thus the two unauthenticated > packages on my own server. > > It's a plain minimum Squeeze i386 installation in KVM, then > installed torrus-apache2 (which installs quite a lot of packages, > including apache2 and mod_perl2), then dist-upgrade to wheezy. > > Not sure whether the VM will boot tomorrow, I hope the attached > information helps. Thanks, I was able to reproduce it too. I pressed ctrl-z just after libc6 was upgraded (around where it would ask about upgrading with debconf when not in a chroot), and running debconf reproduces the loop. Confirmed that mblen is busted. At this point, perl is half-configured; libtext-charwidth-perl is still at the version from stable. After these two get upgraded, the problem goes away. (libtext-wrapi18n-perl currently has the same version in both suites so I don't know if apt would have partially upgraded it to a newer version at this point. And debconf is still at the version from stable.) So apt breaks the old version of libtext-charwidth-perl's dependency on the old version of perl, to resolve the upgrade. Then debconf-i18n tries to use the module indirectly and it blows up. Note that debconf-i18n is a Required package, and depends on libtext-charwidth-perl, so apt is going to extreme lengths to break the cycle. It would be possible to have debconf test for mblen being broken and avoid doing multibyte aware word wrapping.. except debconf does not get upgraded in time! Indeed, it's hard to see where to put a fix for this at all, since only perl is (partially) upgraded yet. -- see shy jo
signature.asc
Description: Digital signature
