Hi! On Fri, 2017-01-06 at 11:33:08 +0100, Vincent Lefevre wrote: > Package: dpkg > Version: 1.18.18 > Severity: grave > Justification: renders package unusable
I don't think this severity is right here, at least for dpkg, but let's see. > When I tried to upgrade from aptitude: > > Performing actions... > Retrieving bug reports... Done > Parsing Found/Fixed information... Done > Retrieving bug reports... Done > Parsing Found/Fixed information... Done > Reading changelogs... Done > apt-listchanges: Do you want to continue? [Y/n] > (Reading database ... 509222 files and directories currently installed.) > Preparing to unpack .../libapt-pkg5.0_1.4~beta3_amd64.deb ... > Unpacking libapt-pkg5.0:amd64 (1.4~beta3) over (1.4~beta2) ... > Setting up libapt-pkg5.0:amd64 (1.4~beta3) ... > dpkg: error: dpkg status database is locked by another process > ====== How can you help? (doc: https://wiki.debian.org/how-can-i-help ) > ====== > > ----- Show old opportunities as well as new ones: how-can-i-help --old ----- > E: Sub-process /usr/bin/dpkg returned an error code (2) > Processing triggers for libc-bin (2.24-8) ... > Press Return to continue, 'q' followed by Return to quit. > > The only other process matching apt and dpkg is aptitude itself. I don't think this is a problem in dpkg itself, there's nothing I can remember that has changed regarding the locking and similar. I'm assuming that cannot easily reproduce the problem? That the system probably has some unnattended async calls to a command that locks the dpkg database? Either that, or if it's a multi-admin system perhaps someone else started an aptitude instance just between the time apt/aptitude release the dpkg lock so that dpkg itself can take it? Thanks, Guillem
