On Thu, Nov 17, 2016 at 07:20:47AM +0900, Daniel Kahn Gillmor wrote: > On Wed 2016-11-16 22:42:04 +0900, David Kalnischkies wrote: > > On Wed, Nov 16, 2016 at 02:40:59PM +0900, Daniel Kahn Gillmor wrote: > >> weird that it says "1 not upgraded" in response to "apt autoremove" > >> but "0 not upgraded" in response to "apt upgrade", eh? > > > > I smell Multi-Arch:same version-screw. The way we tell the resolver to > > not travel down this road is by reseting the candidate version – but > > that means it has no chance to know later on that that package was > > "upgradeable"… > > > > The usual resolver debug flags could be interesting: > > -o Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1 > > > > Please also save your /var/lib/dpkg/status and /var/lib/apt/lists/ > > somewhere as resolver things are highly state dependent and disappear > > usually within a few mirror updates. > > > > And as you have a new enough apt version, lets run apt with > > -o Dir::Log::solver=/tmp/edsp.log.xz > > also as that should collect all relevant information of system state for > > the resolver in one still big but at least highly compressed file > > I might want to have later if my guess from above is completely wrong. > > which commands did you want me to run with these options? Ideally both although given you don't like the behaviour of 'upgrade' that is going to be the most interesting and the other a sort of reference material for comparison. Look for "Ignore MarkInstall of … as it is not in sync with its M-A:same sibling … (… != …)" which would be a direct screw. There are others, so perhaps add -o Debug::pkgDepCache::AutoInstall=1 as well – a single package might actually more realistically be effected by the fix for #735967 (which is what I described above as resetting). In that case you should be seeing a "… <dependency type> … can't be satisfied!" message. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature