Dear Maintainer, thanks for aptitude, I'm using it daily. I'm typically running on Debian/unstable, and frequently experience the following problem with the TUI: - open 'aptitude' - select a package PACKAGE to be installed - hit 'g' - aptitude opens new *red* window where it prints - the error window grows as one such line is printed about every 500ms until it finally fills the entire height of the screen - aptitude remains somewhat operational (e.g. you can 'q'uit in the background) but refuses to install the actual package - quitting aptitude and restarting it makes the problem go away I have no idea why this happens, but originally thought it might be related to not having run 'update' as a first step. 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). in any case, i have not been able to find a way to reliably reproduce the problem (it just happens every now and then). i've seen this problem for a "long time" by now (probably pre 2021) i've attached a screenshot.
Hi IOhannes, IOhannes m zmoelnig wrote: 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. Hmmmm. 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". 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). Ack. Yes, haven't seen it recently. 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 <debian-tex-maint@lists.debian.org> 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&arch=all) and I had to revert that "fix". 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
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). 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. '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
Hi David, David Kalnischkies wrote: […] […] Thanks for these explanations and clarifications, much appreciated! Regards, Axel