Package: apt-show-versions Version: 0.22.12 Followup-For: Bug #825036 Dear Maintainer,
Hi! I started to report this a few weeks ago then got sidetracked. The issue was fixed by simply reinstalling, but now it's showing up again on one of my maybe 4 Debian Bullseye debootstrap installs. Of note, I haven't used this package in a couple years. I install it as a fan favorite kind of thing to show support since it was a huge help when I was newer at personalizing Debian. Also of note is that I wasn't familiar with how some portion of apt-show-versions gets deleted and then refreshed (?). When this occurred a few weeks ago, I had an install that hadn't been upgraded yet. It still had its /var/cache/apt-show-versions directory where that entire directory was missing from the other installs that were hitting this failure. This is the error message that kicks out at the end of "apt-get update": ++++ BEGIN APT-GET UPDATE APT-SHOW-VERSIONS ERROR ++++ can't create /var/cache/apt-show-versions/files: No such file or directory at /usr/bin/apt-show-versions line 197. Reading package lists... Done E: Problem executing scripts APT::Update::Post-Invoke-Success 'test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i' E: Sub-process returned an error code ++++ END APT-GET UPDATE APT-SHOW-VERSIONS ERROR ++++ Today I "cognitively" caught the reference to /usr/bin/apt-show-versions. Shortest take on that possible is to ask... could Debian's move toward symlinking /bin and /sbin, etc, have something to do with this? Yes, I see this bug is 2016, but still.. maybe something even back then was already in progress regarding symlinks. Am asking because a few years ago, my debootstrap installs' root users all started whining, "I HAVE NO NAME!" By some miracle, I was able to make a connection that symlinking a HUGE previously downloaded packages hoard to /var/cache/apt/archives was the culprit. The fix for that was to "mount -B" the same hoard to /apt/archives instead. That issue hasn't reoccurred since I made that "mount -B" switch. In the interest of fairness that a user deviance could be a potential trigger, this following error was also thrown today. This text appears in full in between the "Reading package lists" and "Problem executing scripts" lines: ++++ BEGIN SIGNAL ERROR ++++ W: GPG error: https://updates.signal.org/desktop/apt xenial InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D980A17457F6FB06 E: The repository 'https://updates.signal.org/desktop/apt xenial InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. ++++ END SIGNAL ERROR ++++ What that's telling me, the (deviant) User, is that I rsync'ed that particular instance of Bullseye. In the process, I forgot to take the final, appropriate "wget -O- | apt-key add" vendor trust step. Yes, I know, third party. Never used it, just installed because it was potentially going to be used by a group whose advocacy I was going to support. I can't remember if that error was thrown the other several times this happened a few weeks ago. Signal's not installed on all of my Bullseye partitions BECAUSE I haven't used it. I'm just thinking that MAYBE its failure as *that one, singular product's method of failing* somehow stops something else from occurring. In other words, one step might be to make sure it's not touching something it shouldn't be touching when it fails. Lastly, these were what I was going to send when I first encountered this a few weeks ago. These are from my history.log and reflect the last two Bullseye "apt-get upgrade" actions performed just before this apt-show-versions error originally occurred. Both are included because I figure it could either be that the dust settled on the 2021.05.26 upgrade (via reboot) and maybe caused this, OR the glitch could have also already registered while the 2021.05.28 upgrade was still actively in progress and not yet completed. 2021.05.26 APT-GET UPGRADE FOR BULLSEYE Upgrade: iwd:amd64 (1.12-1, 1.14-3), libgtk2.0-bin:amd64 (2.24.33-1, 2.24.33-2), libgail18:amd64 (2.24.33-1, 2.24.33-2), libgtk2.0-common:amd64 (2.24.33-1, 2.24.33-2), libgtk2.0-0:amd64 (2.24.33-1, 2.24.33-2), xfig:amd64 (1:3.2.8-2, 1:3.2.8-3), gtk2-engines-pixbuf:amd64 (2.24.33-1, 2.24.33-2), xfig-libs:amd64 (1:3.2.8-2, 1:3.2.8-3), libgail-common:amd64 (2.24.33-1, 2.24.33-2) 2021.05.28 APT-GET UPGRADE FOR SAME BULLSEYE INSTALL Upgrade: libxml2-dev:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7), libxml2-utils:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7), opera-stable:amd64 (76.0.4017.123, 76.0.4017.154), libxml2:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7), python3-yaml:amd64 (5.3.1-3+b1, 5.3.1-4), python3-libxml2:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7) That's all I can think of right now. Hope this helps beyond the simple fix of simply reinstalling the package. Thanks for all you do to help Debian! Cindy :) -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-show-versions depends on: ii apt 2.2.3 ii libapt-pkg-perl 0.1.39 ii perl [libstorable-perl] 5.32.1-4 apt-show-versions recommends no packages. apt-show-versions suggests no packages. -- no debconf information
