Bug#1082190: /usr/bin/ping: iputils-ping: Apparmor denial
Package: iputils-ping Version: 3:20240117-1 Severity: important File: /usr/bin/ping Hello, When running ping, I get the following apparmor denial (well it's in complain, so nothing is really denied ATM) type=AVC msg=audit(1726736548.607:760): apparmor="ALLOWED" operation="open" class="file" profile="ping" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=22129 comm="ping" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0FSUID="bigon" OUID="root" type=SYSCALL msg=audit(1726736548.607:760): arch=c03e syscall=257 success=yes exit=5 a0=ff9c a1=7ffd75b7a670 a2=80100 a3=0 items=0 ppid=22072 pid=22129 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=3 comm="ping" exe="/usr/bin/ping" subj=ping key=(null)ARCH=x86_64 SYSCALL=openat AUID="bigon" UID="bigon" GID="bigon" EUID="bigon" SUID="bigon" FSUID="bigon" EGID="bigon" SGID="bigon" FSGID="bigon" type=PROCTITLE msg=audit(1726736548.607:760): proctitle=70696E6700772E70657264752E636F6D That still should be fixed I guess Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iputils-ping depends on: ii libc62.40-2 ii libcap2 1:2.66-5 ii libcap2-bin 1:2.66-5 ii libidn2-02.3.7-2 iputils-ping recommends no packages. iputils-ping suggests no packages. -- no debconf information
Bug#1067790: nut: move files to /usr (DEP17) and partially revert time64
Hello Michael, Thanks for the NMU Kind regards, Laurent Le 4/09/24 à 15:28, Michael Biebl a écrit : Hi, I've incorporated the suggestions from Helmut and also added a strictly versioned dependency on libnutscan2 to nut-server, to ensure that the t64 variant is replaced on upgrades (I noticed that apt didn't do that otherwise when doing a test upgrade). The changes have been uploaded to DELAYED/3. Updated debdiff is attached. Regards, Michael
Bug#1077937: [Pkg-utopia-maintainers] Bug#1077937: avahi-daemon: WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended.
Le 6/08/24 à 18:32, Michael Biebl a écrit : Am 05.08.24 um 11:45 schrieb Luca Boccassi: On Mon, 5 Aug 2024 at 10:31, Laurent Bigonville wrote: On Mon, 05 Aug 2024 00:15:00 +0100 Luca Boccassi wrote: > I'm not sure what could be done here, and I don't think anything should > even if it could. Either don't install/enable both at the same time, or > disable mDNS in resolved (it's optional). The avahi-daemon is pulled by some packages and disabling it completely will break stuff. It seems that Fedora has gone the "disable mDNS support by default in systemd-resolved" route: https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_793 An other option could be to let avahi-daemon puts a snippet to disable systemd-resolved mDNS support in /etc/systemd/resolved.conf.d/ So what's your preferred way here? I do not want to disable it globally as it's possible to just disable avahi, but if Michael wants to ship a drop-in for resolved in avahi that's fine by me, as the drop-in can be masked locally too I would prefer the solution Fedora has chosen, i.e. build systemd with -Ddefault-mdns=no. This will provide a more predictable behaviour for systemd-resolved and is imho a cleaner solution. Users that want the mdns functionality can easily opt-in via a config snippet. So what are we doing here?
Bug#1079293: cups-pk-helper: Cannot acquire org.opensuse.CupsPkHelper.Mechanism on the bus
Package: cups-pk-helper Followup-For: Bug #1079293 Hello (again), This is seems better Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-pk-helper depends on: ii adduser3.137 ii libc6 2.39-7 ii libcups2t642.4.10-1 ii libglib2.0-0t642.81.2-1 ii libpolkit-gobject-1-0 125-2 cups-pk-helper recommends no packages. cups-pk-helper suggests no packages. -- Configuration Files: /etc/dbus-1/system.d/org.opensuse.CupsPkHelper.Mechanism.conf changed [not included] -- no debconf information diff -Nru cups-pk-helper-0.2.6/debian/rules cups-pk-helper-0.2.6/debian/rules --- cups-pk-helper-0.2.6/debian/rules 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/rules 2024-08-22 13:39:57.0 +0200 @@ -9,4 +9,4 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- --enable-compile-warnings=yes + dh_auto_configure -- --enable-compile-warnings=yes --with-daemon-user=cups-pk-helper
Bug#1079293: cups-pk-helper: Cannot acquire org.opensuse.CupsPkHelper.Mechanism on the bus
Package: cups-pk-helper Followup-For: Bug #1079293 Hello, The attached patch should fix the issue Not tested though Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-pk-helper depends on: ii adduser3.137 ii libc6 2.39-7 ii libcups2t642.4.10-1 ii libglib2.0-0t642.81.2-1 ii libpolkit-gobject-1-0 125-2 cups-pk-helper recommends no packages. cups-pk-helper suggests no packages. -- Configuration Files: /etc/dbus-1/system.d/org.opensuse.CupsPkHelper.Mechanism.conf changed [not included] -- no debconf information diff -Nru cups-pk-helper-0.2.6/debian/patches/series cups-pk-helper-0.2.6/debian/patches/series --- cups-pk-helper-0.2.6/debian/patches/series 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/patches/series 2024-08-22 13:23:39.0 +0200 @@ -5,4 +5,3 @@ Add-default-statements-to-silence-compiler-warnings.patch Don-t-use-g_type_init-on-recent-glib.patch run_as_cups-pk-helper.patch -Use_cups-pk-helper_in_org.opensuse.CupsPkHelper.Mechanism.conf.patch diff -Nru cups-pk-helper-0.2.6/debian/patches/Use_cups-pk-helper_in_org.opensuse.CupsPkHelper.Mechanism.conf.patch cups-pk-helper-0.2.6/debian/patches/Use_cups-pk-helper_in_org.opensuse.CupsPkHelper.Mechanism.conf.patch --- cups-pk-helper-0.2.6/debian/patches/Use_cups-pk-helper_in_org.opensuse.CupsPkHelper.Mechanism.conf.patch 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/patches/Use_cups-pk-helper_in_org.opensuse.CupsPkHelper.Mechanism.conf.patch 1970-01-01 01:00:00.0 +0100 @@ -1,20 +0,0 @@ -Description: Use cups-pk-helper in *Mechanism.conf - . - cups-pk-helper (0.2.6-1ubuntu4~artful1) artful; urgency=medium - . - * Try: prevent delete of other's jobs -Author: Shem Pasamba -Forwarded: no -Last-Update: 2017-12-20 - cups-pk-helper-0.2.6.orig/src/org.opensuse.CupsPkHelper.Mechanism.conf -+++ cups-pk-helper-0.2.6/src/org.opensuse.CupsPkHelper.Mechanism.conf -@@ -6,7 +6,7 @@ - - - -- -+ - - - diff -Nru cups-pk-helper-0.2.6/debian/rules cups-pk-helper-0.2.6/debian/rules --- cups-pk-helper-0.2.6/debian/rules 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/rules 2024-08-22 13:23:39.0 +0200 @@ -9,4 +9,4 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- --enable-compile-warnings=yes + dh_auto_configure -- --enable-compile-warnings=yes --with-daemon-user=cups-pk-helper
Bug#1079293: cups-pk-helper: Cannot acquire org.opensuse.CupsPkHelper.Mechanism on the bus
Package: cups-pk-helper Version: 0.2.6-2 Severity: grave Justification: renders package unusable Hello, It seems that cups-pk-helper is not working anymore. It fails to start with Cannot acquire org.opensuse.CupsPkHelper.Mechanism on the bus It seems that the dbus .service file is trying to start it as root, but the configuration requires that the user is cups-pk-helper The two need to be equivalent Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-pk-helper depends on: ii adduser3.137 ii libc6 2.39-7 ii libcups2t642.4.10-1 ii libglib2.0-0t642.81.2-1 ii libpolkit-gobject-1-0 125-2 cups-pk-helper recommends no packages. cups-pk-helper suggests no packages. -- no debconf information
Bug#955955: thunderbird: Depends on deprecated dbus-glib
Source: thunderbird Followup-For: Bug #955955 Hello, Since today and version (1:128.1.0esr-1) the binary package does not depend against libdbus-glib. But it seems that the build-dependencies still contains libdbus-glib-1-dev That should also be removed and then that bug could be closed I guess. Could you please drop libdbus-glib-1-dev from the BD? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.3-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1077937: avahi-daemon: WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended.
On Mon, 05 Aug 2024 00:15:00 +0100 Luca Boccassi wrote: > I'm not sure what could be done here, and I don't think anything should > even if it could. Either don't install/enable both at the same time, or > disable mDNS in resolved (it's optional). The avahi-daemon is pulled by some packages and disabling it completely will break stuff. It seems that Fedora has gone the "disable mDNS support by default in systemd-resolved" route: https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_793 An other option could be to let avahi-daemon puts a snippet to disable systemd-resolved mDNS support in /etc/systemd/resolved.conf.d/ So what's your preferred way here? Kind regards, Laurent Bigonville
Bug#1077937: avahi-daemon: WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended.
Package: avahi-daemon Version: 0.8-13+b2 Severity: important X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Hello, In the logs I see the following: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. *** And Host name conflict, retrying with -XXX I think this is caused by systemd-resolved? That should be addressed I guess? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages avahi-daemon depends on: ii adduser 3.137 ii dbus [default-dbus-system-bus] 1.14.10-4+b1 ii libavahi-common30.8-13+b2 ii libavahi-core7 0.8-13+b2 ii libc6 2.39-6 ii libcap2 1:2.66-5 ii libdaemon0 0.14-7.1+b1 ii libdbus-1-3 1.14.10-4+b1 ii libexpat1 2.6.2-1 Versions of packages avahi-daemon recommends: ii libnss-mdns 0.15.1-4 Versions of packages avahi-daemon suggests: ii avahi-autoipd 0.8-13+b2 -- no debconf information
Bug#1077614: RFP: puppetlabs-bolt -- infrastructure orchestration tool
Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-puppet-de...@lists.alioth.debian.org * Package name: puppetlabs-bolt Version : 3.29.0 Upstream Contact: pup...@puppet.com * URL : https://www.puppet.com/docs/bolt/ * License : Apache License 2.0 Programming Lang: Ruby Description : infrastructure orchestration tool Bolt is an open source orchestration tool that automates the manual work it takes to maintain your infrastructure. Use Bolt to automate tasks that you perform on an as-needed basis or as part of a greater orchestration workflow. For example, you can use Bolt to patch and update systems, troubleshoot servers, deploy applications, or stop and restart services. Bolt can be installed on your local workstation and connects directly to remote targets with SSH or WinRM, so you are not required to install any agent software.
Bug#1076946: libvirt-daemon-system: Apparmor prevents /proc/sys/vm/max_map_count to be read
Package: libvirt-daemon-system Version: 10.5.0-1 Severity: normal Hello, When starting a VM, I get the following denial from apparmor: type=AVC msg=audit(1721828131.241:1176): apparmor="DENIED" operation="open" class="file" profile="libvirt-6fde45f5-ff7e-4277-87b9-123a8aa30c7e" name="/proc/sys/vm/max_map_count" pid=149623 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0^]FSUID="libvirt-qemu" OUID="root" Not sure what this breaks, but it must either be allowed or silenced Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.10-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon-system depends on: ii adduser 3.137 ii debconf [debconf-2.0] 1.5.87 ii firewalld 2.2.0-1 ii gettext-base0.22.5-1 ii iptables1.8.10-4 ii libvirt-clients 10.5.0-1 ii libvirt-daemon 10.5.0-1 ii libvirt-daemon-config-network 10.5.0-1 ii libvirt-daemon-config-nwfilter 10.5.0-1 ii libvirt-daemon-system-systemd 10.5.0-1 ii libvirt010.5.0-1 ii logrotate 3.22.0-1 ii polkitd 124-3 Versions of packages libvirt-daemon-system recommends: ii dmidecode3.6-1 ii dnsmasq-base [dnsmasq-base] 2.90-4 ii iproute2 6.10.0-1 ii mdevctl 1.3.0-2.1 ii parted 3.6-4 Versions of packages libvirt-daemon-system suggests: ii apparmor3.1.7-1+b1 ii auditd 1:3.1.2-4+b1 pn nfs-common pn open-iscsi pn pm-utils ii systemd 256.2-1 pn systemtap pn zfsutils -- Configuration Files: /etc/libvirt/qemu.conf [Errno 13] Permission non accordée: '/etc/libvirt/qemu.conf' -- debconf information excluded
Bug#1076782: apparmor: vim syntax file in different package that its manpage (apparmor.vim)
Package: apparmor Version: 3.1.7-1+b1 Severity: minor Hello, It seems that the vim syntax file is in a different package that its manpage apparmor: /usr/share/man/man5/apparmor.vim.5.gz apparmor-utils: /usr/share/vim/addons/syntax/apparmor.vim apparmor-utils: /usr/share/vim/registry/vim-apparmor.yaml Maybe it should be moved inside the same package? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apparmor depends on: ii debconf [debconf-2.0] 1.5.87 ii libc6 2.39-5 apparmor recommends no packages. Versions of packages apparmor suggests: pn apparmor-profiles-extra ii apparmor-utils 3.1.7-1 -- debconf information excluded
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
Le 18/07/24 à 10:54, Diederik de Haas a écrit : Control: severity -1 minor [...] I fail to see how this is any package's problem. Your boot partition is too small to perform the requested operation. During compression it needs the space for the uncompressed files and the space needed for the compressed archive, so it generally needs (much) more space then it finally needs as the uncompressed files will be removed again once the compressed archive is complete. Solution: make your boot partition larger. Or remove older/other kernels, but IMO this will only delay the inevitable. Reducing severity to minor, but I actually think it should just be closed. On 18 Jul 2024 10:17:20 +0200 Laurent Bigonville wrote: It's related to firmware-misc-nonfree that is now pulling firmware-nvidia-graphics that contains a lot of (non-free) firmwares. With firmware-nvidia-graphics installed, my initramfs grows to something like 200M compared to 64M without it. The firmware-nvidia-graphics package was created exactly because its size got big(ger) and (partially therefor) deserved its own package instead of making the firmware-misc-nonfree extremely large. That package is meant for 'the other' firmware which don't deserve their own package. The firmware-nvidia-graphics is recommended by firmware-misc-nonfree as the nvidia graphics firmware files were moved from the latter to the former. Solution: If you don't need firmware-nvidia-graphics, don't install it. If you do need it, but don't have the space for it, then increase your storage size. Well you change expectation from users that have firmware-misc-nonfree installed by pulling that huge package IMVHO, a lot of people with firmware-misc-nonfree installed will experience an issue when updating. The /boot partition size I've here is the default one from the debian-installer
Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"
reassign 1076539 firmware-misc-nonfree 20240610-1 severity 1076539 serious affects 1076539 + plymouth thanks Le 18/07/24 à 09:43, Bastian Venthur a écrit : Dear Maintainer, trying to update plymouth fails with "No space left on device": Hello, I also had the problem this morning, but it's not related to plymouth. It's related to firmware-misc-nonfree that is now pulling firmware-nvidia-graphics that contains a lot of (non-free) firmwares. With firmware-nvidia-graphics installed, my initramfs grows to something like 200M compared to 64M without it. I'm reassigning this to firmware-misc-nonfree Kind regards, Laurent Bigonville
Bug#1076406: simple-scan: Missing icons
Package: simple-scan Version: 46.0-1 Severity: normal Hello, It seems that there are missing in the interface At least one in the main dialog next to the "Scan" button and one at the bottom after a successful scan That should be fixed. Kind regards, Laurent Bigonville -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.8-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages simple-scan depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.10-4+b1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii libadwaita-1-01.5.2-1 ii libc6 2.38-14 ii libcairo2 1.18.0-3+b1 ii libcolord21.4.7-1+b1 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-1 ii libglib2.0-0t64 2.80.4-1 ii libgtk-4-14.12.5+ds-6+b1 ii libgusb2 0.4.9-1 ii libpackagekit-glib2-181.3.0-1 ii libsane1 1.3.0-1 ii libwebp7 1.4.0-0.1 ii libwebpmux3 1.4.0-0.1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.3.dfsg+really1.3.1-1 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information
Bug#1076139: qemu-guest-agent: Allow to configure qemu-ga
Package: qemu-guest-agent Followup-For: Bug #1076139 Hello again, In RHEL9-like, the RPC calls that are blacklisted are a bit different: https://git.almalinux.org/rpms/qemu-kvm/src/branch/c9/SOURCES/qemu-ga.sysconfig https://git.almalinux.org/rpms/qemu-kvm/src/branch/c9/SOURCES/qemu-guest-agent.service -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.8-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-guest-agent depends on: ii init-system-helpers 1.66 ii libc62.38-14 ii libglib2.0-0t64 2.80.4-1 ii libnuma1 2.0.18-1 ii libudev1 256.2-1 ii liburing22.6-1 qemu-guest-agent recommends no packages. qemu-guest-agent suggests no packages.
Bug#1076139: qemu-guest-agent: Allow to configure qemu-ga
Package: qemu-guest-agent Version: 1:7.2+dfsg-7+deb12u6 Severity: normal Hello, The service file qemu-guest-agent is not allowing to customize the options. Worst it seems that it's not blacklisting some of the RPC calls by default If I look at what fedora is doing it allows that and even does it by default: https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/qemu-guest-agent.service https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/qemu-ga.sysconfig That should be added I'm also wondering whether this is not a security issue too Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.8-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-guest-agent depends on: ii init-system-helpers 1.66 ii libc62.38-14 ii libglib2.0-0t64 2.80.4-1 ii libnuma1 2.0.18-1 ii libudev1 256.2-1 ii liburing22.6-1 qemu-guest-agent recommends no packages. qemu-guest-agent suggests no packages.
Bug#1073937: opencryptoki: Do not build on several architectures due to libitm1 build-dependency
Source: opencryptoki Version: 3.23.0+dfsg-0.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, It seems that opencryptoki BD again against libitm1 but that package is not available on all architectures. I did fix that in bug #989555 but it seems that the patch was lost I quickly checked and I think that the libitm1 build-dependency is not necesarry anymore and can completely be removed, to be double checked. Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1073935: RFP: onceover -- Testing tools for Puppet controlrepos
Package: wnpp Severity: wishlist * Package name: onceover Version : 3.22.0 Upstream Contact: Dylan Ratcliffe * URL : https://github.com/voxpupuli/onceover/ * License : Apache-2.0 Programming Lang: Ruby Description : Testing tools for Puppet controlrepos Onceover is a tool to automatically run basic tests on an entire Puppet control repository. It includes automatic parsing of the Puppetfile, environment.conf and others in order to stop silly mistakes ever reaching your Puppet Master! Should probably be packaged alongside the other Puppet packages
Bug#1073265: wsdd: Please install the firewalld service files
Package: wsdd Version: 2:0.8-1 Severity: wishlist Hello, Upstream is shipping firewalld service files but these are not installed, I guess these should be shipped in one of the packages (the main one?) They should more than probably be installed in /usr/lib/firewalld/services/ (and not in /etc) Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wsdd depends on: ii python3 3.11.8-1 wsdd recommends no packages. wsdd suggests no packages. -- no debconf information
Bug#1072376: intel-compute-runtime: Please update to 24.17.29377.17
Source: intel-compute-runtime Version: 24.13.29138.7-1 Severity: normal Hello, ATM the package is removed from testing because it's compiled with llvm 14 But there is a new version 24.17.29377.17, that I guess should compile with llvm 17 Could you please update the package? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.11-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1070833: evolution: Failed to load module: /usr/lib/evolution/modules/module-rss.so
Source: evolution Version: 3.52.1-1 Severity: serious Hello, When starting evolution, I see the following messages in the terminal: (process:20505): e-data-server-WARNING **: 09:48:19.447: module_load: libevolution-rss-common.so: cannot open shared object file: No such file or directory Failed to load module: /usr/lib/evolution/modules/module-rss.so (evolution:20505): camel-CRITICAL **: 09:48:19.525: camel_provider_list: Could not load /usr/lib/evolution-data-server/camel-providers/libcamelrss.so: libevolution-rss-common.so: cannot open shared object file: No such file or directory It seems that libcamelrss.so is loading libevolution-rss-common.so but the file is installed in evolution-dev instead of libevolution. Please move that file Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1070707: wsdd: Please upgrade to version 0.8
Source: wsdd Version: 2:0.7.1-5 Severity: normal Hello, Could you please upgrade the pacakge to version 0.8 This fixes bugs like https://github.com/christgau/wsdd/issues/199 Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1070644: gnome-remote-desktop: System .service file enabled but not the user one?
Package: gnome-remote-desktop Version: 46.1-3 Severity: normal Hello, It seems that the system systemd .service is enabled at boot, while the user one is not. Any reason why the former is enabled and the later is not? Not sure I see the rational here Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-remote-desktop depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii fuse33.14.0-5 ii init-system-helpers 1.66 ii libc62.38-7 ii libcairo21.18.0-3+b1 ii libei1 1.2.1-1 ii libepoxy01.5.10-1+b2 ii libfreerdp-server3-3 3.5.1+dfsg1-3 ii libfreerdp3-33.5.1+dfsg1-3 ii libfuse3-3 3.14.0-5 ii libglib2.0-0t64 2.80.0-9 ii libmutter-14-0 46.1-2 ii libnotify4 0.8.3-1+b1 ii libopus0 1.4-1+b1 ii libpipewire-0.3-0t64 1.0.5-1+b3 ii libpolkit-gobject-1-0124-2 ii libsecret-1-00.21.4-1+b1 ii libsystemd0 255.5-1 ii libtss2-esys-3.0.2-0t64 4.0.1-7.2 ii libtss2-mu-4.0.1-0t644.0.1-7.2 ii libtss2-rc0t64 4.0.1-7.2 ii libtss2-tctildr0t64 4.0.1-7.2 ii libwinpr3-3 3.5.1+dfsg1-3 ii libxkbcommon01.6.0-1+b1 ii pipewire 1.0.5-1+b3 ii systemd [systemd-sysusers] 255.5-1 ii wireplumber 0.4.17-1+b2 gnome-remote-desktop recommends no packages. gnome-remote-desktop suggests no packages. -- no debconf information
Bug#1063897: firefox: poor performance compared to vendor package
On Wed, 14 Feb 2024 16:49:59 +0100 Sylvestre Ledru wrote: > > Le 14/02/2024 à 13:00, Lorenzo Bertini a écrit : > > Dear Maintainer, > > > > Firefox on debian (both ESR and sid versions) is performing poorly. Here are the > > results on one of my machines, but it's consistent with all the others: > > > > Test: Browserbench Speedometer 2.1 (https://browserbench.org/Speedometer2.1) > > > > Gentoo: 290 (+65%) > > Debian sid with vendor package: 260 (+50%) > > Debian sid firefox: 175 (-) > > Debian sid firefox-esr: 160 (-10%) > > > > Upon inspection, I think the cause is the optimization flags, including LTO, PGO, O3. > > Please take this report in consideration, as the performance increase is massive. > > it is expected and why Mozilla is providing a Debian package now AFACS, the packages provided by mozilla are only nightly/devedition/beta, but there is no stable release with the optimizations, or am I overlooking something?
Bug#1064060: wsdd: Split to client and server packages?
On Fri, 16 Feb 2024 10:04:53 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= wrote: > gvfs 1.53.90-1 uses wsdd to find newer Windows network shares. > > My initial understanding is that wsdd can be used both to advertise > network shares or to find network shares. gvfs only needs the "find" > behavior and gvfs calls wsdd from $PATH directly when needed. > > I believe it is unwanted behavior for wsdd.service to be running for > gvfs's use case. > > Therefore, please create a separate package for wsdd.service , perhaps > named wsdd-server Currently all machines installing wsdd start to advertise on the network and are automatically discoverable, this is less than optimal indeed. And other alternative is to pass "--no-enable --no-start" to dh_installsystemd and add an After/Wants in the packages that really requires the "server" part to be running? Not sure what other packages we are talking about here? There is currently on one rdep and it's gvfs But I agree the "server" part shouldn't be running by default, at least without the "--no-host" option
Bug#1063391: systemd: Please enable password quality check feature
Source: systemd Version: 255.3-1 Severity: wishlist Hello, Would it possible to enable the password quality check feature? If I understand the code, it's dynamically loaded at runtim, so no hard dependency on it(?) There are two backends for this, it looks like libpwquality1 has more rdepends than libpasswdqc1 $ apt-cache rdepends libpwquality1 libpwquality1 Reverse Depends: libpwquality-dev libpwquality1-dbgsym freeipa-server-trust-ad freeipa-server zulucrypt-gui seahorse mate-user-admin python3-pwquality libpwquality-tools gnome-control-center libpam-pwquality gnome-initial-setup gnome-disk-utility budgie-control-center calamares $ apt-cache rdepends libpasswdqc1 libpasswdqc1 Reverse Depends: libpasswdqc-dev libpasswdqc1-dbgsym passwdqc libpam-passwdqc
Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”
On Mon, 29 Jan 2024 10:47:50 +0100 Laurent Bigonville wrote: > > Hello, > > It seems that fwupd is not starting anymore on my machine. > > In the logs I can see: > > jan 29 10:40:28 eriador systemd[1]: Starting fwupd.service - Firmware > update daemon... > jan 29 10:40:28 eriador fwupd[13042]: Failed to load daemon: failed to > load engine: Failed to load config: Key file does not have group “redfish” > jan 29 10:40:28 eriador systemd[1]: fwupd.service: Main process exited, > code=exited, status=1/FAILURE > jan 29 10:40:28 eriador systemd[1]: fwupd.service: Failed with result > 'exit-code'. > jan 29 10:40:28 eriador systemd[1]: Failed to start fwupd.service - > Firmware update daemon. > I've no idea what happened, but the configuration file was changed (I didn't do these changes): $ sudo diff -u fwupd/fwupd.conf /etc/fwupd/fwupd.conf --- fwupd/fwupd.conf 2024-01-24 10:15:36.0 +0100 +++ /etc/fwupd/fwupd.conf 2023-07-13 11:36:11.244229063 +0200 @@ -1,5 +1,20 @@ -# use `man 5 fwupd.conf` for documentation [fwupd] DisabledPlugins=test;test_ble OnlyTrusted=true AllowEmulation=false +DisabledPlugins=test;test_ble +IgnorePower=false +OnlyTrusted=true +AllowEmulation=false + +[msr] +MinimumSmeKernelVersion=5.18.0 + +[redfish] + +[thunderbolt] +MinimumKernelVersion=4.13.0 +DelayedActivation=false +RetimerOfflineMode=false + +[uefi_capsule]
Bug#1061776: fail2ban: Wrong journalmatch for sshd jail
Package: fail2ban Version: 1.0.2-2 Severity: serious Tags: sid trixie bookworm Hello, The default journalmatch for ssh the following: filter.d/sshd.conf: journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd But the .service file for ssh in debian is called ssh.service, not sshd.service If I run journalctl _SYSTEMD_UNIT=sshd.service _COMM=sshd, I get no entries. If I run journalctl _SYSTEMD_UNIT=ssh.service _COMM=sshd , I get the logs I think there are still something broken with the switch to journald The configuration should be changed to: "_SYSTEMD_UNIT=ssh.service _COMM=sshd" IMVHO Kind regards, Laurent Bigonville
Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”
Package: fwupd Version: 1.9.12-1 Severity: serious Hello, It seems that fwupd is not starting anymore on my machine. In the logs I can see: jan 29 10:40:28 eriador systemd[1]: Starting fwupd.service - Firmware update daemon... jan 29 10:40:28 eriador fwupd[13042]: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish” jan 29 10:40:28 eriador systemd[1]: fwupd.service: Main process exited, code=exited, status=1/FAILURE jan 29 10:40:28 eriador systemd[1]: fwupd.service: Failed with result 'exit-code'. jan 29 10:40:28 eriador systemd[1]: Failed to start fwupd.service - Firmware update daemon. Kind regards, Laurent Bigonville
Bug#926900: sslv3 alert illegal parameter
tag 926900 patch thanks The attached patch fixes the issue for me Le 26/01/24 à 10:38, Laurent Bigonville a écrit : When looking at the documentation of smtplib (the python library used here), it says: An SMTP_SSL instance behaves exactly the same as instances of SMTP. SMTP_SSL*should be used for situations where SSL is required from the beginning of the connection and using starttls() is not appropriate*. If host is not specified, the local host is used. If port is zero, the standard SMTP-over-SSL port (465) is used. So that means that SMTP_SSL is used for connections where SSL is present from the start and not when STARTTLS is used to upgrade the connection to a secure one. The documentation of reportbug says: smtptls: Enables TLS encryption for the SMTP connection, using STARTTLS. This setting is ignored if you connect to port 465, in which case SSL/TLS will always be used. So either the documentation is wrong, of the code is. The following python code works: >>> smtp = smtplib.SMTP('mail-submit.debian.org',587) >>> smtp.ehlo() (250, b'stravinsky.debian.org Hello eriador.bigon.be [2a02:a03f:65c5:3301:a912:aba9:d92d:4965]\nSIZE 104857600\n8BITMIME\nCHUNKING\nSTARTTLS\nSMTPUTF8\nHELP') >>> smtp.starttls() (220, b'TLS go ahead') >>> smtp.quit() (221, b'stravinsky.debian.org closing connection') >>> While this is not: >>> smtplib.SMTP_SSL('mail-submit.debian.org',587) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/smtplib.py", line 1050, in __init__ SMTP.__init__(self, host, port, local_hostname, timeout, File "/usr/lib/python3.11/smtplib.py", line 255, in __init__ (code, msg) = self.connect(host, port) File "/usr/lib/python3.11/smtplib.py", line 341, in connect self.sock = self._get_socket(host, port, self.timeout) ^^ File "/usr/lib/python3.11/smtplib.py", line 1057, in _get_socket new_socket = self.context.wrap_socket(new_socket, File "/usr/lib/python3.11/ssl.py", line 517, in wrap_socket return self.sslsocket_class._create( ^ File "/usr/lib/python3.11/ssl.py", line 1108, in _create self.do_handshake() File "/usr/lib/python3.11/ssl.py", line 1383, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1006) >>>From 19b99e6c66c5febbcf590846cf29f824bc1c1440 Mon Sep 17 00:00:00 2001 From: Laurent Bigonville Date: Fri, 26 Jan 2024 13:56:09 +0100 Subject: [PATCH] Fix issue when sending mails using SSL/STARTTLS The hostname passed to smtplib should not contain the port, this hostname is used to verify the SSL certificate. Closes: #926900 --- reportbug/submit.py | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/reportbug/submit.py b/reportbug/submit.py index 0daaad4..94a30bf 100644 --- a/reportbug/submit.py +++ b/reportbug/submit.py @@ -446,6 +446,11 @@ def send_report(body, attachments, mua, fromaddr, sendto, ccaddr, bccaddr, tryagain = True refused = None retry = 0 +_smtphost = smtphost.split(':')[0] +try: +smtpport = smtphost.split(':')[1] +except IndexError: +smtpport = 25 while tryagain: tryagain = False ewrite("Connecting to %s via SMTP...\n", smtphost) @@ -453,14 +458,14 @@ def send_report(body, attachments, mua, fromaddr, sendto, ccaddr, bccaddr, conn = None # if we're using reportbug.debian.org, send mail to # submit -if smtphost.lower() == 'reportbug.debian.org': -conn = smtplib.SMTP(smtphost, 587) -elif smtphost.endswith(':465'): +if _smtphost.lower() == 'reportbug.debian.org': +conn = smtplib.SMTP(_smtphost, 587) +elif smtpport == 465: # ignore smtptls setting since port 465 implies SSL smtptls = None -conn = smtplib.SMTP_SSL(smtphost) +conn = smtplib.SMTP_SSL(_smtphost, 465) else: -conn = smtplib.SMTP(smtphost) +conn = smtplib.SMTP(_smtphost, smtpport) response = conn.ehlo() if not (200 <= response[0] <= 299): conn.helo() -- 2.43.0
Bug#1061569: spam: reportbug test
Package: spam Severity: normal Test, please disregard
Bug#926900: sslv3 alert illegal parameter
When looking at the documentation of smtplib (the python library used here), it says: An SMTP_SSL instance behaves exactly the same as instances of SMTP. SMTP_SSL*should be used for situations where SSL is required from the beginning of the connection and using starttls() is not appropriate*. If host is not specified, the local host is used. If port is zero, the standard SMTP-over-SSL port (465) is used. So that means that SMTP_SSL is used for connections where SSL is present from the start and not when STARTTLS is used to upgrade the connection to a secure one. The documentation of reportbug says: smtptls: Enables TLS encryption for the SMTP connection, using STARTTLS. This setting is ignored if you connect to port 465, in which case SSL/TLS will always be used. So either the documentation is wrong, of the code is. The following python code works: smtp = smtplib.SMTP('mail-submit.debian.org',587) smtp.ehlo() (250, b'stravinsky.debian.org Hello eriador.bigon.be [2a02:a03f:65c5:3301:a912:aba9:d92d:4965]\nSIZE 104857600\n8BITMIME\nCHUNKING\nSTARTTLS\nSMTPUTF8\nHELP') smtp.starttls() (220, b'TLS go ahead') smtp.quit() (221, b'stravinsky.debian.org closing connection') While this is not: smtplib.SMTP_SSL('mail-submit.debian.org',587) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/smtplib.py", line 1050, in __init__ SMTP.__init__(self, host, port, local_hostname, timeout, File "/usr/lib/python3.11/smtplib.py", line 255, in __init__ (code, msg) = self.connect(host, port) File "/usr/lib/python3.11/smtplib.py", line 341, in connect self.sock = self._get_socket(host, port, self.timeout) ^^ File "/usr/lib/python3.11/smtplib.py", line 1057, in _get_socket new_socket = self.context.wrap_socket(new_socket, File "/usr/lib/python3.11/ssl.py", line 517, in wrap_socket return self.sslsocket_class._create( ^ File "/usr/lib/python3.11/ssl.py", line 1108, in _create self.do_handshake() File "/usr/lib/python3.11/ssl.py", line 1383, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1006)
Bug#926900: Processed: severity of 926900 is serious
Le 25/01/24 à 16:04, Sandro Tosi a écrit : Well I raised this bug to serious as 1) I think these days, having non functional SSL is a real problem 2) mail-submit.debian.org (the SMTP server that can be used by DD to send mail with DKIM signature) is triggering this error. We can argue over the severity, I think that this should be fixed ASAP https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/doc/README.Users?ref_type=heads#L200-202 I'm not sure why you are pointing me to this? The problem is that reportbugs is not happy when trying to connect to some SMTP servers when using "smtptls" depending of their configuration, NOTHING to do with the BTS. The SMTP server I mentioned here is just an example AND it works perfectly with the openssl command: $ openssl s_client -connect mail-submit.debian.org:587 -starttls smtp CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = stravinsky.debian.org verify return:1 --- Certificate chain 0 s:CN = stravinsky.debian.org i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Dec 2 00:46:54 2023 GMT; NotAfter: Mar 1 00:46:53 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT --- Server certificate -BEGIN CERTIFICATE- MIIGDzCCBPegAwIBAgISBLG1+0K75F9l9yqzoMGdBCvFMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yMzEyMDIwMDQ2NTRaFw0yNDAzMDEwMDQ2NTNaMCAxHjAcBgNVBAMT FXN0cmF2aW5za3kuZGViaWFuLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC AgoCggIBALtI7AqU8JfQYct7WM69VCUQo1trInbUPVZ61i4Nmqa7nzCCw8C+4GkF +R8PQhjX3rGjK8NpLNruP+e7YbzrxR69OL9kZwXDFLhAwMn6OJ8UzoHwSeYstBLY mHxBcuy+dDVsE9oZQXFqT+mpEPGhAR8ynmzekGpfItiFLX8LmS36QKUnL4es2v3V jfhsZXNoS5dPM53nzuRaB3s2Vp7HAIxbT4PijEMTsfE0qdG3a5Qok5U/S+uE7fix A3nQbCd+qvAIb0mhoedpUmiCfBUVpWFl6NLdiJxiKTJdH2f0F8xB9l/OnE8NlpXu cqNP+wiw9AknBjH4xKYJP4BUVLlL4C5qiEvuIpAkqi4/EqHwWK+Z5njZfq7mWuSY 8fepsMiLxuMdvJCCg7T/bHrM7hFRyUewYvk/xFqYPEGW+Tv7kdwMU/CsiiGzAt6b k6hfftixOJbguLFAnKRgvNy3cB5ZQ/ehOEjGTaF952lJgDPYOnUL8iO+hd9lkPJJ JfRHpEZHUZ1U0T0vR9mEFPGF5rO5+NvlCImTyeLvVxFXdtoxVGApl9R9lxVXQHZI mGivYdPlDGpBSxwxEN9AObpl/QelL8MR5eLQfjXN86sUTR66MgtCQ4/GJs+l69Wv hFTBfGn1eDEo10I9qJVToV+5an0qWFPfH4q8/FZP/+wdEGwJgYHNAgMBAAGjggIv MIICKzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFHn9eJOpQZ+x7hjjPihPC4UuBaxl MB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkw RzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAC hhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMDgGA1UdEQQxMC+CFm1haWwtc3VibWl0 LmRlYmlhbi5vcmeCFXN0cmF2aW5za3kuZGViaWFuLm9yZzATBgNVHSAEDDAKMAgG BmeBDAECATCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1ADtTd3U+LbmAToswWwb+ QDtn2E/D9Me9AA0tcm/h+tQXAAABjCg1DJsAAAQDAEYwRAIgd8qYrzL27ecIMX5T VUz9bqJGIwyPsl3ke4fEy2PFPlkCIFmY9E6jXE8gFLrOVV9lFSJN6MoRWY9mYg9Z a1xNMaSqAHcA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGMKDUM rgAABAMASDBGAiEAykZgWprc6hA/rahTqXrU0jYyJKiceZly6WZGjhcfrwYCIQC4 tG+C8PJCr5QVhOU+MkNqHM2vXvZ/pOkMg8iN4oFzKzANBgkqhkiG9w0BAQsFAAOC AQEAVKPeYIZ6ed64BjO8v2rwOw3H+bDO5gO13MV79FvJrS+7T4Lkw7poUprN9Iv1 VpAgq3g8P6mAKwBgo+zi00eQjYwtP/cdMQ1KiUDdtadCAsjgopsJ/Aucdd41wMV8 wPlVh60+VdrF3xBlxLnVLydUmrnI2PYTfzH1w/b47Jh48ITFRfbnHo0oXI4rUnEA Bi4IhoGJCrSD8TyCHfeQzd1xMnIwB/Q6YAin716C3HlW486AyrlPkpSrag4YSNoW eZUF8fucmRdYFQdOXE2kAVR11YK/uPvGd+b+MyX1RAx7Bd1TFUkdOziIgTMfC9Wb bdUPIa+wZcviKUDRO45Y2Dl8NA== -END CERTIFICATE- subject=CN = stravinsky.debian.org issuer=C = US, O = Let's Encrypt, CN = R3 --- Acceptable client certificate CA names C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian SMTP CA, CN = Debian SMTP CA, emailAddress =hostmas...@puppet.debian.org Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5584 bytes and written 467 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit This TLS version forbids renegotiation. Compression: NONE
Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc
Package: pcscd Version: 2.0.1-1 Severity: normal X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org Hello, When looking at the logs of pcscd, I see the following messages: jan 22 09:47:37 edoras pcscd[1663]: auth.c:125:IsClientAuthorized() Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Process not found jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized() Process 1565 (user: 115) is NOT authorized for action: access_pcsc It seems that GDM is not allowed to talk to pcscd. GDM has the functionality to detect whether there is a smartcard in the reader and then use the gdm-smartcard PAM service instead of the gdm-password one to perform login. I guess that GDM should be whitelisted to allow it to use pcscd? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages pcscd depends on: ii init-system-helpers 1.66 ii libc6 2.37-13 ii libccid [pcsc-ifd-handler] 1.5.5-1 ii libglib2.0-02.78.3-1 ii libpcsclite12.0.1-1 ii libpolkit-gobject-1-0 124-1 ii libsystemd0 255.2-4 ii libudev1255.2-4 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 255.2-4 -- no debconf information
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
Le 12/01/24 à 12:46, Jörg-Volker Peetz a écrit : Hello Laurent, Hello Jörg, Thanks for your reply [...] Concerning the loopback (127.0.0.1/::1) interface, here is the output of the command 'ip ad': 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever I disabled IPv6 on my system (the linux kernel is locally configured and compiled). Ssh has no problems on the loopback device, i.e., For debugging purpose, could you try to re-enable IPv6 in the kernel and check that the lo interface has the ::1 address assign to it and then try again? Kind regards, Laurent Bigonville
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
severity 1059922 important thanks > Dear Laurent Bigonville, Hello Jörg, > with version 2.8.0-7 an EATON UPS connected to a debian computer via > USB was working in standalone mode as expected. The only change in the > config files was in /etc/nut/ups.conf where I added the following lines: > > [Eaton] > driver = usbhid-ups > port = auto > vendorid = 0463 > pollfreq = 30 > > After the upgrade to version 2.8.1-1 the upsd daemon would fail to > start. The output in /var/log/syslog is > > upsd[12132]: not listening on ::1 port 3493 > upsd[12132]: listening on 127.0.0.1 port 3493 > upsd[12132]: no listening interface available > > instead of > > upsd[12553]: listening on 127.0.0.1 port 3493 > upsd[12553]: not listening on ::1 port 3493 > upsd[12553]: Connected to UPS [Eaton]: usbhid-ups-Eaton > upsd[12555]: Startup successful > > for the working version 2.8.0. > Any ideas? Could you please attach the other configuration files here (please check for clear-text passwords)? Do you have the loopback (127.0.0.1/::1) interface properly working? I cannot reproduce this at home where I have also an EATON UPS Kind regards, Laurent Bigonville
Bug#1060378: cups-daemon: apparmor denies net_admin capability
Package: cups-daemon Version: 2.4.7-1 Severity: normal Hello, I see a lot of denials from apparmor regarding net_admin capability: type=AVC msg=audit(1704872737.703:1422): apparmor="DENIED" operation="capable" class="cap" profile="/usr/sbin/cupsd" pid=149384 comm="cupsd" capability=12 capname="net_admin" Not too sure what part requires it, but I guess it should be either allowed or the audit trail should be suppressed Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-daemon depends on: ii adduser3.137 ii bc 1.07.1-3+b1 ii init-system-helpers1.66 ii libavahi-client3 0.8-13+b1 ii libavahi-common3 0.8-13+b1 ii libc6 2.37-13 ii libcups2 2.4.7-1+b1 ii libdbus-1-31.14.10-4 ii libgssapi-krb5-2 1.20.1-5 ii libpam0g 1.5.2-9.1+b1 ii libpaper1 1.1.29 ii libsystemd0255.2-4 ii procps 2:4.0.4-2+b1 ii ssl-cert 1.1.2 ii sysvinit-utils [lsb-base] 3.08-5 Versions of packages cups-daemon recommends: ii avahi-daemon 0.8-13+b1 ii colord1.4.6-5 ii cups-browsed 1.28.17-3+b1 ii ipp-usb 0.9.23-1+b7 Versions of packages cups-daemon suggests: ii cups 2.4.7-1+b1 pn cups-bsd ii cups-client2.4.7-1+b1 ii cups-common2.4.7-1 ii cups-filters 1.28.17-3+b1 pn cups-pdf ii cups-ppdc 2.4.7-1+b1 ii cups-server-common 2.4.7-1 pn foomatic-db-compressed-ppds | foomatic-db ii ghostscript10.02.1~dfsg-2 ii poppler-utils 22.12.0-2+b1 pn smbclient ii udev 255.2-4 -- no debconf information
Bug#1056988: libvirt0: Wrong usage of ${binary:Version}
Source: libvirt Version: 9.9.0-1 Severity: normal Hello, libvirt0 Recommends libvirt-l10n with the version equal to ${binary:Version} But libvirt-l10n is an arch:all package, the version should be equal to ${source:Version} Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1056642: wireshark: Mix of QT5 and QT6 dependencies
Package: wireshark Version: 4.2.0-1 Severity: normal Hello, It seems that the wireshark package has a mix of QT5 and QT6 dependencies: Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.0), libgcrypt20 (>= 1.10.0), libglib2.0-0 (>= 2.75.3), libminizip1, libnl-3-200 (>= 3.2.21), libnl-genl-3-200 (>= 3.2.7), libnl-route-3-200 (>= 3.2.7), libpcap0.8 (>= 1.5.1), libqt6core5compat6 (>= 6.2.1), libqt6core6 (>= 6.4.0), libqt6gui6 (>= 6.4.0), libqt6multimedia6 (>= 6.2.1), libqt6printsupport6 (>= 6.1.2), libqt6widgets6 (>= 6.3.0), libspeexdsp1 (>= 1.2.1), libstdc++6 (>= 13.1), libwireshark17 (>= 4.1.1), libwiretap14 (>= 4.1.0), libwsutil15 (>= 4.1.1rc0), wireshark-common (= 4.2.0-1), libqt5svg5 Recommends: libqt5multimedia5-plugins I guess that both libqt5svg5 and libqt5multimedia5-plugins should be updated to their QT6 counter parts? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireshark depends on: ii libc62.37-12 ii libgcc-s113.2.0-6 ii libgcrypt20 1.10.2-3 ii libglib2.0-0 2.78.1-4 ii libminizip1 1:1.3.dfsg-3 ii libnl-3-200 3.7.0-0.2+b1 ii libnl-genl-3-200 3.7.0-0.2+b1 ii libnl-route-3-2003.7.0-0.2+b1 ii libpcap0.8 1.10.4-4 ii libqt5svg5 5.15.10-2 ii libqt6core5compat6 6.4.2-4 ii libqt6core6 6.4.2+dfsg-19 ii libqt6gui6 6.4.2+dfsg-19 ii libqt6multimedia66.4.2-11 ii libqt6printsupport6 6.4.2+dfsg-19 ii libqt6widgets6 6.4.2+dfsg-19 ii libspeexdsp1 1.2.1-1 ii libstdc++6 13.2.0-6 ii libwireshark17 4.2.0-1 ii libwiretap14 4.2.0-1 ii libwsutil15 4.2.0-1 ii wireshark-common 4.2.0-1 Versions of packages wireshark recommends: ii libqt5multimedia5-plugins 5.15.10-2 wireshark suggests no packages. -- no debconf information
Bug#808940: ITP: terraform -- tool for managing cloud infrastructure
retitle 808940 ITP: opentofu -- tool for managing cloud infrastructure thanks On Thu, 24 Dec 2015 14:08:40 +0100 Daniel Stender wrote: Hello, > * Package name : terraform > Version : 0.6.8 > Upstream Author : Mitchell Hashimoto > * URL : https://terraform.io/ > * License : MPL-2.0 > Programming Lang: Go > Description : tool for managing cloud infrastructure > > Terraform is a tool for launching complex infrastructure like from cloud providers > like AWS or DigitlOcean. Like the other tools from HashiCorp (Vagrant, Packer etc.) > a simple CLI based program which is very easy to use, employing configuration files > for the needed setups. For more info, please see the documentation and quick intro > on the site. > Now that hashicorp has changed the licence of their software BSL, I guess that this RFP should be changed to package opentofu instead? https://opentofu.org/
Bug#1040838: libblockdev: Please build the "tools" and create a -tools package
Source: libblockdev Version: 3.0.1-1 Severity: wishlist Hello, The libblockdev source package contains two "tools" that are currently not built. One for them is "vfat-resize", that looks like an intresting feature to have? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1029095: libselinux: claim /run/setrans directory
On Tue, 17 Jan 2023 17:44:13 +0100 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: Hello Christian, > Libselinux by default, since Debian does not specify DISABLE_SETRANS > at compile time, tries to translate security contexts within non-raw > interfaces, e.g. getfilecon(3). The purpose is to translate MCS/MLS > labels into human readable via mcstransd(8). The translation happens > via communication over the public accessible UNIX socket > /var/run/setrans/.setrans-unix, created by mcstransd(8). mcstransd(8) > however is not installed by default, not a dependency of another > package, nor recommended or suggested by one. Thus mcstransd(8) is > probably not running on many (most?) SELinux enabled systems and > thereby the directory /var/run/setrans is not created. This leaves > the opportunity for (compromised) programs to create it and the UNIX > socket to take control of the security context translation. It might > not be prevented by the SELinux policy since most daemons are allowed > to create entries in /var/run and UNIX socket communication between > daemons is common. As a solution the directory /var/run/setrans > should be created at boot by a trusted party with the default context > according to the loaded policy (e.g. setrans_runtime_t), which no > other daemon than mcstransd(8) should have the permission to create > sockets inside. For example Fedora uses the tmpfiles.d(5) snippet: > > d /run/setrans 0755 root root I'm wondering if that couldn't be done directly by the systemd package instead of the libselinux1, that might avoid us the need to introduce a new libselinux-common package or headache in the (unlikely?) case there a soname change to the libselinux library. Note that we might need to remove the RuntimeDirectory=setrans option in the mcstrans.service to avoid conflict (but that might be for the next debian release) If that's OK for you I'll coordinate with the debian systemd maintainer Kind regards, Laurent
Bug#1037478: ca-certificates-java: Loop in the execution of the trigger
Package: ca-certificates-java Version: 20230103 Severity: serious Hello, While updating today, I got the following error: dpkg: boucle détectée durant le traitement des actions différées : listes des paquets qui en sont responsables (normalement) : ca-certificates-java -> ca-certificates-java paquets bloqués par le traitement impossible d'actions différées requises : ca-certificates-java: update-ca-certificates-java: /usr/lib/jvm libc-bin: ldconfig dictionaries-common: aspell-autobuildhash There seems to be a loop in the trigger execution Kind regards Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages ca-certificates-java depends on: ii ca-certificates 20230311 ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.19+7-1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- Configuration Files: /etc/default/cacerts [Errno 13] Permission non accordée: '/etc/default/cacerts' -- no debconf information
Bug#1035076: plymouth: Plymouth package has defective hard-dependency on systemd
Le 29/04/23 à 15:37, Faulk Johnny a écrit : I am not saying to remove the systemd dependency. I am saying that changing "systemd," to "systemd | elogind" under the control section for the plymouth package in particular, NOT the build dependencies, thus allowing installation on (and forcing a dependency on) either one of them. Those who use a no-systemd system know full well there is a risk, seeing as it's a pretty deliberate act to begin with in Debian. Changing it as described above would have no affect at all on systemd systems, as it would still pull in systemd and enforce that need. Please reconsider this course of action. The fact that plymouth package is depending on systemd has nothing to do with the fact that it requires (e)logind (it actually doesn't, plymouth runs at early boot and has nothing to do with a user session). As said the dependency is needed because plymouth requires some udev rules (namely /usr/lib/udev/rules.d/71-seat.rules) and tags to properly detect the framebuffer/drm devices. So as long at the rules file is shipped, in systemd package, plymouth will have that dependency. On Sat, Apr 29, 2023 at 6:25 AM, Laurent Bigonville Like explained in bug #1035076, the fact that systemd is pulled by the plymouth package doesn't mean you cannot use it with an other initsystem on debian, the package that actually changes the default initsystem is "systemd-sysv", not "systemd" Removing the dependency might break plymouth at it requires some udev rules files that are shipped by the systemd package (the rules are used to tag the framebuffer devices/heads installed on the machines). So removing that could break some setup Kind regards, Laurent Bigonville
Bug#1035076: plymouth: Plymouth package has defective hard-dependency on systemd
tag 1035076 + wontfix thanks Le 29/04/23 à 00:10, john faulk a écrit : Dear Maintainer, Hello, The Plymouth Package has a hard-dependency on systemd for installation. This should not be the case, seeing as there are initscripts present for it. I have tested a simple fix where elogind is added in the source control file as an alternative to systemd's dependency, and it has worked every time I have tried it. This will allow non-systemd users to use plymouth, and is a very simple fix. Like explained in bug #1035076, the fact that systemd is pulled by the plymouth package doesn't mean you cannot use it with an other initsystem on debian, the package that actually changes the default initsystem is "systemd-sysv", not "systemd" Removing the dependency might break plymouth at it requires some udev rules files that are shipped by the systemd package (the rules are used to tag the framebuffer devices/heads installed on the machines). So removing that could break some setup Kind regards, Laurent Bigonville
Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog
On Sun, 12 Feb 2023 09:06:02 -0500 Alexis wrote: [...] > > > * What was the outcome of this action? > > The following error was thrown: > > Gtk-WARNING **: 08:47:30.475: Error acquiring permission: Failed to acquire permission for action-id org.opensuse.cupspkhelper.mechanism.all-edit Do you have the cups-pk-helper package installed? system-config-printer-common already recommends that package. The definition of Recommends is: "This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations.", so you should probably also install recommended packages. Kind regards, Laurent Bigonville
Bug#1034223: powerman: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
severity 1034223 important thanks On Tue, 11 Apr 2023 16:42:32 +0200 Andreas Henriksson wrote: > Hello Laurent Bigonville, > > On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > > Package: powerman > > Version: 2.3.27-2 > > Severity: serious > > Tags: sid bookworm > > User: debhel...@packages.debian.org > > Usertags: systemd-files-in-usr-bookworm > > > > Dear Maintainer, > > > > It seems that your package powerman is shipping files (.service, .socket or > > .timer) in /usr/lib/systemd/system. > > > > This is not supported by the version of dh_installsystemd/debhelper currently > > in unstable and bookworm (See: #1031695). That means that currently your > > service might not be enabled at boot and/or started as expected. > [...] > > Note that debian/rules has: > > ``` > override_dh_installinit: > dh_installinit --no-start --no-enable > > override_dh_installsystemd: > dh_installsystemd --no-start --no-enable > ``` > > So do you agree that the severity of this bug report should be downgraded > (maybe even closed)? I think severity can be downgraded (to "important"?), this is still a problem as systemctl daemon-reload is not called, but at least there will be surprise after a reboot.
Bug#1034340: ltunify: 0.3-1
Package: ltunify Version: 0.3-1 Severity: normal Hello, The udev rules file starts with the following: # skip actual unified devices, only consider the receiver DRIVERS=="logitech-djdevice", GOTO="not_unify_recv" For what I understand only the permissions of reciver should be modified But for what I can see, the permissions of the hidraw device of my mouse are also modified: $ ls -la /dev/hidraw* [...] crw-rw+ 1 root root 248, 3 13 avr 10:15 /dev/hidraw3 crw-rw+ 1 root root 248, 4 13 avr 10:15 /dev/hidraw4 [259919.846547] logitech-djreceiver 0003:046D:C52B.0034: hiddev0,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-1.1.4/input2 [259919.976009] logitech-hidpp-device 0003:046D:101A.0035: input,hidraw4: USB HID v1.11 Mouse [Logitech Performance MX] on usb-:00:14.0-1.1.4/input2:2 So that doesn't seem to be right. When running udevadm info on the two devices, I don't see the driver being displayed, so I think that the matching based on the driver is not working. Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1034337: ltunify: udev not triggered after installation
Package: ltunify Version: 0.3-1 Severity: normal Hello, It seems that the package is installing a udev rules file, but udev is not (re)triggered after installation. You should probably add something like that (to be tested) in the postinst script: udevadm control --reload || true udevadm trigger --subsystem-match=hidraw --action=change || true Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1034055: fwknop-apparmor-profile: AppArmor profile installed in systemd system service path
Le 7/04/23 à 20:19, Francois Marier a écrit : On 2023-04-07 at 07:23:07, Laurent Bigonville (bi...@debian.org) wrote: It seems that you install the apparmor profile in the path for systemd system service The following change should be reverted: https://salsa.debian.org/debian/fwknop/-/commit/d3a5aaef39fedc1bb94e26921afbf63f79b31af7 Hm, that does look like a mistake. I don't remember what might have caused me to make that change. I guess the apparmor profile hasn't been in use for a while then. It seems like it's too late in the release process to re-add it in bookworm. Here's what I'm thinking of doing: - move it to /usr/share/apparmor/extra-profiles/ (so it's not turned on by default) for bookworm - move it back to /etc/apparmor.d/ after bookworm Alternatively, I could also not change anything for bookworm since it's not enabled as an AppArmor profile and it will be ignored as a systemd unit file. What do you think? Sorry for the late answer. I see that you moved the file to /usr/share/apparmor/extra-profiles/, for now it's OK I guess, might be indeed be too late to enable the profile so late in the development cycle An other option for bookworm+1 is to move the file back to /etc/apparmor.d/ AND merge the profile back in the main package so it's installed along side the daemon and kill fwknop-apparmor-profile (that package only ships one file AFAICS) Apparmor profile can be put in complain/non-enforcing mode if the user really wants to.
Bug#1034249: pvpgn: Do not exit the postinst script early if not in "configure" state
Package: pvpgn Version: 1.8.5-3 Severity: important Hello, Currently the postinst maintainer script exits early if it is not run in "configure" mode: # # Skip, if we are not in "configure" state # if [ "$1" != "configure" ]; then echo "I: Skipping configuration" exit 0 fi DIRS="bak/charinfo bak/charsave bnmail chanlogs charinfo charsave ladders reports status teams users" for DIR in $DIRS; do mkdir -p /var/lib/pvpgn/$DIR done INMHO, this is not good as debhelper snippets might not be properly executed (ie. the ones from dh_installsystemd or dh_installinit) The script should be changed to something like: DIRS="bak/charinfo bak/charsave bnmail chanlogs charinfo charsave ladders reports status teams users" if [ "$1" = "configure" ]; then for DIR in $DIRS; do mkdir -p /var/lib/pvpgn/$DIR done fi Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pvpgn depends on: ii libc6 2.36-9 pn libcdb1 pn libmariadb3 pn libpq5 ii libsqlite3-0 3.40.1-2 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages pvpgn recommends: pn tinycdb ii wget 1.21.3-1+b2 Versions of packages pvpgn suggests: pn default-mysql-server | virtual-mysql-server pn fortune
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
FTR, I opened RC bugs against all the impacted packages so they will hopefully be fixed for bookworm See: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debhelper%40packages.debian.org&tag=systemd-files-in-usr-bookworm
Bug#1034055: fwknop-apparmor-profile: AppArmor profile installed in systemd system service path
Package: fwknop-apparmor-profile Version: 2.6.10-13 Severity: serious Hello It seems that you install the apparmor profile in the path for systemd system service The following change should be reverted: https://salsa.debian.org/debian/fwknop/-/commit/d3a5aaef39fedc1bb94e26921afbf63f79b31af7 Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwknop-apparmor-profile depends on: pn fwknop-server fwknop-apparmor-profile recommends no packages. fwknop-apparmor-profile suggests no packages.
Bug#1033999: webkit2gtk: FTBFS on hurd-i386 (disable GBM support)
Source: webkit2gtk Version: 2.39.1-1 Severity: important Tags: ftbfs Hello, It seems that webkit FTBFS again on hurd-i386 The issue seems to be the fact that libgbm is missing: -- Could NOT find GBM (missing: GBM_LIBRARIES GBM_INCLUDE_DIR) CMake Error at Source/cmake/OptionsGTK.cmake:403 (message): GBM is required for USE_GBM I guess that should be disabled on that arch? Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1033045: librest-dev: Missing dependencies
Package: librest-dev Version: 0.9.1-4 Severity: serious Hello, It seems that librest-dev and librest-extras-dev are missing dependencies that are declared in the .pc files, like libjson-gib-dev and others. That should probably be fixed Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages librest-dev depends on: ii gir1.2-rest-1.0 0.9.1-4 ii librest-1.0-00.9.1-4 pn libsoup-3.0-dev ii libxml2-dev 2.9.14+dfsg-1.1+b3 librest-dev recommends no packages. librest-dev suggests no packages.
Bug#1032183: libgusb-dev: missing dependency on libjson-glib-1.0-dev
On Wed, 1 Mar 2023 11:06:21 + Simon McVittie wrote: > Control: tags -1 + patch > > On Wed, 01 Mar 2023 at 10:52:44 +, Simon McVittie wrote: > > I'll send the obvious patch when I have a bug number. > > Attached, or available from > https://salsa.debian.org/efi-team/libgusb/-/merge_requests/6 Hello, Independently of whether the package should migrate to testing/bookworm now, could this bug be fixed? I think the necessary patches are in git, is it possible to upload? Kind regards, Laurent Bigonville
Bug#1032510: packagekit: pkcon what-provides application/x-keepass2 makes PK crash
Package: packagekit Version: 1.2.6-3 Severity: serious Hello, pkcon what-provides application/x-keepass2 makes PK crash: $ pkcon what-provides application/x-keepass2 Getting provides[=] Loading cache [=] Querying[=] e daemon crashed mid-transaction! Finished[ ] (0%) Stack trace of thread 10447: #0 0x7faf3ef75ccc __pthread_kill_implementation (libc.so.6 + 0x8accc) #1 0x7faf3ef26ef2 __GI_raise (libc.so.6 + 0x3bef2) #2 0x7faf3ef11472 __GI_abort (libc.so.6 + 0x26472) #3 0x7faf3c89d919 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9d919) #4 0x7faf3c8a8e1a _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xa8e1a) #5 0x7faf3c8a8e85 _ZSt9terminatev (libstdc++.so.6 + 0xa8e85) #6 0x7faf3c8a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8) #7 0x7faf3c8a00e4 _ZSt19__throw_logic_errorPKc (libstdc++.so.6 + 0xa00e4) #8 0x7faf3e96cb3a _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC4IS3_EEPKcRKS3_ (libpk_backend_apt.so + 0x2cb3a) #9 0x7faf3e95d122 backend_what_provides_thread (libpk_backend_apt.so + 0x1d122) #10 0x5644cb0c7aca pk_backend_job_thread_setup (packagekitd + 0x23aca) #11 0x7faf3f5dbcfd g_thread_proxy (libglib-2.0.so.0 + 0x7ecfd) #12 0x7faf3ef73fd4 start_thread (libc.so.6 + 0x88fd4) #13 0x7faf3eff466c __clone3 (libc.so.6 + 0x10966c) This breaks GNOME ability to suggest which application to install when opening files. Feel free to downgrade the severity if you want. Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages packagekit depends on: ii init-system-helpers 1.65.2 ii libappstream4 0.16.1-1 ii libapt-pkg6.0 2.6.0 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-1 ii libglib2.0-bin 2.74.6-1 ii libgstreamer1.0-0 1.22.0-2 ii libpackagekit-glib2-18 1.2.6-3 ii libpolkit-gobject-1-0 122-3 ii libsqlite3-03.40.1-1 ii libstdc++6 12.2.0-14 ii libsystemd0 252.6-1 ii polkitd 122-3 Versions of packages packagekit recommends: ii packagekit-tools 1.2.6-3 ii systemd 252.6-1 Versions of packages packagekit suggests: ii appstream 0.16.1-1 -- no debconf information
Bug#1032406: /usr/bin/xgpsspeed: TypeError: 'km/h' is not a valid speed unit
Package: gpsd-clients Version: 3.22-4.1+b1 Severity: normal File: /usr/bin/xgpsspeed Hello, When running xgpsspeed on my machine, I get the following trace: Traceback (most recent call last): File "/usr/bin/xgpsspeed", line 1015, in Main( File "/usr/bin/xgpsspeed", line 652, in __init__ self.widget = NauticalSpeedometer( File "/usr/bin/xgpsspeed", line 305, in __init__ Speedometer.__init__(self, speed_unit) File "/usr/bin/xgpsspeed", line 87, in __init__ raise TypeError( TypeError: 'km/h' is not a valid speed unit Explicitly setting the speed unit with --speedunits kmh fixes the issue There seems to be an incompatibility between what's used in xgpsspeed and gps/clienthelpers.py Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages gpsd-clients depends on: ii gir1.2-gtk-3.0 3.24.36-4 ii gpsd-tools 3.22-4.1+b1 ii libbluetooth3 5.66-1 ii libc6 2.36-8 ii libdbus-1-3 1.14.6-1 ii libgps283.22-4.1+b1 ii libusb-1.0-02:1.0.26-1 ii python3 3.11.2-1 ii python3-cairo 1.20.1-5+b1 ii python3-gi 3.42.2-3+b1 ii python3-gi-cairo3.42.2-3+b1 ii python3-gps 3.22-4.1+b1 ii python3-matplotlib 3.6.3-1+b1 ii python3-serial 3.5-1.1 gpsd-clients recommends no packages. Versions of packages gpsd-clients suggests: ii gpsd 3.22-4.1+b1 -- no debconf information
Bug#1031506: darktable: Please adjust the architectures on which darktable is built
Source: darktable Version: 4.2.0-2 Severity: normal Hello, On x32 architecture, darktable FTBFS with the following error: 71 | #error "Unfortunately we only work on the 64-bit architectures amd64, ARMv8-A, PPC64 and riscv64." ATM, I see that ppc64 and riscv64 are not listed in the package architectures list. These should maybe be added. On the other side, x32 should maybe be removed Kr, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017736: auditd: noise service shutdown of dispatcher plugins
On Fri, 19 Aug 2022 19:42:50 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: > From upstream report: https://github.com/linux-audit/audit-userspace/issues/272 > As mentioned in the upstream bug, I think that this should also be set upstream as on shutdown/reboot, systemd WILL stop auditd too I'm not sure that should be applied to debian only
Bug#1029760: evince: AppArmor prevents opening PDF files stored on Google drive
Package: evince Version: 43.1-2+b1 Severity: important Hello, It seems that the AppArmor profile is not allowing evince to read file accessed via the GVFS on Google drive (and probably other integrations) I get the following denials: type=AVC msg=audit(1674751821.962:528): apparmor="DENIED" operation="open" profile="/usr/bin/evince" name="/run/user/1000/gvfs/google-drive:host=example.com,user=foo/" pid=11026 comm="EvJobScheduler" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000FSUID="bigon" OUID="bigon" Adding the following rule is allowing me to read my files, but I'm not sure that enough or consistant with the other rules (shouldn't write access be allowed too?): /{,var/}run/user/*/gvfs/** r, Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evince depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii evince-common43.1-2 ii gsettings-desktop-schemas43.0-1 ii libatk1.0-0 2.46.0-4 ii libc62.36-8 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libevdocument3-4 43.1-2+b1 ii libevview3-3 43.1-2+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.5-1 ii libgnome-desktop-3-2043.1-1 ii libgtk-3-0 3.24.36-2 ii libhandy-1-0 1.8.0-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libsecret-1-00.20.5-3 ii shared-mime-info 2.2-1 Versions of packages evince recommends: ii dbus-user-session [default-dbus-session-bus] 1.14.4-1 Versions of packages evince suggests: ii gvfs 1.50.3-1 pn nautilus-sendto ii poppler-data 0.4.11-1 pn unrar -- no debconf information
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Package: grub-common Version: 2.06-7 Severity: serious File: /usr/sbin/grub-probe Hello, On a newly installed laptop, it seems that grub-probe is not able to detect that files are on an encrypted FS. New laptop: $ sudo grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png lvm $ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:00 476,9G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 488M 0 part /boot └─nvme0n1p3 259:30 476G 0 part └─nvme0n1p3_crypt 254:00 475,9G 0 crypt ├─new_laptop--vg-root254:10 27,9G 0 lvm / ├─new_laptop--vg-swap_1 254:20 976M 0 lvm [SWAP] ├─new_laptop--vg-home254:3040G 0 lvm /home └─new_laptop--vg-libvirt 254:4060G 0 lvm /var/lib/libvirt Old laptop: $ sudo grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png cryptodisk luks gcry_rijndael gcry_rijndael gcry_sha256 lvm $ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda8:01 0B 0 disk nvme0n1 259:00 476,9G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 244M 0 part /boot └─nvme0n1p3 259:30 476,2G 0 part └─nvme0n1p3_crypt 254:00 476,2G 0 crypt ├─old_laptop--vg-root254:10 27,9G 0 lvm / ├─old_laptop--vg-swap_1 254:20 31,7G 0 lvm [SWAP] ├─old_laptop--vg-home254:30 120G 0 lvm /home ├─old_laptop--vg-sid_amd64_sbuild254:40 5G 0 lvm ├─old_laptop--vg-flatpak 254:5050G 0 lvm /var/lib/flatpak ├─old_laptop--vg-libvirt 254:6075G 0 lvm /var/lib/libvirt ├─old_laptop--vg-docker 254:7010G 0 lvm /var/lib/docker ├─old_laptop--vg-acng254:8010G 0 lvm /var/cache/apt-cacher-ng └─old_laptop--vg-buster_amd64_sbuild 254:90 5G 0 lvm Setting this as serious as this seems to be a regression, this at least breaks grub ability to display the theme wallpaper. Kind regards, Laurent Bigonville
Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot
On Mon, 3 Oct 2022 21:48:42 +0100 Steve McIntyre wrote: > On Mon, Oct 03, 2022 at 09:22:02PM +0200, Vincent Bernat wrote: > > > >shim-unsigned has been updated to 15.6 which has the right patches in. But > >for some reason, shim-signed is still at 15.4. > > We've had problems in submitting shim 15.6 to Microsoft for > signing. We're working on a solution, but it's going to take a little > longer yet. Hello Steven, Sorry to insist (again), but do you have any news about this? We are slowly approaching the freeze for bookworm and having a fix for this looks quite important to me. Kind regards, Laurent Bigonville
Bug#1023530: nut: flaky autopkgtest: varying failures
On Sun, 6 Nov 2022 07:30:38 +0100 Paul Gevers wrote: > Dear maintainer(s), Hello Paul > I looked at the results of the autopkgtest of your package. I noticed > that it regularly fails (after the fix for bug #1019221). > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. It's impossible for me to reproduce this locally, can you still see that in the CI runs? For me this looks like a race condition, the test code already waits for 2 sec after the start of the nut daemon an drivers to be certain that everything is properly started. I can increase that sleep, but that's probably not the best solution. An other solution is to have a loop checking that the (dummy) driver is really connected, but I need to investigate how and I've no time ATM. Last solution could be to ask the release team to tag this bug as "bookworm-ignore" so it can be part of the upcoming release and try to fix this for the next one. WDYT? Kind regards, Laurent Bigonville
Bug#828903: auditd embeds a copy of libev
Hello, Le 15/12/22 à 17:08, Bastian Germann a écrit : On Tue, 28 Jun 2016 22:28:07 +0200 Nicolas Braud-Santoni wrote: The audit source package ships a (custom, patched) copy of libev. Moreover, it is not listed in the security team's list of code copies: https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup I discovered the issue while preparing a DEP5 copyright file for the audit source package, and more generally fixing all Lintian warnings while preparing a patch for #759604. I think this is an important issue and have included a patch. Would you please consider to apply this before the bookworm freeze? Do you think you could bring that upstream? Not sure we want to carry this patch forever
Bug#1024693: firefox: back/forward 2 fingers gesture not working
Package: firefox Version: 107.0-1 Severity: normal Hello, Since a few versions, firefox is supposed to support the back/forward 2 fingers gesture on wayland. This is working on my fedora work laptop and it's supposed to work on ubuntu as well, but not on my debian laptop https://www.omglinux.com/firefox-two-finger-swipe-back-coming-soon/ Not sure what's happening here Kind regards, Laurent Bigonville -- Package-specific info: -- Addons package information -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages firefox depends on: ii debianutils 5.7-0.4 ii fontconfig 2.13.1-4.5 ii libasound2 1.2.7.2-1 ii libatk1.0-0 2.46.0-4 ii libc62.36-5 ii libcairo-gobject21.16.0-6 ii libcairo21.16.0-6 ii libdbus-1-3 1.14.4-1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libffi8 3.4.4-1 ii libfontconfig1 2.13.1-4.5 ii libfreetype6 2.12.1+dfsg-3 ii libgcc-s112.2.0-9 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libglib2.0-0 2.74.1-2 ii libgtk-3-0 3.24.34-5 ii libnspr4 2:4.35-1 ii libnss3 2:3.85-1 ii libpango-1.0-0 1.50.10+ds-1 ii libstdc++6 12.2.0-9 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.1-2 ii libx11-xcb1 2:1.8.1-2 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:3.3.17-7.1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages firefox recommends: ii libavcodec58 7:4.4.2-1+b3 ii libavcodec59 7:5.1.2-1 Versions of packages firefox suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.20.1-1 pn pulseaudio -- no debconf information
Bug#1019624: UPSONIC IRT-3K 2U broken by length checking in blazer_usb/nutdrv_qx
On Tue, 13 Sep 2022 10:19:24 +1000 "Trent W. Buck" wrote: Hello, > > Short version: > > 1. UPSONIC IRT-3K 2U speaks a variant of Q1 which omits final \r. > 2. nut 2.4 doesn't check for final \r, so it Just Works. > 3. nut 2.7 checks for final \r, cannot talk to my UPS. > 4. I fixed #3 but it's not very good. Do you think you could check whether nut 2.8.0 (currently in unstable) works with your UPS? Otherwise if the bug is still happening, could you please open a bug upstream if it's not already done? Kind regards, Laurent Bigonville
Bug#958036: nut-snmp: SNMPv3 with privacy method "AES" fails to communicate with UPS
On Fri, 17 Apr 2020 12:32:15 -0400 Wilfried Teiken wrote: > > Dear Maintainer, Hello Wilfried, > > when configuring SNMP as v3 with privacy enabled and "privProtocol = AES" in > /etc/nut/ups.conf for the UPS then the communication with the UPS will fail. > > The sympton is that on startup the driver will report: > - "Unknown mibs value: apcc" (with "mibs = apcc") > - "No supported device detected" (with "mibs = auto" > > Communication with "privProtocol = DES" works if the SNMP endpoint is configured > accordingly, so this only affects the "AES" setting. > > The underlying root cause is a length issue for the 'usmAESPrivProtocol' > oid value, causing the wrong privacy string being passed into the net-snmp > library caused by a #define that is leading to a sizeof() with a pointer > instead of the oid array. > > See attached patch for a fix. Could you please tell me if you are still experiencing this issue with the version 2.8.0 that is currently in debian unstable? I can see that the code to detect usmAESPrivProtocol/usmAES128PrivProtocol availability has changed. Also, in the build logs of version 2.7.14, I can see the compiler complain about the size of these types, while this warning is not present in version 2.8.0 I think that this is now fixed. Could you please confirm? Kind regards, Laurent Bigonville
Bug#1021384: ITP: low-memory-monitor -- Monitors low-memory conditions
Package: wnpp Severity: wishlist Owner: Laurent Bigonville X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: low-memory-monitor Version : 2.1 Upstream Author : Bastien Nocera * URL : https://gitlab.freedesktop.org/hadess/low-memory-monitor * License : GPL-3+ Programming Lang: C Description : Monitors low-memory conditions The Low Memory Monitor is an early boot daemon that will monitor memory pressure information coming from the kernel, and, first, send a signal to user-space applications when memory is running low, and then optionally activate the kernel's OOM killer when memory is running really low.
Bug#1021160: simple-scan: Please bump libhandy-1-dev build-dependency
Source: simple-scan Version: 42.0-1 Severity: important Hello, Currently, simple-scan package defines a build-dependency against libhandy-1-dev (>= 1.1.90), but the meson files requires libhandy-1-dev >= 1.6.0 libhandy-1-dev >= 1.6.0 is not available on on all architectures and it's probably a good idea to update the debian/control file and bump the version of the libhandy-1-dev build-dependency. Kind regards, Laurent Bigonville -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1021040: tlog: FTBFS on non-linux architectures
Source: tlog Version: 12.1-1 Severity: important Tags: ftbfs patch Justification: fails to build from source (but built successfully in the past) Hello, tlog FTBFS on non-linux architectures because it tries to build systemd/journald support Disable journald support on non-linux architecture should fix this Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -Nru tlog-12.1/debian/control tlog-12.1/debian/control --- tlog-12.1/debian/control2022-05-19 16:23:08.0 +0200 +++ tlog-12.1/debian/control2022-09-30 22:57:22.0 +0200 @@ -6,7 +6,7 @@ debhelper-compat (= 12), libcurl4-gnutls-dev, libjson-c-dev, - libsystemd-dev, + libsystemd-dev [linux-any], libutempter-dev, pkg-config, Rules-Requires-Root: no diff -Nru tlog-12.1/debian/rules tlog-12.1/debian/rules --- tlog-12.1/debian/rules 2022-05-19 16:23:08.0 +0200 +++ tlog-12.1/debian/rules 2022-09-30 22:57:22.0 +0200 @@ -8,12 +8,16 @@ DPKG_EXPORT_BUILDFLAGS = 1 -include /usr/share/dpkg/buildflags.mk +ifneq ($(DEB_HOST_ARCH_OS),linux) +DISABLE_JOURNAL:=--disable-journal +endif + %: dh $@ override_dh_auto_configure: dh_auto_configure -- \ - --enable-utempter + --enable-utempter $(DISABLE_JOURNAL) override_dh_auto_install: # dh_install -p libtlog0 lib/tlog/.libs/libtlog.so.0.0.0 usr/lib/$(DEB_HOST_MULTIARCH)/
Bug#978650: podman: please provide a default container registry for looking up short image names
Hello, Sorry for coming back to the topic here, but I (still) personally think that defining "unqualified-search-registries" with sensible default (dockerhub and quay.io?) is a better solution. For what I understand, the two arguments here against are 1) it's not up-to debian to choose the registries for the users 2) there are security concerns about using random images. IMVHO, it's still the role of a distribution to provide sensible defaults to their users (lot/all packages are already doing so today in the distribution). The fact that the package is adding that shortnames.conf file (with a selected subset of images) is actually forcing our users to use images (and not just repositories). With unqualified-search-registries set, podman WILL ask the user from where they want to pull the image from (currently nothing is asked), this would actually allow the user to have MORE control and clarity over the repository they uses. I also not sure what would happen if the package maintainer would change the content of that file to point to an other repository (let's say because of a dispute), the user would start pulling an image they are not expecting? With setting "unqualified-search-registries", the choice of the user is preserved. To that, I would also add that, AFAICS, debian is breaking expectation for users coming from other distributions here. So would it be possible to reconsider the solution here? Kind regards, Laurent Bigonville
Bug#1017372: #1017372 plymouth: reproducible builds: year and week embedded in .pc files
Le 22/09/22 à 21:02, Holger Levsen a écrit : hi Laurent, Hello Holger, what do you think of the proposed patch? for your convinience: (see https://bugs.debian.org/1017372 for more explainations but this is the diff) Subject: [PATCH] configure.ac: Avoid embedding the date in the version. Use the version from the last debian/changelog entry, otherwise the build will differ if built on a different year and week and from git builds vs. builds from source tarball. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 6e00c0c..0de1856 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_INIT([plymouth], -m4_esyscmd_s([date +%y.%V.$(git rev-list $(git describe --abbrev=0)..HEAD --count) || echo 0]), +m4_esyscmd_s([dpkg-parsechangelog --show-field Version]), Thanks for the patch. I've modified the command line to 'dpkg-parsechangelog --show-field Version | sed -e 's/-[^-]*$//' | sed -e 's/^[0-9]*://'' to drop the epoch and debian revision from the version, and only keep the upstream one. (inspired from /usr/share/dpkg/pkg-info.mk) I also opened a bug upstream: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/188 Kind regards, Laurent Bigonville
Bug#1020386: mesa: FTBFS on x32
Source: mesa Version: 21.0.0-1 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, mesa currently FTBFS on x32, with the following errors: dh_install -a dh_install: warning: Cannot find (any matches for) "usr/share/drirc.d/00-radv-defaults.conf" (tried in ., debian/tmp) dh_install: warning: mesa-vulkan-drivers missing files: usr/share/drirc.d/00-radv-defaults.conf dh_install: error: missing files, aborting make[1]: *** [debian/rules:228: override_dh_install] Error 25 That's probably happening because the amd vulkan driver is not built Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1017498: Plymouth Alternative Package Without Systemd Dependency
closes 1017498 severity 1017498 wishlist tags 1017498 + wontfix thanks On Wed, 17 Aug 2022 04:31:05 +0200 (CEST) truetec...@tutanota.com wrote: > When manually setting up an alternative init system such as OpenRC in Debian, the Plymouth boot splash cannot be used as the plymouth package has a hard dependency on SystemD. However, Plymouth can be configured to work without it either way as seen in Devuan. > > It might be that this requires a change in how the package is compiled, though I am not knowledgeable on the subject. However, seeing as other packages such as DBus are provided with separate non-Systemd variants, so there is precedent for that. > > I know that Systemd is the only officially supported init on Debian, but would it be possible to make this package usable on all systems? Aside from the eye-candy, it can make entering encryption passwords more legible. The fact that systemd is pulled by the plymouth package doesn't mean you cannot use it with an other initsystem on debian, the package that actually changes the default initsystem is "systemd-sysv", not "systemd" Removing the dependency might break plymouth at it requires some udev rules files that are shipped by the systemd package (the rules are used to tag the framebuffer devices/heads installed on the machines). I'm not planning to put extra work for this here.
Bug#1013630: cmake does not properly detect x32 architecture with nasm/yasm
Package: cmake Version: 3.23.2-1 Severity: important Tags: upstream Hello, Currently svt-av1 FTBFS on x32 with the following errror: [ 11%] Building ASM_NASM object Source/Lib/Common/ASM_SSE2/CMakeFiles/COMMON_ASM_SSE2.dir/intrapred_sse2.asm.o cd /<>/obj-x86_64-linux-gnux32/Source/Lib/Common/ASM_SSE2 && /usr/bin/yasm -DARCH_X86_64=1 -DEN_AVX512_SUPPORT=0 -DEXCLUDE_HASH=0 -DREPRODUCIBLE_BUILDS=1 -DSAFECLIB_STR_NULL_SLACK=1 -D_FORTIFY_SOURCE=2 -I/<>/. -I/<>/Source/API -I/<>/Source/Lib/Common/Codec -I/<>/Source/Lib/Common/C_DEFAULT -I/<>/Source/Lib/Common/ASM_SSE2 -DUNIX64 -f elf -o CMakeFiles/COMMON_ASM_SSE2.dir/intrapred_sse2.asm.o /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:57: warning: `rcx' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:57: error: undefined symbol `rcx' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:57: error: (Each undefined symbol is reported only once.) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:58: warning: `rdx' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:58: error: undefined symbol `rdx' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:66: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:66: error: undefined symbol `rdi' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:67: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:67: warning: `rsi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:67: error: undefined symbol `rsi' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:68: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:68: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:68: warning: `rsi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:69: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:70: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:70: warning: `rsi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:81: warning: `rcx' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:87: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:88: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:88: warning: `rsi' is a register in 64-bit mode [...] As you can see, yasm is called with "-f elf" and not "-f elfx32" That should be fixed upstream Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages cmake depends on: ii cmake-data3.23.2-1 ii libarchive13 3.6.0-1 ii libc6 2.33-7 ii libcurl4 7.83.1-2 ii libexpat1 2.4.8-1 ii libgcc-s1 12.1.0-4 ii libjsoncpp25 1.9.5-4 ii librhash0 1.4.3-1 ii libstdc++612.1.0-4 ii libuv11.44.1-2 ii procps2:3.3.17-7+b1 ii zlib1g1:1.2.11.dfsg-4 Versions of packages cmake recommends: ii gcc 4:11.2.0-2 ii make 4.3-4.1 Versions of packages cmake suggests: pn cmake-doc pn cmake-format ii ninja-build 1.11.0-1 -- no debconf information
Bug#1011726: switcheroo-control: FTBFS: AssertionError: 0 != 1
severity 1011726 important thanks On Thu, 26 May 2022 08:13:24 +0200 Lucas Nussbaum wrote: > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Hello, I cannot reproduce this on my laptop, not sure what happened I'll reduce the severity to important so the package is not removed from unstable for now Kind regards, Laurent Bigonville
Bug#1011159: qbs: FTBFS on hppa: '/usr/lib/qt5/bin/qdoc': No such file or directory
On Tue, 17 May 2022 17:54:50 + John David Anglin wrote: > Source: qbs > Version: 1.22.1-2 > Severity: normal > [...] > qdoc-qt5 is no longer built on hppa because it requires clang. > > If there is no way to work around this issue, maybe add qdoc-qt5 to > package dependencies. I guess an other option would be to disable the documentation generation when building arch:any packages as I think all the doc is installed in arch:all ones?
Bug#1013097: openh264: FTBFS on x32
On Fri, 17 Jun 2022 11:14:29 +0200 Bastian Germann wrote: > Control: reopen -1 > > The patch in https://github.com/cisco/openh264/issues/3545 does not affect the FTBFS. With ARCH=x32 set, the package builds fine locally
Bug#1013097: openh264: FTBFS on x32
_copy.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/mc_chroma.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/mc_luma.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/satd_sad.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/vaa.o' is incompatible with i386:x64-32 output Here again there is a proble when calling nasm with the "-f elf64" flag: nasm -DUNIX64 -DHAVE_AVX2 -f elf64 -I./codec/common/x86/ -o codec/encoder/core/x86/coeff.o codec/encoder/core/x86/coeff.asm It should be "-f elfx32" here With these two changes, the build is suceeding on x32 architecture This has been forwarded upstream: https://github.com/cisco/openh264/issues/3545 Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012743: opencv: FTBFS on hppa (missing viz module)
Source: opencv Version: 4.5.4+dfsg-9 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, opencv FTBFS on hppa because it seems that the viz module is not enabled during the build dh_install -a dh_install: warning: Cannot find (any matches for) "usr/include/opencv4/opencv2/viz.hpp" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/include/opencv4/opencv2/viz.hpp dh_install: warning: Cannot find (any matches for) "usr/include/opencv4/opencv2/viz/*" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/include/opencv4/opencv2/viz/* dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.a" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/lib/*/libopencv_viz.a dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.so" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/lib/*/libopencv_viz.so dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.so.*" (tried in ., debian/tmp) dh_install: warning: libopencv-viz4.5d missing files: usr/lib/*/libopencv_viz.so.* dh_install: error: missing files, aborting https://buildd.debian.org/status/fetch.php?pkg=opencv&arch=hppa&ver=4.5.4%2Bdfsg-9%2Bb7&stamp=1655076922&raw=0 I see that some build-dependencies are not installed on hppa (and others) architectures. Maybe the libopencv-viz* packages should not be built on these? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012523: gnuplot: Please review the build-dependencies
Source: gnuplot Version: 5.4.2+dfsg2-2 Severity: normal Hello, gnuplot is not building on some ports due to the build-dependencies against some Qt libraries (mainly QtWebkit), but looking in the code it seems that some of these are not needed anymore (removing these BD results in the same binary packages) In the configure I see: PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network Qt5Svg Qt5PrintSupport]) So AFAICS, at least libqt5webkit5-dev and libqt5opengl5-dev are not needed anymore Could you please check? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012518: python3-distutils: CFLAGS and CPPFLAGS leaking in LD flags
Package: python3-distutils Version: 3.9.12-1 Severity: important Hello, When trying to build matplotlib (that uses hardening +pie) on x32, -specs=/usr/share/dpkg/pie-compile.specs ends up being added to the flags passed to the linker. This breaks the build with: x86_64-linux-gnux32-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -g -O2 -ffile-prefix-map=/tmp/matplotlib-3.5.1=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_bezier_arc.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_curves.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_image_filters.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_trans_affine.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_contour.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_dash.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_stroke.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vpgen_segmentator.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/_backend_agg.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/_backend_agg_wrapper.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/checkdep_freetype2.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/py_converters.o -o build/lib.linux-x86_64-3.9/matplotlib/backends/_backend_agg.cpython-39-x86_64-linux-gnux32.so -lfreetype /usr/bin/ld: /tmp/cc7JfqHN.ltrans3.ltrans.o: warning: relocation against `PyExc_ValueError' in read-only section `.text' /usr/bin/ld: /tmp/cc7JfqHN.ltrans0.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `_Py_NoneStruct' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status Looking in distutils code (/usr/lib/python3.9/distutils/sysconfig.py) it seems that the CFLAGS and CPPFLAGS are leaking in the flags passed to the linkers (LDFLAGS/LDSHARED) Is that expected? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages python3-distutils depends on: ii python3 3.10.4-1+b1 ii python3-lib2to3 3.9.12-1 python3-distutils recommends no packages. python3-distutils suggests no packages. -- no debconf information
Bug#1012489: ceph: FTBFS on some architectures becuase of missing boost_context (and probably boost_coroutine)
Source: ceph Version: 16.2.7+ds-4 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, Ceph currently FTBFS on some architecture (x32, sparc64, ppc64, ia64, alpha). This is related to the fact that libboost-context-dev not being installed during the build: libboost-context-dev (>= 1.74.0) [!ia64 !m68k !ppc64 !sh4 !sparc64 !x32 !alpha], libboost-coroutine-dev (>= 1.74.0) [!ia64 !m68k !ppc64 !sh4 !sparc64 !x32 !alpha], Either the part of the code using this/these library/libraries should be disabled on these architectures or the arch qualifier should be removed so ceph is not attempted to be build on these architectures as we know it will fail (and we are not wasting cpu time). And it will start building again if boost_context is added to these architectures eventually (I've a patch that makes the build x32 succeed). I would go for the later. Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012379: subversion: Please disable java support on kfreebsd
Source: subversion Version: 1.14.2-1 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hello, Java support should be disabled on kfreebsd too openjdk8 (the current default) is no available on that architecture for years (and openjdk11 is not even supported by the package) The attached patch should(?) disable the java support Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -Nru subversion-1.14.2/debian/control subversion-1.14.2/debian/control --- subversion-1.14.2/debian/control2022-04-12 14:38:19.0 +0200 +++ subversion-1.14.2/debian/control2022-06-05 23:36:42.0 +0200 @@ -6,11 +6,11 @@ bash-completion, chrpath, debhelper-compat (= 12), - default-jdk-headless (>= 2:1.8) [!hurd-i386 !hppa !sparc] , + default-jdk-headless (>= 2:1.8) [!hurd-i386 !hppa !sparc !kfreebsd-amd64 !kfreebsd-i386] , dh-apache2, dh-python, doxygen, - junit4 [!hurd-i386 !hppa !sparc] , + junit4 [!hurd-i386 !hppa !sparc !kfreebsd-amd64 !kfreebsd-i386] , libapr1-dev, libaprutil1-dev, libdb5.3-dev, diff -Nru subversion-1.14.2/debian/rules subversion-1.14.2/debian/rules --- subversion-1.14.2/debian/rules 2022-04-12 14:38:19.0 +0200 +++ subversion-1.14.2/debian/rules 2022-06-05 23:36:42.0 +0200 @@ -27,7 +27,7 @@ # with DISABLE_JAVAHL_ARCHS. ENABLE_JAVAHL= yes -DISABLE_JAVAHL_ARCHS = hurd-i386 hppa sparc +DISABLE_JAVAHL_ARCHS = hurd-i386 hppa sparc kfreebsd-amd64 kfreebsd-i386 ifneq (,$(filter $(DEB_HOST_ARCH), $(DISABLE_JAVAHL_ARCHS))) ENABLE_JAVAHL = endif
Bug#1012378: elfutils: FTBFS on kfreebsd
Source: elfutils Version: 0.186-1 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, elfutils currently FTBFS on kfreebsd with the current error: gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/share/locale"' -I. -I.. -I. -I. -I../lib -I.. -I. -I./../libelf -I./../libebl -I./../libdw -I./../libdwelf -I/usr/include/p11-kit-1 -I/usr/include/x86_64-kfreebsd-gnu -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Wunused -Wextra -Wstack-usage=262144 -D_FORTIFY_SOURCE=2 -g -O3 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -MT debuginfod-client.o -MD -MP -MF .deps/debuginfod-client.Tpo -c -o debuginfod-client.o debuginfod-client.c debuginfod-client.c: In function ‘debuginfod_query_server’: debuginfod-client.c:1042:37: error: ‘CLOCK_MONOTONIC_RAW’ undeclared (first use in this function); did you mean ‘CLOCK_MONOTONIC_FAST’? 1042 | if ( maxtime > 0 && clock_gettime(CLOCK_MONOTONIC_RAW, &start_time) == -1) | ^~~ | CLOCK_MONOTONIC_FAST debuginfod-client.c:1042:37: note: each undeclared identifier is reported only once for each function it appears in -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1011952: mesa: FTBFS on kfreebsd
Le 2/06/22 à 18:25, Timo Aaltonen a écrit : Laurent Bigonville kirjoitti 27.5.2022 klo 18.43: Source: mesa Version: 22.1.0~rc5-1 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081 Hello, mesa currently FTBFS on kfreebsd The attached patch seems to fix this The patch has been propsed upstream Could you please apply that patch? Is disabling gallium-extra-hud a part of the fix? Yes indeed, should have mentioned it Apparently it requires linux specific wireless headers, disabling it on non-linux/kfreebsd is allowing the package to build
Bug#1011952: mesa: FTBFS on kfreebsd
Source: mesa Version: 22.1.0~rc5-1 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081 Hello, mesa currently FTBFS on kfreebsd The attached patch seems to fix this The patch has been propsed upstream Could you please apply that patch? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -u mesa-22.1.0/debian/patches/series mesa-22.1.0/debian/patches/series --- mesa-22.1.0/debian/patches/series +++ mesa-22.1.0/debian/patches/series @@ -2,3 +2,4 @@ path_max.diff src_glx_dri_common.h.diff revert-enabling-tlsdesc-support.diff +fix_ftbfs_kfreebsd.patch diff -u mesa-22.1.0/debian/rules mesa-22.1.0/debian/rules --- mesa-22.1.0/debian/rules +++ mesa-22.1.0/debian/rules @@ -56,7 +56,6 @@ confflags_DIRECT_RENDERING = -Dglx-direct=true confflags_GBM = -Dgbm=enabled - confflags_GALLIUM += -Dgallium-extra-hud=true confflags_GALLIUM += -Dgallium-vdpau=enabled confflags_GALLIUM += -Dlmsensors=enabled @@ -68,6 +67,7 @@ ifeq ($(DEB_HOST_ARCH_OS), linux) confflags_DRI3 = -Ddri3=enabled + confflags_GALLIUM += -Dgallium-extra-hud=true # Gallium drivers which require kernel support, not yet ported to non-Linux GALLIUM_DRIVERS += nouveau virgl only in patch2: unchanged: --- mesa-22.1.0.orig/debian/patches/fix_ftbfs_kfreebsd.patch +++ mesa-22.1.0/debian/patches/fix_ftbfs_kfreebsd.patch @@ -0,0 +1,53 @@ +From 809fc7ef474a6010f2eafc853d8d1322f97a539c Mon Sep 17 00:00:00 2001 +From: Laurent Bigonville +Date: Thu, 17 Feb 2022 14:49:27 +0100 +Subject: [PATCH] Try to fix FTBFS on kfreebsd architecture + +Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081 +--- + include/drm-uapi/sync_file.h | 1 + + src/util/u_qsort.h | 2 +- + src/util/u_thread.h | 2 +- + 3 files changed, 3 insertions(+), 2 deletions(-) + +diff --git a/include/drm-uapi/sync_file.h b/include/drm-uapi/sync_file.h +index 11d86db53e4..7ede34e12de 100644 +--- a/include/drm-uapi/sync_file.h b/include/drm-uapi/sync_file.h +@@ -19,6 +19,7 @@ + + #else /* One of the BSDs */ + ++#include + #include + #include + +diff --git a/src/util/u_qsort.h b/src/util/u_qsort.h +index 34fff94dba4..ac3dfebaa6b 100644 +--- a/src/util/u_qsort.h b/src/util/u_qsort.h +@@ -57,7 +57,7 @@ util_qsort_r(void *base, size_t nmemb, size_t size, + void *arg) + { + #if HAVE_QSORT_R +-# if DETECT_OS_APPLE || DETECT_OS_BSD ++# if (DETECT_OS_APPLE || DETECT_OS_BSD) && ! defined(__GLIBC__) +/* BSD/macOS qsort_r takes "arg" before the comparison function and it + * pass the "arg" before the elements. + */ +diff --git a/src/util/u_thread.h b/src/util/u_thread.h +index d06ff6beddb..70c02bf938c 100644 +--- a/src/util/u_thread.h b/src/util/u_thread.h +@@ -125,7 +125,7 @@ static inline thrd_t u_thread_create(int (*routine)(void *), void *param) + static inline void u_thread_setname( const char *name ) + { + #if defined(HAVE_PTHREAD) +-#if DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS ++#if DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS || defined(__GLIBC__) +int ret = pthread_setname_np(pthread_self(), name); +if (ret == ERANGE) { + char buf[16]; +-- +GitLab +
Bug#1011163: samba: FTBFS on kfreebsd
Source: samba Version: 2:4.16.1+dfsg-4 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, samba still FTBFS on kfreebsd PYTHONHASHSEED=1 python3 ./buildtools/bin/waf -j2 -j1 configure -C --prefix=/usr --enable-fhs --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/libexec --libdir=/usr/lib/x86_64-kfreebsd-gnu --datadir=/usr/share --with-modulesdir=/usr/lib/x86_64-kfreebsd-gnu/samba --with-pammodulesdir=/lib/x86_64-kfreebsd-gnu/security --with-privatedir=/var/lib/samba/private --with-smbpasswd-file=/etc/samba/smbpasswd --with-piddir=/run/samba --with-lockdir=/run/samba --with-statedir=/var/lib/samba --with-cachedir=/var/cache/samba --with-pam --with-syslog --with-utmp --with-winbind --with-quota --with-automount --with-ldap --with-ads --with-gpgme --enable-avahi --enable-spotlight --disable-rpath --disable-rpath-install --with-shared-modules=idmap_rid,idmap_ad,idmap_adex,idmap_hash,idmap_ldap,idmap_tdb2,vfs_dfs_samba4,auth_samba4,vfs_nfs4acl_xattr --bundled-libraries=NONE,pytevent,ldb --with-cluster-support --enable-etcd-reclock --with-socketpath=/run/ctdb/ctdbd.socket --with-logdir=/var/log/ctdb --disable-cephfs --without-systemd || \ { echo " contents of config.log:"; cat bin/config.log; false; } Setting top to : /<> Setting out to : /<>/bin Checking for 'clang' (C compiler): Traceback (most recent call last): File "/<>/third_party/waf/waflib/Utils.py", line 831, in wrap return cache[k] KeyError: (,) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/<>/third_party/waf/waflib/Utils.py", line 831, in wrap return cache[k] KeyError: (,) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/<>/third_party/waf/waflib/Scripting.py", line 159, in waf_entry_point run_commands() File "/<>/third_party/waf/waflib/Scripting.py", line 255, in run_commands ctx = run_command(cmd_name) File "/<>/third_party/waf/waflib/Scripting.py", line 239, in run_command ctx.execute() File "/<>/third_party/waf/waflib/Configure.py", line 159, in execute super(ConfigurationContext, self).execute() File "/<>/third_party/waf/waflib/Context.py", line 214, in execute self.recurse([os.path.dirname(g_module.root_path)]) File "/<>/third_party/waf/waflib/Context.py", line 296, in recurse user_function(self) File "/<>/wscript", line 163, in configure conf.RECURSE('lib/replace') File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun return f(*k, **kw) File "/<>/./buildtools/wafsamba/samba_utils.py", line 469, in RECURSE return ctx.recurse(relpath) File "/<>/third_party/waf/waflib/Context.py", line 296, in recurse user_function(self) File "/<>/third_party/waf/waflib/Utils.py", line 833, in wrap ret = fun(*k) File "/<>/lib/replace/wscript", line 30, in configure conf.RECURSE('buildtools/wafsamba') File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun return f(*k, **kw) File "/<>/./buildtools/wafsamba/samba_utils.py", line 469, in RECURSE return ctx.recurse(relpath) File "/<>/third_party/waf/waflib/Context.py", line 296, in recurse user_function(self) File "/<>/third_party/waf/waflib/Utils.py", line 833, in wrap ret = fun(*k) File "/<>/buildtools/wafsamba/wscript", line 296, in configure conf.load('compiler_c') File "/<>/third_party/waf/waflib/Configure.py", line 271, in load func(self) File "/<>/third_party/waf/waflib/Tools/compiler_c.py", line 79, in configure conf.load(compiler) File "/<>/third_party/waf/waflib/Configure.py", line 271, in load func(self) File "/<>/third_party/waf/waflib/Tools/clang.py", line 22, in configure conf.find_clang() File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun return f(*k, **kw) File "/<>/third_party/waf/waflib/Tools/clang.py", line 18, in find_clang conf.get_cc_version(cc, clang=True) File "/<>/third_party/waf/waflib/Configure.py", line 317, in fun return f(*k, **kw) File "/<>/third_party/waf/waflib/Tools/c_config.py", line 1027, in get_cc_version cmd = cc + ['-dM', '-E', '-'] TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' Kind regards, Laurent Bigonville -- Package-spec
Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
Hello, Any news about this? By not allowing this package on some architectures, you are shifting the complexity of adding architecture qualifier to other packages higher in the dependency chain, so I'm also not sure this is a good thing either. As said by other, disabling optional language bindings on architectures where the language is not supported is quite common... my 2¢ Laurent Bigonville
Bug#1006530: mariadb-10.6: FTBFS on x32: undefined reference to misc functions and files (regression from MariaDB 10.5)
On Tue, 15 Mar 2022 15:22:15 +1100 Daniel Black wrote: > The error is earlier in the logs: > > -- Looking for sched_getcpu - found > -- Could NOT find PMEM (missing: PMEM_LIBRARIES PMEM_INCLUDE_DIR) > CMake Error at storage/innobase/CMakeLists.txt:345 (MESSAGE): > WITH_PMEM=ON cannot be satisfied > > When the configure stage fails, the builds outputs the > CMakeOutput/Error logs to complement this error earlier in the logs. > In this case its not useful but other times it is. > > so the architecture test in debian/rules isn't right as it adds WITH_PMEM=ON. > WITH_PMEM=ON doesn't seem explicitly added to the options on x32, so I'm wondering if WITH_PMEM=OFF shouldn't be added explicitly on architectures where libpmem is not available/supported
Bug#980744: Please add support for upcoming bullseye release
On Thu, 21 Jan 2021 10:25:08 +0100 Laurent Bigonville wrote: > Hello, > > The new debian release is coming and osinfo-db is currently not > supporting it. > > Could you please add support for bullseye? > I've created a branch with two patches that should be uploaded in stable as the currently the version in debian bullseye of osinfo-db is not supporting bullseye https://salsa.debian.org/bigon/osinfo-db/-/commits/debian/bullseye/ Could you please to as table upload with these? I still think that such bugs should be RC, as the data for the current stable must be supported in stable...
Bug#1009972: libvirt: TPM emulation requires swtpm, swtpm_setup and swtpm_ioctl executables
Source: libvirt Version: 8.2.0-1 Severity: normal Hello, TPM emulation requires the swtpm, swtpm_setup and swtpm_ioctl executables (that are shipped in swtpm and swtpm-tools packages) But libvirt is not depending on them. A (soft?) dependency should probably be added Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1009175: python3-samba package trying to replace file owned by samba one (dckeytab)
Package: python3-samba Version: 2:4.16.0+dfsg-2 Severity: serious Hello, When updating my system this morning, I got the following error: Préparation du dépaquetage de .../03-python3-samba_2%3a4.16.0+dfsg-2_amd64.deb ... Dépaquetage de python3-samba (2:4.16.0+dfsg-2) sur (2:4.13.14+dfsg-1+b3) ... dpkg: erreur de traitement de l'archive /tmp/apt-dpkg-install-pB0IcL/03-python3-samba_2%3a4.16.0+dfsg-2_amd64.deb (--unpack) : tentative de remplacement de « /usr/lib/python3/dist-packages/samba/dckeytab.cpython-310-x86_64-linux-gnu.so », qui appartient aussi au paquet samba 2:4.13.14+dfsg-1+b3 dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe)) Apparently the dckeytab.cpython-310-x86_64-linux-gnu.so file moved from the samba package to the python3-samba without the proper Breaks/Replaces -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages python3-samba depends on: ii libbsd0 0.11.6-1 ii libc6 2.33-7 ii libgnutls30 3.7.3-4+b1 ii libldb2 2:2.5.0+smb-2+samba4.16.0+dfsg ii libpython3.10 3.10.4-3 ii libtalloc2 2.3.3-3+b1 ii libtevent0 0.11.0-1 ii libwbclient02:4.16.0+dfsg-2 ii python3 3.10.4-1 ii python3-ldb 2:2.5.0+smb-2+samba4.16.0+dfsg ii python3-talloc 2.3.3-3+b1 ii python3-tdb 1.4.6-2+b1 ii samba-libs 2:4.16.0+dfsg-2 Versions of packages python3-samba recommends: ii python3-gpg 1.16.0-1.2 python3-samba suggests no packages. -- no debconf information
Bug#1006127: wireless-regdb stable policy
FTR, this seems to be fixed in the last release (2022-02-18) of wireless-regdb: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=e427ff2a592e26fc1e8336769b9a1ad223f6f697
Bug#1007769: scipy: FTBFS on sh4
Source: scipy Version: 1.7.3-2 Severity: important Tags: ftbfs Forwarded: https://github.com/scipy/scipy/issues/15584 Hello, scipy currently FTBFS on sh4 with the following error: sh4-linux-gnu-gcc: scipy/special/_test_round.c scipy/special/_test_round.c: In function ‘__pyx_pf_5scipy_7special_11_test_round_have_fenv’: scipy/special/_test_round.c:2213:30: error: ‘FE_UPWARD’ undeclared (first use in this function) 2213 | __pyx_t_1 = ((fesetround(FE_UPWARD) != 0) != 0); | ^ scipy/special/_test_round.c:2213:30: note: each undeclared identifier is reported only once for each function it appears in scipy/special/_test_round.c:2241:30: error: ‘FE_DOWNWARD’ undeclared (first use in this function); did you mean ‘FP_INT_DOWNWARD’? 2241 | __pyx_t_1 = ((fesetround(FE_DOWNWARD) != 0) != 0); | ^~~ | FP_INT_DOWNWARD scipy/special/_test_round.c: In function ‘__pyx_pf_5scipy_7special_11_test_round_4test_add_round’: scipy/special/_test_round.c:2767:37: error: ‘FE_UPWARD’ undeclared (first use in this function) 2767 | __pyx_v_status = fesetround(FE_UPWARD); | ^ scipy/special/_test_round.c:2825:37: error: ‘FE_DOWNWARD’ undeclared (first use in this function); did you mean ‘FP_INT_DOWNWARD’? 2825 | __pyx_v_status = fesetround(FE_DOWNWARD); | ^~~ | FP_INT_DOWNWARD Upstream seems to think that it's a bug in the architecture and propose that debian carries a patch for it: https://github.com/scipy/scipy/issues/15584#issuecomment-1069125146 Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#819349: libnss3: broken AES on x32 on certain Intel CPUs
Hello, I can confirm that the last patch proposed in #819349 workaround the FTBFS of NSS and also fixes the FTBFS of libsrtp2 (bug #958427) Would it be possible to apply the patch in NSS to workaround the issue then? Kind regards, Laurent Bigonville
Bug#1007233: nss: FTBFS on x32 architecture
Source: nss Version: 2:3.52-1 Severity: important Tags: ftbfs Hello, nss currently FTBFS on x32 architecture with the following error: A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot. ERROR: Unable to switch FIPS modes. This is already reported upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1062903 Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#958427: libsrtp2: FTBFS on x32: bogus printf with time_t, then segfaults [regression]
found 958427 2.4.2-3 thanks So apparently the patch proposed here was not enough and the test is crashing :/ Thorsten do you think you could have a look?