Bug#1077197: libcurl4-openssl-dev: Insufficient dependencies for pkgconf requirements
On Fri, 26 Jul 2024 19:03:58 +0300 Adrian Bunk wrote: Package: libcurl4-openssl-dev Version: 8.9.0-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: Rene Engelhard Control: affects -1 libcurl4-gnutls-dev src:libreoffice $ pkgconf --cflags libcurl Package libidn2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libidn2.pc' to the PKG_CONFIG_PATH environment variable Package 'libidn2', required by 'libcurl', not found Package 'zlib', required by 'libcurl', not found Package 'libbrotlidec', required by 'libcurl', not found Package 'libzstd', required by 'libcurl', not found Package 'openssl', required by 'libcurl', not found Package 'libpsl', required by 'libcurl', not found Package 'libssh2', required by 'libcurl', not found Package 'librtmp', required by 'libcurl', not found Package 'libnghttp2', required by 'libcurl', not found $ This is due to the following that is not in the version in trixie: /usr/lib/x86_64-linux-gnu/pkgconfig/libcurl.pc:Requires.private: libidn2,zlib,libbrotlidec,libzstd,openssl,libpsl,libssh2,librtmp,libnghttp2 This also affects libcurl4-gnutls-dev OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1
Am 24.07.24 um 13:10 schrieb Michael Biebl: Control: affects -1 kwin-wayland I'm attaching a backtrace of the Xwayland crash. I assume once Xwayland crashes, kwin-waylands simply hangs there. The attached one is a better backtrace with dbgsym packages installed for xwayland (trying to start a plasma (wayland) session). PID: 2553 (Xwayland) UID: 1000 (michael) GID: 1000 (michael) Signal: 6 (ABRT) Timestamp: Wed 2024-07-24 13:35:38 CEST (1min 24s ago) Command Line: /usr/bin/Xwayland :1 -auth /run/user/1000/xauth_dhTrZM -listenfd 42 -listenfd 43 -displayfd 34 -rootless -wm 37 Executable: /usr/bin/Xwayland Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kwin_wayland.service Unit: user@1000.service User Unit: plasma-kwin_wayland.service Slice: user-1000.slice Owner UID: 1000 (michael) Boot ID: 0f300ad7ff3d424ead2e9df253442778 Machine ID: 99fb0a5ab0cc48af99d8633039a7f3c2 Hostname: debian Storage: /var/lib/systemd/coredump/core.Xwayland.1000.0f300ad7ff3d424ead2e9df253442778.2553.172182093800.zst (present) Size on Disk: 1.8M Message: Process 2553 (Xwayland) of user 1000 dumped core. Module libstdc++.so.6 from deb gcc-14-14.1.0-5.amd64 Module libzstd.so.1 from deb libzstd-1.5.6+dfsg-1.amd64 Module libgcc_s.so.1 from deb gcc-14-14.1.0-5.amd64 Stack trace of thread 2553: #0 0x7ff3734253ac __pthread_kill_implementation (libc.so.6 + 0x8e3ac) #1 0x7ff3733d64f2 __GI_raise (libc.so.6 + 0x3f4f2) #2 0x7ff3733bf4ed __GI_abort (libc.so.6 + 0x284ed) #3 0x561ef0a67fa0 OsAbort (Xwayland + 0x18efa0) #4 0x561ef0a6c709 AbortServer (Xwayland + 0x193709) #5 0x561ef0a6d6d9 FatalError (Xwayland + 0x1946d9) #6 0x561ef0a650e9 OsSigHandler (Xwayland + 0x18c0e9) #7 0x7ff3733d6590 __restore_rt (libc.so.6 + 0x3f590) #8 0x7ff373a2e244 wl_proxy_get_version (libwayland-client.so.0 + 0x8244) #9 0x561ef091f696 wl_shm_create_pool (Xwayland + 0x46696) #10 0x561ef09196a6 xwl_realize_cursor (Xwayland + 0x406a6) #11 0x561ef09eec95 AnimCurRealizeCursor (Xwayland + 0x115c95) #12 0x561ef099a0e4 InitializeSprite (Xwayland + 0xc10e4) #13 0x561ef0987572 EnableDevice (Xwayland + 0xae572) #14 0x561ef0988646 InitCoreDevices (Xwayland + 0xaf646) #15 0x561ef0993ba9 dix_main (Xwayland + 0xbaba9) #16 0x7ff3733c0c8a __libc_start_call_main (libc.so.6 + 0x29c8a) #17 0x7ff3733c0d45 __libc_start_main_impl (libc.so.6 + 0x29d45) #18 0x561ef0912ba1 _start (Xwayland + 0x39ba1) ELF object binary architecture: AMD x86-64 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1
Control: affects -1 kwin-wayland I'm attaching a backtrace of the Xwayland crash. I assume once Xwayland crashes, kwin-waylands simply hangs there. PID: 12411 (Xwayland) UID: 1000 (michael) GID: 1000 (michael) Signal: 6 (ABRT) Timestamp: Wed 2024-07-24 12:57:51 CEST (7min ago) Command Line: /usr/bin/Xwayland :1 -auth /run/user/1000/xauth_ZOAcsx -listenfd 50 -listenfd 51 -displayfd 42 -rootless -wm 45 Executable: /usr/bin/Xwayland Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kwin_wayland.service Unit: user@1000.service User Unit: plasma-kwin_wayland.service Slice: user-1000.slice Owner UID: 1000 (michael) Boot ID: 86f2abd3ad804710a057fe05ce954620 Machine ID: 97d9d85a6adb4ccb9f4079cfd58b28a4 Hostname: mars Storage: /var/lib/systemd/coredump/core.Xwayland.1000.86f2abd3ad804710a057fe05ce954620.12411.172181867100.zst (present) Size on Disk: 2.2M Message: Process 12411 (Xwayland) of user 1000 dumped core. Module libstdc++.so.6 from deb gcc-14-14.1.0-5.amd64 Module libzstd.so.1 from deb libzstd-1.5.6+dfsg-1.amd64 Module libgcc_s.so.1 from deb gcc-14-14.1.0-5.amd64 Stack trace of thread 12411: #0 0x7f3790c963ac n/a (libc.so.6 + 0x8e3ac) #1 0x7f3790c474f2 raise (libc.so.6 + 0x3f4f2) #2 0x7f3790c304ed abort (libc.so.6 + 0x284ed) #3 0x55ffb57cbfa0 n/a (Xwayland + 0x18efa0) #4 0x55ffb57d0709 n/a (Xwayland + 0x193709) #5 0x55ffb57d16d9 n/a (Xwayland + 0x1946d9) #6 0x55ffb57c90e9 n/a (Xwayland + 0x18c0e9) #7 0x7f3790c47590 n/a (libc.so.6 + 0x3f590) #8 0x7f379129f224 wl_proxy_get_version (libwayland-client.so.0 + 0x8224) #9 0x55ffb5683696 n/a (Xwayland + 0x46696) #10 0x55ffb567d6a6 n/a (Xwayland + 0x406a6) #11 0x55ffb5752c95 n/a (Xwayland + 0x115c95) #12 0x55ffb56fe0e4 n/a (Xwayland + 0xc10e4) #13 0x55ffb56eb572 n/a (Xwayland + 0xae572) #14 0x55ffb56ec646 n/a (Xwayland + 0xaf646) #15 0x55ffb56f7ba9 n/a (Xwayland + 0xbaba9) #16 0x7f3790c31c8a n/a (libc.so.6 + 0x29c8a) #17 0x7f3790c31d45 __libc_start_main (libc.so.6 + 0x29d45) #18 0x55ffb5676ba1 n/a (Xwayland + 0x39ba1) Stack trace of thread 12420: #0 0x7f3790c911be n/a (libc.so.6 + 0x891be) #1 0x7f3790c93920 pthread_cond_wait (libc.so.6 + 0x8b920) #2 0x7f378e11e5ed n/a (radeonsi_dri.so + 0x11e5ed) #3 0x7f378e0fe37b n/a (radeonsi_dri.so + 0xfe37b) #4 0x7f378e11e51b n/a (radeonsi_dri.so + 0x11e51b) #5 0x7f3790c946c2 n/a (libc.so.6 + 0x8c6c2) #6 0x7f3790d0f128 n/a (libc.so.6 + 0x107128) Stack trace of thread 12419: #0 0x7f3790c911be n/a (libc.so.6 + 0x891be) #1 0x7f3790c93920 pthread_cond_wait (libc.so.6 + 0x8b920) #2 0x7f378e11e5ed n/a (radeonsi_dri.so + 0x11e5ed) #3 0x7f378e0fe37b n/a (radeonsi_dri.so + 0xfe37b) #4 0x7f378e11e51b n/a (radeonsi_dri.so + 0x11e51b) #5 0x7f3790c946c2 n/a (libc.so.6 + 0x8c6c2) #6 0x7f3790d0f128 n/a (libc.so.6 + 0x107128) Stack trace of thread 12429: #0 0x7f3790c911be n/a (libc.so.6 + 0x891be) #1 0x7f3790c93920 pthread_cond_wait (libc.so.6 + 0x8b920) #2 0x7f378e11e5ed n/a (radeonsi_dri.so + 0x11e5ed) #3 0x7f378e0fe37b n/a (radeonsi_dri.so + 0xfe37b) #4 0x7f378e11e51b n/a (radeonsi_dri.so + 0x11e51b) #5 0x7f3790c946c2 n/a (libc.so.6 + 0x8c6c2) #6 0x7f3790d0f128 n/a (libc.so.6 + 0x107128) Stack trace of thread 12427: #0 0x7f3790c911be n/a (libc.so.6 + 0x891be) #1 0x7f3790c93920 pthread_cond_wait (libc.so.6 + 0x8b920) #2 0x7f378e11e5ed n/a (radeonsi_dri.so + 0x11e5ed) #3 0x7f378e0fe37b n/a (radeonsi_dri.so + 0xfe37b) #4 0x7f378e11e51b n/a (radeonsi_dri.so + 0x11e51b) #5 0x7f3790c946c2 n/a (libc.so.6 + 0x8c6c2) #6 0x7f3790d0f128 n/a (libc.so.6 + 0x107128) Stack trace of thread 12413: #0 0x7f3790c911be n/a (libc.so.6 + 0x891be) #1 0x7f3790c93920
Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1
On Tue, 23 Jul 2024 23:05:21 +0200 Michael Biebl wrote: Bumping the issue to RC so users are informed before the upgrade and the faulty package doesn't migrate to testing. Also reassigning to a more appropriate package and fixing the version (1.22.0-2.1+b1 is explicitly not affected). Running a git bisect shows f06736a8a0880ab159d946b06407268ddb41bd4d as the first faulty commit: https://gitlab.freedesktop.org/wayland/wayland/-/commit/f06736a8a0880ab159d946b06407268ddb41bd4d OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074789: daemon-rexec no longer reopens /run/systemd/userdb/io.systemd.DynamicUser
Am 20.07.24 um 17:44 schrieb Michael Biebl: Am 20.07.24 um 17:40 schrieb Michael Biebl: Am 20.07.24 um 17:36 schrieb Michael Biebl: Btw, I vaguely remember successfully testing dist-upgrades of a GNOME installation from bullseye to bookworm. So I suspect this was broken by one of the latest stable updates Just tested this by upgrading 247.3-7+deb11u4 → 252.6-1 (snapshots.d.o) → systemd listens on the socket after the upgrade 247.3-7+deb11u4 → 252.26-1~deb12u2 (bookworm) → systemd *does not* listen on the socket after the upgrade Given that these bug reports started popping up only recently, my guess is that it's one of the more recent systemd stable updates like 252.26-1~deb12u2 which regressed. git bisect shows https://github.com/systemd/systemd-stable/commit/a5fd23650dc as the first faulty commit: core/varlink: make sure we setup non-serialized varlink sockets Before this PR, if m->varlink_server is not yet set up during deserialization, we call manager_setup_varlink_server rather than manager_varlink_init, the former of which doesn't setup varlink addresses, but only binds to methods. This results in that newly-added varlink addresses not getting created if deserialization takes place. Therefore, let's switch to manager_varlink_init, and add some sanity checks to it in order to prevent listening on the same address twice. Reverting that fixes daemon-reexec on upgrades. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074789: daemon-rexec no longer reopens /run/systemd/userdb/io.systemd.DynamicUser
Am 20.07.24 um 17:40 schrieb Michael Biebl: Am 20.07.24 um 17:36 schrieb Michael Biebl: Btw, I vaguely remember successfully testing dist-upgrades of a GNOME installation from bullseye to bookworm. So I suspect this was broken by one of the latest stable updates Just tested this by upgrading 247.3-7+deb11u4 → 252.6-1 (snapshots.d.o) → systemd listens on the socket after the upgrade 247.3-7+deb11u4 → 252.26-1~deb12u2 (bookworm) → systemd *does not* listen on the socket after the upgrade Given that these bug reports started popping up only recently, my guess is that it's one of the more recent systemd stable updates like 252.26-1~deb12u2 which regressed. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074789: daemon-rexec no longer reopens /run/systemd/userdb/io.systemd.DynamicUser
Am 20.07.24 um 17:36 schrieb Michael Biebl: Btw, I vaguely remember successfully testing dist-upgrades of a GNOME installation from bullseye to bookworm. So I suspect this was broken by one of the latest stable updates Just tested this by upgrading 247.3-7+deb11u4 → 252.6-1 (snapshots.d.o) → systemd listens on the socket after the upgrade 247.3-7+deb11u4 → 252.26-1~deb12u2 (bookworm) → systemd *does not* listen on the socket after the upgrade OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074789: Use SYSTEMD_NSS_DYNAMIC_BYPASS=1 ?
Am 20.07.24 um 17:24 schrieb Michael Biebl: Control: severity -1 serious I can reproduce the "Failed to check if group polkitd already exists: Connection refused" error in a bullseye VM that is dist-upgraded to bookworm. systemd v247 before the upgrade listens on /run/systemd/userdb/io.systemd.DynamicUser once systemd has been upgraded to v252 and reexecd in postinst, systemd no longer listens on this socket. ... Afterwards, PID 1 no longer listens on the socket. I assume that something goes wrong during the daemon-reexec causing systemd to reopen the socket. Any subsequent call to systemd-sysusers then fails. Btw, I vaguely remember successfully testing dist-upgrades of a GNOME installation from bullseye to bookworm. So I suspect this was broken by one of the latest stable updates OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060545: drbd-utils: Please switch Build-Depends to systemd-dev
Control: tags -1 + patch pending
I've uploaded an updated package to DELAYED/14.
Please find a debdiff attached.
Regards,
Michael
diff -Nru drbd-utils-9.22.0/debian/changelog drbd-utils-9.22.0/debian/changelog
--- drbd-utils-9.22.0/debian/changelog 2023-01-09 15:51:18.0 +0100
+++ drbd-utils-9.22.0/debian/changelog 2024-07-17 19:22:06.0 +0200
@@ -1,3 +1,27 @@
+drbd-utils (9.22.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add Build-Depends on pkgconf and systemd-dev to get the proper paths for
+udev rules and systemd service files. (Closes: #1060545, #921153)
+ * Rely on systemd.pc and udev.pc to get the correct paths and do not
+override it in debian/rules.
+ * Do not set sbindir in debian/rules and use the default instead, which is
+/usr/sbin.
+ * Install drdb.conf modules-load config into /usr/lib/modules-load.d/ which
+is the canonical location.
+ * Drop debian/patches/0005-initscript-remove-path.patch which is no longer
+applicable.
+ * Drop debian/drbd-utils.dirs, it is not actually needed and creates
+unneeded directories like lib/udev/rules.d.
+ * Add debian/patches/0009-no-hard-coded-paths.patch which ensures that all
+scripts and binaries are installed into /usr.
+ * The changes above ensure that all files are installed into non-aliased
+locations. (Closes: #1073716)
+ * Drop debian/drbd-utils.postinst which is no longer needed.
+ * Drop dependency on obsolete package lsb-base.
+
+ -- Michael Biebl Wed, 17 Jul 2024 19:22:06 +0200
+
drbd-utils (9.22.0-1) unstable; urgency=medium
* New upstream version 9.22.0
diff -Nru drbd-utils-9.22.0/debian/control drbd-utils-9.22.0/debian/control
--- drbd-utils-9.22.0/debian/control2023-01-09 15:50:35.0 +0100
+++ drbd-utils-9.22.0/debian/control2024-07-17 19:22:06.0 +0200
@@ -9,7 +9,9 @@
docbook-xsl,
docbook-xml,
asciidoctor,
+ pkgconf,
udev,
+ systemd-dev,
bash-completion,
po4a
Standards-Version: 4.6.1
@@ -19,8 +21,7 @@
Package: drbd-utils
Architecture: linux-any
-Depends: lsb-base (>= 3.0-6),
- ${shlibs:Depends},
+Depends: ${shlibs:Depends},
${misc:Depends}
Breaks: drbd8-utils (<< 2:8.9.0)
Replaces: drbd8-utils (<< 2:8.9.0)
diff -Nru drbd-utils-9.22.0/debian/drbd-utils.dirs
drbd-utils-9.22.0/debian/drbd-utils.dirs
--- drbd-utils-9.22.0/debian/drbd-utils.dirs2020-08-24 15:35:36.0
+0200
+++ drbd-utils-9.22.0/debian/drbd-utils.dirs1970-01-01 01:00:00.0
+0100
@@ -1,4 +0,0 @@
-etc
-etc/init.d
-etc/ha.d/resource.d
-lib/udev/rules.d
diff -Nru drbd-utils-9.22.0/debian/drbd-utils.postinst
drbd-utils-9.22.0/debian/drbd-utils.postinst
--- drbd-utils-9.22.0/debian/drbd-utils.postinst2020-08-24
15:35:36.0 +0200
+++ drbd-utils-9.22.0/debian/drbd-utils.postinst1970-01-01
01:00:00.0 +0100
@@ -1,13 +0,0 @@
-#!/bin/sh
-
-set -e
-
-# Cleanup the old systemd unit state, if applicable
-if dpkg --compare-versions "$2" lt-nl "8.9.5-1~"; then
- if deb-systemd-helper debian-installed drbd.service; then
- deb-systemd-helper purge drbd.service >/dev/null
- deb-systemd-helper unmask drbd.service >/dev/null
- fi
-fi
-
-#DEBHELPER#
diff -Nru drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch
drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch
--- drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch
2022-07-19 12:24:50.0 +0200
+++ drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch
1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-From: Apollon Oikonomopoulos
-Date: Mon, 18 Nov 2019 22:27:25 +0200
-Subject: Remove /usr from the initscript's PATH
-
-All utilities reside on /sbin. Furthermore, the declaration of
-/usr/sbin makes lintian complain about a missing dependency on $remote_fs,
-which is strictly not necessary.
-Last-Update: 2014-06-13
-Forwarded: no
- scripts/drbd | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/scripts/drbd b/scripts/drbd
-index fbed28f..333eedb 100755
a/scripts/drbd
-+++ b/scripts/drbd
-@@ -41,7 +41,7 @@ RMMOD="/sbin/rmmod"
- UDEV_TIMEOUT=10
- ADD_MOD_PARAM=""
-
--PATH=/usr/sbin:/sbin:$PATH
-+PATH=/sbin:/bin
-
- if [ -f $DEFAULTFILE ]; then
- . $DEFAULTFILE
diff -Nru drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch
drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch
--- drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch
1970-01-01 01:00:00.0 +0100
+++ drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch
2024-07-17 19:22:06.0 +0200
@@ -0,0 +1,91 @@
+Description: Do not hard-code paths to install scripts and helper binaries
+ Instead use $LIBDIR everyw
Bug#1052643: intel-hdcp: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending patch
I've uploaded an updated package to DELAYED/14 fixing both RC issues.
debdiff is attached.
Regards,
Michael
diff -Nru intel-hdcp-20.3.0/debian/changelog intel-hdcp-20.3.0/debian/changelog
--- intel-hdcp-20.3.0/debian/changelog 2020-10-17 12:42:44.0 +0200
+++ intel-hdcp-20.3.0/debian/changelog 2024-07-17 20:02:41.0 +0200
@@ -1,3 +1,17 @@
+intel-hdcp (20.3.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Michael Biebl ]
+ * Replace systemd Build-Depends with systemd-dev for systemd.pc.
+(Closes: #1060469)
+ * Replace Build-Depends on obsolete pkg-config with pkgconf.
+
+ [ Helmut Grohne ]
+ * Fix FTBFS when systemd.pc changes systemdsystemunitdir. (Closes: #1052643)
+
+ -- Michael Biebl Wed, 17 Jul 2024 20:02:41 +0200
+
intel-hdcp (20.3.0-1) unstable; urgency=medium
* Initial release (Closes: #972379)
diff -Nru intel-hdcp-20.3.0/debian/control intel-hdcp-20.3.0/debian/control
--- intel-hdcp-20.3.0/debian/control2020-10-17 12:36:10.0 +0200
+++ intel-hdcp-20.3.0/debian/control2024-07-17 20:02:30.0 +0200
@@ -8,8 +8,8 @@
libegl-dev,
libssl-dev,
libwayland-dev,
- pkg-config,
- systemd,
+ pkgconf,
+ systemd-dev,
Standards-Version: 4.5.0
Homepage: https://github.com/intel/hdcp
Vcs-Browser: https://salsa.debian.org/debian/intel-hdcp
diff -Nru intel-hdcp-20.3.0/debian/intel-hdcp.install
intel-hdcp-20.3.0/debian/intel-hdcp.install
--- intel-hdcp-20.3.0/debian/intel-hdcp.install 2020-10-17 11:51:03.0
+0200
+++ intel-hdcp-20.3.0/debian/intel-hdcp.install 2024-07-17 20:02:41.0
+0200
@@ -1,2 +1,2 @@
-lib/systemd/system/hdcpd.service
+${env:systemdsystemunitdir}/hdcpd.service
usr/bin/hdcpd
diff -Nru intel-hdcp-20.3.0/debian/rules intel-hdcp-20.3.0/debian/rules
--- intel-hdcp-20.3.0/debian/rules 2020-10-16 11:12:01.0 +0200
+++ intel-hdcp-20.3.0/debian/rules 2024-07-17 20:02:41.0 +0200
@@ -1,5 +1,7 @@
#!/usr/bin/make -f
+export systemdsystemunitdir = $(shell pkg-config
--variable=systemdsystemunitdir systemd)
+
%:
dh $@ --builddir build/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1060492: freeipa: Please switch Build-Depends to systemd-dev
Control: tags -1 + patch pending I've uploaded an updated package to DELAYED/14. debdiff is attached. Regards, Michael diff -Nru freeipa-4.11.1/debian/changelog freeipa-4.11.1/debian/changelog --- freeipa-4.11.1/debian/changelog 2024-04-12 13:31:35.0 +0200 +++ freeipa-4.11.1/debian/changelog 2024-07-17 19:35:06.0 +0200 @@ -1,3 +1,11 @@ +freeipa (4.11.1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace systemd Build-Depends with systemd-dev for systemd.pc. +(Closes: #1060469) + + -- Michael Biebl Wed, 17 Jul 2024 19:35:06 +0200 + freeipa (4.11.1-2) unstable; urgency=medium * use-raw-strings.diff: Import patch from upstream to fix noise when diff -Nru freeipa-4.11.1/debian/control freeipa-4.11.1/debian/control --- freeipa-4.11.1/debian/control 2024-04-12 13:31:35.0 +0200 +++ freeipa-4.11.1/debian/control 2024-07-17 19:35:01.0 +0200 @@ -49,7 +49,7 @@ python3-sss (>= 1.14.0), python3-usb (>= 1.0.0~b2), python3-yubico, - systemd, + systemd-dev, uuid-dev, Package: freeipa-common OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060560: spice-vdagent: Please switch Build-Depends to systemd-dev
Control: tags -1 + patch pending I've uploaded an updated package to DELAYED/14. debdiff is attached. Regards, Michael diff -Nru spice-vdagent-0.22.1/debian/changelog spice-vdagent-0.22.1/debian/changelog --- spice-vdagent-0.22.1/debian/changelog 2023-11-21 07:53:12.0 +0100 +++ spice-vdagent-0.22.1/debian/changelog 2024-07-17 18:52:52.0 +0200 @@ -1,3 +1,11 @@ +spice-vdagent (0.22.1-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop systemd and udev Build-Depends and only keep systemd-dev. Only the +latter is required to get systemd.pc and udev.pc. (Closes: #1060560) + + -- Michael Biebl Wed, 17 Jul 2024 18:52:52 +0200 + spice-vdagent (0.22.1-4) unstable; urgency=medium [ Helmut Grohne ] diff -Nru spice-vdagent-0.22.1/debian/control spice-vdagent-0.22.1/debian/control --- spice-vdagent-0.22.1/debian/control 2023-11-21 07:53:12.0 +0100 +++ spice-vdagent-0.22.1/debian/control 2024-07-17 18:52:46.0 +0200 @@ -16,9 +16,7 @@ libxrandr-dev, pkg-config, procps, - systemd, systemd-dev, - udev, libdrm-dev Standards-Version: 4.6.2 Section: x11 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060573: nitrokey-app: Please switch Build-Depends to systemd-dev
tags 1067912 + patch pending thanks Am 17.07.24 um 16:47 schrieb Michael Biebl: Control: tags -1 + pending patch It appears the udev Build-Depends is no longer necessary as the udev rules file was moved into libnitrokey. I've uploaded a fixed package to DELAYED/14. debdiff is attached. Regards, Michael While at it, I've included another RC bug fix for 1067912 in the NMU. Updated debdiff attached. Regards, Michael diff -Nru nitrokey-app-1.4.2/debian/changelog nitrokey-app-1.4.2/debian/changelog --- nitrokey-app-1.4.2/debian/changelog 2021-02-08 12:12:12.0 +0100 +++ nitrokey-app-1.4.2/debian/changelog 2024-07-17 16:38:50.0 +0200 @@ -1,3 +1,15 @@ +nitrokey-app (1.4.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop no longer needed udev Build-Depends, the udev rules file was moved +into libnitrokey. (Closes: #1060573) + * Drop Build-Depends on libqt5concurrent5. +This library was renamed as part of the time64 transition. As it is pulled +in automatically via qtbase5-dev, it appears removing it is preferrably to +changing it. (Closes: #1067912) + + -- Michael Biebl Wed, 17 Jul 2024 16:38:50 +0200 + nitrokey-app (1.4.2-1) unstable; urgency=medium * New upstream release. diff -Nru nitrokey-app-1.4.2/debian/control nitrokey-app-1.4.2/debian/control --- nitrokey-app-1.4.2/debian/control 2021-02-08 12:12:12.0 +0100 +++ nitrokey-app-1.4.2/debian/control 2024-07-17 16:38:50.0 +0200 @@ -6,12 +6,10 @@ cmake (>=3.1.0), debhelper (>= 13~), libusb-1.0-0-dev, - udev, qtbase5-dev, qt5-qmake, qttools5-dev, libqt5svg5-dev, - libqt5concurrent5, libhidapi-dev, pkg-config, libnitrokey-dev (>=3.5) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060570: golang-github-containers-toolbox: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending patch I've uploaded a fixed package to DELAYED/14. debdiff is attached. Regards, Michael diff -Nru golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/changelog golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/changelog --- golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/changelog 2023-01-29 17:45:53.0 +0100 +++ golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/changelog 2024-07-17 16:59:05.0 +0200 @@ -1,3 +1,11 @@ +golang-github-containers-toolbox (0.0.99.3+git20230118+446d7bfdef6a-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace systemd Build-Depends with systemd-dev for systemd.pc. +(Closes: #1065386) + + -- Michael Biebl Wed, 17 Jul 2024 16:59:05 +0200 + golang-github-containers-toolbox (0.0.99.3+git20230118+446d7bfdef6a-2) unstable; urgency=medium * Add community images for Debian and Ubuntu. diff -Nru golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/control golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/control --- golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/control 2023-01-29 17:45:53.0 +0100 +++ golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/debian/control 2024-07-17 16:59:05.0 +0200 @@ -32,7 +32,7 @@ pkgconf, skopeo , shellcheck , - systemd, + systemd-dev, Standards-Version: 4.6.0 Homepage: https://containertoolbx.org/ Vcs-Browser: https://salsa.debian.org/debian/podman-toolbox OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060573: nitrokey-app: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending patch It appears the udev Build-Depends is no longer necessary as the udev rules file was moved into libnitrokey. I've uploaded a fixed package to DELAYED/14. debdiff is attached. Regards, Michael diff -Nru nitrokey-app-1.4.2/debian/changelog nitrokey-app-1.4.2/debian/changelog --- nitrokey-app-1.4.2/debian/changelog 2021-02-08 12:12:12.0 +0100 +++ nitrokey-app-1.4.2/debian/changelog 2024-07-17 16:38:50.0 +0200 @@ -1,3 +1,11 @@ +nitrokey-app (1.4.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop no longer needed udev Build-Depends, the udev rules file was moved +into libnitrokey. (Closes: #1060573) + + -- Michael Biebl Wed, 17 Jul 2024 16:38:50 +0200 + nitrokey-app (1.4.2-1) unstable; urgency=medium * New upstream release. diff -Nru nitrokey-app-1.4.2/debian/control nitrokey-app-1.4.2/debian/control --- nitrokey-app-1.4.2/debian/control 2021-02-08 12:12:12.0 +0100 +++ nitrokey-app-1.4.2/debian/control 2024-07-17 16:38:50.0 +0200 @@ -6,7 +6,6 @@ cmake (>=3.1.0), debhelper (>= 13~), libusb-1.0-0-dev, - udev, qtbase5-dev, qt5-qmake, qttools5-dev, OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060587: ledmon: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending patch I've uploaded a fixed package to DELAYED/14. debdiff is attached. A diff of the binary packages shows: $ debdiff --nocontrol ledmon_0.97-1_amd64.changes ledmon_0.97-1.1_amd64.changes [The following lists of changes regard files as different if they have different names, permissions or owners.] Files in second .changes but not in first - -rw-r--r-- root/root /usr/lib/systemd/system/ledmon.service Regards, Michael diff -Nru ledmon-0.97/debian/changelog ledmon-0.97/debian/changelog --- ledmon-0.97/debian/changelog2024-02-27 16:20:44.0 +0100 +++ ledmon-0.97/debian/changelog2024-07-17 16:29:18.0 +0200 @@ -1,3 +1,10 @@ +ledmon (0.97-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace systemd Build-Depends with systemd-dev. (Closes: #1060587) + + -- Michael Biebl Wed, 17 Jul 2024 16:29:18 +0200 + ledmon (0.97-1) unstable; urgency=medium * New upstream release 0.97. diff -Nru ledmon-0.97/debian/control ledmon-0.97/debian/control --- ledmon-0.97/debian/control 2024-02-27 16:20:44.0 +0100 +++ ledmon-0.97/debian/control 2024-07-17 16:29:16.0 +0200 @@ -2,7 +2,7 @@ Section: admin Priority: optional Maintainer: Hsieh-Tseng Shen -Build-Depends: debhelper-compat (= 13), systemd, pkg-config, libsgutils2-dev, libudev-dev, libpci-dev +Build-Depends: debhelper-compat (= 13), systemd-dev, pkg-config, libsgutils2-dev, libudev-dev, libpci-dev Standards-Version: 4.6.1 Rules-Requires-Root: no Vcs-Git: https://salsa.debian.org/debian/ledmon.git OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060589: certmonger: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending I've uploaded a fixed package to DELAYED/14. debdiff is attached. Regards, Michael diff -Nru certmonger-0.79.19/debian/changelog certmonger-0.79.19/debian/changelog --- certmonger-0.79.19/debian/changelog 2023-10-17 13:18:42.0 +0200 +++ certmonger-0.79.19/debian/changelog 2024-07-17 16:17:36.0 +0200 @@ -1,3 +1,10 @@ +certmonger (0.79.19-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace systemd Build-Depends with systemd-dev. (Closes: #1060589) + + -- Michael Biebl Wed, 17 Jul 2024 16:17:36 +0200 + certmonger (0.79.19-1) unstable; urgency=medium [ Timo Aaltonen ] diff -Nru certmonger-0.79.19/debian/control certmonger-0.79.19/debian/control --- certmonger-0.79.19/debian/control 2023-10-17 12:57:50.0 +0200 +++ certmonger-0.79.19/debian/control 2024-07-17 16:17:34.0 +0200 @@ -19,7 +19,7 @@ libnss3-dev (>= 2:3.69), libpopt-dev, libssl-dev, - systemd [linux-any], + systemd-dev [linux-any], libtevent-dev, libxml2-dev, lsb-release, OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065386: anytun: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending I've uploaded a fixed package to DELAYED/14. debdiff is attached. Regards, Michael diff -Nru anytun-0.3.8/debian/changelog anytun-0.3.8/debian/changelog --- anytun-0.3.8/debian/changelog 2021-02-05 13:23:34.0 +0100 +++ anytun-0.3.8/debian/changelog 2024-07-17 15:12:59.0 +0200 @@ -1,3 +1,10 @@ +anytun (0.3.8-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Replace systemd Build-Depends with systemd-dev (Closes: #1065386) + + -- Michael Biebl Wed, 17 Jul 2024 15:12:59 +0200 + anytun (0.3.8-1) unstable; urgency=medium [ Darshaka Pathirana ] diff -Nru anytun-0.3.8/debian/control anytun-0.3.8/debian/control --- anytun-0.3.8/debian/control 2021-02-05 13:23:34.0 +0100 +++ anytun-0.3.8/debian/control 2024-07-17 15:12:48.0 +0200 @@ -10,7 +10,7 @@ libboost-thread-dev, libgcrypt20-dev, pkg-config, - systemd + systemd-dev Homepage: http://www.anytun.org/ Standards-Version: 4.5.1 Vcs-git: https://salsa.debian.org/debian/anytun.git OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest
Control: reassign -1 src:firewalld Control: found -1 2.1.2-1 Control: severity -1 important Control: forwarded -1 https://github.com/firewalld/firewalld/pull/1360 We will handle this on the firewalld side. So reassigning accordingly. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest
Looping in Eric (firewalld upstream), to make him aware of this issue
and gather his input.
Michael
Am 17.06.24 um 22:16 schrieb Jeremy Sowden:
On 2024-06-17, at 15:57:05 +0200, Michael Biebl wrote:
Source: iptables
Version: 1.8.10-4
Severity: serious
The cherry-pick of the commit 34f085b1607364f4eaded1140060dcaf965a2649
Revert "xshared: Print protocol numbers if --numeric was given" breaks
firewalld, as seen in
https://ci.debian.net/packages/f/firewalld/testing/amd64/47810213/
firewalld is very susceptible to changes of the output and command
line interface of iptables. See an older issue
https://github.com/firewalld/firewalld/issues/1112
Filing with RC severity, so the package doesn't migrate to testing
(the debci results should prevent that, but this is just to make
doubly sure)
This change of iptables afaics has landed in a stable release
(bookworm). Do we really want to revert it again and make all users of
--numeric have to update again?
Hi. Let me explain my understanding of the current situation. I appre-
ciate that you probably know most of this already, but I just want to
avoid any confusion.
Upstream made a change that affected the output of protocols in listings
in the presence of the `--numeric` flag. Previously, they were still
output by name, after the change they were output by number. This was
released upstream in 1.8.9 and made its way into Bookworm.
This change broke stuff. As a result of a bug-report:
https://bugzilla.netfilter.org/show_bug.cgi?id=1729
upstream reverted the change in commit 34f085b16073 ("Revert "xshared:
Print protocol numbers if --numeric was given""). This is where things
currently stand upstream: in the next release (1.8.11), the original
behaviour will be restored.
A report was also created in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067733
In response, I applied the upstream commit and uploaded it to unstable.
I have a draft bookworm-pu bug-report that I had intended to send
requesting that this change go into Bookworm to minimize the time before
the old behaviour is restored. Obviously, I will hold off while we
discuss this. :)
What do you propose? The firewalld test-suite was updated to work with
the new output; however, other tools were not, and upstream reverted the
change because there were no compelling reasons for it and it had caused
breakage in those tools. As things stand, the old behaviour will be re-
stored. Would you rather wait for the next upstream release? Are you
suggesting that we ask upstream to revert 34f085b16073? Or do you have
something else in mind?
J.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest
Am 17.06.24 um 22:16 schrieb Jeremy Sowden:
On 2024-06-17, at 15:57:05 +0200, Michael Biebl wrote:
Source: iptables
Version: 1.8.10-4
Severity: serious
The cherry-pick of the commit 34f085b1607364f4eaded1140060dcaf965a2649
Revert "xshared: Print protocol numbers if --numeric was given" breaks
firewalld, as seen in
https://ci.debian.net/packages/f/firewalld/testing/amd64/47810213/
firewalld is very susceptible to changes of the output and command
line interface of iptables. See an older issue
https://github.com/firewalld/firewalld/issues/1112
Filing with RC severity, so the package doesn't migrate to testing
(the debci results should prevent that, but this is just to make
doubly sure)
This change of iptables afaics has landed in a stable release
(bookworm). Do we really want to revert it again and make all users of
--numeric have to update again?
Hi. Let me explain my understanding of the current situation. I appre-
ciate that you probably know most of this already, but I just want to
avoid any confusion.
Upstream made a change that affected the output of protocols in listings
in the presence of the `--numeric` flag. Previously, they were still
output by name, after the change they were output by number. This was
released upstream in 1.8.9 and made its way into Bookworm.
This change broke stuff. As a result of a bug-report:
https://bugzilla.netfilter.org/show_bug.cgi?id=1729
upstream reverted the change in commit 34f085b16073 ("Revert "xshared:
Print protocol numbers if --numeric was given""). This is where things
currently stand upstream: in the next release (1.8.11), the original
behaviour will be restored.
A report was also created in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067733
In response, I applied the upstream commit and uploaded it to unstable.
I have a draft bookworm-pu bug-report that I had intended to send
requesting that this change go into Bookworm to minimize the time before
the old behaviour is restored. Obviously, I will hold off while we
discuss this. :)
What do you propose? The firewalld test-suite was updated to work with
the new output; however, other tools were not, and upstream reverted the
change because there were no compelling reasons for it and it had caused
breakage in those tools. As things stand, the old behaviour will be re-
stored. Would you rather wait for the next upstream release? Are you
suggesting that we ask upstream to revert 34f085b16073? Or do you have
something else in mind?
Maybe inform iptables upstream about this.
Personally I think it's to late to revert this again. After, it's now
two years since this change was committed and you might just as well
break tools now which rely on the new/fixed behaviour.
Regards,
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest
Source: iptables Version: 1.8.10-4 Severity: serious The cherry-pick of the commit 34f085b1607364f4eaded1140060dcaf965a2649 Revert "xshared: Print protocol numbers if --numeric was given" breaks firewalld, as seen in https://ci.debian.net/packages/f/firewalld/testing/amd64/47810213/ firewalld is very susceptible to changes of the output and command line interface of iptables. See an older issue https://github.com/firewalld/firewalld/issues/1112 Filing with RC severity, so the package doesn't migrate to testing (the debci results should prevent that, but this is just to make doubly sure) This change of iptables afaics has landed in a stable release (bookworm). Do we really want to revert it again and make all users of --numeric have to update again? Regards, Michael -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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
Bug#1072517: /etc/apparmor.d/cockpit-desktop in Zeile 1: Could not open 'abi/4.0'
Package: cockpit-ws Version: 317-1 Severity: serious File: /etc/apparmor.d/cockpit-desktop During todays boot I encountered the following failure: × apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Mon 2024-06-03 14:35:42 CEST; 1min 55s ago Invocation: 05781cbd4c8c4e7e96203d87010c5716 Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ Process: 1014 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=1/FAILURE) Main PID: 1014 (code=exited, status=1/FAILURE) Jun 03 14:35:42 mars apparmor.systemd[1014]: Restarting AppArmor Jun 03 14:35:42 mars apparmor.systemd[1014]: Reloading AppArmor profiles Jun 03 14:35:42 mars apparmor.systemd[1026]: AppArmor-Analysefehler f?r /etc/apparmor.d in profile /etc/apparmor.d/cockpit-desktop in Zeile 1: Could not open 'abi/4.0': Datei oder Verzeichnis nicht gefunden Jun 03 14:35:42 mars apparmor.systemd[1040]: Skipping profile in /etc/apparmor.d/disable: usr.bin.thunderbird Jun 03 14:35:42 mars apparmor.systemd[1065]: AppArmor-Analysefehler f?r /etc/apparmor.d/cockpit-desktop in profile /etc/apparmor.d/cockpit-desktop in Zeile 1: Could not open 'abi/4.0': Datei oder Verzeichnis nicht gefunden Jun 03 14:35:42 mars apparmor.systemd[1134]: Skipping profile in /etc/apparmor.d/disable: usr.bin.thunderbird Jun 03 14:35:42 mars apparmor.systemd[1014]: Error: At least one profile failed to load Jun 03 14:35:42 mars systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE Jun 03 14:35:42 mars systemd[1]: apparmor.service: Failed with result 'exit-code'. Jun 03 14:35:42 mars systemd[1]: Failed to start apparmor.service - Load AppArmor profiles. I suppose, the cockpit-desktop AA profile uses features that are not available on Debian: # apt-cache policy apparmor apparmor: Installed: 3.0.13-2 Candidate: 3.0.13-2 Version table: *** 3.0.13-2 500 500 http://deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 cockpit-ws depends on: ii adduser 3.137 ii glib-networking 2.80.0-1 ii libc6 2.38-12 ii libcrypt1 1:4.4.36-4 ii libglib2.0-0t64 2.80.2-2 ii libgnutls30t64 3.8.5-4 ii libgssapi-krb5-21.20.1-6+b1 ii libjson-glib-1.0-0 1.8.0-2+b1 ii libpam0g1.5.3-7 ii libsystemd0 256~rc3-7 ii openssl 3.2.1-3 ii systemd 256~rc3-7 cockpit-ws recommends no packages. Versions of packages cockpit-ws suggests: ii python33.11.8-1 pn sssd-dbus -- no debconf information
Bug#1069789: test_bluetooth_hidpp_mouse autopkgtest fails
Control: severity -1 important Seems to pass pretty reliably on debci, thus downgrading to important. https://ci.debian.net/packages/u/upower/ Regards, Michael On Wed, 24 Apr 2024 23:34:48 +0500 Andrey Rakhmatullin wrote: Package: upower Version: 1.90.3-1 Severity: serious Control: forwarded -1 https://gitlab.freedesktop.org/upower/upower/-/issues/228 Control: tags -1 + upstream https://ci.debian.net/packages/u/upower/unstable/amd64/45053064/ 217s == 217s ERROR: test_bluetooth_hidpp_mouse (__main__.Tests.test_bluetooth_hidpp_mouse) 217s Logitech Bluetooth LE mouse with HID++ kernel support 217s -- 217s Traceback (most recent call last): 217s File "/usr/libexec/upower/integration-test.py", line 2337, in test_bluetooth_hidpp_mouse 217s self.assertEqual(self.get_dbus_dev_property(bat0_up, 'Model'), alias) 217s 217s File "/usr/libexec/upower/integration-test.py", line 273, in get_dbus_dev_property 217s return self.dbus.call_sync(UP, device, 217s^^^ 217s gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/UPower/devices/mouse_dev_11_22_33_44_AA_BB” (19) -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 upower depends on: ii dbus 1.14.10-4+b1 ii libc6 2.37-18 ii libglib2.0-0t642.78.4-7 ii libgudev-1.0-0 238-5 ii libimobiledevice6 1.3.0-7.1+b1 ii libplist3 2.2.0-7+b1 ii libupower-glib31.90.3-1 ii udev 255.4-1+b1 Versions of packages upower recommends: ii polkitd 124-2 upower suggests no packages. -- debconf-show failed OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070019: [Pkg-utopia-maintainers] Bug#1070019: Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev
Am 29.04.24 um 14:03 schrieb Michael Biebl:
It appears that this is a regression introduced in util-linux 2.40-7.
The udisks2 test suite passes with 2.40-6.
So I assume it's one of the upstream changes from
"""
* Import upstream stable/v2.40 up to
a8aa0b5f154a44557f5bae5a4027bdbfe42b0323
* lsns: fix netns use
* libmount: fix comment typo for mnt_fs_get_comment()
* libmount: Fix access check for utab in context
* lsblk: simplify SOURCES code
* findmnt: always zero-terminate SOURCES data
* agetty: Don't override TERM passed by the user
* libsmartcols: reset wrap after calculation
* lslocks: remove a unused local variable
* lslocks: don't abort gathering per-process information even if
opening a /proc/[0-9]* fails
* lsns: tolerate lsns_ioctl(fd, NS_GET_{PARENT,USERNS}) failing
with ENOSYS
* lsns: report with warnx if a namespace related ioctl fails with
ENOSYS
* Fix misplaced else in mnt_update_already_done
* findmnt: revise the code for -I and -D option (Closes: #1069634)
* libblkid: topology/ioctl: simplify ioctl handling
* libblkid: topology/ioctl: correctly handle kernel types
* pam_lastlog2: link against liblastlog
* libblkid: Fix segfault when blkid.conf doesn't exist (Closes:
#1069634)
"""
that broke udisks2.
Please disregard what I wrote above. I made a mistake when testing with
a trixie qemu VM and the util-linux packages weren't actually upgraded
but stayed on 2.39
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1070019: [Pkg-utopia-maintainers] Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev
Am 28.04.24 um 18:20 schrieb Chris Hofstaedtler:
Source: udisks2
Version: 2.10.1-6
Severity: serious
Hi,
udisks2's autopkgtest fails when tried together with util-linux 2.40. An
example can be seen here:
https://ci.debian.net/packages/u/udisks2/testing/amd64/46012968/
537s ==
537s FAIL: test_ext4 (__main__.FS.test_ext4)
537s fs: ext4
537s --
537s Traceback (most recent call last):
537s File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test",
line 1107, in _do_udisks_check
537s cd_fs.call_mount_sync(ro_options, None)
537s gi.repository.GLib.GError: udisks-error-quark:
GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 at
/media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call failed:
/dev/sr1: Can't open blockdev (0)
537s
537s During handling of the above exception, another exception occurred:
537s
537s Traceback (most recent call last):
537s File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test",
line 725, in test_ext4
537s self._do_fs_check('ext4')
537s File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test",
line 894, in _do_fs_check
537s self._do_udisks_check(fs_type)
537s File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test",
line 1112, in _do_udisks_check
537s self.fail('Mounting read-only device with \'rw\' option failed'
537s AssertionError: Mounting read-only device with 'rw' option failedwith an
unexpected error.
537s Got: udisks-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.Failed:
Error mounting /dev/sr1 at /media/root/41b1acb1-744c-422a-9071-2dba5368a683:
fsconfig system call failed: /dev/sr1: Can't open blockdev (0)
537s Expected: 'is write-protected but explicit read-write mode requested' or
'is write-protected but `rw' option given'
I do not understand what this error means, or what the underlying problem is.
Please investigate.
It appears that this is a regression introduced in util-linux 2.40-7.
The udisks2 test suite passes with 2.40-6.
So I assume it's one of the upstream changes from
"""
* Import upstream stable/v2.40 up to
a8aa0b5f154a44557f5bae5a4027bdbfe42b0323
* lsns: fix netns use
* libmount: fix comment typo for mnt_fs_get_comment()
* libmount: Fix access check for utab in context
* lsblk: simplify SOURCES code
* findmnt: always zero-terminate SOURCES data
* agetty: Don't override TERM passed by the user
* libsmartcols: reset wrap after calculation
* lslocks: remove a unused local variable
* lslocks: don't abort gathering per-process information even if
opening a /proc/[0-9]* fails
* lsns: tolerate lsns_ioctl(fd, NS_GET_{PARENT,USERNS}) failing
with ENOSYS
* lsns: report with warnx if a namespace related ioctl fails with
ENOSYS
* Fix misplaced else in mnt_update_already_done
* findmnt: revise the code for -I and -D option (Closes: #1069634)
* libblkid: topology/ioctl: simplify ioctl handling
* libblkid: topology/ioctl: correctly handle kernel types
* pam_lastlog2: link against liblastlog
* libblkid: Fix segfault when blkid.conf doesn't exist (Closes:
#1069634)
"""
that broke udisks2.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1068936: marked as pending in libcanberra
Control: tag -1 pending Hello, Bug #1068936 in libcanberra 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/gnome-team/libcanberra/-/commit/eaae0b24b9aaa36345235f31f2f0912e93fe36d6 Drop hard-coded dependency on libgtk-3-0 (>= 3.2.2-3) Closes: #1068936 (this message was generated automatically) -- Greetings https://bugs.debian.org/1068936
Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies
Please see the related MR https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/75 By dropping the hand-written maintscript code, we should mitigate this problem, as the problematic code would not be run on upgrades. In addition, the generated maintscript code used "|| true", so would ignore the systemctl/deb-systemd-invoke failure. Unless of course restart-after-upgrade is not actually what you want for mariadb-server. In this case though, the hand-written code should be removed nonetheless but we would need to adjust the dh_installsystemd call in debian/rules to use the old stop-before-upgrade/start-after-upgrade behaviour. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066531: policykit-1: FTBFS: ../subprojects/mocklibc-1.0/src/netgroup-debug.c:25:3: error: implicit declaration of function ‘print_indent’ [-Werror=implicit-function-declaration]
Am 15.03.24 um 19:55 schrieb Michael Biebl: Control: tags -1 - patch On Wed, 13 Mar 2024 13:01:49 + Mark Hindley wrote: Control: tags -1 patch I also bumped into this whilst rebuilding src:policykit-1 yesterday. There is an upstream patch[1], but it doesn't fix the build for me; I think it is patching the wrong files.The problem appears to be multiple copies of mocklibc. AFAICS ./test/mocklibc is not used in favour of a meson subproject. The pkla-compat tarball also has mocklibc, but that is also patched already. We should drop pkla-compat in trixie. But that is a separate issue. Getting the multiple layers of quilt and meson patches to work was unpleasant. So the attached patch may save you some time. HTH Mark [1] https://github.com/polkit-org/polkit/commit/0d78d1e4bf5ab3ce11678005b220aac0cfc5bee5 Thanks for the patch Unfortunately it fails to apply to the src:policykit-1 package as shipped in Debian sid. Thus marking the bug report accordingly. Thanks for hint regarding diff_files for wrapped Meson projects. I've submitted this upstream as https://github.com/polkit-org/polkit/pull/436 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066531: policykit-1: FTBFS: ../subprojects/mocklibc-1.0/src/netgroup-debug.c:25:3: error: implicit declaration of function ‘print_indent’ [-Werror=implicit-function-declaration]
Control: tags -1 - patch On Wed, 13 Mar 2024 13:01:49 + Mark Hindley wrote: Control: tags -1 patch I also bumped into this whilst rebuilding src:policykit-1 yesterday. There is an upstream patch[1], but it doesn't fix the build for me; I think it is patching the wrong files.The problem appears to be multiple copies of mocklibc. AFAICS ./test/mocklibc is not used in favour of a meson subproject. The pkla-compat tarball also has mocklibc, but that is also patched already. Getting the multiple layers of quilt and meson patches to work was unpleasant. So the attached patch may save you some time. HTH Mark [1] https://github.com/polkit-org/polkit/commit/0d78d1e4bf5ab3ce11678005b220aac0cfc5bee5 Thanks for the patch Unfortunately it fails to apply to the src:policykit-1 package as shipped in Debian sid. Thus marking the bug report accordingly. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065485: file conflict with qemu-system-common / failure during upgrade
Package: qemu-system-data Version: 1:8.2.1+ds-2 Severity: serious During the lastest upgrade, I get Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... dpkg: error processing archive /var/cache/apt/archives/qemu-system-data_1%3a8.2.2+ds-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html', which is also in package qemu-system-common 1:8.2.1+ds-2 Errors were encountered while processing: /var/cache/apt/archives/qemu-system-data_1%3a8.2.2+ds-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
Bug#1064981: Breaks autopkgtest suite of systemd and multipath-tools
Control: severity -1 important Hi On Wed, 28 Feb 2024 18:49:00 +0100 Michael Biebl wrote: Source: lvm2 Version: 2.03.22-1 Severity: serious Hi, filing this issue with severity RC to prevent testing migration. It appears the new LVM release breaks both systemd and multipath-tools's autopkgtest suite https://ci.debian.net/packages/m/multipath-tools/testing/amd64/43382441/ https://github.com/systemd/systemd/issues/31517 After further investigation, the failure in multipath-tools turned out to be a result of https://salsa.debian.org/linux-blocks-team/multipath-tools/-/blob/master/debian/patches/0002-11-dm-mpath-fix-DM_UDEV_RULES_VSN-check.patch?ref_type=heads So far this patch had been necessary, since lvm2 itself had modified the udev rules downstream, but no longer does that thankfully with the latest update. See the remarks in https://github.com/systemd/systemd/issues/31517#issuecomment-1971788035 Chris updated multipath-tools accordingly: https://salsa.debian.org/linux-blocks-team/multipath-tools/-/commit/902a13b2c628d2cfde74cb78fd1ba4425af3d7d4 and uploaded it as 0.9.7-6. With that, multipath-tools and systemd's autopkgtest are unbroken again. I'm still keeping the bug report open, as you might consider adding a versioned breaks against multipath-tools to dmsetup. Downgrading to non-RC now though. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064981: Breaks autopkgtest suite of systemd and multipath-tools
Source: lvm2 Version: 2.03.22-1 Severity: serious Hi, filing this issue with severity RC to prevent testing migration. It appears the new LVM release breaks both systemd and multipath-tools's autopkgtest suite https://ci.debian.net/packages/m/multipath-tools/testing/amd64/43382441/ https://github.com/systemd/systemd/issues/31517
Bug#1063053: [Pkg-utopia-maintainers] Bug#1063053: Bug#1063053: volume-key: NMU diff for 64-bit time_t transition
Am 05.02.24 um 11:29 schrieb Michael Biebl: Am 04.02.24 um 19:31 schrieb Steve Langasek: Source: volume-key Version: 0.3.12-5 Severity: serious Tags: patch pending sid trixie Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t NOTICE: these changes must not be uploaded to unstable yet! Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified volume-key as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to have a library transition, which is most easily done by renaming the runtime library package. Since turning on 64-bit time_t is being handled centrally through a change to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for volume-key which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. This also looks like a false positive. volume-key uses time_t internally at https://salsa.debian.org/utopia-team/volume-key/-/blob/debian/sid/lib/kmip.c?ref_type=heads#L2132-2154 This is not exposed in the ABI though or am I misunderstanding the changes introduced by the time-t transition ? Please put a hold on the upload until this has been investigated properly. Thanks. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062484: [Pkg-utopia-maintainers] Bug#1062484: Bug#1062484: libnma: NMU diff for 64-bit time_t transition
Am 02.02.24 um 08:45 schrieb Steve Langasek: Hi Michael, On Thu, Feb 01, 2024 at 06:34:13PM +0100, Michael Biebl wrote: Am 01.02.24 um 18:00 schrieb Steve Langasek: Source: libnma Version: 1.10.6-2 Severity: serious Tags: patch pending Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified libnma as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). I would like to avoid an unnecessary package rename. Can you point me to the place where time_t is exposed in the ABI? Well I have a post to debian-devel-announce today which would've provided more pointers to this sort of thing, but unfortunately lists.debian.org no longer appears to reliably let mail through from Debian Developers (despite having valid signatures with both dkim and PGP). libnma falls into the bucket of packages that we weren't able to analyze, so we assume out of an abundance of caution that it is ABI-breaking and should be renamed: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libnma-headers/base/log.txt If you feel strongly that the package should not be renamed, patches to https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads are very welcome to make it possible to compile the headers for analysis and confirm that the library's ABI is not affected by time_t. From the log it looks like this is a missing gtk include, which can easily be fixed either in the upstream source or by adding an appropriate quirk to the above script. We will happily rerun abi-compliance-checker to confirm the ABI status if this is fixed. Please put a hold on the upload until this has been investigated properly. Thanks. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063053: [Pkg-utopia-maintainers] Bug#1063053: volume-key: NMU diff for 64-bit time_t transition
Am 04.02.24 um 19:31 schrieb Steve Langasek: Source: volume-key Version: 0.3.12-5 Severity: serious Tags: patch pending sid trixie Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t NOTICE: these changes must not be uploaded to unstable yet! Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified volume-key as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to have a library transition, which is most easily done by renaming the runtime library package. Since turning on 64-bit time_t is being handled centrally through a change to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for volume-key which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. This also looks like a false positive. volume-key uses time_t internally at https://salsa.debian.org/utopia-team/volume-key/-/blob/debian/sid/lib/kmip.c?ref_type=heads#L2132-2154 This is not exposed in the ABI though or am I misunderstanding the changes introduced by the time-t transition ? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062484: [Pkg-utopia-maintainers] Bug#1062484: libnma: NMU diff for 64-bit time_t transition
Am 01.02.24 um 18:00 schrieb Steve Langasek: Source: libnma Version: 1.10.6-2 Severity: serious Tags: patch pending Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified libnma as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). I would like to avoid an unnecessary package rename. Can you point me to the place where time_t is exposed in the ABI? Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054783: marked as pending in libpwquality
Control: tag -1 pending Hello, Bug #1054783 in libpwquality 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/gnome-team/libpwquality/-/commit/9d2b7de5013c69263549e16b4be4606afd8098f4 Use DEB_PYTHON_INSTALL_LAYOUT="deb" to get the correct sysconfig scheme on Debian See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412 Closes: #1054783 Gbp-Dch: Short (this message was generated automatically) -- Greetings https://bugs.debian.org/1054783
Bug#1057220: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1057220 in systemd 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/systemd-team/systemd/-/commit/9c3ba47aed892cfd5cd8c1458a58687cf98d5ae5 Restore diverted symlinks in systemd-sysv.postinst that may have been lost due to /usr-merge Closes: #1057220 (this message was generated automatically) -- Greetings https://bugs.debian.org/1057220
Bug#1058937: /usr-move: Do we support upgrades without apt?
Am 21.12.23 um 11:50 schrieb Christoph Berg: Re: Helmut Grohne Is it ok to call upgrade scenarios failures that cannot be reproduced using apt unsupported until we no longer deal with aliasing? If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug) with no action calling the scenario unsupported. I think we should only deal with problems that can reasonably happen in practice. If an extra hammer is required to hit the problem, we should not spend extra effort on it. A (dist-)upgrade not using apt is very much a corner case/niche use case. I'd be interested if #1058937 can be reproduced using aptitude, though. While the release notes explicitly recommend using apt/apt-get, I do think that dist-upgrades using aptitude should not run into those file loss issues. If aptitude is safe, I'd consider #1058937 a bug, that is not release critical and I'd assign low(er) priority to it. Other issues, like getting all packages updated to move their files to /usr, have higher priority. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057799: systemd: fails to configure
Am 09.12.23 um 00:53 schrieb JP Pozzi: Hello, Here the result : grep users /etc/group /etc/gshadow /etc/group:users:x:100: /etc/gshadow:users:*::suricata You appear to have a mismatch between /etc/group and /etc/gshadow. Either your user "suricata" is listed in both or none. Not sure how you ended up in this situation, but this looks like a local misconfiguration. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057799: systemd: fails to configure
Am 08.12.23 um 18:48 schrieb Michael Biebl: On Fri, 08 Dec 2023 17:30:23 +0100 JPP wrote: Package: systemd Version: 252.19-1~deb12u1 Severity: serious Tags: d-i Justification: normal Dear Maintainer, I get a problem upgrading the system, systemd fails to configure : sudo dpkg --configure systemd Setting up systemd (252.19-1~deb12u1) ... Creating group 'users' with GID 100. /etc/gshadow: Group "users" already exists. Can you attach the output of sudo grep users /etc/group /etc/gshadow The output of sudo SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/basic.conf as well, please OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057799: systemd: fails to configure
On Fri, 08 Dec 2023 17:30:23 +0100 JPP wrote: Package: systemd Version: 252.19-1~deb12u1 Severity: serious Tags: d-i Justification: normal Dear Maintainer, I get a problem upgrading the system, systemd fails to configure : sudo dpkg --configure systemd Setting up systemd (252.19-1~deb12u1) ... Creating group 'users' with GID 100. /etc/gshadow: Group "users" already exists. Can you attach the output of sudo grep users /etc/group /etc/gshadow OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057035: Missing Breaks/Replaces / file conflict with ubuntu-cloud-keyring
Package: ubuntu-keyring Version: 2023.11.28.1-0.1 Severity: serious Preparing to unpack .../ubuntu-keyring_2023.11.28.1-0.1_all.deb ... Unpacking ubuntu-keyring (2023.11.28.1-0.1) over (2020.06.17.1-1) ... dpkg: error processing archive /var/cache/apt/archives/ubuntu-keyring_2023.11.28.1-0.1_all.deb (--unpack): trying to overwrite '/usr/share/keyrings/ubuntu-cloud-keyring.gpg', which is also in package ubuntu-cloud-keyring 2020.06.17.1-1 Errors were encountered while processing: /var/cache/apt/archives/ubuntu-keyring_2023.11.28.1-0.1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) It appears a file was moved without a proper Breaks/Replaces.
Bug#1056313: [Pkg-utopia-maintainers] Bug#1056313: network-manager: breaks networking
Control: severity -1 normal Control: block -1 1055067 Am 20.11.23 um 13:25 schrieb Vincent Lefevre: 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. Please work together with the isc-dhcp-client maintainers to get this AppArmor config updated. There is nothing that can be done in the network-manager package about this. 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? We could consider adding such a versioned Breaks, once a fixed version of isc-dhcp-client exists. Given that network-manager by default no longer uses dhclient, and unversioned Breaks is not warranted. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056108: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1056108 in systemd 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/systemd-team/systemd/-/commit/06facf0023b0b64be2d68c5c225190bcb8e203da Add versioned Breaks against dracut The introduction of systemd-executor in v255 breaks the initrd that is generated by dracut. Without systemd-executor, a systemd based initrd will fail to boot. The dracut package needs to be updated to include this new binary. Closes: #1056108 (this message was generated automatically) -- Greetings https://bugs.debian.org/1056108
Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor
Hi Thomas Am 17.11.23 um 10:12 schrieb Thomas Lange: I've already included the upstream patch to the git master branch of dracut on salsa. The next dracut release in Debian will include the fix. Great, thanks. I assume this version will be 059-5 ? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor
I've filed a corresponding bug report against systemd, so users are notified of this issue and the package doesn't migrate to testing prematurely: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056108 We will add a versioned Breaks against dracut to systemd to ensure that dracut users do not accidentally upgrade. Sorry for the breakage. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056108: v255 breaks boot with dracut
Package: systemd Version: 255~rc2-1 Severity: serious The addition of systemd-executor breaks dracut in a bad way. It generates an unbootable initrd. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056059 Filing with RC severity to notify users and to prevent testing migration. We should add a (versioned) Breaks against dracut to ensure that dracut users do not end up with an unbootable system. Michael
Bug#1054650: [Pkg-utopia-maintainers] Bug#1054650: dbus: makes the machine extremely slow, freezes on shutdown
Am 27.10.23 um 13:45 schrieb Vincent Lefevre: Package: dbus Version: 1.14.10-2 Severity: critical Justification: breaks the whole system dbus 1.14.10-2 makes the machine extremely slow (this affects the boot, login, the su command, and package installation at least), and it freezes on shutdown. This is reproducible (I've tested on 2 successive reboots). You are running an unmerged-usr system, which is no longer supported. Please ensure your system is properly usrmerged and your problems will go away. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053898: marked as pending in rsyslog
Control: tag -1 pending Hello, Bug #1053898 in rsyslog 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/debian/rsyslog/-/commit/e5ef6fb976924ca792379950a1a491a1f170c96b Update autopkgtest now that rsyslog.service is hardened (closes: #1053898) Previously, rsyslog was told to put its entries in /tmp/test-rsyslog-syslog.log which was then checked with logcheck. But rsyslog.service now runs with PrivateTmp=true which means test-rsyslog-syslog.log is not available after the service ends. (Additionally, improve diagnostic messages when no output was detected) (this message was generated automatically) -- Greetings https://bugs.debian.org/1053898
Bug#1053898: Hardening rsyslog.service breaks debian/tests/logcheck autopkgtest
Source: rsyslog Version: 8.2310.0-1 Severity: serious X-Debbugs-Cc: Richard Lewis The latest update of rsyslog enabled various systemd hardening and security features, specifically: CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_RESOURCE CAP_SYSLOG SystemCallFilter=@system-service NoNewPrivileges=yes PrivateTmp=yes PrivateDevices=yes ProtectHome=yes ProtectSystem=full ProtectKernelTunables=yes ProtectKernelModules=yes ProtectClock=yes ProtectControlGroups=yes ProtectHostname=yes It turns out that `PrivateTmp=yes` breaks the logcheck autopkgtest. @Richard: as author of that test, could you please that a look at this issue. It currently prevents rsyslog from migrating to testing. https://qa.debian.org/excuses.php?package=rsyslog Regards, Michael
Bug#1050436: upower: autopkgtest regression on i386: excessive precision?
Control: severity -1 important Am 01.09.23 um 00:37 schrieb Michael Biebl: On Thu, 24 Aug 2023 17:18:35 +0200 Paul Gevers wrote: Source: upower 1.90.2-4 Severity: serious Tags: sid trixie X-Debbugs-CC: b...@debian.org User: debian...@lists.debian.org Usertags: regression Control: affects -1 src:libgudev Dear maintainer(s), With a recent upload of upower, the autopkgtest of upower fails on i386 in testing when that autopkgtest is run with the binary packages of upower and libgudev from unstable. It passes when run with only packages from testing. In tabular form: pass fail libgudev from testing 238-2 upower from testing 1.90.2-4 all others from testing from testing I copied some of the output at the bottom of this report. Looking at the error this *seems* to me the result of the excessive precision of i386, but I hope the i386 porter (in XDCC) can shed his light on that too. Currently this regression is blocking the migration of libgudev to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libgudev https://ci.debian.net/data/autopkgtest/testing/i386/u/upower/37102682/log.gz 208s == 208s FAIL: test_battery_energy_charge_mixed (__main__.Tests.test_battery_energy_charge_mixed) 208s battery which reports both current charge and energy 208s -- 208s Traceback (most recent call last): 208s File "/usr/libexec/upower/integration-test.py", line 887, in test_battery_energy_charge_mixed 208s self.assertEqual(self.get_dbus_dev_property(bat0_up, 'Percentage'), 40.0) 208s AssertionError: 40.01 != 40.0 Adrian, as i386 porter, could you have a look at this? I've forwarded the issue to upstream but didn't receive any feedback. I also didn't receive any feedback from the i386 porters. Since I only have limited interest in i386 I've updated the package to ignore the autopkgtest failure on i386. I'd obviously would like to see this fixed probably and would appreciate any help from people interested in i386. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050256: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci
Control: severity -1 important Am 09.09.23 um 14:20 schrieb intrigeri: Hi again, Thank you all for working both on workarounds for Debian CI and on a proper upstream Linux kernel fix. Impressive cross-team work! :) +1 At this stage it seems clear that the bug and the corresponding ideal fix are in the AppArmor part of src:linux, and the bug affects at least src:apparmor and src:lxc. I'd like to reflect this in the metadata of #1050256 by reassigning the bug to Linux, and adding "affects" indications. I'll do so in the next few days unless someone objects soon. It also affects at least src:systemd, src:pdns, src:policykit-1 All those packages have added workarounds for this issue. I'll revert the workaround in systemd and notify the maintainers of pdns and policykit-1. Doing so will also be an opportunity for me to sum up the problem for the maintainers of src:linux, and let them know about our desired timeline: ideally this would be fixed in the upcoming Bookworm point-release. This being said, if said timeline can't be met in src:linux, it'll be up to the maintainers of LXC in Debian to decide what they want to do in the upcoming Bookworm point-release. If I misunderstood something important, please let me know. Sounds good to me. For now, given that all the debci hosts are running the backports kernel, I'm downgrading the severity again. When you do the reassignment, you should probably merge this bug report with #1038315 and #1042880, now that we know what the root cause is. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050256: autopkgtest fails on debci
Am 04.09.23 um 20:23 schrieb Mathias Gibbens: On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote: I took a quick look through v6.1..v6.3.1 there is a patch that I think is the likely fix, it first landed in v6.2 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets Thanks for the pointer John -- I think that is the fix we've been looking for! Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the other commits from the patchset of Oct 3, 2022 that modified a bunch of the apparmor code. Because I couldn't quickly cherry-pick all the changes without amassing a large diff, I made the small proof-of- concept patch at the end of this message and applied it to the 6.1.38- 4 kernel from bookworm. Booting with the patched kernel allows services to start up in containers without any issues. :) So, I think the next step should be to get that commit properly backported to the v6.1 longterm tree and included in an upstream release. Hopefully that would be able to happen in enough time so that it is bundled with the kernel updates for bookworm's point release next month. If not, we should be sure to get it into Debian's packaging so at least there's a proper fix available. Thanks for the update Mathias, this looks very promising. A stable update of the Linux 6.1.x kernel would obviously be the ideal solution. John, could you help with getting this fix into 6.1.x? Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050256: autopkgtest fails on debci
Am 03.09.23 um 10:50 schrieb Paul Gevers: Hi, On 03-09-2023 02:56, Michael Biebl wrote: ng? Do the debci maintainers / lxc maintainers / release team have any preference regarding a/, b/ and c/ ? One part of me likes the ci.d.n infrastructure to run stable as an example of "eat your own dogfood". Another part of me agrees with Antonio that it makes sense if it would run a backports kernel to be as close as possible to testing as we can reasonably (maintenance wise) can get. Because we have a known issue at hand, the balance goes to backports for me. If Antonio doesn't beat me to it, I'll get to it (although I don't know yet how to do that in our configuration [1] and exclude riscv64 too). I have manually upgraded the s390x host and rebooted, so that can serve as a test arch. Seems it worked, the latest run succeeded: https://ci.debian.net/data/autopkgtest/testing/s390x/s/systemd/37374052/log.gz Thanks! OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050436: upower: autopkgtest regression on i386: excessive precision?
On Thu, 24 Aug 2023 17:18:35 +0200 Paul Gevers wrote: Source: upower 1.90.2-4 Severity: serious Tags: sid trixie X-Debbugs-CC: b...@debian.org User: debian...@lists.debian.org Usertags: regression Control: affects -1 src:libgudev Dear maintainer(s), With a recent upload of upower, the autopkgtest of upower fails on i386 in testing when that autopkgtest is run with the binary packages of upower and libgudev from unstable. It passes when run with only packages from testing. In tabular form: passfail libgudev from testing238-2 upower from testing1.90.2-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Looking at the error this *seems* to me the result of the excessive precision of i386, but I hope the i386 porter (in XDCC) can shed his light on that too. Currently this regression is blocking the migration of libgudev to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libgudev https://ci.debian.net/data/autopkgtest/testing/i386/u/upower/37102682/log.gz 208s == 208s FAIL: test_battery_energy_charge_mixed (__main__.Tests.test_battery_energy_charge_mixed) 208s battery which reports both current charge and energy 208s -- 208s Traceback (most recent call last): 208s File "/usr/libexec/upower/integration-test.py", line 887, in test_battery_energy_charge_mixed 208s self.assertEqual(self.get_dbus_dev_property(bat0_up, 'Percentage'), 40.0) 208s AssertionError: 40.01 != 40.0 Adrian, as i386 porter, could you have a look at this? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050606: Acknowledgement (find: ‘/lib/systemd/system-sleep’: No such file or directory)
Control: tags -1 + patch
Please find attached a patch which should be sufficient to address this
issue. I can offer to NMU, in case you are busy.
Regards,
Michael
diff --git a/debian/scripts/suspend/cryptsetup-suspend-wrapper b/debian/scripts/suspend/cryptsetup-suspend-wrapper
index 52e09dd1..953196c0 100644
--- a/debian/scripts/suspend/cryptsetup-suspend-wrapper
+++ b/debian/scripts/suspend/cryptsetup-suspend-wrapper
@@ -46,6 +46,7 @@ read_config() {
# Run all executable scripts in directory SYSTEM_SLEEP_PATH with arguments ARGS
# mimic systemd behavior
run_dir() {
+[ -d "$SYSTEM_SLEEP_PATH" ] || return 0
find "$SYSTEM_SLEEP_PATH" -type f -executable -execdir {} "$@" \;
}
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1050606: find: ‘/lib/systemd/system-sleep’: No such file or directory
Package: cryptsetup-suspend Version: 2:2.6.1-4 Severity: serious The cryptsetup-suspend wrapper makes unconditional use of the /lib/systemd/system-sleep directory. This directory was removed from the systemd package as a result of the discussion in https://salsa.debian.org/systemd-team/systemd/-/merge_requests/208 The failing autopkgtest of cryptsetup is now blocking the testing migration of the systemd package (thus the RC severity). Please update cryptsetup-suspend-wrapper to handle the case where the directory /lib/systemd/system-sleep is missing. Regards, Michael
Bug#1040924: clevis-udisks2: Depends on NBS libblockdev-crypto2
Am 17.07.23 um 13:07 schrieb Michael Biebl:
So, instead of changing the dependency from libblockdev-crypto2 to
libblockdev-crypto3, you might consider dropping the dependency
altogether, as clevis-udisks2 already depends on udisks2 and
clevis-crypto2 doesn't actually use libblockdev-crypto directly.
If (bookworm-) backports are a concern, you might also use something
like this
diff --git a/debian/control b/debian/control
index c33360c..e542b2a 100644
--- a/debian/control
+++ b/debian/control
@@ -107,7 +107,7 @@ Architecture: linux-any
Depends: ${misc:Depends}, ${shlibs:Depends},
adduser,
clevis-luks (= ${binary:Version}),
-libblockdev-crypto2,
+udisks2 (>= 2.10) | libblockdev-crypto2,
udisks2,
Description: UDisks2/Storaged integration for clevis
Clevis is a plugable framework for automated decryption. This package
This is what cockpit-storaged has done.
Regards,
Michael
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1040924: clevis-udisks2: Depends on NBS libblockdev-crypto2
On Thu, 13 Jul 2023 07:59:45 +0200 Christoph Biedl wrote: Control: Tags 1040924 +pending Jeremy Bícha wrote... > Yes, it's a transition. Sorry that it didn't follow the recommended procedure. Thanks for the clarification. New version is underway, I'd like to do some thourough testing, though. libblockdev plugins did have a soname bump (2→3), and I indeed missed clevis (sorry for that), otherwise I would have filed a bug report in advance. Just a side-note: Due to the way udisks 2.10 treats missing libraries, libblockdev-crypto3 is now a hard dependency of udisks2. See [1] for further information. So, instead of changing the dependency from libblockdev-crypto2 to libblockdev-crypto3, you might consider dropping the dependency altogether, as clevis-udisks2 already depends on udisks2 and clevis-crypto2 doesn't actually use libblockdev-crypto directly. Michael [1] https://github.com/storaged-project/udisks/issues/1142 OpenPGP_signature Description: OpenPGP digital signature
Bug#1040988: Clashes with existing composite manager
Package: picom Version: 10.2-1 Severity: serious picom adds an autostart file which makes it automatically start on session login. Today I noticed that journald/rsyslog ran while and my logs were flodded with the following messages (I was logged into a GNOME session at that time): Jul 13 19:18:11 pluto picom.desktop[2236]: [ 13.07.2023 19:18:11.510 redirect_start FATAL ERROR ] Another composite manager is already running (and does not handle _NET_WM_CM_Sn correctly) Jul 13 19:18:11 pluto picom.desktop[2236]: [ 13.07.2023 19:18:11.510 redirect_start FATAL ERROR ] Another composite manager is already running (and does not handle _NET_WM_CM_Sn correctly) Jul 13 19:18:11 pluto picom.desktop[2236]: [ 13.07.2023 19:18:11.510 redirect_start FATAL ERROR ] Another composite manager is already running (and does not handle _NET_WM_CM_Sn correctly) Within minutes, my disk was filled with hundreds of megabytes of log data (/var/log/syslog was over 1GB), before I killed the rogue picom process. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 picom depends on: ii libc62.37-5 ii libconfig9 1.5-0.4 ii libdbus-1-3 1.14.8-2 ii libegl1 1.6.0-1 pn libev4 ii libgl1 1.6.0-1 ii libpcre3 2:8.39-15 ii libpixman-1-00.42.2-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-composite01.15-1 ii libxcb-damage0 1.15-1 ii libxcb-glx0 1.15-1 ii libxcb-image00.4.0-2 ii libxcb-present0 1.15-1 ii libxcb-randr01.15-1 ii libxcb-render-util0 0.3.9-1+b1 ii libxcb-render0 1.15-1 ii libxcb-shape01.15-1 ii libxcb-sync1 1.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb-xinerama0 1.15-1 ii libxcb1 1.15-1 ii python3 3.11.4-5 picom recommends no packages. picom suggests no packages.
Bug#1039858: Missing dependencies on json-c >= 0.13, openssl >= 1.1.0, libkeyutils
Package: libnvme-dev Version: 1.4-3 Severity: serious The libnvme.pc declares the following dependencies: Requires.private: json-c >= 0.13, openssl >= 1.1.0, libkeyutils Those need to be added to the Depends of libnvme-dev, otherwise pkgconfig will fail to e.g. resolve cflags. # pkgconf --cflags libnvme Package json-c was not found in the pkg-config search path. Perhaps you should add the directory containing `json-c.pc' to the PKG_CONFIG_PATH environment variable Package 'json-c', required by 'libnvme', not found Package 'openssl', required by 'libnvme', not found Package 'libkeyutils', required by 'libnvme', not found
Bug#1038762: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1038762 in systemd 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/systemd-team/systemd/-/commit/23aa01874155dffb67ca69e576eb82f7ebc8ef46 Stop localed from writing to /etc/default/keyboard and symlink it to /etc/vconsole.conf Integration is not set up for now, but GDM needs to query the configured values. Allow reading, but disallow setting keymaps. Closes: #1038762 (this message was generated automatically) -- Greetings https://bugs.debian.org/1038762
Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout
Am 21.06.23 um 03:02 schrieb Michael Biebl: Am 21.06.23 um 02:34 schrieb Lyndon Brown: The latest package update (to unstable) has broken login keyboard- layout support. I'm marking this as critical due to the chaotic potential for locking many users out of their accounts / systems, some of whom unlike myself may have no clue what's wrong and how to get around it, if they can. Afaics, this only affects gdm, which directly queries localed, which no longer reports the keymap state: $ localectl System Locale: LANG=C.UTF-8 VC Keymap: (unset) X11 Layout: (unset) This is a result of https://salsa.debian.org/systemd-team/systemd/-/commit/8d0405b0cfb9c84791da5b8f7288453e23624acf Hm, actually, it seems to be the result of dropping debian/patches/debian/Use-Debian-specific-config-files.patch See the discussion in https://salsa.debian.org/systemd-team/systemd/-/merge_requests/189 As a quick/temporary workaround, you can run ln -s /etc/default/keyboard /etc/vconsole.conf OpenPGP_signature Description: OpenPGP digital signature
Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout
Am 21.06.23 um 02:34 schrieb Lyndon Brown: The latest package update (to unstable) has broken login keyboard- layout support. I'm marking this as critical due to the chaotic potential for locking many users out of their accounts / systems, some of whom unlike myself may have no clue what's wrong and how to get around it, if they can. Afaics, this only affects gdm, which directly queries localed, which no longer reports the keymap state: $ localectl System Locale: LANG=C.UTF-8 VC Keymap: (unset) X11 Layout: (unset) This is a result of https://salsa.debian.org/systemd-team/systemd/-/commit/8d0405b0cfb9c84791da5b8f7288453e23624acf See the discussion in https://salsa.debian.org/systemd-team/systemd/-/merge_requests/189 OpenPGP_signature Description: OpenPGP digital signature
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
[trimmed the list of CCs] Am 30.05.23 um 13:36 schrieb Jochen Sprickerhof: # find / -name e2scrub_reap.service /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/e2scrub_reap.service /var/lib/systemd/deb-systemd-helper-enabled/default.target.wants/e2scrub_reap.service /usr/lib/systemd/system/e2scrub_reap.service /etc/systemd/system/default.target.wants/e2scrub_reap.service [...] Interesting. Will check. OpenPGP_signature Description: OpenPGP digital signature
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
The title of this bug report is highly misleading. Let's see what's actually happening here: bullseye chroot: # find /etc/systemd/system/ -name e2scrub_reap.service /etc/systemd/system/default.target.wants/e2scrub_reap.service bookworm chroot: # find /etc/systemd/system/ -name e2scrub_reap.service /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service bullseye chroot upgraded to bookworm: # find /etc/systemd/system/ -name e2scrub_reap.service /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service /etc/systemd/system/default.target.wants/e2scrub_reap.service So, you have the service enabled both in default.target and multi-user.target. Does this pose any actual problem? Not really. It is properly started during boot and if you purge the package, both symlinks are removed. It is thus imho not a serious issue, but something you might want to fix at it is a bit confusing. That said, I find the piuparts output not very readable, so there might be another issue I don't see. In this case, Andreas needs to clarify the RC status of this bug. So what I would suggest is a if dpkg --compare-versions "$2" lt "$ver of your next upload"; then rm -f /etc/systemd/system/default.target.wants/e2scrub_reap.service fi in your postinst to clean up the stray enablement symlink. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Control: reassign -1 e2fsprogs Am 14.05.23 um 11:30 schrieb Andreas Beckmann: On 09/05/2023 17.48, Michael Biebl wrote: Andreas, you filed this with RC severity with the justification that systemd units are not enabled. I don't see that, so could you please clarify. What I could find out so far is the change of WantedBy target not being properly cleaned up on upgrades, but that doesn't strike me as RC (and would need to be done in e2fsprogs) Yes, looks like this is in the e2fsprogs realm. Please reassign it there together with instructions how to fix it, i.e. what should be done in the maintainer scripts. IMO the expected outcome from e2fsprogs perspective should be identical system configuration (w.r.t. enabled systemd units) after both fresh install and upgrade from bullseye, regardless of the installation status of systemd. If e2fsprogs doesn't care about this, it can downgrade the severity. Andreas OpenPGP_signature Description: OpenPGP digital signature
Bug#1035543: init-system-helpers: bla bla
On Fri, 5 May 2023 13:38:52 +0200 Michael Biebl wrote: Am 05.05.23 um 11:14 schrieb Luca Boccassi: > On Fri, 05 May 2023 11:04:29 +0200 Andreas Beckmann >> This is a new systemd unit in package e2fsprogs. It's not, both bullseye and bookworm ship this file in e2fsprogs. The difference is this bullseye: cat /lib/systemd/system/e2scrub_reap.service | tail -n 2 [Install] WantedBy=default.target bookworm # cat /lib/systemd/system/e2scrub_reap.service | tail -n 2 [Install] WantedBy=multi-user.target I.e. it changed the target from default.target to multi-user.target. i-s-h does not have support for removing obsolete enablement symlinks in such a case. Andreas, you filed this with RC severity with the justification that systemd units are not enabled. I don't see that, so could you please clarify. What I could find out so far is the change of WantedBy target not being properly cleaned up on upgrades, but that doesn't strike me as RC (and would need to be done in e2fsprogs) Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1035543: init-system-helpers: bla bla
Am 05.05.23 um 11:14 schrieb Luca Boccassi: On Fri, 05 May 2023 11:04:29 +0200 Andreas Beckmann This is a new systemd unit in package e2fsprogs. It's not, both bullseye and bookworm ship this file in e2fsprogs. The difference is this bullseye: cat /lib/systemd/system/e2scrub_reap.service | tail -n 2 [Install] WantedBy=default.target bookworm # cat /lib/systemd/system/e2scrub_reap.service | tail -n 2 [Install] WantedBy=multi-user.target I.e. it changed the target from default.target to multi-user.target. i-s-h does not have support for removing obsolete enablement symlinks in such a case. If this failure is actually e2fsprogs's fault by incorrectly using the helpers, please reassign the bug there (with instructions how to do it correctly). Isn't this a variation of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695 ? Doesn't look like it. OpenPGP_signature Description: OpenPGP digital signature
Bug#1031399: rsyslog: Log rotation broken on non-systemd systems
Control: severity -1 wishlist Control: retitle -1 document log rotation on non-default inits Am 16.02.23 um 15:41 schrieb Matthew Vernon: Package: rsyslog Version: 8.2212.0-1 Severity: serious Hi, When removing the systemv init scripts from rsyslog (which can be managed by orphan-sysvinit-scripts), the following was also removed from /usr/lib/rsyslog/rsyslog-rotate: else invoke-rc.d rsyslog rotate > /dev/null This means on non-systemd systems logrotate tries but fails to tell rsyslog to rotate its logs. Could you restore this, please? I don't plan to re-add this (btw, this would break if orphan-sysvinit-scripts is not installed). I'll add a note to README.Debian to the logrotate section though, what users of non-default inits need to consider. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Hi Otto Am 05.02.23 um 17:55 schrieb Otto Kekäläinen: This is now solved on https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/31 Mangling the maintainers scripts of another package is a delicate issue as it's often fragile and can cause hard to debug failures in corner cases. Personally, I would have turned the versioned packages into empty transitional packages. This would have made the upgrade process much smoother and avoided this issue altogether (the new empty versioned packages would have no maintainer scripts). It's also common practice for such use cases. Any reason why you didn't consider this approach? Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Am 30.01.23 um 07:59 schrieb Otto Kekäläinen: The only problem there is that on purge deb-systemd-helper and update-rc.d will disable the service, but that is not based on package ownership. The maintainer scripts will act on files which effectively no longer belong to this package. That's the issue, correct. OpenPGP_signature Description: OpenPGP digital signature
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Am 29.01.2023 um 04:12 schrieb Otto Kekäläinen: Hi! I managed now to reproduce this. The purge step is not relevant, but simply the upgrade itself. ... -> upgrade successful, but service stopped working - the service file has no executable bit anymore. That's only half of the bug report. The removal of the configuration state when purging the old, versioned packages is the second half (and the more important one) OpenPGP_signature Description: OpenPGP digital signature
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Am 21.01.23 um 21:28 schrieb Otto Kekäläinen: Hi! I have been frantically trying to reproduce the issue you reported. It's trivial to reproduce: Have the versioned mariadb packages installed (say from unstable), then make an apt full-upgrade, which will install the new unversioned ones and forces the the versioned ones to be deinstalled. After that is done, purge the old, versioned packages. OpenPGP_signature Description: OpenPGP digital signature
Bug#1029136: configuration files not properly migrated on switch to unversioned packages
Package: mariadb-server Version: 1:10.11.1-1 Severity: serious The latest update switch to unversioned packages. One issue I immediately noticed is that /etc/init.d/mariadb was installed 644, i.e. is not executable. Even, after purging the now obsolete -10.6 packages, I got this: Löschen der Konfigurationsdateien von mariadb-server-10.6 (1:10.6.11-2) ... Löschen der Konfigurationsdateien von mariadb-client-10.6 (1:10.6.11-2) ... [master 28eeae9] committing changes in /etc made by "aptitude" Author: Michael Biebl 12 files changed, 80 deletions(-) delete mode 100644 logcheck/ignore.d.paranoid/mariadb-server-10_6 delete mode 100644 logcheck/ignore.d.server/mariadb-server-10_6 delete mode 100644 logcheck/ignore.d.workstation/mariadb-server-10_6 delete mode 12 rc0.d/K01mariadb delete mode 12 rc1.d/K01mariadb delete mode 12 rc2.d/S01mariadb delete mode 12 rc3.d/S01mariadb delete mode 12 rc4.d/S01mariadb delete mode 12 rc5.d/S01mariadb delete mode 12 rc6.d/K01mariadb delete mode 12 systemd/system/multi-user.target.wants/mariadb.service This is not good. May advice would be to keep (emtpy) transitional packages mariadb-server-10.6/mariadb-client-10.6 and mariadb-server-10.5/mariadb-client-10.5 which itself depend on the unversioned mariadb package. This will not only make the upgrade smoother, it will also ensure that if you purge the empty transitional packages, you do not accidentally remove any import configuration state. Post bookworm you can then safely drop those empty transitional packages. Regards, Michael -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 mariadb-server depends on: ii adduser3.130 ii debconf [debconf-2.0] 1.5.82 ii galera-4 26.4.11-1+b2 ii gawk 1:5.1.0-1 ii iproute2 6.1.0-1 ii libc6 2.36-8 ii libdbi-perl1.643-4 ii libpam0g 1.5.2-6 ii libssl33.0.7-1 ii libstdc++6 12.2.0-14 ii lsb-base 11.5 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.1-1 ii mariadb-common 1:10.11.1-1 ii mariadb-server-core1:10.11.1-1 ii passwd 1:4.13+dfsg1-1 ii perl 5.36.0-7 ii procps 2:4.0.2-3 ii psmisc 23.6-1 ii rsync 3.2.7-1 ii socat 1.7.4.4-2 ii sysvinit-utils [lsb-base] 3.06-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii pv 1.6.20-1 Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 pn mariadb-test ii netcat-openbsd 1.219-1 -- Configuration Files: /etc/logcheck/ignore.d.paranoid/mariadb-server [Errno 13] Keine Berechtigung: '/etc/logcheck/ignore.d.paranoid/mariadb-server' /etc/logcheck/ignore.d.server/mariadb-server [Errno 13] Keine Berechtigung: '/etc/logcheck/ignore.d.server/mariadb-server' -- debconf information excluded
Bug#1028416: systemctl kexec doesn't shutdown system properly and corrupts mounted filesystems
Control: reassign -1 kexec-tools Am 10.01.23 um 20:34 schrieb KOLANICH: Package: systemd Version: 252.4-1 Severity: grave So do kexec-tools if a user has chosen to use it for reboots during package configuration. Either of the following can cause fs corruption (to the point one has to use `fsck -y`): a) the procedure described in https://wiki.archlinux.org/title/Kexec#Manually 1. `kexec -l /boot/vmlinuz-6.0.0-6-amd64 --initrd=/boot/initrd-6.0.0-6-amd64 --reuse-cmdline` 2. `systemctl kexec` b) Just choosing to use kexec for reboots when installing it, and then rebooting. Since systemd basically just calls kexec [1] and running kexec directly shows the same issue, let's reassign this to kexec-tools Michael [1] https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c#L584 OpenPGP_signature Description: OpenPGP digital signature
Bug#1028471: FTBFS: error: variable length array declaration not allowed at file scope
Source: cmucl Version: 21d-1.1 Severity: serious Tags: ftbfs Trying to build cmucl (on i386) fails with the following error: FORTIFY_SOURCE=2 -c -o interrupt.o ../../src/lisp/interrupt.c ../../src/lisp/interrupt.c:408:6: error: variable length array declaration not allowed at file scope char altstack[SIGNAL_STACK_SIZE]; ^~ 1 error generated. gmake[2]: *** [: interrupt.o] Error 1 gmake[2]: Leaving directory '/build/cmucl-21d/linux-2/lisp' Failed: /usr/bin/gmake -C linux-2/lisp make[1]: *** [debian/Makefile:16: all] Error 1 make[1]: Leaving directory '/build/cmucl-21d' make: *** [debian/rules:47: build-arch-stamp] Error 2 This build failure can also be seen on debci: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/cmucl.html
Bug#1027166: rc.local should NOT depend on network-online or anything else
Control: severity -1 wishlist Control: tags -1 + wontfix Hello Am 28.12.22 um 19:55 schrieb Michael Tokarev: Package: systemd Version: 252.2-2~bpo11+1 Severity: serious I just come across a situation where my notebook does not let me in while I'm in a place where network is not available. This is entirely wrong. After a painful debugging session, I found the debian-shipped file /lib/systemd/system/rc-local.service.d/debian.conf , which adds dependency of rc.local for network-online. Found the commit which introduced this: commit 4a26840495a297e50283a1f8def090540d15042d Author: Martin Pitt Date: Mon Jun 1 15:56:45 2015 +0200 Make rc-local.service wait for network-online.target (if it gets started) Add debian/extra/units/rc-local.service.d/wait-online.conf. This not specified by LSB, but has been behaving that way in Debian under SysV init and upstart. LP: #1451797 and found the original bugreport from 2015, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451797 (and a new one filed in 2021, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950906 ). On all systems, rc.local is empty by default (or doesn't exist), so it does not depend on anything at all. Only the user who modifies this file *locally* knows which dependencies are required, and this user can add their own /etc/systemd/system/rc-local.d/whatever.conf with the right deps, if needed. Adding *any* dependencies by default is entirely, utterly wrong. This way, you force completely innocent, unsuspecting people who used to put some quick thing into their rc.local to suffer from being unable to login. There are a couple of misconceptions in this bug report. I'll try to address them individually - rc.local does *not* add a dependency on network-online.target (which would be a Wants or Requires), but merely adds an ordering (After=) against network-online.target. network-online.target is an active unit, i.e. it needs to be pulled in explicitly. If the target was active for you, then some other unit other then rc-local.service requested its start The choice of not adding a "Wants=network-online.target" to rc-local.service is deliberate. We do not want to pull it in by ourselves. - "does not let me in" I assume you mean that you are not able to log in (on the console). This is incorrect. What network-online.target does (or to be specific the services that hook into network-online.target) is to delay the start of this target until network is available. So at most, you should experience a delay until you can log in. E.g. in case of NetworkManager-wait-online.service it is 60s. If you have a service that hooks into network-online.target that blocks indefinitely, then this is a bug in this service. It should have a timeout. - The After=network-online.target ordering in rc-local.service was done, as users in the past often added stuff like "mount some network resource) or did other stuff that required network access. By changing the behaviour of rc-local.service we would breaks all those exising rc-local scripts out in the wild. So we are not going to change its behaviour when it has been this way for over decades. So marking the bug as wishlist (change of behaviour) + wontfix. If you don't like the rc.local behaviour, my recommendation would be to simply not use it. It's a hack anyway and it is super easy to write a custom service unit. Alternatively, you can disable /etc/rc.local hasn't been installed by default for a long time and hasn't been made executable for even longer. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1025908: marked as pending in systemd
Control: tag -1 pending Hello, Bug #1025908 in systemd 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/systemd-team/systemd/-/commit/ecc39a3106a6bf9ccbbc3b98c7b5d72074b68431 Skip flaky test_resolved_domain_restricted_dns in networkd-test.py This test is part of DnsmasqClientTest and does not work reliably under LXC/debci, so skip it for the time being. Closes: #1025908 (this message was generated automatically) -- Greetings https://bugs.debian.org/1025908
Bug#1024699: [Pkg-utopia-maintainers] Bug#1024699: volume-key: Testsuite error on local rebuild
Control: tags -1 + moreinfo unreproducible Control: severity -1 normal Am 23.11.22 um 13:18 schrieb Andreas Metzler: Source: volume-key Version: 0.3.12-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, volume-key FTBFS on current sid: FAIL: packet_roundtrips.sh Please provide instructions how this issue can be reproduced Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1024275: [Pkg-utopia-maintainers] Bug#1024275: network-manager-openvpn: can't connect to vpn after last update: can't set proper cipher.
Control: severity -1 normal
Control: notforwarded -1
Am 16.11.22 um 22:54 schrieb Daniel Serpell:
Package: network-manager-openvpn
Version: 1.10.2-1
Severity: normal
Dear maintainer,
After upgrading to 1.10.2-1, I can't connect to the VPN anymore.
This is the logs from NetworkManager:
nm-openvpn[]: [] Peer Connection Initiated with
[AF_INET]:
nm-openvpn[]: OPTIONS ERROR: failed to negotiate cipher with server. Add
the server's cipher ('AES-256-CBC') to --data-ciphers (currently 'AES-256-GCM')
if you want to connect to this server.
nm-openvpn[]: ERROR: Failed to apply push options
nm-openvpn[]: Failed to open tun/tap interface
nm-openvpn[]: SIGUSR1[soft,process-push-msg-failed] received, process
restarting
Trying to change the cipher to AES-256-CBC in network properties does not work,
it reverts back to AES-256-GCM.
I recreated the failing OpenVPN connection and I can't reproduce the
problem anymore.
I thus closed the upstream issue and dropped the forwarded meta data.
My recommendation, if you can still reproduce the issue, is to file the
issue upstream [1] yourself. It's likely that upstream has further question.
Regards,
Michael
[1] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1023124: libsystemd-shared-251.so: cannot open shared object file
Control: tags -1 + moreinfo Am 30.10.22 um 13:34 schrieb Salvo "LtWorf" Tomaselli: E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up systemd (252~rc3-2) ... systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-251.so: cannot open shared object file: No such file or directory .. merged-usr: no Please attach the output of whereis systemd-machine-id-setup OpenPGP_signature Description: OpenPGP digital signature
Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures
Source: cockpit Version: 276.1-1 Severity: serious cockpit seems to fail its test suite on the aforementioned architectures on armel: ~ (cockpit-bridge:13294): cockpit-bridge-WARNING **: 11:53:58.528: couldn't create runtime dir: /run/user/2952: Permission denied cockpit-bridge-Message: 11:53:58.577: incompatible: package requires a later version of cockpit: 999.5 > 277 cockpit-bridge-Message: 11:53:58.577: requires: package has an unknown requirement: unknown cockpit-bridge-Message: 11:53:58.582: couldn't get polkit authority: Error initializing authority: Could not connect: No such file or directory # cockpit-protocol-DEBUG: cockpit-bridge: reading input 1 # cockpit-protocol-DEBUG: cockpit-bridge: received a 358 byte payload # cockpit-ws-DEBUG: received init message # cockpit-protocol-DEBUG: cockpit-bridge: queued 67 byte payload # cockpit-protocol-DEBUG: cockpit-bridge: want more data # cockpit-protocol-DEBUG: cockpit-bridge: queued 302 byte payload # cockpit-protocol-DEBUG: cockpit-bridge: queued 35 byte payload # cockpit-protocol-DEBUG: cockpit-bridge: queued 34 byte payload # cockpit-protocol-DEBUG: cockpit-bridge: end of input # cockpit-protocol-DEBUG: cockpit-bridge: pipe closing when output queue empty # cockpit-protocol-DEBUG: cockpit-bridge: couldn't write: Broken pipe # cockpit-protocol-DEBUG: cockpit-bridge: closing pipe: terminated # cockpit-protocol-DEBUG: cockpit-bridge: killing child: 13294 Bail out! GLib-FATAL-WARNING: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes. (test-channelresponse:13227): GLib-WARNING **: 11:53:58.590: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes. ** cockpit-ws:ERROR:src/ws/test-channelresponse.c:526:test_resource_failure: Got unexpected message: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes. instead of cockpit-ws-Message: *: external channel failed: * Bail out! cockpit-ws:ERROR:src/ws/test-channelresponse.c:526:test_resource_failure: Got unexpected message: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes. instead of cockpit-ws-Message: *: external channel failed: * FAIL test-channelresponse (exit status: 134) on mips* the test suite is killed after 150min of inactivity This currently prevents testing migration, thus filing with RC severity.
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
On Mon, 17 Oct 2022 22:13:47 +0300 Michael Tokarev wrote: 16.10.2022 08:04, Adrian Bunk wrote: ... > With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: > https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A7.1%2Bdfsg-2%2Bb1=1665894634=0 > > The complete list is currently: > $ pkg-config --cflags virglrenderer > Package epoxy was not found in the pkg-config search path. > Perhaps you should add the directory containing `epoxy.pc' > to the PKG_CONFIG_PATH environment variable > Package 'epoxy', required by 'virglrenderer', not found > Package 'libdrm', required by 'virglrenderer', not found > Package 'gbm', required by 'virglrenderer', not found > Package 'vulkan', required by 'virglrenderer', not found > Package 'libva', required by 'virglrenderer', not found > Package 'libva-drm', required by 'virglrenderer', not found > $ > > In practice, most/all of the -dev build dependencies also have to become > dependencies of libvirglrenderer-dev. Actually this is an interesting question and a quite common issue. This package does not provide a static library. All the mentioned packages are listed in Requires.private pkgconfig tag: Version: 0.10.3 Requires.private: epoxy >= 1.5.4, libdrm >= 2.4.50, gbm >= 0.0.0, x11, vulkan, libva, libva-drm The thing is: these are needed by a static-link library (dynamic .so libs are already handled by debian package dependencies). They're not used when building other software with libvirglrenderer. It is only pkg-config which fails to find them, for actual usage these are not needed. I used to remove Requires.private: tags from the .pc files in such cases, entirely, because it makes no sense in this context. And it makes build just a bit faster too. But indeed, many maintainers tend to add lots'a stuff to Depends. I'd remove the Requires.private here as well. Patching the upstream provided .pc file in Debian feels odd, tbh. Are you sure Requires.private is only relevant for static linking? Isn't this what Libs.private is for. Looping in Tollef and Andrew, as maintainers of pkgconf/pkg-config. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1021923: ionit: FTBFS dh_auto_test: error: pybuild --test -i python{version} -p 3.10 returned exit code 13
Am 17.10.22 um 15:33 schrieb Nilesh Patra: affects 1021895 src:ionit close 1021923 stop Hi Michael, On Mon, 17 Oct 2022 13:56:40 +0200 Michael Biebl wrote: Source: ionit Version: 0.5.0-1 Severity: serious Tags: ftbfs ionit FTBFS in unstable test_pylint (tests.test_pylint.PylintTestCase) Test: Run pylint on Python source code. ... Running following command: [...] This FTBFS occurs due to a bug in pylint which has been fixed upstream and needs fixing at debian end. I'll team-upload the fix in a week if no activity happens from maintainer's end. I am closing your bug. Could we keep it open and block this bug by 1021895? I.e. only close it once pylint has actually been fixed. This makes it a bit easier to track progress. OpenPGP_signature Description: OpenPGP digital signature
Bug#1021925: prometheus-openstack-exporter: FTBFS dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned exit code 13
Source: prometheus-openstack-exporter
Version: 0.1.4-2
Severity: serious
Tags: ftbfs
prometheus-openstack-exporter FTBFS in unstable
dpkg-source --before-build .
fakeroot debian/rules clean
dh clean --with systemd,python3 --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:240: python3.10 setup.py clean
error: Multiple top-level packages discovered in a flat-layout: ['snap',
'debian'].
To avoid accidental inclusion of unwanted files or directories,
setuptools will not proceed with this build.
If you are trying to create a single distribution with multiple packages
on purpose, you should not rely on automatic discovery.
Instead, consider the following options:
1. set up custom discovery (`find` directive with `include` or `exclude`)
2. use a `src-layout`
3. explicitly set `py_modules` or `packages` with a list of names
To find more information, look for "package discovery" on setuptools docs.
E: pybuild pybuild:379: clean: plugin distutils failed with: exit code=1:
python3.10 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned exit
code 13
make: *** [debian/rules:4: clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit
status 2
Full build log available at
https://buildd.debian.org/status/fetch.php?pkg=prometheus-openstack-exporter=all=0.1.4-2.1=1665842181=0
Bug#1021924: networking-mlnx: FTBFS test failures: sqlalchemy.exc.InvalidRequestError: A transaction is already begun on this Session.
Source: networking-mlnx Version: 1:16.0.0-3 Severity: serious Tags: ftbfs networking-mlnx FTBFS in unstable It appears to be trigger lots of test suite failures and is killed eventually Traceback (most recent call last): File "/<>/networking_mlnx/journal/journal.py", line 91, in run_sync_thread self._sync_progress_rows(context.session) File "/<>/networking_mlnx/journal/journal.py", line 188, in _sync_progress_rows rows = db.get_all_monitoring_db_row_by_oldest(session) File "/usr/lib/python3/dist-packages/neutron_lib/db/api.py", line 140, in wrapped with excutils.save_and_reraise_exception(): File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 227, in __exit__ self.force_reraise() File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 200, in force_reraise raise self.value File "/usr/lib/python3/dist-packages/neutron_lib/db/api.py", line 138, in wrapped return f(*args, **kwargs) File "/usr/lib/python3/dist-packages/oslo_db/api.py", line 144, in wrapper with excutils.save_and_reraise_exception() as ectxt: File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 227, in __exit__ self.force_reraise() File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 200, in force_reraise raise self.value File "/usr/lib/python3/dist-packages/oslo_db/api.py", line 142, in wrapper return f(*args, **kwargs) File "/usr/lib/python3/dist-packages/neutron_lib/db/api.py", line 186, in wrapped with excutils.save_and_reraise_exception(): File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 227, in __exit__ self.force_reraise() File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 200, in force_reraise raise self.value File "/usr/lib/python3/dist-packages/neutron_lib/db/api.py", line 184, in wrapped return f(*dup_args, **dup_kwargs) File "/<>/networking_mlnx/db/db.py", line 95, in get_all_monitoring_db_row_by_oldest with session.begin(): File "", line 2, in begin File "/usr/lib/python3/dist-packages/sqlalchemy/util/deprecations.py", line 309, in warned return fn(*args, **kwargs) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 1327, in begin raise sa_exc.InvalidRequestError( sqlalchemy.exc.InvalidRequestError: A transaction is already begun on this Session. E: ABORT: Received TERM signal (requesting cleanup and shutdown) Full build log available at https://buildd.debian.org/status/fetch.php?pkg=networking-mlnx=all=1%3A16.0.0-3.1=1665990240=0
Bug#1021923: ionit: FTBFS dh_auto_test: error: pybuild --test -i python{version} -p 3.10 returned exit code 13
Source: ionit
Version: 0.5.0-1
Severity: serious
Tags: ftbfs
ionit FTBFS in unstable
test_pylint (tests.test_pylint.PylintTestCase)
Test: Run pylint on Python source code. ... Running following command:
/usr/bin/python3.10 -m pylint --rcfile=/<>/tests/pylint.conf --
/<>/ionit tests ionit_plugin.py /<>/setup.py
FAIL
==
FAIL: test_pylint (tests.test_pylint.PylintTestCase)
Test: Run pylint on Python source code.
--
Traceback (most recent call last):
File "/<>/tests/test_pylint.py", line 74, in test_pylint
self.fail("\n".join(msgs))
AssertionError: pylint found issues:
* Module --
--:1:0: F0001: No module named -- (fatal)
--
Ran 32 tests in 7.529s
FAILED (failures=1)
E: pybuild pybuild:379: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.10/build; python3.10 -m unittest discover
-v -s /<>
dh_auto_test: error: pybuild --test -i python{version} -p 3.10 returned exit
code 13
make: *** [debian/rules:6: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit
status 2
Full build log available at
https://buildd.debian.org/status/fetch.php?pkg=ionit=all=0.5.0-1.1=1665834431=0
Bug#1021922: console-setup: FTBFS make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2
Source: console-setup Version: 1.210 Severity: serious Tags: ftbfs console-setup FTBFS in unstable gzip -9n >/acm/VISCII.acm >/<>/acm/VISCII.acm.gz umask 022; /<>/Fonts/bdf2psf --log /<>/Fonts/Arabic-Fixed15.log /<>/Fonts/bdf/9x15-IL2.bdf+/<>/Fonts/bdf/9x15.bdf+/<>/Fonts/bdf/9x15c.bdf /<>/Fonts/standard.equivalents \ /<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set 512 /<>/Fonts/Arabic-Fixed15.psf /<>/Fonts/Arabic-Fixed15.sfm umask 022; /<>/Fonts/bdf2psf --log /<>/Fonts/Arabic-Fixed16.log /<>/Fonts/bdf/georgian16.bdf+/<>/Fonts/bdf/unifont.bdf+/<>/Fonts/bdf/h16.bdf+/<>/Fonts/bdf/etl16-unicode.bdf /<>/Fonts/standard.equivalents \ /<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set 512 /<>/Fonts/Arabic-Fixed16.psf /<>/Fonts/Arabic-Fixed16.sfm umask 022; /<>/Fonts/bdf2psf --log /<>/Fonts/Arabic-VGA14.log /<>/Fonts/bdf/legacy14i.bdf+/<>/Fonts/bdf/legacy14f.bdf+/<>/Fonts/bdf/legacy14l.bdf+/<>/Fonts/bdf/legacy14b.bdf /<>/Fonts/standard.equivalents \ /<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set 512 /<>/Fonts/Arabic-VGA14.psf /<>/Fonts/Arabic-VGA14.sfm umask 022; /<>/Fonts/bdf2psf --log /<>/Fonts/Arabic-VGA16.log /<>/Fonts/bdf/u_vga16_fix.bdf+/<>/Fonts/bdf/u_vga16.bdf+/<>/Fonts/bdf/legacy16c.bdf+/<>/Fonts/bdf/legacy16f.bdf+/<>/Fonts/bdf/legacy16k.bdf /<>/Fonts/standard.equivalents \ /<>/Fonts/ascii.set+/<>/Fonts/linux.set+/<>/Fonts/fontsets/Arabic.512+:/<>/Fonts/useful.set 512 /<>/Fonts/Arabic-VGA16.psf /<>/Fonts/Arabic-VGA16.sfm /<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file or directory /<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file or directory make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-Fixed15.psf] Error 2 make: *** Waiting for unfinished jobs /<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file or directory make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-Fixed16.psf] Error 2 make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA14.psf] Error 2 /<>/Fonts/bdf2psf: /<>/console-setup-1.210: No such file or directory make: *** [Fonts/Makefile:338: /<>/Fonts/Arabic-VGA16.psf] Error 2 dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2 Full build log available at https://buildd.debian.org/status/fetch.php?pkg=console-setup=all=1.210%2Bnmu1=1665832544=0
Bug#1021921: buildbot: FTBFS with dh_auto_test failures
Source: buildbot
Version: 3.5.0-1
Severity: serious
Tags: ftbfs
buildbot FTBFS in unstable
[ERROR]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1660,
in _inlineCallbacks
result = current_context.run(gen.send, result)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 119, in test_OnLeave
self.connector.app.gotConnection()
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 47, in gotConnection
r = self.make(self)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 77, in make
return MasterService(config)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 40, in __init__
self.config = config
builtins.AttributeError: can't set attribute 'config'
buildbot.test.unit.test_wamp_connector.WampConnector.test_OnLeave
===
[ERROR]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1660,
in _inlineCallbacks
result = current_context.run(gen.send, result)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 111, in test_publish
self.connector.app.gotConnection()
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 47, in gotConnection
r = self.make(self)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 77, in make
return MasterService(config)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 40, in __init__
self.config = config
builtins.AttributeError: can't set attribute 'config'
buildbot.test.unit.test_wamp_connector.WampConnector.test_publish
===
[ERROR]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1660,
in _inlineCallbacks
result = current_context.run(gen.send, result)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 94, in test_startup
self.connector.app.gotConnection()
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 47, in gotConnection
r = self.make(self)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 77, in make
return MasterService(config)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 40, in __init__
self.config = config
builtins.AttributeError: can't set attribute 'config'
buildbot.test.unit.test_wamp_connector.WampConnector.test_startup
===
[ERROR]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1660,
in _inlineCallbacks
result = current_context.run(gen.send, result)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 103, in test_subscribe
self.connector.app.gotConnection()
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/test/unit/test_wamp_connector.py",
line 47, in gotConnection
r = self.make(self)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 77, in make
return MasterService(config)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/buildbot/wamp/connector.py",
line 40, in __init__
self.config = config
builtins.AttributeError: can't set attribute 'config'
buildbot.test.unit.test_wamp_connector.WampConnector.test_subscribe
---
Ran 1055 tests in 90.100s
FAILED (skips=67, errors=4, successes=984)
E: pybuild pybuild:379: test: plugin custom failed with: exit code=1:
PYTHONPATH=pkg:/<>/debian/tmp//usr/lib/python3.10/dist-packages
PATH=$PATH:/<>/debian/tmp/usr/bin trial3 --reporter=text
buildbot.test buildbot_worker.test
rm -fr -- /tmp/dh-xdg-rundir-PYLGdnhC
dh_auto_test: error: pybuild --test -i python{version} -p 3.10 --system=custom
"--test-args=PYTHONPATH=pkg:{destdir}/{install_dir}
PATH=\$PATH:{destdir}/usr/bin trial3 --reporter=text buildbot.test
buildbot_worker.test" returned exit code 13
make[1]: *** [debian/rules:41: override_dh_auto_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:61: binary-indep] Error 2
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit
status 2
Full build log available at
Bug#1021920: FTBFS: dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned exit code 13
Source: salt
Version: 3004.1+dfsg-2
Severity: serious
Tags: ftbfs
salt FTBFS in unstable
make[2]: Entering directory '/<>/doc'
rm -rf _build/*
test -d 'locale' && find locale/ -name *.mo -exec rm {} \; || true
make[2]: Leaving directory '/<>/doc'
dh_auto_clean
I: pybuild base:240: python3.10 setup.py clean
/<>/setup.py:8: DeprecationWarning: The distutils package is
deprecated and slated for removal in Python 3.12. Use setuptools or check PEP
632 for potential alternatives
import distutils.dist
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
Distutils was imported before Setuptools, but importing Setuptools also
replaces the `distutils` module in `sys.modules`. This may lead to undesirable
behaviors or errors. To avoid these issues, avoid using distutils directly,
ensure that setuptools is installed in the traditional way (e.g. not an
editable install), and/or make sure that setuptools is always imported before
distutils.
warnings.warn(
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning:
Setuptools is replacing distutils.
warnings.warn("Setuptools is replacing distutils.")
3004.1
Traceback (most recent call last):
File "/<>/setup.py", line 1461, in
setup(distclass=SaltDistribution)
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 87, in
setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line
172, in setup
ok = dist.parse_command_line()
File "/<>/setup.py", line 1425, in parse_command_line
args = distutils.dist.Distribution.parse_command_line(self)
File "/usr/lib/python3.10/distutils/dist.py", line 483, in parse_command_line
args = self._parse_command_opts(parser, args)
File "/usr/lib/python3.10/distutils/dist.py", line 546, in _parse_command_opts
raise DistutilsClassError(
distutils.errors.DistutilsClassError: command class
must subclass Command
E: pybuild pybuild:379: clean: plugin distutils failed with: exit code=1:
python3.10 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned exit
code 13
make[1]: *** [debian/rules:30: override_dh_auto_clean] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit
status 2
Full build log available at
https://buildd.debian.org/status/fetch.php?pkg=salt=all=3004.1%2Bdfsg-2.1=1665843910=0
Bug#1021672: Cannot reproduce
Control: severity -1 normal Control: tags -1 unreproducible Control: close -1 Am 12.10.22 um 21:38 schrieb Matteo Settenvini: Okay, I retried and I cannot reproduce it now. I think what happened is: * my system was hanging at the beginning due to some unrelated problem with video (mesa). * I rebooted from a pendrive, and regenerated the initrd with dracut and hostonly=yes. * I believe this somehow messed up the kernel modules included in the initrd by dracut? That is certainly problematic as the kernel from the pendrive might have different modules as builtin. * Once I rebooted again to a pendrive, I changed the hostonly parameter to "no", and at the same time downgraded udev. * Things started working again for the wrong reason. I apologize for this, it seemed reproducible when I tried at the beginning. For sure it's a strange bug. Feel free to downgrade and close this. Ok OpenPGP_signature Description: OpenPGP digital signature
Bug#1021672: udev: No USB (no keyboard nor FIDO token!) at boot after update from udev 251.5-1 to 252.5-2
Am 12.10.22 um 20:18 schrieb Michael Biebl: Please remove "debug" from the kernel command line and capture the log messages I meant to say "quiet". You can also add "systemd.log_level=debug" to increase the verbosity. See man kernel-command-line. OpenPGP_signature Description: OpenPGP digital signature
Bug#1021672: udev: No USB (no keyboard nor FIDO token!) at boot after update from udev 251.5-1 to 252.5-2
On Wed, 12 Oct 2022 19:39:40 +0200 Matteo Settenvini wrote: Package: udev Version: 251.5-2 Severity: critical Justification: breaks the whole system Dear Maintainer, I have a root partition (separate from the boot partition) which is encrypted with LUKS and unlocked at boot. After an upgrade to udev 251.5-2, keyboard, mouse, and FIDO token (all three USB devices) are not primed during boot. This is easy to see by just attempting to hit BlockNum on the keyboard (the light does not come on). Hence, there is no way anymore for me to unlock the root filesystem, which renders the whole system unusable. Note: I use dracut, although I do not think it is to blame here. Booting from a USB pendrive, and downgrading to udev 251.5-1 (along with systemd) fixes the issue. Let me know how I can provider better information to you. Please remove "debug" from the kernel command line and capture the log messages OpenPGP_signature Description: OpenPGP digital signature
Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
Hi Paul, since a partial removal of exempi on s390x will have a ripple effect on our rdeps (e.g. GNOME), I will probably override dh_auto_test to ignore any failures on s390x to avoid unnecessary work for rdeps of src:exempi. I do not really like this situation though, so I'd very much appreciate if Dipak or any other s390x porter would look into this issue. Regards, Michael Am 23.09.22 um 21:38 schrieb Paul Gevers: Hi Dipak, On Tue, 30 Aug 2022 09:57:44 + Dipak Zope1 wrote: Apologies for late response. It looks like the issue is related to the synchronization between atop and atopacctd. I am looking into it further and will keep this thread updated. I think we established that you replied here but had the other bug in mind (in atop). I am looking forward to have a fix for this for s390x. Can you still look into the exempi issue in this bug report? On 30/08/22, 12:44 AM, "Paul Gevers" wrote: Hi Michael On 29-08-2022 14:23, Michael Biebl wrote: > As you are probably aware, this issue is known and tracked in [1]. Which I added as a blocker and mentioned in my message, so yes. > The > package FTBFS after enabling the test suite. I raised this issue > upstream but there is no real interest/motivation [2] on their part to > address these (most likely endianess related) issues. > So I informed the s390x porters as well but got not feedback so far. Ack, I saw the latter part. > To me it seems it's better to not continue ship a known broken package > on s390x and think a partial architecture removal is probably the better > alternative. If you think the package indeed is severely broken, then removal sounds best. If its broken in some less common use cases, it may be OK to leave it for now (skipping those tests on 390x) and let the porters have a look when they have time. > Let me know what you think It all depends on how broken it is. If you would consider the bugs found by the tests RC, then removal is the better choice unless a porter steps up to fix it. If the bugs would be important at most, than skipping broken tests on s390x sounds like the better option. Removal bugs are hard to time predict. Paul PS: I would not disable building on s390x if you have the test suite finding out severe problems (as the d/control file doesn't have negated architecture fields yet). Just getting the binary removed and FTBFS will prevent the architecture from building again. Otherwise I think we need to go this route. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1020290: init-system-helpers depends on usrmerge | usr-is-merged
control: severity -1 normal control: tags -1 + moreinfo unreproducible control: retitle -1 apt incorrectly prefer usr-is-merged Am 21.09.22 um 15:12 schrieb Craig Sanders: reopen 1020290 severity 1020290 critical stop There's no need to repeat (again!) what i've already said. Unfortunately it is not possible to address the issue you are seeing without further information or having a way to reproduce the issue. Maybe you can provide a minimal reproducer (based on a minimal chroot).
Bug#1013341: /usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
Control: severity -1 important On Sat, 23 Jul 2022 18:04:43 +0200 Jan Kiszka wrote: Upstream patch proposal sent: https://sourceforge.net/p/gnu-efi/mailman/message/37684742/ Thanks for that, Jan. Seems your patch was rejected unfortunately. I couldn't quite follow the reasoning of the rejection, but it's definitely possible that I'm missing the finer details. That said, since systemd now works around that build failure, I'm downgrading this issue to non-RC. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1019443: Upgrade to 1.10.0 breaks nm-connection-editor
Package: libnma0 Version: 1.10.0-1 Severity: serious Forwarded: https://gitlab.gnome.org/GNOME/libnma/-/issues/17 Filing as RC to prevent testing migration. After upgrading libnma from 1.8.40 to 1.10.0, nm-connection-editor shows the following broken behaviour when trying to edit a connection: a file chooser repeatedly pops up. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libnma0 depends on: ii libc62.34-7 ii libcairo21.16.0-6 ii libgck-1-0 3.41.1-1 ii libgcr-base-3-1 3.41.1-1 ii libglib2.0-0 2.73.3-3 ii libgtk-3-0 3.24.34-3 ii libnm0 1.40.0-1 ii libnma-common1.10.0-1 libnma0 recommends no packages. libnma0 suggests no packages. -- no debconf information
