2016-12-24 03:08 [email protected]:
2016-12-24 02:55 Manuel A. Fernandez Montecelo:
This seems to be due to changes in behaviour of apt or some strange
interaction, because the relevant sections of aptitude have not changed
in a long time. (I didn't experience the same behaviour because I
couldn't upgrade my computer at the time).
[...]
Anyway, I think that I fixed it now, by not being strict with this kind
of errors (to cope with what I think that it's a new behaviour from
libapt)... I am just not sure if this change will bring other problems,
let's see.
Note, just in case... relevant commits of apt seem to be:
commit 1044354995513348f4836772fe77068585091d6b
Author: David Kalnischkies <[email protected]>
Date: Wed Aug 24 21:49:34 2016 +0200
improve code & doc for aquire weak/loop failing
commit 2e2865ae53a65c00dd55a892d5b48458f3110366
Author: David Kalnischkies <[email protected]>
Date: Wed Aug 24 09:47:48 2016 +0200
do fail on weakhash/loop earlier in acquire
More notes to maintainers/future self in the case that we have to
revisit this issue in the future...
Actually, I was sleepy last night and it shows... the bug report is a
few days before those changes in apt were commited (which were probably
released weeks later), so they shouldn't be the cause (at least not if
all the comments to this bug and the dupes refer to the same behaviour).
I/we didn't let aptitude to migrate to testing from end of 2015 until
August of 2016, and even if many many changes happened during that time,
the "package list updates download manager" for the UI (there are
several of those for different downloads, and different ones for command
line) didn't see much action, and nothing that looks particularly
related on a cursory look in that code / relevant commits during 2016.
"aptitude update" (command line) worked fine, because as I said a
different download manager (with its different code paths) was involved,
and the fact that aptitude appeared to be hung in "Loading cache"
doesn't mean that there's something like an infinite loop related to
that message -- it was simply added as a banner, so slower systems had
something to show in these expensive operations/long time, but it was
not a change in behaviour in that respect.
Even if newer versions of aptitude didn't migrate to testing for many
months, nobody complained during those months for the behaviour in
unstable (and we get more complaints from unstable than from testing),
so it's quite strange if nobody hit that for months and suddenly it
happened to lots of people within at once.
Additionally, I wasn't observing that behaviour with updated aptitude
(the versions that people complained about) and older apt which I didn't
update for a few months (I checked again today, just in case), so it
points more towards changes in apt behaviours (not necessarily a "bad
one" -- possibly fixing a bug) or interactions aptitude<->libapt.
What it happens is that aptitude uses pkgAcquire from (lib)apt to
download the lists, it returns the status Failed instead of Continue, so
aptitude thinks that something happened preventing it to continue and
bails out at that point, not removing "Loading cache" and not doing
anything else either, just sitting idle waiting for the next keypresses
(eveything else works fine -- just that many options are disabled,
because it's still technically in the "loading the package cache"
state).
(BTW, in my case I could at least see the download error --a red row in
the list of downloaded repos-- the first time that it happened, aptitude
said "There have been download errors", and a dialog showed asking me to
confirm if I wanted to continue, which can be disabled but the default
should be Show-If-Error).
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
