I just got this dialog from the aptitude TUI after updating package list with "aptitude -u": ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ │E: Failed to download some files ▒│ │W: Failed to fetch https://deb.opera.com/opera/dists/stable/InRelease: ▒│ │W: Failed to fetch https://deb.opera.com/opera-beta/dists/stable/InRelease: ▒│ │W: Failed to fetch https://deb.opera.com/opera-snapshot/dists/stable/InRelease: ▒│ │E: Some index files failed to download. They have been ignored, or old ones used instead. ▒│ │ [ Ok ] │ └─────────────────────────────────────────────────────────────────────────────────────────────┘ With "aptitude update", it looks like this, showing more details: Fetched 269 kB in 15s (18.2 kB/s) E: Repository 'https://deb.opera.com/opera stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' E: Repository 'https://deb.opera.com/opera-beta stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' E: Repository 'https://deb.opera.com/opera-snapshot stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' E: Failed to download some files W: Failed to fetch https://deb.opera.com/opera/dists/stable/InRelease: W: Failed to fetch https://deb.opera.com/opera-beta/dists/stable/InRelease: W: Failed to fetch https://deb.opera.com/opera-snapshot/dists/stable/InRelease: E: Some index files failed to download. They have been ignored, or old ones used instead. But with "apt update" I get this dialog (and afterwards two more) instead of just failing package list updates: E: Repository 'https://deb.opera.com/opera stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' 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] Seems as if currently aptitude doesn't have the capability to make a dialog out of this. Additionally, it shows less of the error message(s) in TUI mode than in CLI mode despite it IMHO shou;dn't.
currently, apt-get "only" prints the errors and expects the confirmation via commandline flag(s) [or as usual via config options]. Implementation wise it should be "simple": You likely have a class extending pkgAcquireStatus – change that to pkgAcquireStatus2 (yeah for keeping ABI compatibility) and implement the method "bool ReleaseInfoChanges(metaIndex const * const LastRelease, metaIndex const * const CurrentRelease, std::vector<ReleaseInfoChange> &&Changes)". See apt-private/acqprogress.cc for an example in the apt sources implementing the behaviour in apt/apt-get. Feel free to ask if there is something unclear… it is a security feature of sorts & I implemented it, so its kinda important to me. :) Best regards David Kalnischkies
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
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