Hello!
As you know, Debian buster has been released yesterday and the current
Debian testing has just been renamed from 'buster' to 'bullseye'.
Good, but... today I tried to update the repository lists and upgrade
my Debian testing boxes with aptitude:
# cat /etc/apt/sources.list
deb http://deb.debian.org/debian testing main
deb http://deb.debian.org/debian unstable main
deb http://deb.debian.org/debian-security testing-security main
# aptitude update && aptitude --purge-unused safe-upgrade
Get: 1 http://deb.debian.org/debian testing InRelease [87.0 kB]
Hit http://deb.debian.org/debian unstable InRelease
Get: 2 http://deb.debian.org/debian-security testing-security InRelease [26.1 kB]
Fetched 26.1 kB in 0s (57.2 kB/s)
E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye'
E: Failed to download some files
W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease:
E: Some index files failed to download. They have been ignored, or old ones used instead.
OK, it's telling me that the codename has changed, so I have to be
sure I want to continue to use that repository.
This is useful in cases where the user has configured something
like "deb http://deb.debian.org/debian stable main" and does not
want to be caught unprepared by a new stable release.
But for Debian testing, I really want to continue tracking testing
and the codename change is not an actual discontinuity.
I had to do the following:
# apt update
Get:1 http://deb.debian.org/debian testing InRelease [87.0 kB]
Hit:2 http://deb.debian.org/debian unstable InRelease
E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
Hit:3 http://deb.debian.org/debian-security testing-security InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
and then resume my usual upgrading procedure:
# aptitude update && aptitude --purge-unused safe-upgrade
Hit http://deb.debian.org/debian testing InRelease
Hit http://deb.debian.org/debian unstable InRelease
Hit http://deb.debian.org/debian-security testing-security InRelease
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
I think this is a bug in aptitude: it should interactively ask the user
to explicitly confirm the will to go on with the new codename, like apt
does, and also provide a command line option to do so
("--allow-releaseinfo-change", see the apt-get(8) man page).
Please implement this feature.
Thanks for your time and dedication!
Bye.
Hi Francesco, Michael and Sven, Francesco Poli (wintermute) wrote: […] Indeed. This also seems to have an impact where buster changed from "testing" to "stable", see https://bugs.debian.org/931543. That's actually prompted by a change in libapt (as Sven already pointed out in #931543) which aptitude indeed hasn't been updated a for. I though must admit that we actually were aware of this issue as I ran into it with a third-party repo a few months ago, see https://bugs.debian.org/915246. But admittedly I totally underestimated its severity and especially also its impact at release time as I didn't think of that exactly the same will happen when Debian shifts all suite names at release time. Sorry for that. I hope that Manuel (CCc'ed) can provide a fix which we then can also apply to aptitude in Buster in the first minor update which is expected in about a month. The official workaround is to use "apt update" once inbetween, answer its questions (with "y" :-) and then continue to use aptitude. Regards, Axel
Hello Axel, thanks for chiming in! [...] [...] [...] It's OK, luckily we have the simple "apt update" workaround (although many people will have to be informed about it...). I am looking forward to seeing this fix implemented. Bye!
into extending the reporting let me add some implementation hints:
(Note that this is against apt/master which has some API changes, but in
that case that means ABI-compat classes where folded into another, so
backports should be rather trivial – adding virtual methods is ABI
breaking, so in buster the class to derive from has the creative name
pkgAcquireStatus2 as it is itself derived from pkgAcquireStatus)
libapt has a pkgAcquireStatus class which gained a new virtual method:
ReleaseInfoChanges – kinda similar to the existing MediaChange. aptitude
subclasses this a few times, just pick the right one I guess.
See apt{,-get}s implementation:
https://salsa.debian.org/apt-team/apt/blob/master/apt-private/acqprogress.cc#L334
I guess you want to work directly with the parameter
std::vector<ReleaseInfoChange> &&Changes rather than do the trickery to
make "proper" apt error messages out of it and then print them directly
by wrap-calling the default implementation I did there – aka it is
probably simpler for you.
See the doc for the struct in the method in the header:
https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/acquire.h#L797
And the code generating the messages you can reuse via the struct:
https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/acquire-item.cc#L1806
If I could make a wish I would suggest featuring the messages which
don't need confirmation (in apt N: lines) not too prominently – as in
don't make them a popup dialog with an OK button (while the other type
is a popup dialog with yes and no buttons). 😉
I can't speak for aptitude folks and I am not too good with aptitude
code, but if I would be that might be a good bug for tagging +newcomer.
Happy to help in case there are {lib,}apt questions in any case – although
I have insane reply delays currently.
Best regards
David "breaking the world one feature at a time" Kalnischkies
Dear Maintainer, Running aptitude without arguments then pressing u seemingy successfully updated the package list, however it did not contain the changes from the new stable update 10.1. Running "apt-get update" on the command line produced the following error messages: N: Für das Depot »http://ftp.hu.debian.org/debian buster InRelease« wurde der »Version«-Wert von »« in »10.1« geändert. E: Für das Depot »http://ftp.hu.debian.org/debian buster InRelease« wurde der »Suite«-Wert von »testing« in »stable« geändert. N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie weitere Informationen benötigen. N: Für das Depot »http://deb.debian.org/debian buster InRelease« wurde der »Version«-Wert von »« in »10.1« geändert. E: Für das Depot »http://deb.debian.org/debian buster InRelease« wurde der »Suite«-Wert von »testing« in »stable« geändert. N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie weitere Informationen benötigen. After running "apt update" and answering "i" to the confirmation questions, I have managed to update. In my opinion, aptitude should explicitly ask for confirmation in these cases, instead of silently ignoring the messages. Best wishes, Gábor
On Sun, 7 Jul 2019 16:41:27 +0200 Francesco Poli wrote: [...] Hello again! After more than two years, this bug is still unfixed in aptitude... # cat /etc/apt/sources.list deb http://deb.debian.org/debian testing main deb http://deb.debian.org/debian unstable main deb http://deb.debian.org/debian-security testing-security main # aptitude update && aptitude --purge-unused safe-upgrade Get: 1 http://deb.debian.org/debian testing InRelease [81.6 kB] Get: 2 http://deb.debian.org/debian unstable InRelease [165 kB] Get: 3 http://deb.debian.org/debian-security testing-security InRelease [35.6 kB] Fetched 282 kB in 8s (36.6 kB/s) E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'bullseye' to 'bookworm' E: Repository 'http://deb.debian.org/debian-security testing-security InRelease' changed its 'Codename' value from 'bullseye-security' to 'bookworm-security' E: Failed to download some files W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease: W: Failed to fetch http://deb.debian.org/debian-security/dists/testing-security/InRelease: E: Some index files failed to download. They have been ignored, or old ones used instead. Once again, I had to work around the bug by using 'apt update': # apt update Get:1 http://deb.debian.org/debian testing InRelease [81.6 kB] Hit:2 http://deb.debian.org/debian unstable InRelease Get:3 http://deb.debian.org/debian-security testing-security InRelease [35.6 kB] E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'bullseye' to 'bookworm' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. Do you want to accept these changes and continue updating from this repository? [y/N] y E: Repository 'http://deb.debian.org/debian-security testing-security InRelease' changed its 'Codename' value from 'bullseye-security' to 'bookworm-security' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. Do you want to accept these changes and continue updating from this repository? [y/N] y Reading package lists... Done Building dependency tree... Done Reading state information... Done 4 packages can be upgraded. Run 'apt list --upgradable' to see them. At that point, I was able to resume my usual upgrade routine with: # aptitude update && aptitude --purge-unused safe-upgrade Are there any plans to fix this bug in aptitude once and for all? Please
Hi, Francesco Poli wrote: Correct. I assume so, yes. But not by myself as this is outside of my C/C++ capabilities. (In other words: I hope that Manuel — or someone else — will find time to tackle this at some point with one of the next upstream releases.) Oh, and of course: Patches are welcome! If there are well working patches, I can also apply them in the upstream branches and do upstream releases with them. I just can't write new C++ code from scratch. (I other words: Within the Aptitude team, I'm primarily the package maintainer and Manuel does nearly all of the upstream development.) Regards, Axel