On Fri, 2014-10-24 at 03:23 +0200, Christoph Anton Mitterer wrote: > So that's kinda worrisome... how to get out of this when one cannot > upgrade to a newer version of dpkg?
Okay I just found that the blocking point was debian-security-support:
W A acpi-fakekey
0.142-5 0.142-5
u acpi-support
0.142-5 0.142-5
W A acpi-support-base
0.142-5 0.142-5
W apt-file
2.5.4 2.5.4
W A autopoint
0.19.3-1 0.19.3-1
u A cpp-4.9-doc
4.9.1-3 4.9.1-3
T debian-security-support
2014.09.07 2014.09.07
W A gcc-4.9-doc
4.9.1-3 4.9.1-3
u gettext
0.19.3-1 0.19.3-1
W A gettext-base
0.19.3-1 0.19.3-1
W A gettext-doc
0.19.3-1 0.19.3-1
T A libc-bin
2.19-12 2.19-12
W locales
2.19-12 2.19-12
W A openjdk-7-doc
7u71-2.5.3-1 7u71-2.5.3-1
W A python-requests
2.4.3-2 2.4.3-2
u vim
2:7.4.488-1 2:7.4.488-1
W A vim-common
2:7.4.488-1 2:7.4.488-1
W A vim-doc
2:7.4.488-1 2:7.4.488-1
u A vim-nox
2:7.4.488-1 2:7.4.488-1
W A vim-runtime
2:7.4.488-1 2:7.4.488-1
I could dpkg --configure debian-security-support, which already solved
the triggers-aWaited for many other packagees,... and then another dpkg
--configure -a configured all the unconfigured leftovers.
Guillem,... any ideas whether/how these kills (or pressing Ctrl-C)
affects the dpkg status DB and other metadata?
Should I be worried and look whether I need to import backups? At least
at a first glance, everything looks normal again, though, in aptitude.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
