Bug#1065310: deborphan should take "Provides:" into account
On 2024-07-07 18:21:17 +0300, jim_p wrote: > As a user of deborphan for more than a decade on all my systems, > it is sad to see it go. Is there an apt command or parameter that > replaces it? More or less, and this is not really satisfactory. See the discussion at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them
Control: reassign -1 apt Control: retitle -1 When installing a package, apt should always upgrade rather than remove packages to satisfy dependencies Control: severity -1 normal Control: found -1 2.6.1 Control: found -1 2.9.5 Control: found -1 2.9.6 Note: In the initial test, I had done "apt install libpoppler-dev". "apt install libqt6core6t64" was just an attempt to simplify it, but the result is exactly the same. On 2024-07-03 19:13:37 +0200, Patrick Franz wrote: > So in both cases, apt proposes a solution that does exactly what you > asked it for. In the first example, there are multiple solutions and apt > happened to pick one that you don't want. Why it picked that one and not > another one, I do not know. Maybe it found this solution quicker. In any case, this is not satisfactory. Upgrades should always be favored instead of removals. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them
In case this can be useful, I've attached the output of apt-get install libqt6core6t64 -s -o Debug::pkgProblemResolver=true -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) zira:~> apt-get install libqt6core6t64 -s -o Debug::pkgProblemResolver=true NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Building dependency tree... Reading state information... Starting pkgProblemResolver with broken count: 16 Starting 2 pkgProblemResolver with broken count: 16 Investigating (0) libqt6svg6:amd64 < 6.4.2-4+b2 -> 6.6.2-2 @ii umU Ib > Broken libqt6svg6:amd64 Depends on libqt6gui6:amd64 < none | 6.6.2+dfsg-8 @un uH > (>= 6.6.2+dfsg~) Considering libqt6gui6:amd64 0 as a solution to libqt6svg6:amd64 9 Re-Instated libxcb-cursor0:amd64 Re-Instated libqt6gui6:amd64 Re-Instated libqt6svg6:amd64 Investigating (0) libqt6qml6:amd64 < 6.4.2+dfsg-4+b2 -> 6.6.2+dfsg-3 @ii umU Ib > Broken libqt6qml6:amd64 Depends on libqt6network6:amd64 < none | 6.6.2+dfsg-8 @un uH > (>= 6.6.2+dfsg~) Considering libqt6network6:amd64 0 as a solution to libqt6qml6:amd64 7 Re-Instated libqt6network6:amd64 Re-Instated libqt6qml6:amd64 Investigating (0) qt6-wayland:amd64 < 6.4.2-5+b2 -> 6.6.2-2 @ii umU Ib > Broken qt6-wayland:amd64 Depends on libqt6opengl6:amd64 < none | 6.6.2+dfsg-8 @un uH > (>= 6.6.2+dfsg~) Considering libqt6opengl6:amd64 0 as a solution to qt6-wayland:amd64 7 Re-Instated libqt6opengl6:amd64 Re-Instated qt6-wayland:amd64 Investigating (0) libqt6gui6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mK Ib > Broken libqt6gui6t64:amd64 Depends on qt6-base-abi:amd64 < none @un mH > (= 6.4.2) Considering libqt6core6t64:amd64 10069 as a solution to libqt6gui6t64:amd64 7 Removing libqt6gui6t64:amd64 rather than change qt6-base-abi:amd64 Investigating (0) libqt6dbus6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mK Ib > Broken libqt6dbus6t64:amd64 Depends on qt6-base-abi:amd64 < none @un mH > (= 6.4.2) Considering libqt6core6t64:amd64 10069 as a solution to libqt6dbus6t64:amd64 6 Removing libqt6dbus6t64:amd64 rather than change qt6-base-abi:amd64 Investigating (0) libqt6widgets6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mK Ib > Broken libqt6widgets6t64:amd64 Depends on libqt6gui6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mR > (>= 6.4.0) Considering libqt6gui6t64:amd64 7 as a solution to libqt6widgets6t64:amd64 1 Removing libqt6widgets6t64:amd64 rather than change libqt6gui6t64:amd64 Investigating (0) wireshark:amd64 < 4.2.4-1 | 4.2.5-2+b1 @ii umH Ib > Broken wireshark:amd64 Depends on libqt6gui6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mR > (>= 6.4.0) Considering libqt6gui6t64:amd64 7 as a solution to wireshark:amd64 0 Re-Instated libqt6widgets6:amd64 Re-Instated libnghttp3-9:amd64 Re-Instated libwsutil15t64:amd64 Re-Instated libwireshark-data:amd64 Re-Instated libwireshark17t64:amd64 Re-Instated libwiretap14t64:amd64 Re-Instated wireshark-common:amd64 Re-Instated wireshark:amd64 Investigating (0) libqt6opengl6:amd64 < none -> 6.6.2+dfsg-8 @un uN Ib > Broken libqt6opengl6:amd64 Breaks on libqt6opengl6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mK Ib > (< 6.6.2+dfsg-8) Considering libqt6opengl6t64:amd64 0 as a solution to libqt6opengl6:amd64 0 Holding Back libqt6opengl6:amd64 rather than change libqt6opengl6t64:amd64 Investigating (0) libqt6opengl6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mK Ib > Broken libqt6opengl6t64:amd64 Depends on libqt6gui6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mR > (>= 6.3.1) Considering libqt6gui6t64:amd64 7 as a solution to libqt6opengl6t64:amd64 0 Removing libqt6opengl6t64:amd64 rather than change libqt6gui6t64:amd64 Investigating (0) libpoppler-qt6-3t64:amd64 < 24.02.0-4 | 24.02.0-5+b1 @ii umH Ib > Broken libpoppler-qt6-3t64:amd64 Depends on libqt6gui6t64:amd64 < 6.4.2+dfsg-21.1+b1 @ii mR > (>= 6.1.2) Considering libqt6gui6t64:amd64 7 as a solution to libpoppler-qt6-3t64:amd64 0 Re-Instated libpoppler134:amd64 Re-Instated libpoppler-qt6-3t64:amd64 Investigating (0) libqt6network6:amd64 < none -> 6.6.2+dfsg-8 @un uN Ib > Broken libqt6network6:amd64 Depends on libqt6dbus6:amd64 < none | 6.6.2+dfsg-8 @un uH > (>= 6.4.0) Considering libqt6dbus6:amd64 0 as a solution to libqt6network6:amd64 0 Holding Back libqt6network6:amd64 rather than change libqt6dbus6:amd64 Investigating (0) libqt6gui6:amd64 < none -> 6.6.2+dfsg-8 @un uN Ib > Broken libqt6gui6:amd64 Depends on libqt6dbus6:amd64 < none | 6.6.2+dfsg-8 @un uH > (>= 6.4.0) Considering libqt6dbus6:amd64 0 as a so
Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them
Note that as noted in its changelog, there was a regression in apt 2.9.5. However, apt 2.9.6 yields the same behavior. And to be sure that there wasn't any other regression, I downgraded apt to stable and installed libapt-pkg6.0 from stable (replacing the libapt-pkg6.0t64 package from the t64 transition): apt install apt/stable libapt-pkg6.0/stable (this also removed non-important packages for the test), i.e. version 2.6.1, and there was still the same behavior: zira:~> apt install libqt6core6t64 -s NOTE: This is only a simulation! apt needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: [...] The following additional packages will be installed: libnghttp3-9 libpoppler-cpp0t64 libpoppler-dev libpoppler-glib8t64 libpoppler-private-dev libpoppler-qt5-1t64 libpoppler134 libqt6core5compat6 libqt6sql6 libqt6sql6-sqlite libwireshark-data libwireshark17t64 libwiretap14t64 libwsutil15t64 poppler-utils wireshark-common Suggested packages: geoipupdate geoip-database-extra libjs-leaflet libjs-leaflet.markercluster snmp-mibs-downloader wireshark-doc Recommended packages: wireshark | tshark The following packages will be REMOVED: libpoppler-qt6-3t64 libqt6dbus6t64 libqt6gui6t64 libqt6multimedia6 libqt6network6t64 libqt6opengl6t64 libqt6printsupport6t64 libqt6qml6 libqt6qmlmodels6 libqt6quick6 libqt6sql6t64 libqt6svg6 libqt6waylandclient6 libqt6waylandcompositor6 libqt6waylandeglclienthwintegration6 libqt6waylandeglcompositorhwintegration6 libqt6widgets6t64 libqt6wlshellintegration6 qpdfview qpdfview-djvu-plugin qpdfview-pdf-poppler-plugin qpdfview-ps-plugin qpdfview-translations qt6-gtk-platformtheme qt6-qpa-plugins qt6-wayland wireshark The following NEW packages will be installed: libnghttp3-9 libqt6sql6 The following packages will be upgraded: libpoppler-cpp0t64 libpoppler-dev libpoppler-glib8t64 libpoppler-private-dev libpoppler-qt5-1t64 libpoppler134 libqt6core5compat6 libqt6core6t64 libqt6sql6-sqlite libwireshark-data libwireshark17t64 libwiretap14t64 libwsutil15t64 poppler-utils wireshark-common [...] thus removing qpdfview and wireshark. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them
Hi Patrick, On 2024-07-03 00:30:55 +0200, Patrick Franz wrote: > this seems more a problem of apt than of Qt. Even if apt could be improved, this would still be a bug in the concerned packages, which must declare adequate relationships to allow the upgrade. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059068#15 where David Kalnischkies says You should really know this by now as that isn't your first report, but okay: Upgrade problems are NEVER a problem to be solved in apt, they are ALWAYS a problem in the involved packages. NO EXCEPTIONS. > For some reason, apt is not able to resolve the dependencies when you > only want to upgrade libqt6core6t64, but is able to do so when you want > to upgrade libqt6core6t64 and wireshark. > > To me, that means that the dependencies in Qt are correct (that it wants > to replace some libqt6...t64 packages with non-t64 versions is the > correct solution). See above. It seems that the issue is that the upgrade of libqt6core6t64 alone seems to remove other Qt packages instead of upgrading them. In particular, "apt install libqt6core6t64" wants to remove qt6-wayland, but if I try "apt install libqt6core6t64 qt6-wayland", then the upgrade is fine. So there seems to be really something wrong with the Qt package relationships. > Have you tried upgrading just libqt6core6t64 with aptitude ? aptitude doesn't want to do anything. aptitude is often much worse (but much safer as it will normally not break "Recommends" without confirmation). And sometimes it can't even handle simple cases, where it has only some dependencies to install. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them
Source: qt6-base Version: 6.6.2+dfsg-8 Severity: serious If I want to upgrade libqt6core6t64, apt wants to remove qpdfview and wireshark instead of upgrading them: # apt install libqt6core6t64 The following packages were automatically installed and are no longer required: libnghttp3-3 libqt6sql6 libts0t64 libqt6concurrent6t64 libqt6sql6-sqlite Use 'apt autoremove' to remove them. Upgrading: libpoppler-cpp0t64 libpoppler134 libwireshark17t64 libpoppler-dev libqt6core5compat6 libwiretap14t64 libpoppler-glib8t64 libqt6core6t64 libwsutil15t64 libpoppler-private-dev libqt6sql6-sqlite poppler-utils libpoppler-qt5-1t64 libwireshark-data wireshark-common Installing dependencies: libnghttp3-9 libqt6sql6 REMOVING: libpoppler-qt6-3t64 libqt6waylandeglclienthwintegration6 libqt6dbus6t64libqt6waylandeglcompositorhwintegration6 libqt6gui6t64 libqt6widgets6t64 libqt6multimedia6 libqt6wlshellintegration6 libqt6network6t64 qpdfview libqt6opengl6t64 qpdfview-djvu-plugin libqt6printsupport6t64qpdfview-pdf-poppler-plugin libqt6qml6qpdfview-ps-plugin libqt6qmlmodels6 qpdfview-translations libqt6quick6 qt6-gtk-platformtheme libqt6sql6t64 qt6-qpa-plugins libqt6svg6qt6-wayland libqt6waylandclient6 wireshark libqt6waylandcompositor6 Summary: Upgrading: 15, Installing: 2, Removing: 27, Not Upgrading: 97 Download size: 21.6 MB / 25.9 MB Freed space: 60.1 MB Continue? [Y/n] n Abort. This is unnecessary, as wireshark could be upgraded. This can be seen by explicitly providing wireshark as to be upgraded: # apt install libqt6core6t64 wireshark The following package was automatically installed and is no longer required: libnghttp3-3 Use 'apt autoremove' to remove it. Upgrading: libpoppler-cpp0t64libqt6wlshellintegration6 libpoppler-devlibwireshark-data libpoppler-glib8t64 libwireshark17t64 libpoppler-private-devlibwiretap14t64 libpoppler-qt5-1t64 libwsutil15t64 libpoppler-qt6-3t64 poppler-utils libpoppler134 qpdfview libqt6core5compat6qpdfview-djvu-plugin libqt6core6t64qpdfview-pdf-poppler-plugin libqt6multimedia6 qpdfview-ps-plugin libqt6qml6qt6-gtk-platformtheme libqt6qmlmodels6 qt6-qpa-plugins libqt6quick6 qt6-wayland libqt6sql6-sqlite wireshark libqt6svg6wireshark-common libqt6waylandclient6 wireshark-doc libqt6waylandcompositor6 Installing dependencies: libnghttp3-9 libqt6network6 libqt6sql6 libqt6dbus6 libqt6opengl6libqt6widgets6 libqt6gui6libqt6printsupport6 libxcb-cursor0 REMOVING: libqt6dbus6t64 libqt6sql6t64 libqt6gui6t64 libqt6waylandeglclienthwintegration6 libqt6network6t64 libqt6waylandeglcompositorhwintegration6 libqt6opengl6t64libqt6widgets6t64 libqt6printsupport6t64 Summary: Upgrading: 33, Installing: 9, Removing: 9, Not Upgrading: 96 Download size: 37.0 MB / 53.9 MB Space needed: 3012 kB / 150 GB available Continue? [Y/n] n Abort. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1074260: otpclient-cli usage disagrees with the man page
Control: reopen -1 Control: retitle -1 otpclient-cli usage disagrees with the man page Control: severity -1 normal On 2024-06-26 13:03:06 +, Debian Bug Tracking System wrote: > Hi Vincent, > > On Tue, 25 Jun 2024 15:09:17 +0200 Vincent Lefevre wrote: > > > > "otpclient-cli show -a " or "otpclient-cli list" prompts > > for the password, but does not output anything else. > > The command is almost correct, but the hyphens are missing, > try this: > > $ otpclient-cli --show -a > > $ otpclient-cli --list This is not what the otpclient-cli(1) man page says: Main Options: -v, --version Show program version. show Show a token. list List all pairs of account and issuer. export Export data. I suspect that these were intended to be commands, thus without hyphens. But perhaps that this is no longer the case. So either the program or the man page needs to be changed. The man page also gives Help Options: -h, --help Show this help. --help-show Show options. --help-export Export options. The -h / --help option works and gives a different usage, and --help-show and --help-export do not work. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1074260: otpclient-cli: does not output anything
Package: otpclient-cli Version: 3.6.0-1 Severity: grave Justification: renders package unusable "otpclient-cli show -a " or "otpclient-cli list" prompts for the password, but does not output anything else. No issues with the GUI version. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) 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 otpclient-cli depends on: ii libc62.38-13 ii libcotp3 3.0.0-1+b1 ii libgcrypt20 1.10.3-3 ii libglib2.0-0t64 2.80.3-1 ii libjansson4 2.14-2+b2 ii libsecret-1-00.21.4-1+b1 ii libuuid1 2.40.1-9 Versions of packages otpclient-cli recommends: ii otpclient 3.6.0-1 otpclient-cli suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1073074: Info received (Bug#1073074: Acknowledgement (firefox: looses previous tabs))
Hi, On 2024-06-19 13:39:56 -0700, Phil Dibowitz wrote: > Mike Hommey wrote: > > This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1901899 > > Yes! I haven't been able to get it to remember my tabs for a week, but I put > in the password once, and now my tabs are properly restored on startup (even > if I don't enter the password). Nice catch, thanks! > > It'd be great if we could get 127.0.1 in which this is fixed. The firefox 127.0.1-1 Debian package is now available. Is this bug fixed? -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1073053: unbound returns SERVFAIL for every request
Package: unbound Version: 1.20.0-1 Severity: grave Justification: renders package unusable I've just installed unbound on a new machine to avoid bug 1070120. With /etc/resolv.conf containing only nameserver 127.0.0.1 I get SERVFAIL for every request. For instance: $ host google.com Host google.com not found: 2(SERVFAIL) -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 unbound depends on: ii adduser 3.137 ii init-system-helpers 1.66 ii libc62.38-12.1 ii libevent-2.1-7t642.1.12-stable-10 ii libhiredis1.1.0 1.2.0-6+b2 ii libnghttp2-141.62.1-1 ii libprotobuf-c1 1.4.1-1+b2 ii libpython3.11t64 3.11.9-1 ii libssl3t64 3.2.2-1 ii libsystemd0 255.5-1 Versions of packages unbound recommends: ii dns-root-data 2024041801 Versions of packages unbound suggests: ii apparmor 3.0.13-2 ii openssl 3.2.2-1 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1069449: firejail: FTBFS on armhf: ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined
On 2024-04-20 14:51:12 +0200, Lucas Nussbaum wrote: > > /tmp/ccnMX2lv.s: Assembler messages: > > /tmp/ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined > > /tmp/ccnMX2lv.s:2079: Error: symbol `freopen64' is already defined > > /tmp/ccnMX2lv.s:3164: Error: symbol `__stat64_time64' is already defined > > /tmp/ccnMX2lv.s:3474: Error: symbol `__lstat64_time64' is already defined > > make[2]: *** [../../src/so.mk:23: libtrace.o] Error 1 firejail has been removed from testing due to this bug. Any news? I think that the buggy patch for musl https://github.com/netblue30/firejail/commit/a86c4fe93f130752a862ff0a5ee75f073c3586b1 mentioned in the upstream bug https://github.com/netblue30/firejail/issues/5906 should be reverted. BTW, for architectures without -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 (such as amd64), though the code compiles and linking succeeds too, I'm wondering whether the behavior is correct, because there are 2 definitions of some functions (like fopen64): one from libtrace and one from the glibc. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1071829: fail2ban: spurious ">" character in paths-debian.conf
Package: fail2ban Version: 1.1.0-3 Severity: grave Justification: renders package unusable The /etc/fail2ban/paths-debian.conf file starts with ># Debian which yields an error: May 25 10:39:45 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service. May 25 10:39:45 qaa fail2ban-server[172274]: 2024-05-25 10:39:45,628 fail2ban [172274]: ERROR Failed during configuration: File contains no section headers. May 25 10:39:45 qaa fail2ban-server[172274]: file: '/etc/fail2ban/paths-debian.conf', line: 1 May 25 10:39:45 qaa fail2ban-server[172274]: '># Debian\n' May 25 10:39:45 qaa fail2ban-server[172274]: 2024-05-25 10:39:45,630 fail2ban [172274]: ERROR Async configuration of server failed May 25 10:39:45 qaa systemd[1]: fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION May 25 10:39:45 qaa systemd[1]: fail2ban.service: Failed with result 'exit-code'. The first hunk in debian/patches/update_backend_system.diff, which adds this character, should be removed: Index: fail2ban/config/paths-debian.conf === --- fail2ban.orig/config/paths-debian.conf +++ fail2ban/config/paths-debian.conf @@ -1,4 +1,4 @@ -# Debian +># Debian [INCLUDES] -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 fail2ban depends on: ii python3 3.11.8-1 ii python3-systemd 235-1+b3 Versions of packages fail2ban recommends: ii iptables 1.8.10-3 ii nftables 1.0.9-2 ii python3-pyinotify 0.9.6-2 ii whois 5.5.23 Versions of packages fail2ban suggests: ii mailutils [mailx] 1:3.17-1.1+b2 pn monit ii sqlite33.45.3-1 pn system-log-daemon -- Configuration Files: /etc/fail2ban/action.d/mikrotik.conf [Errno 2] No such file or directory: '/etc/fail2ban/action.d/mikrotik.conf' /etc/fail2ban/filter.d/dante.conf [Errno 2] No such file or directory: '/etc/fail2ban/filter.d/dante.conf' /etc/fail2ban/filter.d/nginx-error-common.conf [Errno 2] No such file or directory: '/etc/fail2ban/filter.d/nginx-error-common.conf' /etc/fail2ban/filter.d/nginx-forbidden.conf [Errno 2] No such file or directory: '/etc/fail2ban/filter.d/nginx-forbidden.conf' /etc/fail2ban/filter.d/routeros-auth.conf [Errno 2] No such file or directory: '/etc/fail2ban/filter.d/routeros-auth.conf' -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"
On 2024-05-24 14:52:08 +0200, Sylvestre Ledru wrote: > Could you please propose a PR ? I didn't find the time to fix this lately > (and i don't use fail2ban anymore). https://salsa.debian.org/python-team/packages/fail2ban/-/merge_requests/9 This restores the use of nftables and selects the systemd backend for the same set of jails as Fedora and Arch (openSUSE also has mysql, but this is probably a mistake because Fedora and Arch had it initially but it got removed because "mysqld does not log login attempts to the journal" -- I did not check whether this is still the case or the Fedora and Arch settings are out-of-date). Note that the setting for sshd is necessary. For the other jails, this may also be needed if the user has enabled other jails but has not set the backend explicitly (not needed with fail2ban 1.0.2-3 in testing). For instance, in my case, I had enabled the postfix jail, and without this setting, after the upgrade from testing, fail2ban was failing for the same reason as with sshd. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"
On 2024-05-07 08:35:28 +0200, Sylvestre Ledru wrote: > > Le 07/05/2024 à 03:57, Vincent Lefevre a écrit : > > On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote: > > > May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 > > > fail2ban[557228]: ERROR Failed during configuration: > > > Have not found any log file for sshd jail > > I suppose that this is because sshd no longer uses the systemd > > backend. This is wrong. If I understand correctly, the point of > > > > https://github.com/fail2ban/fail2ban/issues/3292#issuecomment-2078361360 > > > > is to no longer use the systemd backend for all jails, but for > > sshd only. So "backend = systemd" has been removed from DEFAULT, > > but the above comment also points to > > > > https://github.com/fail2ban/fail2ban/commit/85a4881a9a818b6a746109f74980919296eedad0 > > > > which adds for DEFAULT in paths-debian.conf: > > > > > > banaction = nftables > > banaction_allports = nftables[type=allports] > > > > sshd_backend = systemd > > > > > > But paths-debian.conf has not changed in the fail2ban 1.1.0-1 package. > > > ok, thanks. > > Any idea what the fix should be? I am a bit lost in this conversation :/ For the sshd issue (mainly this bug), upstream changed 2 visible things in the above commit: * It changed default's "backend = systemd" to "sshd_backend = systemd" with the reason: remove default backend (systemd) - too dangerous for all jails, because it's hardly to find an error if some jail mistakenly start to monitor journal instead of logfile (even if it exists), but will silently find nothing Indeed, using systemd as the backend for all jails by default may yield silent breakage for services that do not use syslog for logging (this is not like this had already been the default backend). * It disabled the sshd jail by default. What you did in https://salsa.debian.org/python-team/packages/fail2ban/-/commit/c03b1a832132f8033a6c698650daba9c48e22c62 is that the following lines are removed. [DEFAULT] banaction = nftables banaction_allports = nftables[type=allports] backend = systemd (leaving the sshd jail enabled, contrary to upstream's Debian files). Since the sshd jail is still enabled but its backend is now the default backend, it will use a syslog log file (/var/log/auth.log if this has not changed), which doesn't exist if rsyslog is not installed. Said otherwise, the following bugs are back: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037437 (you fixed them in https://salsa.debian.org/python-team/packages/fail2ban/-/commit/e634fa863e2d8035181e9e03476ae6dd56044fe6 on 2024-01-02 by the "backend = systemd", but reverted them in c03b1a832132f8033a6c698650daba9c48e22c62). There are several (non-exclusive) solutions: 1. Do not enable the sshd jail by default, following upstream's decision, and let the user decide whether he should change the backend for sshd when he enables the sshd jail. The side effects after an upgrade: * The sshd jail may no longer be enabled (i.e. if the user hasn't explicitly enabled it in jail.local). So this will need to be announced. * If it is still enabled (due to jail.local), this solution alone (without (2) or (3)) will not fix the problem. 2. Add "sshd_backend = systemd" like upstream, so that the sshd jail will use the systemd backend. A possible side effect after an upgrade from stable: this will break for users who do not use systemd (but contrary to the default "backend = systemd" issue, this should not be a silent breakage, because fail2ban should be able to detect that the systemd logs are not available at all - not tested, though). 3. Recommend the rsyslog package (or "rsyslog | system-log-daemon"). This would ensure that any backend will work, but would add another daemon and additional log files (note that rsyslog is OK, but I don't know whether the other log daemons are compatible with fail2ban's default rules). Moreover, I don't know why you removed the banaction = nftables banaction_allports = nftables[type=allports] from [DEFAULT]. This was about a "switch from iptables to nftables" as said at https://github.com/fail2ban/fail2ban/discussions/3575 Indeed, iptables is not always installed by default, while nftables seems to be installed by the Debian installer (in any case, iptables recommends nftables). So, I suppose that these lines would still be necessary. About the other services that log to the journal via syslog, things like "postfix_backend = system
Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)
On 2024-05-20 01:03:00 +0200, Vincent Lefevre wrote: > The issue remains after downgrading the emacs packages to testing > (1:29.3+1-2). And it disappears after downgrading the packages of gnupg2 source to 2.2.40-3. The issue about the file disappearing does not occur with "emacs -Q" (I'll have to find the exact cause). This is a more general issue, but this bug about emacs hanging just makes it much worse. I'm using (defun find-backup-file-name (fn) (list (concat "~/.poub/" (file-name-nondirectory fn) "~"))) and there's actually a backup there, but this should be regarded as very temporary, as I sometimes clean up this directory. Files should never expected to be *only* there. I suspect wrong logic in Emacs, because with the downgraded gnupg, the file disappearance occurs only after the first save (according to strace, Emacs does a rename to create the backup instead of copying the file). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)
Control: found -1 1:29.3+1-2 On 2024-05-20 00:45:40 +0200, Vincent Lefevre wrote: > On 2024-05-18 01:22:03 +0200, Alex Andreotti wrote: > > [...] Probably a "recent" apt upgrade broke it but I don't know > > exactly which one, before this problem I used to save .gpg files > > often > > Here, there was no such issue on May 1, where I had emacs 1:29.3+1-2. > But gnupg2 has also been upgraded from 2.2.40-3 to 2.2.43-3, though. The issue remains after downgrading the emacs packages to testing (1:29.3+1-2). Note: When Emacs hangs, the gpg process is still running. Something of the form: gpg --no-tty --status-fd 1 --yes --use-agent --enable-progress-filter --command-fd 0 --output epg-outputsyl2kr --encrypt -r *** -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070713: how-can-i-help: undefined local variable or method autorm_header_done
On 2024-05-10 12:20:43 +0200, Diederik de Haas wrote: > Control: severity -1 grave > > On 07 May 2024 19:35:30 +0200 Nicolas Noirbent wrote: > > Package: how-can-i-help > > Version: 18 > > Severity: important > > Tags: patch > > > > Running how-can-i-help outputs nothing past the initial banner, due to an > > undefined variable: > > Which makes the package unusable, so upgrading severity accordingly More or less. I got the error after a bug listed at "New bugs where assistance is requested": New bugs where assistance is requested (tagged 'help'): - libglib2.0-dev - https://bugs.debian.org/1070773 - libglib2.0-dev:i386 on amd64 should not require qemu-user /usr/bin/how-can-i-help:338:in `': undefined local variable or method `autorm_header_done' for main:Object (NameError) autorm_header_done == 0 ^^ Did you mean? autorm_date BTW, I hadn't got any error after 6 upgrades (not involving ruby) with how-can-i-help 18, but now I get an error. It should probably have a testsuite to be able to trigger issues under various conditions. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
Control: reopen -1 On 2024-05-07 11:25:05 +0200, Vincent Lefevre wrote: > What's the status of this bug? > > apt-listbugs still reports python3-lxml as buggy: > > serious bugs of python3-lxml (5.1.0-1 → 5.2.1-1) > b1 - #1068349 - nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean > (Fixed: nbconvert/6.5.3-5) > Summary: > python3-lxml(1 bug) > > Indeed, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068349 > says: "Found in versions nbconvert/6.5.3-4, lxml/5.2.1-1". > > So python3-lxml 5.2.1-1 is regarded as buggy. And this bug prevents the migration to testing: https://tracker.debian.org/pkg/lxml testing migrations [...] Issues preventing migration: ∙ ∙ Updating lxml would introduce bugs in testing: #1068349 It seems that this bug (assigned to 2 different packages) has been closed by mistake, due to the fix of nbconvert: Format: 1.8 Date: Sun, 14 Apr 2024 16:52:34 +0100 Source: nbconvert Architecture: source Version: 6.5.3-5 [...] Closes: 1042699 1068349 [...] * (Build-)depend on python3-lxml-html-clean (closes: #1068349). But this is inconsistent with the fact that lxml is still marked as unfixed. So, reopening. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean
On 2024-04-07 22:06:05 +0100, Rebecca N. Palmer wrote: > To avoid being blocked by this bug, the pandas version I just uploaded > temporarily disables the documentation. > > This is also an option for any other affected packages that urgently need to > be uploaded. (I don't know whether the other two listed Blocks/Affects are > that urgent.) What's the status of this bug? apt-listbugs still reports python3-lxml as buggy: serious bugs of python3-lxml (5.1.0-1 → 5.2.1-1) b1 - #1068349 - nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean (Fixed: nbconvert/6.5.3-5) Summary: python3-lxml(1 bug) Indeed, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068349 says: "Found in versions nbconvert/6.5.3-4, lxml/5.2.1-1". So python3-lxml 5.2.1-1 is regarded as buggy. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"
On 2024-05-07 03:57:44 +0200, Vincent Lefevre wrote: > sshd_backend = systemd BTW, that would fix the issue only for sshd. But what about the other jails the user could have enabled in /etc/fail2ban/jail.local? The user configuration may rely on systemd being the default backend, at least the configured backend for these jails. For instance, concerning postfix, both paths-arch.conf and paths-opensuse.conf have "postfix_backend = systemd", but not paths-debian.conf. Other jails may be concerned. paths-arch.conf has # These services will log to the journal via syslog, so use the journal by # default. syslog_backend = systemd sshd_backend = systemd dropbear_backend = systemd proftpd_backend = systemd pureftpd_backend = systemd wuftpd_backend = systemd postfix_backend = systemd dovecot_backend = systemd and paths-opensuse.conf has # These services will log to the journal via syslog, so use the journal by # default. syslog_backend = systemd sshd_backend = systemd dropbear_backend = systemd proftpd_backend = systemd pureftpd_backend = systemd wuftpd_backend = systemd postfix_backend = systemd dovecot_backend = systemd mysql_backend = systemd But the user may also have his own services with associated jails... Either there should be a better fix or the change should be announced in NEWS.Debian, with a clear explanation on what to do. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"
On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote: > May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban >[557228]: ERROR Failed during configuration: Have not found > any log file for sshd jail I suppose that this is because sshd no longer uses the systemd backend. This is wrong. If I understand correctly, the point of https://github.com/fail2ban/fail2ban/issues/3292#issuecomment-2078361360 is to no longer use the systemd backend for all jails, but for sshd only. So "backend = systemd" has been removed from DEFAULT, but the above comment also points to https://github.com/fail2ban/fail2ban/commit/85a4881a9a818b6a746109f74980919296eedad0 which adds for DEFAULT in paths-debian.conf: banaction = nftables banaction_allports = nftables[type=allports] sshd_backend = systemd But paths-debian.conf has not changed in the fail2ban 1.1.0-1 package. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"
Package: fail2ban Version: 1.1.0-1 Severity: grave Justification: renders package unusable After the upgrade to 1.1.0-1, "systemctl status" gives × fail2ban.service - Fail2Ban Service Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Tue 2024-05-07 03:01:28 CEST; 25min ago Duration: 58ms Docs: man:fail2ban(1) Main PID: 557228 (code=exited, status=255/EXCEPTION) CPU: 55ms May 07 03:01:28 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service. May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban [557228]: ERROR Failed during configuration: Have not found any log file for sshd jail May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,230 fail2ban [557228]: ERROR Async configuration of server failed May 07 03:01:28 qaa systemd[1]: fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION May 07 03:01:28 qaa systemd[1]: fail2ban.service: Failed with result 'exit-code'. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 fail2ban depends on: ii python3 3.11.8-1 ii python3-systemd 235-1+b3 Versions of packages fail2ban recommends: ii iptables 1.8.10-3 ii nftables 1.0.9-1+b2 ii python3-pyinotify 0.9.6-2 ii whois 5.5.22 Versions of packages fail2ban suggests: ii mailutils [mailx] 1:3.17-1.1+b2 pn monit ii sqlite33.45.3-1 pn system-log-daemon -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070652: ruby-json: breaks how-can-i-help
Package: ruby-json Version: 2.7.2+dfsg-1 Severity: grave Justification: renders package unusable This new ruby-json version breaks how-can-i-help: [...] Unpacking ruby-json:amd64 (2.7.2+dfsg-1) over (2.6.3+dfsg-1+b2) ... Setting up ruby-json:amd64 (2.7.2+dfsg-1) ... /usr/bin/how-can-i-help:155:in `': uninitialized constant OpenStruct (NameError) proxy_uri = $proxy_url.nil? ? OpenStruct.new : URI.parse($proxy_url) ^^ -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 ruby-json depends on: ii libc6 2.38-7 ii libruby1:3.1+nmu1 ii libruby3.1t64 3.1.2-8.3 ruby-json recommends no packages. ruby-json suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common
Hi, On 2024-04-28 19:21:18 -0300, Facundo Gaich wrote: > Today I upgraded one of my unstable machines and saw several instances of > something I believe is the same bug. The resolver seems to be failing to > choose to upgrade certain dependencies. What's more, in the aptitude GUI > I can see the rightmost "latest available version" column change on the fly > when I select certain packages for upgrade. > > For example, I currently have libnm0 and libnm0:i386 installed at 1.46.0-1 > and I can see the latest version is 1.46.0-2. If I go into the GUI and > choose > to "Install" libnm0, the latest version column for libnm0:i386 will change > from 1.46.0-2 to 1.46.0-1. Choosing "Install" on libnm0:i386 will then > effectively > do a keep of libnm0 at 1.46.0-1. To fix this, I can either go into > libnm0:i386 and > explicitly choose the newest version or I can restart the GUI and then it > will > list and choose the latest version correctly when I do Install libnm0:i386. > > aptitude version: 0.8.13-6 This is not the same bug. In my case, the resolver chose to do exactly what I was asking to. This is also what appears in the aptitude logs. However, what really happened is something completely different: libmtp-common was attempted to be removed while no such removal was shown on the aptitude side (not even in its debug logs). This is not an issue with the resolver, but what happens somewhere between aptitude and dpkg. The "the latest version column for libnm0:i386 will change from 1.46.0-2 to 1.46.0-1" with the TUI corresponds to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979186 which I had reported 3 years ago and still occurs regularly. Concerning the buggy dependency resolutions (showing that aptitude does not favor the most obvious solutions, whether the TUI is used or not): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064969 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070027: fdisk: dependency problems prevent configuration of fdisk
) Error: Sub-process /usr/bin/dpkg returned an error code (2) End-Date: 2024-04-28 22:05:34 One can see "libfdisk1:amd64 (2.40-6, 2.40-8)", which was not done. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1070027: fdisk: dependency problems prevent configuration of fdisk
, (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 fdisk depends on: ii libc62.37-19 ii libfdisk12.40-6 ii libmount12.40-8 ii libncursesw6 6.4+20240414-1 ii libreadline8t64 8.2-4 ii libsmartcols12.40-8 ii libtinfo66.4+20240414-1 Versions of packages fdisk recommends: ii sensible-utils 0.0.22 fdisk suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1057463: marked as pending in supertuxkart
Hi Reiner, On Sat, Jan 6, 2024 at 1:03 PM Reiner Herrmann wrote: > > Control: tag -1 pending > > Hello, > > Bug #1057463 in supertuxkart reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/games-team/supertuxkart/-/commit/68a3bec7900d9921cb7f0428123db0eda945742a > > > Use system shaderc instead of embedded copy > > Closes: #1057463, #1031387 > > > (this message was generated automatically) > -- > Greetings > > https://bugs.debian.org/1057463 Just wanted to sanity check before uploading, is it ok for me to upload what's currently in salsa to close out #1057463 (and #995771), or are there other blockers / were you waiting on something else? Either way, thanks for fixing these bugs in supertuxkart! Regards, Vincent
Bug#1067316: gnucash-docs: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file:
[Not reassigning yet to openjdk-17-jre-headless, as the change was done on purpose, but Cc-ing the OpenJDK Team.] Hi, Since no-one looked at this issue in a month and gnucash-docs has now been removed from testing... On 2024-03-20 22:03:18 +0100, Lucas Nussbaum wrote: [...] > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > > /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: > > cannot open shared object file: No such file or directory [...] Indeed, on my machine qaa:~> ldd /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so | grep libharfbuzz libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x7fe984534000) where /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so comes from openjdk-17-jre-headless, but the build log shows that libharfbuzz0b is not installed, while being recommended by openjdk-17-jre-headless. However, I would say that even though libharfbuzz.so.0 is used by a particular library, this should be a "Depends:", not a "Recommends:". In any case, I think that gnucash-docs is not supposed to know the libfontmanager.so internals, i.e. this cannot be a bug in gnucash-docs. But also qaa:~> ldd /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so | grep freetype libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x7f835ed1d000) while libfreetype6 is also only recommended. openjdk-17 (17.0.10+7-3) unstable; urgency=medium [...] * Make the dependencies for libfontmanager.so and libjsound.so recommendations in jre-headless, and dependencies in jre. [...] -- Matthias Klose Mon, 11 Mar 2024 16:08:33 +0100 which was done in commit https://salsa.debian.org/openjdk-team/openjdk/-/commit/6f0e4b17a1ff58aaf32da9be9abcf0224c481885 But why? A warning has been added in https://salsa.debian.org/openjdk-team/openjdk/-/commit/8010273018af3ada65de8901735ab60bb0dd5c0e but this is the kind of things that building systems will ignore. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1068713: closing 1068713
close 1068713 2.5.10-1 thanks This bug is already fixed in upstream release 2.5.10
Bug#1068637: apt does not always install Recommends
bin/apt-listbugs::InfoFD "20"; DPkg::Tools::Options::/usr/bin/apt-listchanges ""; DPkg::Tools::Options::/usr/bin/apt-listchanges::Version "2"; DPkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD "20"; DPkg::Post-Invoke ""; DPkg::Post-Invoke:: "[ ! -e /usr/bin/how-can-i-help ] || /usr/bin/how-can-i-help --apt"; AptListbugs ""; AptListbugs::Severities "critical,grave,serious"; AptListbugs::IgnoreRegexp "FTBFS"; apt-file ""; apt-file::Index-Names "deb"; apt-file::Parser ""; apt-file::Parser::Check-For-Description-Header "false"; Binary "apt-config"; Binary::apt ""; Binary::apt::APT ""; Binary::apt::APT::Keep-Downloaded-Packages "true"; Binary::apt::APT::Color "1"; Binary::apt::APT::Cache ""; Binary::apt::APT::Cache::Show ""; Binary::apt::APT::Cache::Show::Version "2"; Binary::apt::APT::Cache::AllVersions "0"; Binary::apt::APT::Cache::ShowVirtuals "1"; Binary::apt::APT::Cache::Search ""; Binary::apt::APT::Cache::Search::Version "2"; Binary::apt::APT::Cache::ShowDependencyType "1"; Binary::apt::APT::Cache::ShowVersion "1"; Binary::apt::APT::Get ""; Binary::apt::APT::Get::Upgrade-Allow-New "1"; Binary::apt::APT::Get::Update ""; Binary::apt::APT::Get::Update::InteractiveReleaseInfoChanges "1"; Binary::apt::APT::Cmd ""; Binary::apt::APT::Cmd::Show-Update-Stats "1"; Binary::apt::APT::Cmd::Pattern-Only "1"; Binary::apt::DPkg ""; Binary::apt::DPkg::Progress-Fancy "1"; Binary::apt::DPkg::Lock ""; Binary::apt::DPkg::Lock::Timeout "-1"; CommandLine ""; CommandLine::AsString "apt-config dump"; -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- /etc/apt/sources.list -- deb https://ftp.debian.org/debian/ stable main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ stable main contrib non-free non-free-firmware # Security updates (previously "stable/updates") deb https://security.debian.org/debian-security stable-security main contrib non-free non-free-firmware deb-src https://security.debian.org/debian-security stable-security main contrib non-free non-free-firmware # stable-updates, previously known as 'volatile' deb https://ftp.debian.org/debian/ stable-updates main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ stable-updates main contrib non-free non-free-firmware deb https://ftp.debian.org/debian/ testing main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ testing main contrib non-free non-free-firmware deb https://security.debian.org/ testing-security main contrib non-free non-free-firmware deb-src https://security.debian.org/ testing-security main contrib non-free non-free-firmware deb https://ftp.debian.org/debian/ unstable main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ unstable main contrib non-free non-free-firmware deb https://ftp.debian.org/debian/ experimental main deb-src https://ftp.debian.org/debian/ experimental main # -dbgsym packages; see # https://lists.debian.org/debian-devel/2015/12/msg00262.html deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main deb http://debug.mirrors.debian.org/debian-debug/ stable-debug main deb http://debug.mirrors.debian.org/debian-debug/ proposed-updates-debug main # Debian Mozilla team - https://mozilla.debian.net/ #deb http://http.debian.net/debian experimental main # Local repository for the default architecture. # Update with "dpkg-scanpackages . > Packages" from it. deb [trusted=yes] file:///var/local/apt ./ # Note: These are the default sources on all my Debian machines. # Additional sources should be put in the sources.list.d directory, # including local repositories for foreign architectures. # $Id: sources.list 163140 2023-11-10 23:20:16Z vinc17/qaa $ -- (no /etc/apt/sources.list.d/* present) -- -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 depends on: ii adduser 3.137 ii base-passwd 3.6.3 ii debian-archive-keyring 2023.4 ii gpgv2.2.40-3 ii libapt-pkg6.0t642.7.14 ii libc6 2.37-15.1 ii libgcc-s1 14-20240330-1 ii libgnutls30t64 3.8.5-1 ii libseccomp2 2.5.5-1 ii libstdc++6 14-20240330-1 ii libsystemd0 255.4-1+b1 Versions of packages apt recommends: ii ca-certificates 20240203 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.13-6 ii dpkg-dev1.22.6 ii gnupg 2.2.40-3 pn powermgmt-base -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0
On 2024-01-13 10:23:06 +0100, Bastian Blank wrote: > On Sat, Jan 13, 2024 at 01:03:17AM +0100, Karsten Kruse wrote: > > Is there something else that needs to be done to get the package back into > > testing? > > Yes, > https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/547 Any news? Note that lvm2 recommends this package. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1067523: firefox: CVE-2024-29943 / CVE-2024-29944 critical bugs, fixed in FF 124.0.1
Package: firefox Version: 124.0-1 Severity: grave Tags: security upstream fixed-upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team Firefox 124.0.1 is available upstream, which fixes 2 critical bugs: https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/ -- Package-specific info: -- Addons package information -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 firefox depends on: ii debianutils 5.17 ii fontconfig 2.15.0-1.1 ii libasound2t641.2.11-1+b1 ii libatk1.0-0t64 2.51.90-4 ii libc62.37-15.1 ii libcairo-gobject21.18.0-1+local1 ii libcairo21.18.0-1+local1 ii libdbus-1-3 1.14.10-4+b1 ii libevent-2.1-7t642.1.12-stable-8.1+b1 ii libffi8 3.4.6-1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b2 ii libgcc-s114-20240315-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b2 ii libglib2.0-0t64 2.78.4-5 ii libgtk-3-0t643.24.41-3 ii libnspr4 2:4.35-1.1+b1 ii libnss3 2:3.99-1 ii libpango-1.0-0 1.51.0+ds-4 ii libstdc++6 14-20240315-1 ii libvpx8 1.13.1-2 ii libx11-6 2:1.8.7-1 ii libx11-xcb1 2:1.8.7-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.4-1 ii procps 2:4.0.4-4 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages firefox recommends: ii libavcodec60 7:6.1.1-3 Versions of packages firefox suggests: ii fonts-lmodern 2.005-1 ii fonts-stix [otf-stix] 1.1.1-5 ii libcanberra0t64 [libcanberra0] 0.30-12.2 ii libgssapi-krb5-21.20.1-6 ii pulseaudio 16.1+dfsg1-3+b1 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64
On 2024-03-18 20:58:02 +0100, Gilles Filippini wrote: > Vincent Lefevre a écrit le 03/03/2024 à 01:08 : > > Package: libhdf5-103-1t64 > > Version: 1.10.10+repack-3.1 > > Severity: serious > > > > libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64. > > This makes the upgrade of curl impossible. > > How am I expected to solve this issue? As I understand it a binNMU should > suffice. Am I right? I think that the issue has now been fixed on the curl side: https://salsa.debian.org/debian/curl/-/commit/40bdd3894230d325d382d59684c32d74202eee5c -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
And on a 3rd machine, where I used aptitude --log-file=/tmp/aptitude.log --log-level=info dpkg: dependency problems prevent removal of libb2-1:amd64: libqt6core6t64:amd64 depends on libb2-1 (>= 0.98.1). dpkg: error processing package libb2-1:amd64 (--purge): dependency problems - not removing (Reading database ... 795189 files and directories currently installed.) Purging configuration files for libts0:amd64 (1.22-1+b1) ... Errors were encountered while processing: libb2-1:amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) In the logs, this package libb2-1 appears only twice: 2024-03-13 01:33:14 [140549832112320] aptcache.cc:2323 INFO aptitude.apt.cache - aptitudeDepCache::sweep(): reinstating libb2-1:amd64 2024-03-13 01:34:48 [140549832112320] aptcache.cc:2323 INFO aptitude.apt.cache - aptitudeDepCache::sweep(): reinstating libb2-1:amd64 I've attached the compressed log file corresponding to this upgrade. The packages that appear as REMOVE/INSTALL/UPGRADE in /var/log/aptitude: [REMOVE, NOT USED] libatrildocument3:amd64 1.26.2-1 [REMOVE, NOT USED] libatrilview3:amd64 1.26.2-1 [REMOVE, NOT USED] libgxps2:amd64 0.3.2-3 [INSTALL, DEPENDENCIES] libatrildocument3t64:amd64 1.26.2-1.1+b1 [INSTALL, DEPENDENCIES] libatrilview3t64:amd64 1.26.2-1.1+b1 [INSTALL, DEPENDENCIES] libgxps2t64:amd64 0.3.2-4+b1 [INSTALL, DEPENDENCIES] libpoppler-cpp0t64:amd64 22.12.0-2.2 [INSTALL, DEPENDENCIES] libpoppler-glib8t64:amd64 22.12.0-2.2 [INSTALL, DEPENDENCIES] libpoppler-qt5-1t64:amd64 22.12.0-2.2 [INSTALL, DEPENDENCIES] libpoppler-qt6-3t64:amd64 22.12.0-2.2 [INSTALL, DEPENDENCIES] libpoppler126t64:amd64 22.12.0-2.2 [INSTALL, DEPENDENCIES] libqt6core6t64:amd64 6.4.2+dfsg-21.1+b1 [INSTALL, DEPENDENCIES] libqt6dbus6t64:amd64 6.4.2+dfsg-21.1+b1 [INSTALL, DEPENDENCIES] libqt6gui6t64:amd64 6.4.2+dfsg-21.1+b1 [INSTALL, DEPENDENCIES] libts0t64:amd64 1.22-1.1 [REMOVE, DEPENDENCIES] libpoppler-cpp0v5:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libpoppler-glib8:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libpoppler-glib8-dbgsym:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libpoppler-qt5-1:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libpoppler-qt6-3:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libpoppler126:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libpoppler126-dbgsym:amd64 22.12.0-2+b1 [REMOVE, DEPENDENCIES] libqt6core6:amd64 6.4.2+dfsg-21 [REMOVE, DEPENDENCIES] libqt6dbus6:amd64 6.4.2+dfsg-21 [REMOVE, DEPENDENCIES] libqt6gui6:amd64 6.4.2+dfsg-21 [REMOVE, DEPENDENCIES] libts0:amd64 1.22-1+b1 [UPGRADE] atril:amd64 1.26.2-1 -> 1.26.2-1.1+b1 [UPGRADE] atril-common:amd64 1.26.2-1 -> 1.26.2-1.1 [UPGRADE] libpoppler-dev:amd64 22.12.0-2+b1 -> 22.12.0-2.2 [UPGRADE] libpoppler-private-dev:amd64 22.12.0-2+b1 -> 22.12.0-2.2 [UPGRADE] poppler-utils:amd64 22.12.0-2+b1 -> 22.12.0-2.2 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) aptitude.log.xz Description: Binary data
Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
The same problem occurred on another machine, with other packages: dpkg: dependency problems prevent removal of libjte2:amd64: libisofs6t64:amd64 depends on libjte2. dpkg: error processing package libjte2:amd64 (--purge): dependency problems - not removing (Reading database ... 708510 files and directories currently installed.) Purging configuration files for libts0:amd64 (1.22-1+b1) ... dpkg: dependency problems prevent removal of libid3tag0:amd64: libimlib2t64:amd64 depends on libid3tag0 (>= 0.15.1b). dpkg: error processing package libid3tag0:amd64 (--purge): dependency problems - not removing Errors were encountered while processing: libjte2:amd64 libid3tag0:amd64 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
On 2024-03-07 17:15:05 +, Simon McVittie wrote: > I can confirm that version 2.24.33-4 of libgtk2.0-common, libgtk2.0-0t64 > and libgtk2.0-bin are, in fact, installable (I have them installed > right now). I can't see any dependency relationships between them that > look suspicious. > > If dpkg is removing libgtk2.0-common, then something must surely be > asking dpkg to remove it? But if it were aptitude, I would assume that it would have a REMOVE line with this package in its logs. > I notice that you have reported at least three bugs that are "the same > shape" with three unrelated libraries, which suggests that this might > be more of an aptitude problem than a GTK problem. Some aptitude developer told me that installation issues were in general due to declarations by packages. > Other logs, in particular /var/log/apt/term.log, might provide more > information about what actually happened. I've attached the corresponding part of this file. Note that libgtk2.0-common is mentioned only at the end (what I had already given). > Alternatively, if there is some heuristic about "try to keep packages > from the same source at the same version" being applied, perhaps waiting > for libgtk2.0-common_2.24.33-4 to become available from the > Architecture: all buildd would help? It was already available. And I installed it just after the error. aptitude should obviously have proposed it for upgrade. I don't know whether this is a bug in aptitude or something wrong in the dependencies. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) Log started: 2024-03-07 16:01:43 (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 655929 files and directories currently installed.) Preparing to unpack .../libgtk2.0-bin_2.24.33-4_amd64.deb ... Unpacking libgtk2.0-bin (2.24.33-4) over (2.24.33-3) ... Preparing to unpack .../libgail-common_2.24.33-4_amd64.deb ... Unpacking libgail-common:amd64 (2.24.33-4) over (2.24.33-3) ... dpkg: libgail18:amd64: dependency problems, but removing anyway as you requested: libgnomecanvas2-0:amd64 depends on libgail18 (>= 1.18.0). (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 655928 files and directories currently installed.) Removing libgail18:amd64 (2.24.33-3) ... Selecting previously unselected package libgail18t64:amd64. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 655923 files and directories currently installed.) Preparing to unpack .../libgail18t64_2.24.33-4_amd64.deb ... Unpacking libgail18t64:amd64 (2.24.33-4) ... dpkg: libgtk2.0-0:amd64: dependency problems, but removing anyway as you requested: xournal depends on libgtk2.0-0 (>= 2.14.0). pinentry-gtk2 depends on libgtk2.0-0 (>= 2.18.0). pavumeter depends on libgtk2.0-0 (>= 2.8.0). libgtkmm-2.4-1v5:amd64 depends on libgtk2.0-0 (>= 2.24.0). libgnomecanvas2-0:amd64 depends on libgtk2.0-0 (>= 2.8.17). libgimp2.0:amd64 depends on libgtk2.0-0 (>= 2.24.10). ibus-gtk:amd64 depends on libgtk2.0-0 (>= 2.24.0). gromit depends on libgtk2.0-0 (>= 2.24.0). gkrellweather depends on libgtk2.0-0 (>= 2.8.0). gkrellm-volume depends on libgtk2.0-0 (>= 2.8.0). gkrellm depends on libgtk2.0-0 (>= 2.24.0). gimp depends on libgtk2.0-
Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common
On 2024-03-07 16:00:35 +0100, Vincent Lefevre wrote: > Will install 11 packages, and remove 3 packages. > 8192 B of disk space will be used > > [...] > [HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3 > [...] > [INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1 > [INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1 > [INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1 > [REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2 > [REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2 > [REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3 > [...] > [UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3 > [UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3 > [UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3 > [UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3 > [UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3 > [UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3 > [UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1 > [UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.1 > Note that libmtp-common:amd64 1.1.21-3.1 was available, but for some unknown reason, aptitude did not propose its upgrade. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
Package: libgtk2.0-0t64 Version: 2.24.33-4 Severity: serious During an upgrade with aptitude: dpkg: dependency problems prevent removal of libgtk2.0-common: libgtk2.0-bin depends on libgtk2.0-common. libgtk2.0-0t64:amd64 depends on libgtk2.0-common. dpkg: error processing package libgtk2.0-common (--purge): dependency problems - not removing Errors were encountered while processing: libgtk2.0-common Note that "apt install -f" has nothing to fix; this upgrade just triggered a dpkg error (similar to bugs 1065603 and 1065625). Moreover, like in these bugs, aptitude did not propose the removal of libgtk2.0-common: Aptitude 0.8.13: log report Thu, Mar 7 2024 16:01:36 +0100 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 5 packages, and remove 2 packages. 2048 B of disk space will be used [...] [HOLD, DEPENDENCIES] libgtk2.0-common:amd64 2.24.33-3 [...] [INSTALL, DEPENDENCIES] libgail18t64:amd64 2.24.33-4 [INSTALL, DEPENDENCIES] libgtk2.0-0t64:amd64 2.24.33-4 [REMOVE, DEPENDENCIES] libgail18:amd64 2.24.33-3 [REMOVE, DEPENDENCIES] libgtk2.0-0:amd64 2.24.33-3 [...] [UPGRADE] gtk2-engines-pixbuf:amd64 2.24.33-3 -> 2.24.33-4 [UPGRADE] libgail-common:amd64 2.24.33-3 -> 2.24.33-4 [UPGRADE] libgtk2.0-bin:amd64 2.24.33-3 -> 2.24.33-4 -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 libgtk2.0-0t64 depends on: ii adwaita-icon-theme 46~rc-1 ii gnome-icon-theme 3.12.0-5 ii hicolor-icon-theme 0.17-2 ii libatk1.0-0t64 2.51.90-2 ii libc62.37-15.1 ii libcairo21.18.0-1+b1 ii libcups2t64 2.4.7-1.2+b1 ii libfontconfig1 2.15.0-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libglib2.0-0t64 2.78.4-3 pn libgtk2.0-common ii libpango-1.0-0 1.51.0+ds-4 ii libpangocairo-1.0-0 1.51.0+ds-4 ii libpangoft2-1.0-01.51.0+ds-4 ii libx11-6 2:1.8.7-1 ii libxcomposite1 1:0.4.5-1 ii libxcursor1 1:1.2.1-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxi6 2:1.8.1-1 ii libxinerama1 2:1.1.4-3 ii libxrandr2 2:1.5.2-2+b1 ii libxrender1 1:0.9.10-1.1 ii shared-mime-info 2.4-1 Versions of packages libgtk2.0-0t64 recommends: ii libgail-common 2.24.33-4 ii libgtk2.0-bin2.24.33-4 ii librsvg2-common 2.54.7+dfsg-2 Versions of packages libgtk2.0-0t64 suggests: ii gvfs 1.53.90-3 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common
Package: libmtp9t64 Version: 1.1.21-3.1 Severity: serious During an upgrade with aptitude: dpkg: dependency problems prevent removal of libmtp-common: libmtp9t64:amd64 depends on libmtp-common. libmtp-runtime depends on libmtp-common. dpkg: error processing package libmtp-common (--purge): dependency problems - not removing Errors were encountered while processing: libmtp-common Note that "apt install -f" has nothing to fix; this upgrade just triggered a dpkg error (similar to bug 1065603). Moreover, like in bug 1065603, aptitude did not propose the removal of libmtp-common: Aptitude 0.8.13: log report Thu, Mar 7 2024 15:49:03 +0100 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 11 packages, and remove 3 packages. 8192 B of disk space will be used [...] [HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3 [...] [INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1 [INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1 [INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1 [REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2 [REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2 [REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3 [...] [UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3 [UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3 [UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3 [UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3 [UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3 [UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3 [UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1 [UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.1 -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 libmtp9t64 depends on: ii libc6 2.37-15.1 ii libgcrypt201.10.3-2 pn libmtp-common ii libusb-1.0-0 2:1.0.27-1 Versions of packages libmtp9t64 recommends: ii libmtp-runtime 1.1.21-3.1 ii udev255.3-2 libmtp9t64 suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade
Control: retitle -1 libdebuginfod1t64 dependency problem makes dpkg fail with attempt of removal of libdebuginfod-common On 2024-03-07 11:28:21 +0100, Vincent Lefevre wrote: > When I wanted to upgrade, this ended up with > > dpkg: dependency problems prevent removal of libdebuginfod-common: > libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1). > > dpkg: error processing package libdebuginfod-common (--purge): > dependency problems - not removing > (Reading database ... 655945 files and directories currently installed.) > Errors were encountered while processing: > libdebuginfod-common Well, the issue just seems to be a dpkg failure. "apt install -f" shows nothing to fix. So I'm wondering why dpkg wanted to remove libdebuginfod-common. FYI, I did the upgrade via aptitude, and this package wasn't proposed for removal. In /var/log/aptitude, after discarding the HOLD lines (which correspond to no changes for these packages): Aptitude 0.8.13: log report Thu, Mar 7 2024 11:24:24 +0100 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 15 packages, and remove 6 packages. 5096 kB of disk space will be freed [...] [INSTALL, DEPENDENCIES] libasm1t64:amd64 0.190-1.1 [INSTALL, DEPENDENCIES] libdebuginfod1t64:amd64 0.190-1.1 [INSTALL, DEPENDENCIES] libdw1t64:amd64 0.190-1.1 [INSTALL, DEPENDENCIES] libelf1t64:amd64 0.190-1.1 [INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-3 [REMOVE, DEPENDENCIES] libasm1:amd64 0.190-1+b1 [REMOVE, DEPENDENCIES] libdebuginfod1:amd64 0.190-1+b1 [REMOVE, DEPENDENCIES] libdw1:amd64 0.190-1+b1 [REMOVE, DEPENDENCIES] libelf1:amd64 0.190-1+b1 [REMOVE, DEPENDENCIES] libglib2.0-0:amd64 2.78.4-1 [REMOVE, DEPENDENCIES] libglib2.0-0-dbgsym:amd64 2.78.4-1 [...] [UPGRADE] elfutils:amd64 0.190-1+b1 -> 0.190-1.1 [UPGRADE] gir1.2-freedesktop:amd64 1.78.1-15 -> 1.78.1-16 [UPGRADE] gir1.2-freedesktop-dev:amd64 1.78.1-15 -> 1.78.1-16 [UPGRADE] gir1.2-girepository-2.0:amd64 1.78.1-15 -> 1.78.1-16 [UPGRADE] gir1.2-glib-2.0:amd64 1.78.1-15 -> 1.78.1-16 [UPGRADE] gir1.2-glib-2.0-dev:amd64 1.78.1-15 -> 1.78.1-16 [UPGRADE] libelf-dev:amd64 0.190-1+b1 -> 0.190-1.1 [UPGRADE] libglib2.0-bin:amd64 2.78.4-1 -> 2.78.4-3 [UPGRADE] libglib2.0-dev:amd64 2.78.4-1 -> 2.78.4-3 [UPGRADE] libglib2.0-dev-bin:amd64 2.78.4-1 -> 2.78.4-3 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade
Package: libdebuginfod1t64 Version: 0.190-1.1 Severity: serious When I wanted to upgrade, this ended up with dpkg: dependency problems prevent removal of libdebuginfod-common: libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1). dpkg: error processing package libdebuginfod-common (--purge): dependency problems - not removing (Reading database ... 655945 files and directories currently installed.) Errors were encountered while processing: libdebuginfod-common -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 libdebuginfod1t64 depends on: ii libc6 2.37-15.1 ii libcurl3t64-gnutls [libcurl3-gnutls] 8.6.0-3.2 pn libdebuginfod-common ii libdw1t64 0.190-1.1 ii libelf1t640.190-1.1 libdebuginfod1t64 recommends no packages. libdebuginfod1t64 suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64
On 2024-03-03 01:08:10 +0100, Vincent Lefevre wrote: > Package: libhdf5-103-1t64 > Version: 1.10.10+repack-3.1 > Severity: serious > > libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64. > This makes the upgrade of curl impossible. It seems that this was actually a bug in curl, where libcurl4t64 had an incorrect X-Time64-Compat and which has just been fixed in https://salsa.debian.org/debian/curl/-/commit/40bdd3894230d325d382d59684c32d74202eee5c -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64
Package: libhdf5-103-1t64 Version: 1.10.10+repack-3.1 Severity: serious libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64. This makes the upgrade of curl impossible. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) 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 libhdf5-103-1t64 depends on: ii libc6 2.37-15.1 ii libcurl48.6.0-3 ii libssl3t64 3.1.5-1.1 ii libsz2 1.1.2-1 ii zlib1g 1:1.3.dfsg-3.1 libhdf5-103-1t64 recommends no packages. libhdf5-103-1t64 suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it
On 2024-02-28 19:20:58 +0100, Vincent Lefevre wrote: > Before the upgrade to gnuplot 6, everything was fine. But after > the upgrade, I get a window where nothing is drawn, i.e. I just > get what's *behind* the window. That's always reproducible on > this machine. > > I've tried GNUTERM=wxt only. I'll do more tests tomorrow. Interesting. This is not reproducible when the display is on another machine (i.e. I connect via ssh). Perhaps an issue related to the local X server? -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it
Package: gnuplot-qt Version: 6.0.0+dfsg1-1 Severity: grave Justification: renders package unusable Before the upgrade to gnuplot 6, everything was fine. But after the upgrade, I get a window where nothing is drawn, i.e. I just get what's *behind* the window. That's always reproducible on this machine. I've tried GNUTERM=wxt only. I'll do more tests tomorrow. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 gnuplot-qt depends on: ii gnuplot-data 6.0.0+dfsg1-1 ii libc62.37-15 ii libcairo21.18.0-1+local1 ii libedit2 3.1-20230828-1 ii libgcc-s114-20240221-2.1 ii libgd3 2.3.3-9+b1 ii libglib2.0-0 2.78.4-1 ii liblua5.4-0 5.4.6-3 ii libpango-1.0-0 1.52.0+ds-1 ii libpangocairo-1.0-0 1.52.0+ds-1 ii libqt5core5a 5.15.10+dfsg-7 ii libqt5gui5 5.15.10+dfsg-7 ii libqt5network5 5.15.10+dfsg-7 ii libqt5printsupport5 5.15.10+dfsg-7 ii libqt5svg5 5.15.10-2+b1 ii libqt5widgets5 5.15.10+dfsg-7 ii libstdc++6 14-20240221-2.1 ii libwebp7 1.3.2-0.4 ii libwebpmux3 1.3.2-0.4 ii libwxbase3.2-1 3.2.4+dfsg-3 ii libwxgtk3.2-13.2.4+dfsg-3 ii libx11-6 2:1.8.7-1 gnuplot-qt recommends no packages. Versions of packages gnuplot-qt suggests: ii gnuplot-doc 6.0.0+dfsg1-1 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064969: apt: can't upgrade with aptitude
On 2024-02-28 15:56:56 +0100, Julian Andres Klode wrote: > aptitude is not our chosen tool for distribution upgrades, as such > failures there are not release critical for the packages. So while > this is release critical for aptitude, it's a wishlist bug for apt > that probably would end up being closed. > > I do believe the correct syntax for aptitude would be to use > > aptitude upgrade apt > > though OK, though this is much slower. But still, apt is not upgraded with this solution (and there is no way to choose another action manually): # aptitude upgrade apt Resolving dependencies... The following packages have been kept back: apt No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 182 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064969: apt: can't upgrade with aptitude
ot;; Acquire::http::TimeOut "10"; Acquire::Languages ""; Acquire::Languages:: "en"; Acquire::Languages:: "none"; Acquire::CompressionTypes ""; Acquire::CompressionTypes::xz "xz"; Acquire::CompressionTypes::bz2 "bzip2"; Acquire::CompressionTypes::lzma "lzma"; Acquire::CompressionTypes::gz "gzip"; Acquire::CompressionTypes::lz4 "lz4"; Acquire::CompressionTypes::zst "zstd"; DPkg ""; DPkg::Path "/usr/sbin:/usr/bin:/sbin:/bin"; DPkg::Pre-Install-Pkgs ""; DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listbugs apt"; DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listbugs apt -T security -s all"; DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listchanges --apt"; DPkg::Pre-Install-Pkgs:: "/usr/sbin/dpkg-preconfigure --apt || true"; DPkg::Tools ""; DPkg::Tools::Options ""; DPkg::Tools::Options::/usr/bin/apt-listbugs ""; DPkg::Tools::Options::/usr/bin/apt-listbugs::Version "3"; DPkg::Tools::Options::/usr/bin/apt-listbugs::InfoFD "20"; DPkg::Tools::Options::/usr/bin/apt-listchanges ""; DPkg::Tools::Options::/usr/bin/apt-listchanges::Version "2"; DPkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD "20"; DPkg::Post-Invoke ""; DPkg::Post-Invoke:: "[ ! -e /usr/bin/how-can-i-help ] || /usr/bin/how-can-i-help --apt"; AptListbugs ""; AptListbugs::Severities "critical,grave,serious"; AptListbugs::IgnoreRegexp "FTBFS"; Aptitude ""; Aptitude::UI ""; Aptitude::UI::Package-Display-Format "%c%a%M %p %Z %24v %24V"; Aptitude::UI::Styles ""; Aptitude::UI::Styles::SolutionActionApproved ""; Aptitude::UI::Styles::SolutionActionApproved::fg "white"; Aptitude::UI::Styles::SolutionActionApproved::bg "green"; Aptitude::UI::Styles::SolutionActionApproved::set "bold"; Aptitude::ProblemResolver ""; Aptitude::ProblemResolver::SolutionCost "safety, removals"; apt-file ""; apt-file::Index-Names "deb"; apt-file::Parser ""; apt-file::Parser::Check-For-Description-Header "false"; Binary "apt-config"; Binary::apt ""; Binary::apt::APT ""; Binary::apt::APT::Keep-Downloaded-Packages "true"; Binary::apt::APT::Color "1"; Binary::apt::APT::Cache ""; Binary::apt::APT::Cache::Show ""; Binary::apt::APT::Cache::Show::Version "2"; Binary::apt::APT::Cache::AllVersions "0"; Binary::apt::APT::Cache::ShowVirtuals "1"; Binary::apt::APT::Cache::Search ""; Binary::apt::APT::Cache::Search::Version "2"; Binary::apt::APT::Cache::ShowDependencyType "1"; Binary::apt::APT::Cache::ShowVersion "1"; Binary::apt::APT::Get ""; Binary::apt::APT::Get::Upgrade-Allow-New "1"; Binary::apt::APT::Get::Update ""; Binary::apt::APT::Get::Update::InteractiveReleaseInfoChanges "1"; Binary::apt::APT::Cmd ""; Binary::apt::APT::Cmd::Show-Update-Stats "1"; Binary::apt::APT::Cmd::Pattern-Only "1"; Binary::apt::DPkg ""; Binary::apt::DPkg::Progress-Fancy "1"; Binary::apt::DPkg::Lock ""; Binary::apt::DPkg::Lock::Timeout "-1"; CommandLine ""; CommandLine::AsString "apt-config dump"; -- (no /etc/apt/preferences present) -- -- /etc/apt/preferences.d/no-adobe-flash-plugin -- Explanation: For security, make sure that the Flash plugin is never installed. Package: flashplugin-nonfree:any Pin: version * Pin-Priority: -1 -- /etc/apt/preferences.d/no-pipewire -- Explanation: pipewire is buggy Package: pipewire:any pipewire-bin:any Pin: version * Pin-Priority: -1 -- /etc/apt/sources.list -- deb https://ftp.debian.org/debian/ stable main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ stable main contrib non-free non-free-firmware # Security updates (previously "stable/updates") deb https://security.debian.org/debian-security stable-security main contrib non-free non-free-firmware deb-src https://security.debian.org/debian-security stable-security main contrib non-free non-free-firmware # stable-updates, previously known as 'volatile' deb https://ftp.debian.org/debian/ stable-updates main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ stable-updates main contrib non-free non-free-firmware deb https://ftp.debian.org/debian/ testing main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ testing main contrib non-free non-free-firmware deb https://security.debian.org/ testing-security main contrib non-free non-free-firmware deb-src https://security.debian.org/ testing-security main contrib non-free non-free-firmware deb https://ftp.debian.org/debian/ unstable main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ unstable main contrib non-free non-free-firmware deb https://ftp.debian.org/debian/ experimental main deb-src https://ftp.debian.org/debian/ experimental main # -dbgsym packages; see # https://lists.debian.org/debian-devel/2015/12/msg00262.html deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main deb http://debug.mirrors.debian.org/debian-debug/ stable-debug main deb http://debug.mirrors.debian.org/debian-debug/ proposed-updates-debug main # Debian Mozilla team - https://mozilla.debian.net/ #deb http://http.debian.net/debian experimental main # Local repository for the default architecture. # Update with "dpkg-scanpackages . > Packages" from it. deb [trusted=yes] file:///var/local/apt ./ # Note: These are the default sources on all my Debian machines. # Additional sources should be put in the sources.list.d directory, # including local repositories for foreign architectures. # $Id: sources.list 163140 2023-11-10 23:20:16Z vinc17/qaa $ -- /etc/apt/sources.list.d/local-i386.list -- # Local repository for packages specific to the i386 architecture. deb [trusted=yes] file:///var/local/apt-i386 ./ # $Id: local-i386.list 108457 2018-05-18 07:22:14Z vinc17/cventin $ -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1055067: isc-dhcp-client: network-manager 1.44.2-3 changed path to nm-dhcp-helper, apparmor need update
On 2024-02-26 00:22:01 +0100, Sven-Haegar Koch wrote: > While installing your test package I lost wifi connection, but I think > that was not from your package but from updating network-manager from > unstable at the same time (did dist-upgrade), which always breaks my > network. With the future stable upgrade, it would be very bad to lose the network connection (not just wifi is concerned) during the upgrade. I suppose that once the new isc-dhcp-client package is available, network-manager should break the old versions (something like that... I don't know whether this is sufficient). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064402: luametatex: "mtxrun --generate": lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'
Control: retitle -1 luametatex: "mtxrun --generate": lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i' More accurate title, as described below. On 2024-02-21 16:15:31 +0100, Vincent Lefevre wrote: > Indeed, I can reproduce the problem on another machine, only with > luametatex 2.11.01+ds-2: > > qaa:~> mtxrun --generate > lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const > variable 'i' > > You'll see the failure in an upgrade if you upgrade luametatex at the > same time as the TeX Live packages (at least, *not after* TeX Live). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'
Control: reassign -1 luametatex 2.11.01+ds-2 Control: severity -1 grave Control: affects -1 texlive-binaries On 2024-02-21 15:46:04 +0100, Vincent Lefevre wrote: > On 2024-02-21 15:28:17 +0100, Vincent Lefevre wrote: > > /tmp/mtxrun.gd7J0NKo just contains: > > > > lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const > > variable 'i' > > > > Note: the tex-common and context (from which /bin/mtxrun.lua comes > > from) are still old packages, and there were no issues with them > > in the past. So I assume that the bug has been introduced in > > /usr/bin/texlua (/bin/mtxrun.lua is a texlua script), which is > > provided by texlive-binaries. > > Or it could be due to luametatex, which appears in /bin/mtxrun.lua > and has been upgraded: > > 2024-02-21 14:47:52 upgrade luametatex:amd64 2.10.08+ds-1+b1 2.11.01+ds-2 Indeed, I can reproduce the problem on another machine, only with luametatex 2.11.01+ds-2: qaa:~> mtxrun --generate lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i' You'll see the failure in an upgrade if you upgrade luametatex at the same time as the TeX Live packages (at least, *not after* TeX Live). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'
On 2024-02-21 15:28:17 +0100, Vincent Lefevre wrote: > /tmp/mtxrun.gd7J0NKo just contains: > > lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const > variable 'i' > > Note: the tex-common and context (from which /bin/mtxrun.lua comes > from) are still old packages, and there were no issues with them > in the past. So I assume that the bug has been introduced in > /usr/bin/texlua (/bin/mtxrun.lua is a texlua script), which is > provided by texlive-binaries. Or it could be due to luametatex, which appears in /bin/mtxrun.lua and has been upgraded: 2024-02-21 14:47:52 upgrade luametatex:amd64 2.10.08+ds-1+b1 2.11.01+ds-2 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'
1 ii libpaper1 1.1.29 ii libpixman-1-0 0.42.2-1 ii libpng16-16 1.6.42-1 ii libpotrace0 1.16-2 ii libptexenc1 2023.20230311.66589-8+b1 ii libstdc++6 14-20240201-3 ii libsynctex2 2023.20230311.66589-8+b1 ii libteckit0 2.5.11+ds1-1+b1 ii libtexlua53-5 2023.20230311.66589-8+b1 ii libx11-62:1.8.7-1 ii libxaw7 2:1.0.14-1 ii libxi6 2:1.8.1-1 ii libxmu6 2:1.1.3-3 ii libxpm4 1:3.5.17-1 ii libxt6 1:1.2.1-1.1 ii libzzip-0-130.13.72+dfsg.1-1.1+b1 ii perl5.38.2-3 ii t1utils 1.41-4 ih tex-common 6.18 ii zlib1g 1:1.3.dfsg-3+b1 Versions of packages texlive-binaries recommends: ii dvisvgm 3.2+ds-1 ii texlive-base 2023.20240207-1 Versions of packages texlive-binaries suggests: pn hintview pn texlive-binaries-sse2 Versions of packages tex-common depends on: ii ucf 3.0043+nmu1 Versions of packages tex-common suggests: ii debhelper 13.13 Versions of packages texlive-binaries is related to: ih tex-common6.18 ii texlive-base 2023.20240207-1 -- debconf information: tex-common/check_texmf_wrong: tex-common/check_texmf_missing: -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1061438: tpm2-tss: can't upgrade the tpm2-tss packages to 4.0.1-6; missing Conflicts?
Source: tpm2-tss Version: 4.0.1-6 Severity: serious It is not possible to upgrade the tpm2-tss packages to 4.0.1-6 with "apt upgrade" or with aptitude (command line or its TUI, without a *manual* dependency resolution): root@disset:~# apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: libtss2-esys-3.0.2-0 libtss2-sys1 libtss2-tcti-cmd0 libtss2-tcti-device0 libtss2-tcti-mssim0 libtss2-tcti-swtpm0 [...] This is apparently due to the rename of libtss2-mu0 to libtss2-mu-4.0.1-0. This latter package has a Breaks+Replaces, but is that sufficient? i.e. isn't Conflicts needed? https://wiki.debian.org/RenamingPackages says "Conflicts should only be used if two packages can never be unpacked at the same time", which is the case for libtss2-mu0 and libtss2-mu-4.0.1-0. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT) 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 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1040988: fixed in picom 10.2-2
On Tue, 26 Dec 2023 16:19:12 + Debian FTP Masters wrote: * Fix infinite loop with GNOME (Closes: #1040988) Upstream also added: https://github.com/yshui/picom/commit/7366553be2b825495c5b1e09be09d0fabde4b9b4 Otherwise, picom won't start at the beginning of a session (no windows yet).
Bug#1059314: imagemagick-6.q16: please update "Suggests: imagemagick-doc" to imagemagick-6-doc
Package: imagemagick-6.q16 Version: 8:6.9.12.98+dfsg1-4 Severity: serious The imagemagick-doc package is not longer built and has been replaced by imagemagick-6-doc. So the "Suggests" should be updated. Note that the current Suggests can prevent installations/upgrades if suggested packages are installed by default, e.g. with --install-suggests or APT::Install-Suggests set to true. -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org compare: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org convert: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org composite: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org conjure: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org display: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org identify: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org import: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org mogrify: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org montage: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org stream: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) 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 imagemagick-6.q16 depends on: ii hicolor-icon-theme 0.17-2 ii libc6 2.37-13 ii libmagickcore-6.q16-7 8:6.9.12.98+dfsg1-4 ii libmagickwand-6.q16-7 8:6.9.12.98+dfsg1-4 Versions of packages imagemagick-6.q16 recommends: ii ghostscript 10.02.1~dfsg-1 ii libmagickcore-6.q16-7-extra 8:6.9.12.98+dfsg1-4 ii netpbm 2:11.04.05-2 Versions of packages imagemagick-6.q16 suggests: pn autotrace ii cups-bsd [lpr] 2.4.7-1 ii curl 8.5.0-1 pn enscript pn ffmpeg ii fig2dev [transfig] 1:3.2.9-3 ii gimp 2.10.36-2 ii gnuplot-qt [gnuplot] 5.4.4+dfsg1-2+b2 pn grads ii graphviz 2.42.2-7+b3 ii groff-base 1.23.0-3 pn hp2xx pn html2ps pn imagemagick-doc pn libraw-bin ii libwmf-bin 0.2.13-1.1 pn mplayer pn povray pn radiance ii sane-utils 1.2.1-7 ii texlive-binaries [texlive-base-bin] 2023.20230311.66589-8 ii xdg-utils1.1.3-4.1 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1059193: imagemagick-6-doc: missing Breaks+Replaces against the dropped imagemagick-doc package, in order to force its removal
Package: imagemagick-6-doc Version: 8:6.9.12.98+dfsg1-4 Severity: serious Justification: Policy 7.6.2 On my new laptop, I can't upgrade the imagemagick packages automatically from 8:6.9.11.60+dfsg-1.6 to 8:6.9.12.98+dfsg1-4 with aptitude (I need to enter the dependency resolution so that imagemagick-doc, which is no longer built, gets removed). The 8:6.9.12.98+dfsg1-1 changelog says: * Drop package imagemagick-doc and imagemagick-common and the imagemagick-doc currently installed (from bookworm) is just a dummy package, so that there is no reason to keep it. If I understand correctly, imagemagick-6-doc intends to replace it, so I'm reporting the bug against imagemagick-6-doc. So this is the case "7.6.2. Replacing whole packages, forcing their removal" of the Debian policy, and also https://wiki.debian.org/RenamingPackages which says to use "Breaks:" + "Replaces:". -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org compare: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org convert: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org composite: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org conjure: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org display: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org identify: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org import: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org mogrify: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org montage: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org stream: ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) 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 imagemagick-6-doc depends on: ii dpkg 1.22.2 ii imagemagick-6-common 8:6.9.11.60+dfsg-1.6 Versions of packages imagemagick-6-doc recommends: ii elinks [www-browser] 0.16.1.1-4.1 ii firefox [www-browser] 121.0-1 ii firefox-esr [www-browser] 115.6.0esr-1 ii libjs-bootstrap3.4.1+dfsg-3 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-jquery-fancybox 12-4 ii libjs-jquery-mousewheel1:3.1.13-5 ii links [www-browser]2.28-1+b2 ii links2 [www-browser] 2.28-1+b2 ii lynx [www-browser] 2.9.0dev.12-1 ii w3m [www-browser] 0.5.3+git20230121-2 Versions of packages imagemagick-6-doc suggests: ii imagemagick 8:6.9.12.98+dfsg1-4 ii imagemagick-6.q16 [imagemagick] 8:6.9.12.98+dfsg1-4 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau
Another piece of information: this is a regression. With the 6.1.0-16-amd64 kernel from stable, "journalctl -b -g ga107" gives Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1) Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/nvdec/scrubber.bin (-2) Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/nvdec/scrubber.bin (-2) and I don't have any issue with the machine. With the 6.5.0-5-amd64 kernel, "journalctl -b -1 -g ga107" gives Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1) Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/acr/ucode_ahesasc.bin (-2) Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/acr/ucode_ahesasc.bin (-2) Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading firmware nvidia/ga107/gr/NET_img.bin Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading firmware nvidia/ga107/gr/fecs_bl.bin Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading firmware nvidia/ga107/gr/fecs_sig.bin Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading firmware nvidia/ga107/gr/gpccs_bl.bin Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading firmware nvidia/ga107/gr/gpccs_sig.bin Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/sec2/sig.bin (-2) Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/sec2/sig.bin (-2) Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/nvdec/scrubber.bin (-2) Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load nvidia/ga107/nvdec/scrubber.bin (-2) and I get the crashes, and as soon as I log out or after "xset dpms force off" is run, the screen remains black. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau
On 2023-12-19 04:32:02 +0100, Vincent Lefevre wrote: > firmware-misc-nonfree triggers the following warnings: > > update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64 [...] > W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin > for module nouveau [...] > while https://forums.debian.net/viewtopic.php?t=155793 says that > the solution is to install firmware-misc-nonfree! I would add that even the section "Firmware missing from Debian" in https://wiki.debian.org/Firmware does not apply because, for instance for the above firmware, there's no "acr" directory in nvidia/ga107: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia/ga107 contains only a "gr" directory. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau
kernel: usif_ioctl+0x27b/0x430 [nouveau] Dec 19 04:02:54 qaa kernel: nouveau_drm_ioctl+0xa5/0xb0 [nouveau] Dec 19 04:02:54 qaa kernel: __x64_sys_ioctl+0x94/0xd0 Dec 19 04:02:54 qaa kernel: do_syscall_64+0x5d/0xc0 Dec 19 04:02:54 qaa kernel: ? exit_to_user_mode_prepare+0x40/0x1e0 Dec 19 04:02:54 qaa kernel: ? syscall_exit_to_user_mode+0x2b/0x40 Dec 19 04:02:54 qaa kernel: ? do_syscall_64+0x6c/0xc0 Dec 19 04:02:54 qaa kernel: ? exit_to_user_mode_prepare+0x14b/0x1e0 Dec 19 04:02:54 qaa kernel: entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Dec 19 04:02:54 qaa kernel: RIP: 0033:0x7f1afd11b51b Dec 19 04:02:54 qaa kernel: Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 Dec 19 04:02:54 qaa kernel: RSP: 002b:7fff91ef9e60 EFLAGS: 0246 ORIG_RAX: 0010 Dec 19 04:02:54 qaa kernel: RAX: ffda RBX: 55c11d65d9d0 RCX: 7f1afd11b51b Dec 19 04:02:54 qaa kernel: RDX: 55c11d62c930 RSI: c0386447 RDI: 0017 Dec 19 04:02:54 qaa kernel: RBP: 55c11d62c930 R08: 55c11d645e80 R09: 55c11d65d9d0 Dec 19 04:02:54 qaa kernel: R10: cc8fce3f6a9d8ed6 R11: 0246 R12: c0386447 Dec 19 04:02:54 qaa kernel: R13: 0017 R14: R15: 55c11d645ec0 Dec 19 04:02:54 qaa kernel: Dec 19 04:02:54 qaa kernel: ---[ end trace ]--- -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable-security'), (900, 'stable-debug'), (900, 'proposed-updates-debug'), (900, 'testing'), (900, 'stable'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.142 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0
Control: tags -1 fixed-upstream On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote: > I've reported the following bug in the MPFR mailing-list. I think > I've fixed the issues on the MPFR side in master, but MPFR is still > affected by the bug on the GMP side (gmp_vasprintf): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344 The gmp_vasprintf function is actually correct (but its documentation is not; and it is gmp_sprintf that is incorrect, which is not a problem for MPFR). I've fixed the remaining bugs in MPFR. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1058690: liblatex-tounicode-perl: trying to overwrite .../ltx2unitxt.1.gz, which is also in package texlive-bibtex-extra 2023.20231207-1
Package: liblatex-tounicode-perl Version: 0.54-1 Severity: serious As a consequence of the upgrade of texlive-bibtex-extra to 2023.20231207-3: [...] Selecting previously unselected package liblatex-tounicode-perl. (Reading database ... 711147 files and directories currently installed.) Preparing to unpack .../00-liblatex-tounicode-perl_0.54-1_all.deb ... Unpacking liblatex-tounicode-perl (0.54-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-seikpl/00-liblatex-tounicode-perl_0.54-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/ltx2unitxt.1.gz', which is also in package texlive-bibtex-extra 2023.20231207-1 [...] It seems that the fix in bug 1058462 is incorrect or incomplete. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=POSIX, 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 liblatex-tounicode-perl depends on: ii perl 5.36.0-10 liblatex-tounicode-perl recommends no packages. liblatex-tounicode-perl suggests no packages. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1057151: clang-17: ClangTargets.cmake cannot find libclang-17.so.1
Control: reassign -1 libclang1-17 1:17.0.6-1 because the problem is actually there (and this package may be installed even if clang-17 isn't). On 2023-11-30 12:13:21 -0700, Cordell Bloor wrote: > While attempting to update rocm-device-libs, I noticed that searching > for clang with find_package(Clang) will fail with an error. The > ClangTargets.cmake file expects libclang to be found at the path > "/usr/lib/llvm-17/lib/libclang-17.so.1", but the file is actually > installed to "/usr/lib/x86_64-linux-gnu/libclang-17.so.1". This seems normal (/usr/lib/x86_64-linux-gnu/libclang-17.so.1 already exists in libclang1-17 1:17.0.5-1). However, the symbolic link /usr/lib/llvm-17/lib/libclang-17.so.1 changed to /usr/lib/llvm-17/lib/libclang-17.so.17 in 1:17.0.6-1, and I'm wondering whether this was expected. I suppose that this is due to one of the following changes: * libclang1-17: Only encode the major version in the soname. Closes: #1056126. * libclang1-17: Provide a symlink for the last soname with the full version. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0
Package: libmpfr6 Version: 4.2.0-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://sympa.inria.fr/sympa/arc/mpfr/2023-12/msg0.html X-Debbugs-Cc: Debian Security Team I've reported the following bug in the MPFR mailing-list. I think I've fixed the issues on the MPFR side in master, but MPFR is still affected by the bug on the GMP side (gmp_vasprintf): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344 The vasprintf.c code (for the formatted output functions) does not handle null characters correctly. These characters can occur by using %c with the value 0. This is shown by the check_null tsprintf.c test: https://gitlab.inria.fr/mpfr/mpfr/-/commit/78e72e6538fabc1b720d97e862ec45354e5c9c3f The possible consequences are: - possible memory corruption with custom memory allocators that do not ignore the size parameter of the "free" function; - a part of the buffer fails to be overwritten (with possible security issues if the buffer contains sensitive data that were expected to be overwritten); - an assertion failure when GNU MPFR has been configured with assertion checking (--enable-assert). Note that some of these issues partly come from a bug in gmp_vasprintf (such as the incorrect return value), which I've reported here: https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html I think that I have fixed these issues on the MPFR side with https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef8570da4e338e9806ecaf2d022210d951 but the first two consequences remain due to the gmp_vasprintf bug. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/1 CPU thread; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=POSIX, 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 libmpfr6 depends on: ii libc6 2.36-9+deb12u3 ii libgmp10 2:6.2.1+dfsg1-1.1 libmpfr6 recommends no packages. libmpfr6 suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1057344: libgmp10: major formatted output function bug with %c and the value 0
Package: libgmp10
Version: 2:6.2.1+dfsg1-1.1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html
X-Debbugs-Cc: Debian Security Team
I've reported the following bug upstream. Debian/stable is affected
(at least on the testcase below, but the various issues are probably
related).
With GMP 6.3.0, the formatted output functions do not handle %c
with the value 0 correctly. For gmp_sprintf, the return value is
incorrect. For gmp_asprintf and gmp_vasprintf, this is either a
buffer overflow (according to the GMP manual: "The block will be
the size of the string and null-terminator.") or, in case this
is an error in the GMP manual, possible memory corruption when
freeing the allocated memory, if the custom memory allocation
function cares about the size parameter.
Testcase for gmp_sprintf:
#include
#include
static void test (int flag)
{
char s[3] = { 1, 1, 1 };
int r;
r = (flag ? sprintf : gmp_sprintf) (s, "%c", 0);
printf ("%4s: r = %d, s = { %d %d %d }\n",
flag ? "libc" : "gmp", r, s[0], s[1], s[2]);
}
int main (void)
{
test (0);
test (1);
return 0;
}
which currently gives:
gmp: r = 0, s = { 0 0 1 }
libc: r = 1, s = { 0 0 1 }
MPFR has various issues concerning %c with the value 0, but an
attempt to fix them fails due to
length = gmp_vasprintf (...);
[...]
mpfr_free_str (s);
which is similar to GMP's tests/misc/t-printf.c file, which contains
got_len = gmp_vasprintf (, fmt, ap);
[...]
(*__gmp_free_func) (got, strlen(got)+1);
But replacing
mpfr_free_str (s);
by
mpfr_free_func (s, length + 1);
i.e. using the return value length instead of strlen(s), also fails.
I suppose that this is related to the incorrect return value.
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=POSIX, 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 libgmp10 depends on:
ii libc6 2.36-9+deb12u3
libgmp10 recommends no packages.
libgmp10 suggests no packages.
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1056313: network-manager: breaks networking
On 2023-11-20 12:24:36 +0100, Vincent Lefevre wrote: > Note: the errors about /usr/libexec/nm-dhcp-helper changed to > > Nov 20 12:17:42 cventin dhclient[295468]: execve > (/usr/libexec/nm-dhcp-helper, ...): No such file or directory > > but the network is working. I don't whether this is related, though. Forget about the "No such file or directory" error. This was the first time I got it, and I suspect that it is due to the downgrade of network-manager (something normally not supported), e.g. the running dhclient was still expecting the new paths, which disappeared with the downgrade. So, the only issue seems the "Permission denied" with the new network-manager versions due to the change of the paths done for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026388 * Install helper binaries into /usr/libexec (Closes: #1026388) and the fact that /etc/apparmor.d/sbin.dhclient from isc-dhcp-client 4.4.3-P1-4 still has the old paths. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1056313: network-manager: breaks networking
On 2023-11-20 12:42:14 +0100, Vincent Lefevre wrote: > I suspect that nm-dhcp-helper has been added because it is now needed. > But it doesn't work due to the "Permission denied". If I understand correctly, /usr/lib/NetworkManager/nm-dhcp-helper moved to /usr/libexec/nm-dhcp-helper, but /etc/apparmor.d/sbin.dhclient from isc-dhcp-client was not updated. /etc/apparmor.d/sbin.dhclient still contains the old paths. Shouldn't there be a "Breaks:" on isc-dhcp-client (<< 4.4.3-P1-4) in order to ensure that the user also upgrades isc-dhcp-client or block the upgrade until isc-dhcp-clients gets modified? -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1056313: network-manager: breaks networking
Control: found -1 1.44.2-3
Control: retitle -1 network-manager: breaks networking (Permission denied for
the new /usr/libexec/nm-dhcp-helper)
On 2023-11-20 12:24:36 +0100, Vincent Lefevre wrote:
> Package: network-manager
> Version: 1.44.2-4
> Severity: grave
> Justification: renders package unusable
>
> Just after the upgrade of network-manager from 1.44.2-1 to 1.44.2-4,
> my network is down.
The testing version 1.44.2-3 is broken too.
> The issue disappeared after downgrading back to 1.44.2-1.
>
> Note: the errors about /usr/libexec/nm-dhcp-helper changed to
>
> Nov 20 12:17:42 cventin dhclient[295468]: execve
> (/usr/libexec/nm-dhcp-helper, ...): No such file or directory
>
> but the network is working. I don't whether this is related, though.
This is because /usr/libexec/nm-dhcp-helper exists in
1.44.2-3 and 1.44.2-4, but not in 1.44.2-1.
I suspect that nm-dhcp-helper has been added because it is now needed.
But it doesn't work due to the "Permission denied".
I've attached more journalctl output, in case it is needed.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Nov 20 12:26:43 cventin systemd[1]: Starting NetworkManager.service - Network
Manager...
Nov 20 12:26:43 cventin dbus-daemon[761]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Nov 20 12:26:43 cventin systemd[1]: Started NetworkManager-dispatcher.service -
Network Manager Script Dispatcher Service.
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.2215]
NetworkManager (version 1.44.2) is starting... (after a restart,
boot:69bc9a99-ac9d-4eb8-9de9-9471a74d32b3)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.2216] Read
config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf)
(etc: dhcp.conf, logging.conf)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.2284]
manager[0x564430a339a0]: monitoring kernel firmware directory '/lib/firmware'.
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.2285]
monitoring ifupdown state file '/run/network/ifstate'.
Nov 20 12:26:43 cventin dbus-daemon[761]: [system] Activating via systemd:
service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.269' (uid=0
pid=296512 comm="/usr/sbin/NetworkManager --no-daemon")
Nov 20 12:26:43 cventin systemd[1]: Starting systemd-hostnamed.service -
Hostname Service...
Nov 20 12:26:43 cventin dbus-daemon[761]: [system] Successfully activated
service 'org.freedesktop.hostname1'
Nov 20 12:26:43 cventin systemd[1]: Started systemd-hostnamed.service -
Hostname Service.
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3134]
hostname: hostname: using hostnamed
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3134]
hostname: static hostname changed from (none) to "cventin"
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3140]
dns-mgr: init: dns=default,systemd-resolved rc-manager=symlink (auto)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3144]
manager[0x564430a339a0]: rfkill: Wi-Fi hardware radio set enabled
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3145]
manager[0x564430a339a0]: rfkill: WWAN hardware radio set enabled
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3171]
Loaded device plugin: NMWifiFactory
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-wifi.so)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3205]
Loaded device plugin: NMBluezManager
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-bluetooth.so)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3208]
Loaded device plugin: NMWwanFactory
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-wwan.so)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3224]
Loaded device plugin: NMTeamFactory
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-team.so)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3228]
Loaded device plugin: NMAtmManager
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-adsl.so)
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3231]
manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3232]
manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3233]
manager: Networking is enabled by state file
Nov 20 12:26:43 cventin NetworkManager[296512]: [1700479603.3238]
settings: Loaded settings plugin: ifupdown
("/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-settings-plugin
Bug#1056313: network-manager: breaks networking
f packages network-manager recommends: ii dnsmasq-base [dnsmasq-base] 2.89-1 ii libpam-systemd 254.5-1 ii modemmanager 1.22.0-1 pn ppp ii wireless-regdb 2022.06.06-1 ii wpasupplicant2:2.10-15 Versions of packages network-manager suggests: ii iptables 1.8.9-2 pn libteam-utils Versions of packages network-manager is related to: ii isc-dhcp-client 4.4.3-P1-4 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1041838: Bug#1041834: libclang-rt-16-dev: undeclared file conflict with libclang-rt-16-dev-wasm{32,64} on /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm*.a
Control: retitle -1 libclang-rt-17-dev: undeclared file conflict with
libclang-rt-17-dev-wasm{32,64} on
/usr/lib/llvm-17/lib/clang/17/lib/wasi/libclang_rt.builtins-wasm*.a
Sending to the right bug ("bts show --mbox 1041838" was giving the
1041834@b.d.o e-mail address instead of 1041838@b.d.o, so that I was
confused).
On 2023-11-09 14:13:37 +0100, Vincent Lefevre wrote:
> On 2023-07-24 06:54:27 +0200, Helmut Grohne wrote:
> > Control: clone -1 -2
> > Control: reassign -2 libclang-rt-17-dev
> >
> > On Mon, Jul 24, 2023 at 06:45:00AM +0200, Helmut Grohne wrote:
> > > libclang-rt-16-dev installs
> > > /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm{32,64}.a,
> > > which are also installed by libclang-rt-16-dev-wasm{32,64} respectively.
> > > Trying to coinstall these packages in unstable results in an unpack
> > > error. I guess that these files should only be contained in the
> > > respective wasm packages. Don't forget to include the necessary
> > > Breaks+Replaces when fixing this.
> >
> > The same issue exists for version 17.
>
> This should have been retitled. Doing it now.
>
> But looking at
>
> https://packages.debian.org/sid/amd64/libclang-rt-17-dev/filelist
>
> I can't see files with "wasm" in the file names.
>
> If I understand correctly, the fix was done in branch 17 too:
>
>
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/f667185dabd4ebb8fd8bdceed64432a6fff10d37
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1055205: chrony: SysV problems after upgrade
Hi Richard, Le 2023-11-02 09:01, Richard Lucassen a écrit : > Package: chrony > Version: 4.4-3 > Severity: normal > > I run chronyd supervised. Therefore I removed symlinks in /etc/rc2.d/ > (update-rc.d chrony remove). > But after an upgrade the deb package installs new symlinks in /etc/rc2.d/ and > starts chronyd, even though chronyd is SysV disabled. > > Please check if /etc/rc2.d/*chrony symlinks exist, if not, don't add these > and do not start chronyd. Maybe it's a good idea to just display a warning in > that case. > I'm closing this bug report as this is, to me, not something that should handled on the packaging side. From update-rc.d(8): A common system administration error is to delete the links with the thought that this will "disable" the service, i.e., that this will prevent the service from being started. However, if all links have been deleted then the next time the package is upgraded, the package's postinst script will run update-rc.d again and this will reinstall links at their factory de- fault locations. The correct way to disable services is to configure the service as stopped in all runlevels in which it is started by default. In the System V init system this means renam- ing the service's symbolic links from S to K. .P The script .BI /etc/init.d/ name must exist before update-rc.d is run to create the links. Running 'update-rc.d chrony disable' as root should work too. > Richard. Have a good day, Vincent signature.asc Description: PGP signature
Bug#1054650: dbus: makes the machine extremely slow, freezes on shutdown
1.14.10-2 ii dbus-system-bus-common 1.14.10-2 ii init-system-helpers 1.64 ii libc6 2.37-12 ii libdbus-1-3 1.14.10-2 ii libexpat1 2.5.0-2 ii libsystemd0 254.5-1 dbus recommends no packages. Versions of packages dbus suggests: ii dbus-user-session [default-dbus-session-bus] 1.14.10-2 ii dbus-x11 [dbus-session-bus] 1.14.10-2 Versions of packages dbus is related to: ii dbus-x11 1.14.10-2 ii systemd 254.5-1 ii systemd-sysv 254.5-1 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1054022: libncursesw6: broken in GNU Screen
Via JuiceSSH+mosh under Android, if I hit a key, I can see spurious escape sequences in the output after the error message: ^[[1;1R^[[49;80R^[[49;80R^[[49;80R -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1054022: libncursesw6: broken in GNU Screen
On 2023-10-16 04:10:36 -0400, Thomas Dickey wrote: > But in a quick check to "upgrade", my sources.list to investigate this, > I get stopped by the "improvements". It might help if you posted the > corresponding sources.list (or are you using the separate gpg stuff?). I'm wondering why this matters as this basically corresponds to unstable. deb https://ftp.debian.org/debian/ stable main contrib non-free deb-src https://ftp.debian.org/debian/ stable main contrib non-free # Security updates (previously "stable/updates") deb https://security.debian.org/debian-security stable-security main contrib non-free deb-src https://security.debian.org/debian-security stable-security main contrib non-free # stable-updates, previously known as 'volatile' deb https://ftp.debian.org/debian/ stable-updates main contrib deb-src https://ftp.debian.org/debian/ stable-updates main contrib deb https://ftp.debian.org/debian/ testing main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ testing main contrib non-free deb https://security.debian.org/ testing-security main contrib non-free non-free-firmware deb-src https://security.debian.org/ testing-security main contrib non-free deb https://ftp.debian.org/debian/ unstable main contrib non-free non-free-firmware deb-src https://ftp.debian.org/debian/ unstable main contrib non-free deb https://ftp.debian.org/debian/ experimental main deb-src https://ftp.debian.org/debian/ experimental main # -dbgsym packages; see # https://lists.debian.org/debian-devel/2015/12/msg00262.html deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main # Debian Mozilla team - https://mozilla.debian.net/ #deb http://http.debian.net/debian experimental main # Local repository for the default architecture. # Update with "dpkg-scanpackages . > Packages" from it. deb [trusted=yes] file:///var/local/apt ./ -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1054022: libncursesw6: broken in GNU Screen
|CREAD,
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
659013 ioctl(2, TCSETSW, {c_iflag=ICRNL|IUTF8,
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD,
c_lflag=ECHOE|ECHOK|ECHOCTL|ECHOKE, ...}) = 0
659013 ioctl(2, TCGETS, {c_iflag=ICRNL|IUTF8,
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD,
c_lflag=ECHOE|ECHOK|ECHOCTL|ECHOKE, ...}) = 0
659013 write(2, "\33[6n", 4)= 4
659013 read(2, "", 19) = 0
659013 write(2, "\33[1;1H", 14) = 14
659013 write(2, "\33[6n", 4)= 4
659013 read(2, "", 19) = 0
659013 write(2, "\33[437457153;385880577H", 22) = 22
659013 ioctl(2, TCGETS, {c_iflag=ICRNL|IUTF8,
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD,
c_lflag=ECHOE|ECHOK|ECHOCTL|ECHOKE, ...}) = 0
659013 ioctl(2, TCSETSW, {c_iflag=ICRNL|IUTF8,
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD,
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
659013 ioctl(2, TCGETS, {c_iflag=ICRNL|IUTF8,
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD,
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
659013 mmap(NULL, 564432896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7f7cbc5ff000
659013 write(2, "Error opening terminal: screen.xterm-256color.\n", 47) = 47
659013 exit_group(1)= ?
659013 +++ exited with 1 +++
Downgrading the ncurses packages to 6.4+20230625-2 makes this problem
disappear.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libncursesw6 depends on:
ii libc6 2.37-12
ii libtinfo6 6.4+20231007-1
Versions of packages libncursesw6 recommends:
ii libgpm2 1.20.7-10+b1
libncursesw6 suggests no packages.
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1041731: groff-base: "-" mapped as HYPHEN
On 2023-09-11 20:33:27 -0700, Russ Allbery wrote: > Yes, I understand why upstream really wants to find a way to make the > distinction between a language hyphen and an ASCII hyphen to work. They > are different characters in the *roff language, and in a proper > typesetting system such as troff is intended to be, it is important to > distinguish between them for the best output. However, the apostrophe and the right single quotation mark are also (semantically) different characters, but now the apostrophe is output as the same character as the right single quotation mark! More importantly, this change also makes searching for words with the concerned characters (apostrophe and hyphen) more difficult (or unnatural) in "less". -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1050232: pyregion: binary-any FTBFS with recent jdupes
Hi, I cannot reproduce this bug in sid. Is is still relevant? Regards Vincent
Bug#1052136: libcdb1: tries to overwrite /usr/share/man/man5/cdb.5.gz in tinycdb 0.78+b1
Package: libcdb1 Version: 0.80-1 Severity: serious When upgrading, I got: Unpacking libcdb1:amd64 (0.80-1) over (0.78+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-DmVfNl/25-libcdb1_0.80-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man5/cdb.5.gz', which is also in package tinycdb 0.78+b1 Missing Breaks+Replaces? -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcdb1 depends on: ii libc6 2.37-10 libcdb1 recommends no packages. libcdb1 suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1051116: maildrop: depends on libgcc1, which is no longer in the archive
On 2023-09-17 13:05:16 +0200, Sebastian Ramacher wrote: > On 2023-09-03 02:26:55 +0200, Vincent Lefevre wrote: > > Package: maildrop > > Version: 2.9.3-2+b1 > > Severity: grave > > Justification: renders package unusable > > > > maildrop depends on libgcc1, which is no longer in the archive. > > This can be checked on > > > > https://packages.debian.org/en/bullseye/maildrop > > > > which says: > > > > dep: libgcc1 (>= 1:3.0) [not armel, armhf, i386, mipsel] > > Package not available > > libgcc1 is provided by libgcc-s1: [...] Indeed. I think that I got confused by bug 557328 (which I noticed only after the upgrade to bookworm). While libgcc-s1 was installed, libgcc1 was not removed by "apt autoremove", and "aptitude why libgcc1" said that maildrop depended on it, hence the confusion. BTW, I'm wondering why libgcc-s1 doesn't have a "Breaks:" on libgcc1 in order to have libgcc1 uninstalled automatically. This would have avoided the issue. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1052040: mmm-mode: post-install script fails
Control: tags -1 - upstream The issue actually comes from the 01-xemacs patch. On 2023-09-16 17:46:23 +0200, Vincent Lefevre wrote: > An easy solution would be to avoid the XEmacs form (marked as > obsolete in GNU Emacs since 23.1 and whose support was removed > in GNU Emacs 28[*]), i.e. change > > (if (not (string-match "XEmacs" (emacs-version))) > (define-obsolete-function-alias 'mmm-add-find-file-hooks > 'mmm-add-find-file-hook > "0.3.8" > "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are > deprecated.") > (define-obsolete-function-alias 'mmm-add-find-file-hooks > 'mmm-add-find-file-hook)) > > to just > > (define-obsolete-function-alias 'mmm-add-find-file-hooks > 'mmm-add-find-file-hook > "0.3.8" > "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are > deprecated.") Alternatively, update to release 0.5.10, where upstream has just removed these obsolete functions: https://github.com/dgutov/mmm-mode/commit/244f8c4794f20a6be5ebe1e405400a9c35ea6d2f so that mmm-auto.el no longer needs to be patched for xemacs. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1052040: mmm-mode: post-install script fails
Control: forwarded -1 https://github.com/dgutov/mmm-mode/issues/137 Control: tags -1 upstream On 2023-09-16 17:02:54 +0200, Vincent Lefevre wrote: > This appears to be related to macro expansion, which seems to > occur even if the code is not executed. An easy solution would be to avoid the XEmacs form (marked as obsolete in GNU Emacs since 23.1 and whose support was removed in GNU Emacs 28[*]), i.e. change (if (not (string-match "XEmacs" (emacs-version))) (define-obsolete-function-alias 'mmm-add-find-file-hooks 'mmm-add-find-file-hook "0.3.8" "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are deprecated.") (define-obsolete-function-alias 'mmm-add-find-file-hooks 'mmm-add-find-file-hook)) to just (define-obsolete-function-alias 'mmm-add-find-file-hooks 'mmm-add-find-file-hook "0.3.8" "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are deprecated.") [*] https://github.com/emacs-mirror/emacs/commit/32c6732 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1052040: mmm-mode: post-install script fails
On 2023-09-16 16:53:33 +0200, Vincent Lefevre wrote: > If I understand correctly, the second define-obsolete-function-alias > (with 2 arguments) is executed instead of the first one (with 4 > arguments). This would mean that > > (string-match "XEmacs" (emacs-version)) > > finds a match. Is there any reason? Actually, it doesn't. This appears to be related to macro expansion, which seems to occur even if the code is not executed. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1052040: mmm-mode: post-install script fails
Ditto here. On 2023-09-16 14:31:11 +0200, mister...@web.de wrote: > In toplevel form: > mmm-auto.el:178:4: Error: Wrong number of arguments: (3 . 4), 2 This seems to be due to this change: -(defalias 'mmm-add-find-file-hooks #'mmm-add-find-file-hook) +(if (not (string-match "XEmacs" (emacs-version))) +(define-obsolete-function-alias 'mmm-add-find-file-hooks 'mmm-add-find-file-hook + "0.3.8" + "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are deprecated.") + (define-obsolete-function-alias 'mmm-add-find-file-hooks 'mmm-add-find-file-hook)) If I understand correctly, the second define-obsolete-function-alias (with 2 arguments) is executed instead of the first one (with 4 arguments). This would mean that (string-match "XEmacs" (emacs-version)) finds a match. Is there any reason? -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1051822: installed chrony package post-installation script subprocess returned error exit status 1
Control: tags -1 + moreinfo Hi Anibal, Le 2023-09-13 13:52, Anibal Monsalve Salazar a écrit : > Package: chrony > Version: 4.2-2 > Severity: critical > > # dpkg -i /mnt/apt/archives/chrony_4.4-1_i386.deb > (Reading database ... 34682 files and directories currently installed.) > Preparing to unpack .../archives/chrony_4.4-1_i386.deb ... > Failed to stop chronyd-restricted.service: Unit chronyd-restricted.service > not loaded. > Unpacking chrony (4.4-1) over (4.3-4) ... > Setting up chrony (4.4-1) ... > Unknown option: comment > adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] > [--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID] > [--disabled-password] [--disabled-login] [--add_extra_groups] USER >Add a normal user > > adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] > [--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password] > [--disabled-login] [--add_extra_groups] USER >Add a system user > > adduser --group [--gid ID] GROUP > addgroup [--gid ID] GROUP >Add a user group > > addgroup --system [--gid ID] GROUP >Add a system group > > adduser USER GROUP >Add an existing user to an existing group > > general options: > --quiet | -q don't give process information to stdout > --force-badname allow usernames which do not match the > NAME_REGEX configuration variable > --help | -h usage message > --version | -vversion number and copyright > --conf | -c FILE use FILE as configuration file > > dpkg: error processing package chrony (--install): > installed chrony package post-installation script subprocess returned error > exit status 1 > Processing triggers for man-db (2.11.2-3) ... > Errors were encountered while processing: > chrony I don't seem to be able to reproduce this issue. Could you please give me more information on the system on which you were upgrading chrony? It seems you were upgrading from chrony 4.3-4, so I guess this system is running testing/unstable‽ Cheers, Vincent signature.asc Description: PGP signature
Bug#1051496: mailgraph: does not support the new syslog format
Control: tags -1 patch upstream
On 2023-09-08 19:30:29 +0200, Vincent Lefevre wrote:
> mailgraph no longer works after the upgrade to bookworm, and
> this is probably due to the fact that it does not support the
> new syslog format: /usr/sbin/mailgraph contains
[...]
> and this format is no longer correct.
>
> There's a git repository where this bug seems to have been fixed
> 5 years ago:
>
> https://gist.github.com/mdklapwijk/4f8d2fc39f09f4aa615cbf8ffae0379a
I've attached a patch based on these modifications.
I've made 2 changes:
* This patch does not add a new type "rsyslog" for this new format;
so both formats are supported at the same time.
* Fixed a variable name ($mon → $montxt) for the old format.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: support the rsyslog high-precision timestamp format.
Patch based on M.D. Klapwijk's modifications for this support:
https://gist.github.com/mdklapwijk/4f8d2fc39f09f4aa615cbf8ffae0379a
(with some changes).
Author: Vincent Lefevre
Bug-Debian: https://bugs.debian.org/1051496
Last-Update: 2023-09-09
--- mailgraph.pl.bak
+++ mailgraph.pl
@@ -202,27 +202,41 @@
}
my $file = $self->{file};
line: while(defined (my $str = $self->_next_line)) {
-# date, time and host
-$str =~ /^
-(\S{3})\s+(\d+) # date -- 1, 2
-\s
-(\d+):(\d+):(\d+)# time -- 3, 4, 5
-(?:\s<\w+\.\w+>)?# FreeBSD's verbose-mode
-\s
-([-\w\.\@:]+)# host -- 6
-\s+
-(?:\[LOG_[A-Z]+\]\s+)? # FreeBSD
-(.*) # text -- 7
-$/x or do
-{
-warn "WARNING: line not in syslog format: $str";
-next line;
-};
-my $mon = $months_map{$1};
-defined $mon or croak "unknown month $1\n";
-$self->_year_increment($mon);
+# date, time and host
+my ($year, $mon, $day, $hour, $min, $sec, $host, $text);
+if(($year, $mon, $day, $hour, $min, $sec, $host, $text) = $str =~ /^
+(\d+)-(\d+)-(\d+)T(\d+):(\d+):(\d+)\S+ # datetime
+\s+
+(\S+) # host
+\s+
+(.*)# text
+$/x) {
+$mon--;
+$self->{year} = $year;
+}
+else {
+my $montxt;
+($montxt, $day, $hour, $min, $sec, $host, $text) = $str =~ /^
+(\S{3})\s+(\d+) # date
+\s
+(\d+):(\d+):(\d+)# time
+(?:\s<\w+\.\w+>)?# FreeBSD's verbose-mode
+\s
+([-\w\.\@:]+)# host
+\s+
+(?:\[LOG_[A-Z]+\]\s+)? # FreeBSD
+(.*) # text
+$/x or do
+{
+warn "WARNING: line not in syslog format: $str";
+next line;
+};
+$mon = $months_map{$montxt};
+defined $mon or croak "unknown month $montxt\n";
+$self->_year_increment($mon);
+}
# convert to unix time
-my $time = $self->str2time($5,$4,$3,$2,$mon,$self->{year}-1900,$self->{GMT});
+my $time = $self->str2time($sec,$min,$hour,$day,$mon,$self->{year}-1900,$self->{GMT});
if(not $self->{allow_future}) {
# accept maximum one day in the present future
if($time - time > 86400) {
@@ -230,7 +244,6 @@
next line;
}
}
-my ($host, $text) = ($6, $7);
# last message repeated ... times
if($text =~ /^(?:last message repeated|above message repeats) (\d+) time/) {
next line if defined $self->{repeat} and not $self->{repeat};
Bug#1051496: mailgraph: does not support the new syslog format
Package: mailgraph
Version: 1.14-20
Severity: grave
Justification: renders package unusable
mailgraph no longer works after the upgrade to bookworm, and
this is probably due to the fact that it does not support the
new syslog format: /usr/sbin/mailgraph contains
sub _next_syslog($)
{
[...]
line: while(defined (my $str = $self->_next_line)) {
# date, time and host
$str =~ /^
(\S{3})\s+(\d+) # date -- 1, 2
\s
(\d+):(\d+):(\d+)# time -- 3, 4, 5
(?:\s<\w+\.\w+>)?# FreeBSD's verbose-mode
\s
([-\w\.\@:]+)# host -- 6
\s+
(?:\[LOG_[A-Z]+\]\s+)? # FreeBSD
(.*) # text -- 7
$/x or do
{
warn "WARNING: line not in syslog format: $str";
next line;
};
and this format is no longer correct.
There's a git repository where this bug seems to have been fixed
5 years ago:
https://gist.github.com/mdklapwijk/4f8d2fc39f09f4aa615cbf8ffae0379a
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-11-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=POSIX, 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 mailgraph depends on:
ii debconf [debconf-2.0] 1.5.82
ii init-system-helpers1.65.2
ii libfile-tail-perl 1.3-7
ii librrds-perl 1.7.2-4+b8
ii lsb-base 11.6
ii perl 5.36.0-7
ii sysvinit-utils [lsb-base] 3.06-4
ii ucf3.0043+nmu1
Versions of packages mailgraph recommends:
ii apache2 [httpd] 2.4.57-2
ii postfix [mail-transport-agent] 3.7.6-0+deb12u2
mailgraph suggests no packages.
-- debconf information:
mailgraph/start_on_boot: true
mailgraph/ignore_localhost: false
mailgraph/mail_log: /var/log/mail.log
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1041492: xpra: FTBFS with ffmpeg 6.0
Control: tags -1 fixed-upstream On 2023-07-19 19:10:36 +0200, Sebastian Ramacher wrote: > xpra FTBFS with ffmpeg 6.0 (available in experimental) and in unstable since a few weeks. Any news? FYI, https://github.com/Xpra-org/xpra/blob/v3.1.x/src/NEWS says that this is fixed in v3.1.4 (2023-03-05): - ffmpeg v6 compatibility and 3.1.5 has even been released on 2023-06-15. Note also that ffmpeg will be removed from future xpra versions (6.x), if I understand correctly: https://github.com/Xpra-org/xpra/commit/20bb5f04233dc650022bc67d5904566d1b158af9 -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1051116: maildrop: depends on libgcc1, which is no longer in the archive
Package: maildrop Version: 2.9.3-2+b1 Severity: grave Justification: renders package unusable maildrop depends on libgcc1, which is no longer in the archive. This can be checked on https://packages.debian.org/en/bullseye/maildrop which says: dep: libgcc1 (>= 1:3.0) [not armel, armhf, i386, mipsel] Package not available This means that some obsolete packages such as libgcc1 cannot be removed before the upgrade to bookworm. -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-debug'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-25-amd64 (SMP w/1 CPU thread) Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maildrop depends on: ii courier-authlib 0.71.1-2 ii libc62.31-13+deb11u6 ii libcourier-unicode4 2.1.2-2 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libgcc1 1:8.3.0-6 ii libgdbm6 1.19-2 ii libpcre3 2:8.39-13 ii libstdc++6 10.2.1-6 Versions of packages maildrop recommends: ii postfix [mail-transport-agent] 3.5.18-0+deb11u1 maildrop suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1050361: RM: mangler -- RoQA; dead upstream; depends on gtk2
Control: severity -1 important On Wed, Aug 23, 2023 at 9:54 AM Bastian Germann wrote: > > Source: mangler > Severity: serious > Version: 1.2.5-5 > > mangler does not seem to be used a lot and is dead upstream. I doubt > that Ventrilo is still a thing nowadays. > > I intend to file a RM bug. > If you have any reasons to keep it in Debian please voice them here. > To get people's attention, I am filing as a serious bug and will > reassign to the FTP team when the package is autoremoved from testing. AFAIK mangler is the only Ventrilo client packaged in Debian, so I'd like to keep this package around until gtk2 removal is imminent (i.e. #947713 is set to severity serious). I see no reason to remove this package prematurely until that happens. I'll keep the package on life support in the meantime. Regards, Vincent
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
On 2023-08-19 07:39:24 +0200, Ansgar wrote: > On Fri, 2023-08-18 at 22:45 +0200, Vincent Lefevre wrote: > > On 2023-08-18 07:35:33 +0200, Ansgar wrote: > > > Please investigate why "usrmerge" is not installed (I assume this is an > > > upgraded system). Or, if it is installed, why /bin, /sbin, /lib* are > > > not symlinks to their respective counterparts in /usr. > > > > I've not upgraded init-system-helpers to 1.65.2 yet > > Please don't file RC bugs if you intentionally break your system. > Probably not non-RC bugs either. First, I initially wasn't aware that this was assuming usrmerge: there was no announce at all. Moreover, doing partial upgrades is not breaking the system. This is perfectly allowed. That's why there is a dependency system, and here, no Depends or Recommends was broken. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
On 2023-08-18 07:35:33 +0200, Ansgar wrote: > This seems the be the real issue: > > +--- > | Debian Release: trixie/sid > | [...] > | merged-usr: no > +---[ https://bugs.debian.org/1049969#5 ] > > /bin *must* be a symlink to /usr/bin, so /usr/bin/run-parts must exist > and cron's PATH is sufficient. > > Please investigate why "usrmerge" is not installed (I assume this is an > upgraded system). Or, if it is installed, why /bin, /sbin, /lib* are > not symlinks to their respective counterparts in /usr. I've not upgraded init-system-helpers to 1.65.2 yet as there are still unresolved major issues with usrmerge: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=usrmerge My machines are very old (2015), and there is some risk to break things (I've actually been in the process to replace them for several months, but there are issues with the French administration, and this takes time). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
Control: retitle -1 cron-daemon-common: in /etc/crontab, run-parts is no longer in $PATH That's actually the real reason. /etc/crontab has PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin but zira:~> dlocate =run-parts debianutils: /bin/run-parts -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
Package: cron-daemon-common Version: 3.0pl1-166 Severity: serious (set to serious because this is a regression whose effect will be to send a spurious mail every hour) After upgrading to 3.0pl1-166, I got a mail with Subject: Cron cd / && run-parts --report /etc/cron.hourly /bin/sh: 1: run-parts: not found This corresponds to this line in /etc/crontab: 17 ** * * rootcd / && run-parts --report /etc/cron.hourly And I suppose that I will get such a mail every hour. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron-daemon-common depends on: ii adduser 3.137 cron-daemon-common recommends no packages. cron-daemon-common suggests no packages. -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1035389: Timeline ETA
Is there any progress or an ETA when this will be picked up?
Bug#1042892: nvidia-legacy-390xx-kernel-dkms: dkms module does not build against kernel 6.4
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042081 for the same bug corresponding to nvidia-kernel-dkms. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1042537: manpages-fr-dev: trying to overwrite '/usr/share/man/fr/man3/uuid_generate_time_safe.3.gz', which is also in package util-linux-locales 2.39.1-3
Package: manpages-fr-dev Version: 4.19.0-6 Severity: serious There's still an issue about the move of man pages (and symlinks) to util-linux-locales (see bugs 1037040 and 1042484 on the subject): Unpacking manpages-fr-dev (4.19.0-6) over (4.19.0-3) ... dpkg: error processing archive /tmp/apt-dpkg-install-McsQDG/8-manpages-fr-dev_4.19.0-6_all.deb (--unpack): trying to overwrite '/usr/share/man/fr/man3/uuid_generate_time_safe.3.gz', which is also in package util-linux-locales 2.39.1-3 This is also a symlink. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled manpages-fr-dev depends on no packages. manpages-fr-dev recommends no packages. Versions of packages manpages-fr-dev suggests: ii glibc-doc 2.37-6 ii man-db [man-browser] 2.11.2-3 ii manpages-dev 6.03-2 -- no debconf information -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged
On 2023-07-28 18:04:24 +0200, Stéphane Glondu wrote: > Note that I would like to keep unison-2.52 (even if a newer version > is packaged) at least in trixie, to allow synchronizing between > bookworm and trixie. Is this version really needed? /usr/share/doc/unison-2.52/NEWS.md.gz says: ## Changes in 2.52.0 Released 2022-03-12 * Feature negotiation, compatible with 2.51. * New archive format (independent of ocaml version, based on umarshal) Upgrade is automatic. * New wire protocol (independent of ocaml version, based on umarshal) New protocol is used if both sides are >= 2.52.0. [...] But you could check and decide later. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1042484: util-linux-locales: /usr/share/man/fr/man1/lastb.1.gz is also in package manpages-fr 4.19.0-5
On 2023-07-29 12:06:01 +0200, Helge Kreutzmann wrote:
> Hello Vincent,
> On Sat, Jul 29, 2023 at 11:48:57AM +0200, Vincent Lefevre wrote:
> > So I would say that this is rather a bug in src:manpages-l10n
> > 4.19.0-5 (the new version meant to be compatible with
> > util-linux-locales 2.39.1-3). Or am I missing something?
>
> It is supposed to be deleted, but retained as broken symlink. I have a
> vague idea what might have happened, but I need to investigate.
The links are added by dh_link, with the .gz extension:
cventin:...pages-l10n-4.19.0> lf **/lastb*
lrwxrwxrwx 1 vlefevre vlefevre 9 2023-07-29 12:29:59
debian/manpages-de/usr/share/man/de/man1/lastb.1.gz -> last.1.gz
lrwxrwxrwx 1 vlefevre vlefevre 9 2023-07-29 12:33:32
debian/manpages-es/usr/share/man/es/man1/lastb.1.gz -> last.1.gz
lrwxrwxrwx 1 vlefevre vlefevre 9 2023-07-29 12:37:06
debian/manpages-fr/usr/share/man/fr/man1/lastb.1.gz -> last.1.gz
[...]
but
https://salsa.debian.org/debian/manpages-l10n/-/commit/eb4ed081ed33e54228978c68318994e5e6edeb05
("Further removals for util-linux transfer: Also the symlink ones (part 2)")
shows lines like
rm -f debian/manpages-es/usr/share/man/es/man1/lastb.1
without the .gz extension.
I suspect that this is the problem.
Also I have the impression that these rm are done too early
(before dh_link is called):
[...]
rm -f debian/manpages-uk/usr/share/man/uk/man8/wipefs.8
rm -f debian/manpages-uk/usr/share/man/uk/man8/zramctl.8
make[1]: Leaving directory '/home/vlefevre/tmp/manpages-l10n-4.19.0'
dh_perl
dh_link
but I'm not sure (the build is not finished on my machine).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1042484: util-linux-locales: /usr/share/man/fr/man1/lastb.1.gz is also in package manpages-fr 4.19.0-5
CC'ed Helge Kreutzmann (maintainer of manpages-l10n). On 2023-07-29 07:30:30 +0200, Jean-Marc wrote: > Package: util-linux-locales > Version: 2.39.1-3 > Severity: serious > Justification: 6 > X-Debbugs-Cc: jean-m...@6jf.be > > Dear Maintainer, > > Upgrading util-linux-locales from 2.38.1-6 to 2.39.1-3 failed and returned > this error message: > > Preparing to unpack .../util-linux-locales_2.39.1-3_all.deb ... > Unpacking util-linux-locales (2.39.1-3) over (2.38.1-6) ... > dpkg: error processing archive > /var/cache/apt/archives/util-linux-locales_2.39.1-3_all.deb (--unpack): > trying to overwrite '/usr/share/man/fr/man1/lastb.1.gz', which is also in > package manpages-fr 4.19.0-5 > Errors were encountered while processing: > /var/cache/apt/archives/util-linux-locales_2.39.1-3_all.deb If I understand correctly, lastb was expected to move from manpages-l10n to util-linux-locales: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037040#20 says Attached is a list of the new files that will show up in util-linux-locales. and the attached file includes lastb. And the file attached in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037040#30 about the manpages-l10n side does *not* contain lastb. So I would say that this is rather a bug in src:manpages-l10n 4.19.0-5 (the new version meant to be compatible with util-linux-locales 2.39.1-3). Or am I missing something? Regards, -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1041588: grep -r fails with "Operation not supported"
Control: tags -1 patch On 2023-07-21 19:38:08 +0200, Vincent Lefevre wrote: > Indeed, it's a bundled gnulib. I was surprised because there is > no "gnulib" directory. Actually these are just files under the m4 > directory. The bug is in "m4/dirfd.m4". I can see > > if test $ac_cv_func_dirfd = no && test $gl_cv_func_dirfd_macro = no; then > HAVE_DIRFD=0 > else > HAVE_DIRFD=1 > dnl Replace only if the system declares dirfd already. > if test $ac_cv_have_decl_dirfd = yes; then > REPLACE_DIRFD=1 > fi > > where the last 4 lines > > dnl Replace only if the system declares dirfd already. > if test $ac_cv_have_decl_dirfd = yes; then > REPLACE_DIRFD=1 > fi > > need to be removed to match the upstream gnulib fix. And I could check that the corresponding attached patch makes the error disappear. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) diff -Naurd grep-3.11-orig/m4/dirfd.m4 grep-3.11/m4/dirfd.m4 --- grep-3.11~/m4/dirfd.m4 2023-04-29 11:03:00.0 +0200 +++ grep-3.11/m4/dirfd.m4 2023-07-21 19:40:41.345044696 +0200 @@ -40,10 +40,6 @@ HAVE_DIRFD=0 else HAVE_DIRFD=1 -dnl Replace only if the system declares dirfd already. -if test $ac_cv_have_decl_dirfd = yes; then - REPLACE_DIRFD=1 -fi dnl Replace dirfd() on native Windows, to support fdopendir(). AC_REQUIRE([gl_DIRENT_DIR]) if test $DIR_HAS_FD_MEMBER = 0; then
Bug#1041588: grep -r fails with "Operation not supported"
On 2023-07-21 13:08:11 -0400, Boyuan Yang wrote: > BTW: Is grep 3.11-1 using Debian-packaged gnulib anywere? I did not > see a build-dependency in > https://sources.debian.org/src/grep/3.11-1/debian/control/ . > > * If grep is indeed using it, please include the build-dep explicitly. > > * If not, your current grep issue is unrelated to Debian-packaged gnulib and > you will need further debugging. Indeed, it's a bundled gnulib. I was surprised because there is no "gnulib" directory. Actually these are just files under the m4 directory. The bug is in "m4/dirfd.m4". I can see if test $ac_cv_func_dirfd = no && test $gl_cv_func_dirfd_macro = no; then HAVE_DIRFD=0 else HAVE_DIRFD=1 dnl Replace only if the system declares dirfd already. if test $ac_cv_have_decl_dirfd = yes; then REPLACE_DIRFD=1 fi where the last 4 lines dnl Replace only if the system declares dirfd already. if test $ac_cv_have_decl_dirfd = yes; then REPLACE_DIRFD=1 fi need to be removed to match the upstream gnulib fix. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
