Bug#995256: [Aptitude-devel] Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error
Hi David, David Kalnischkies wrote: > > I wonder if there is a kind of race condition if aptitude is running > > and then either on the admin on the commandline or a background job > > runs "apt update". > > That can indeed mess up some things as the cache (which is then old) > still points to file locations in the "old" files rather than what an > update might have placed in there in the meantime. […] > > So this package in question is arch:all. > > > > But according to the screenshot, aptitude wants > > texlive-fonts-recommended:amd64 for whatever reason — which indeed > > does not exist. > > This is a misunderstanding. An arch:all deb file is always attributed to > be of the native architecture, in your case amd64. That is because > libapt makes a difference between a package(name with architecture) and > a version (of a package with version number & architecture). […] Thanks for these explanations and clarifications, much appreciated! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error
On Tue, Sep 28, 2021 at 06:38:05PM +0200, Axel Beckert wrote: > > I have no idea why this happens, but originally thought it might be related > > to > > not having run 'update' as a first step. > > I'd rather imagine something the other way round: > > I wonder if there is a kind of race condition if aptitude is running > and then either on the admin on the commandline or a background job > runs "apt update". That can indeed mess up some things as the cache (which is then old) still points to file locations in the "old" files rather than what an update might have placed in there in the meantime. For a long-running process like aptitude it might actually make sense to grab the lists/lock to prevent an update process interfering – but that can technically happen to any libapt client, just that the window for e.g. apt-cache is far smaller. I don't know if that is really the root cause here through as such issues usually run into other errors (if not crashes in unsuspecting clients). Such a problem could be "easily" reproduced by starting aptitude & then modifying a Packages file in such a way that the stanza about the package you want to click on next in the interface is (re)moved. One of these days I have to try if we can make libapt hold onto the file descriptors while the cache is open, but that has all sorts of practical problems (like having hundreds of open file descriptors potentially exhausting limits, lifetime and stuff). > Thanks! There's an interesting fact visible. First let's look at that > package: > > ~ → apt-cache show texlive-fonts-recommended > Package: texlive-fonts-recommended > Version: 2021.20210921-1 > Architecture: all > > So this package in question is arch:all. > > But according to the screenshot, aptitude wants > texlive-fonts-recommended:amd64 for whatever reason — which indeed > does not exist. This is a misunderstanding. An arch:all deb file is always attributed to be of the native architecture, in your case amd64. That is because libapt makes a difference between a package(name with architecture) and a version (of a package with version number & architecture). Imagine a 'package' changing from arch:all to arch:any (or vice versa). Even through these versions have different architectures they will all be versions of the foo:amd64 package. Otherwise those transitions would require explicit user intervention (or a lot of code in package managers) as architectures would change, pins not apply anymore and all sorts of shenanigans. > I tried to fix this in zsh like this: > https://salsa.debian.org/debian/zsh/-/commit/801f5e105ad6d1f767d28c8311edd263790f419f 'all' is an invalid architecture, so while some parsers might accept it and do something roughly sensible, some others might explode and that is perfectly fine. Don't do this. Lintian might warn about this in the future. Note that the package might be 'all', but isn't M-A:foreign, so as above the package only satisfies dependencies on the native architecture. In the cross build this all package has the 'wrong' architecture, that is why it is purely virtual. Probably it was a mistake by the resolver to go down this path due to temporary unavailability of a better choice (aka the native architecture of an earlier M-A:foreign package). Currently not an avoidable mistake as the markup says its okay while it really isn't for crossbuilders… that is unrelated to this bug through (if by some miracle you are interested, look for "very foreign" aka "barbarian" architectures. libapt will allow experimenting with this concept soon, but at this stage (and hopefully forever) clients like apt and aptitude can be mostly ignorant about these topics). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#995256: [Aptitude-devel] Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error
Hi IOhannes, IOhannes m zmoelnig wrote: > - aptitude opens new *red* window where it prints > > > E: Can't find a source to download version 'VERSION' of 'PACKAGE' > > - the error window grows as one such line is printed about every 500ms > until it finally fills the entire height of the screen I think I've seen that once or twice, too, but way to seldom to actually bother as I considered it to be caused by inconsistencies outside aptitude. > - quitting aptitude and restarting it makes the problem go away H. > I have no idea why this happens, but originally thought it might be related to > not having run 'update' as a first step. I'd rather imagine something the other way round: I wonder if there is a kind of race condition if aptitude is running and then either on the admin on the commandline or a background job runs "apt update". > in the meantime i'm not so sure about this anymore (e.g. as i think i don't > have > to run 'update' in the restarted aptitude). No, you don't have to. Aptitude more or less just reads what files are in /var/lib/apt/lists/ (and some more state files). > in any case, i have not been able to find a way to reliably reproduce the > problem (it just happens every now and then). Ack. > i've seen this problem for a "long time" by now (probably pre 2021) Yes, haven't seen it recently. > i've attached a screenshot. Thanks! There's an interesting fact visible. First let's look at that package: ~ → apt-cache show texlive-fonts-recommended Package: texlive-fonts-recommended Source: texlive-base Version: 2021.20210921-1 Installed-Size: 15031 Maintainer: Debian TeX Task Force Architecture: all So this package in question is arch:all. But according to the screenshot, aptitude wants texlive-fonts-recommended:amd64 for whatever reason — which indeed does not exist. So it's probably _not_ related to updating package lists in the background. And yes, I've recently seen such an issue elsewhere, namely here: https://salsa.debian.org/debian/zsh/-/jobs/1950702#L1463 The relevant lines are: The following packages have unmet dependencies: zsh-cross-build-deps:arm64 : Depends: cm-super-minimal:arm64 which is a virtual package and is not provided by any available package Unable to resolve dependencies! Giving up... (And yes, cm-super-minimal is arch:all as well.) Then again, the above was already during dependency resolution and not in the preview. It though still might be caused by the same bug mixing up arch:all with arch:any packages as the above error message stems from src/cmdline/cmdline_resolver.cc and hence is commandline-specific. I tried to fix this in zsh like this: https://salsa.debian.org/debian/zsh/-/commit/801f5e105ad6d1f767d28c8311edd263790f419f And it indeed fixed the crossbuild CI check: https://salsa.debian.org/debian/zsh/-/jobs/1946010 But unfortunately then on the buildds it failed for the arch:all build with "B-D uninstallable" (note the missing 5.8-8 upload on https://buildd.debian.org/status/logs.php?pkg=zsh=all) and I had to revert that "fix". > Architecture: amd64 (x86_64) > Foreign Architectures: i386 I wonder if this is a multiarch related bug since the case I mentioned above was a cross-build and hence also has multiarch involved. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
