Bug#1056752: CVE-2023-49298 also affect Bullseye and Bookworm
Dear Maintainers, The bug CVE-2023-49298 is here: https://tracker.debian.org/pkg/zfs-linux marked as LOW PRIORITY for Bullseye and Bookworm. Are you planning to fix this bug in Bullseye and Bookworm soon? For many users, the fix is important - if the official Debian fix will take longer, it's good to know and make the fix yourself. Thank you for your support for ZFS in Debian, Roman
Bug#1057234: sbuild: Generates weird messages in /var/log/syslog
Hi, Quoting Hilmar Preusse (2023-12-01 23:10:36) > I run sbuild as following: > > sbuild --no-run-lintian --arch-all --dist=sid *.dsc -d unstable-amd64-sbuild > > , where unstable-amd64-sbuild references a chroot. Updating the chroot is > done: > > sudo sbuild-update -udcar unstable-amd64-sbuild > > Both commands generate weird messages in /var/log/syslog like this: > > 2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]: [unstable- > amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot] (root->root) Running > command: "perl -e #012use strict;#012 >use warnings;#012use POSIX;#012 > > Sample file is attached. These #012 are page feed chars IIRC. Unfortunately > logcheck is not able to handle the situation and generates E-Mails, which > report the full command line by line. There is definitely a white list rule > for > schroot in /etc/logcheck/ignore.d.server/schroot, but it is not able to handle > the lot of special characters. Consider to not print the full perl script into > the log file (if possible). > > It may be an issue in logcheck, but rather prefer to avoid message instead of > trying to white list afterwards. it may also be an issue with schroot, no? I do not think sbuild at any point tells schroot to write anything to syslog. What should sbuild do to fix this? Thanks! cheers, josch signature.asc Description: signature
Bug#1057253: libvcflib: add support for loongarch64
Source: libvcflib
Version: 1.0.9+dfsg1-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
The libvcflib source package lacks LoongArch architecture support.
We need to add support for loongarch64 in d/control.
Please consider the patch I have attached.
And the libvcflib source package was compiled successfully on my local
loong64 rootfs environment.
Would it be possible to include the support for LoongArch in the next
upload?
thanks,
Dandan Zhang
diff -Nru libvcflib-1.0.9+dfsg1/debian/control
libvcflib-1.0.9+dfsg1/debian/control
--- libvcflib-1.0.9+dfsg1/debian/control2023-08-06 21:01:54.0
+
+++ libvcflib-1.0.9+dfsg1/debian/control2023-08-06 21:01:54.0
+
@@ -26,7 +26,7 @@
Rules-Requires-Root: no
Package: libvcflib2
-Architecture: any-amd64 arm64 mips64el ppc64el s390x ia64 ppc64 riscv64
sparc64 alpha
+Architecture: any-amd64 arm64 loong64 mips64el ppc64el s390x ia64 ppc64
riscv64 sparc64 alpha
Multi-Arch: same
Section: libs
Depends: ${shlibs:Depends},
@@ -47,7 +47,7 @@
manipulations on VCF files.
Package: libvcflib-dev
-Architecture: any-amd64 arm64 mips64el ppc64el s390x ia64 ppc64 riscv64
sparc64 alpha
+Architecture: any-amd64 arm64 loong64 mips64el ppc64el s390x ia64 ppc64
riscv64 sparc64 alpha
Multi-Arch: same
Section: libdevel
Depends: ${misc:Depends},
@@ -76,7 +76,7 @@
This package contains the static library and the header files.
Package: libvcflib-tools
-Architecture: any-amd64 arm64 mips64el ppc64el s390x ia64 ppc64 riscv64
sparc64 alpha
+Architecture: any-amd64 arm64 loong64 mips64el ppc64el s390x ia64 ppc64
riscv64 sparc64 alpha
Depends: ${shlibs:Depends},
${misc:Depends},
python3:any,
Bug#1057252: libhsa-runtime-dev: headers claim HSA 1.3 support but are missing hsa_amd_memory_async_copy_on_engine
Package: libhsa-runtime-dev Version: 5.2.3-6 Severity: normal Tags: fixed-upstream X-Debbugs-Cc: c...@slerp.xyz, jonathanchesterfi...@gmail.com Dear Maintainer, As reported by Jon Chesterfield [1], > HSA 1.2 introduces an API call hsa_amd_memory_async_copy_on_engine > > /usr/include/hsa_ext_amd.h contains: > /* > >* - 1.0 - initial version > > * - 1.1 - dmabuf export > >* - 1.2 - hsa_amd_memory_async_copy_on_engine > * - 1.3 - HSA_AMD_MEMORY_POOL_GLOBAL_FLAG_EXTENDED_SCOPE_FINE_GRAINED > pool > */ > #define HSA_AMD_INTERFACE_VERSION_MAJOR 1 > #define HSA_AMD_INTERFACE_VERSION_MINOR 3 > > > Openmp has decided to branch on those version macros to guess whether > hsa_amd_memory_async_copy_on_engine is available or not. That's sort > of the best of various bad options available. > > The shared library Debian packages doesn't export the > hsa_amd_memory_async_copy_on_engine symbol. Can check with nm > --dynamic | grep. > > Thus openmp's runtime now refuses to build. Locally 'm going to change > that 3 to a 1. I'm not sure what the right change to packaging is > beyond that the header should match the shared library. The hsa_amd_memory_async_copy_on_engine API call was added in ROCm 5.6. This issue could be fixed on unstable by updating rocr-runtime to the latest upstream release. Regards, Cory Bloor [1]: https://lists.debian.org/debian-ai/2023/12/msg1.html -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages libhsa-runtime-dev depends on: ii libhsa-runtime64-1 5.2.3-6 libhsa-runtime-dev recommends no packages. libhsa-runtime-dev suggests no packages. -- no debconf information
Bug#986713: gpsd: please stop build-depending on makedev
Hi, On Fri, 2023-12-01 at 22:08 +0100, Chris Hofstaedtler wrote: > * Chris Hofstaedtler [231201 21:06]: > > * Chris Hofstaedtler [210820 11:47]: > > > your package build-depends on makedev, which itself is long > > > obsolete. Please consider replacing makedev. > > > > I know that this was tried in gpsd 3.5-5, and apparently caused an > > issue on mips. However, mips itself is long gone, and the mipsel > > build log for 3.5-5 doesn't show a problem. > > > > Would you consider trying removing makedev from Build-Depends once > > again? > > Pinging this bug; I'd really like gpsd to drop its Build-Depends on > makedev. Thanks for the reminder. I will try an experimental upload to see how it goes. With best regards, b.
Bug#1057251: librocfft0-tests: nondeterministic failures in random_real_3d/random_params.vs_fftw
Package: librocfft0-tests Version: 5.5.0-6 Severity: normal Dear Maintainer, The rocfft tests passed then failed on amd64+gfx1032 with an identical set of dependencies. The failing log contained: 55s Random seed: 190206186 <...> 14657s [ RUN ] random_real_3d/random_params.vs_fftw/0 14658s unknown file: Failure 14658s C++ exception with description "rocFFT plan execution failure" thrown in the test body. 14658s 14658s [ FAILED ] random_real_3d/random_params.vs_fftw/0, where GetParam() = (0, 3, 1, 1, 2) (877 ms) 14658s [ RUN ] random_real_3d/random_params.vs_fftw/1 14659s unknown file: Failure 14659s C++ exception with description "rocFFT plan execution failure" thrown in the test body. 14659s 14659s [ FAILED ] random_real_3d/random_params.vs_fftw/1, where GetParam() = (0, 3, 1, 1, 3) (960 ms) https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1032/r/rocfft/1341/log.gz The earlier passing log contained: 57s Random seed: 1459638283 <...> 14609s [ RUN ] random_real_3d/random_params.vs_fftw/0 14609s [ OK ] random_real_3d/random_params.vs_fftw/0 (42 ms) 14609s [ RUN ] random_real_3d/random_params.vs_fftw/1 14609s [ OK ] random_real_3d/random_params.vs_fftw/1 (45 ms) 14609s [ RUN ] random_real_3d/random_params.vs_fftw/2 https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1032/r/rocfft/894/log.gz I've discussed this with the upstream rocFFT developers and they plan to change rocfft-test to only run deterministic tests by default. That will ensure that when end-users are verifying their installation, that they only run the tests that have already been run by the upstream developers. There will be an option to enable the nondeterministic tests, which they will use during their development. In the meantime, I would suggest that `--seed N` be added to the arguments passed to rocfft-test in the autopkgtests. Disabling the nondeterminism in the test suite makes it easier to compare results when the autopkgtests are triggered by dependency updates and to compare results between different GPU architectures. We should also investigate to determine the underlying cause of the failure with `--seed 190206186`. Regards, Cory Bloor -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librocfft0-tests depends on: ii libamdhip64-5 5.2.3-13 ii libboost-program-options1.74.0 1.74.0+ds1-23 ii libc6 2.37-12 ii libfftw3-double33.3.10-1 ii libfftw3-single33.3.10-1 ii libgcc-s1 13.2.0-7 ii librocfft0 5.5.0-6 ii librocrand1 5.5.1-2 ii libstdc++6 13.2.0-7 librocfft0-tests recommends no packages. librocfft0-tests suggests no packages. -- no debconf information
Bug#1057250: coreutils: Unnecessary postinst maintscript
Package: src:coreutils Version: 9.4-2 Severity: minor Dear coreutils maintainers, the postinst maintscript of coreutils can be completely dropped: it contains a single command and the guard condition is always false. ``` if [ "$1" = 'configure' -a ! -e "$DPKG_ROOT/usr/bin/touch" ]; then ln -s /bin/touch "$DPKG_ROOT/usr/bin/touch" fi ``` The guard condition is always false because `/usr/bin/touch` is assured to exist since bookworm. Regards, -- Gioele Barabucci
Bug#1057248: libsdsl: add support for loongarch64
Source: libsdsl
Version: 2.1.1+dfsg-4
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
The libsdsl source package lacks LoongArch architecture support.
We need to add support for loongarch64 in d/control.
Please consider the patch I have attached.
And the libsdsl source package was compiled successfully on my local
loong64 rootfs environment.
Would it be possible to include the support for LoongArch in the next
upload?
thanks,
Dandan Zhang
diff -Nru libsdsl-2.1.1+dfsg/debian/control libsdsl-2.1.1+dfsg/debian/control
--- libsdsl-2.1.1+dfsg/debian/control 2023-08-09 14:55:15.0 +
+++ libsdsl-2.1.1+dfsg/debian/control 2023-08-09 14:55:15.0 +
@@ -16,7 +16,7 @@
Rules-Requires-Root: no
Package: libsdsl-dev
-Architecture: alpha amd64 arm64 kfreebsd-amd64 mips64el ppc64 ppc64el riscv64
s390x sparc64 x32
+Architecture: alpha amd64 arm64 kfreebsd-amd64 loong64 mips64el ppc64 ppc64el
riscv64 s390x sparc64 x32
Multi-Arch: same
Section: libdevel
Depends: libdivsufsort-dev, libsdsl3 (= ${binary:Version}), ${misc:Depends}
@@ -34,7 +34,7 @@
This package installs development files.
Package: libsdsl3
-Architecture: alpha amd64 arm64 kfreebsd-amd64 mips64el ppc64 ppc64el riscv64
s390x sparc64 x32
+Architecture: alpha amd64 arm64 kfreebsd-amd64 loong64 mips64el ppc64 ppc64el
riscv64 s390x sparc64 x32
Multi-Arch: same
Section: libs
Depends: libjs-d3, ${misc:Depends}, ${shlibs:Depends}
Bug#1057249: elki: please package v0.8
Source: elki Version: 0.7.1-10.1 Severity: normal A new version 0.8 is available: https://github.com/elki-project/elki/releases/tag/release0.8.0 Please also add a debian/watch file. Greetings -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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)
Bug#1057247: v4l-utils: will FTBFS when udev.pc changes udevdir
Source: v4l-utils Version: 1.26.0-1 Severity: normal Tags: ftbfs patch User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs a udev rule, great. For the ongoing UsrMerge effort [1], we want to change "udevdir" in udev.pc. When this happens, your package will FTBFS. The upstream build system will install the udev rules into the new path, but the Debian packaging expects them in the old path. For your convenience I'm attaching a patch to fix this. Also available as a merge request on salsa: https://salsa.debian.org/debian/libv4l/-/merge_requests/5 Please apply at your earliest convenience. Per the wiki [1], it is useful to first upload to experimental and wait a few days for the dumat tool evaluating the change, and only then upload to unstable. I expect udev.pc will change soon, and then this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge >From 6d800fb23b74571e0c9454ecf3a6b2b30a3b7e4e Mon Sep 17 00:00:00 2001 From: Chris Hofstaedtler Date: Sat, 2 Dec 2023 03:53:59 +0100 Subject: [PATCH 1/2] Lookup udev install directory from udev.pc --- debian/ir-keytable.install | 2 -- debian/rules | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/ir-keytable.install b/debian/ir-keytable.install index 5cd29e16..008e5265 100644 --- a/debian/ir-keytable.install +++ b/debian/ir-keytable.install @@ -3,5 +3,3 @@ usr/share/man/man1/ir-keytable.1 usr/share/man/man5/rc_keymap.5 etc/rc_maps.cfg etc/rc_keymaps -lib/udev/rc_keymaps -lib/udev/rules.d/70-infrared.rules diff --git a/debian/rules b/debian/rules index 23b0985f..d5ca14b3 100755 --- a/debian/rules +++ b/debian/rules @@ -20,6 +20,7 @@ endif ifeq ($(DEB_HOST_ARCH_OS),linux) deb_systemdsystemunitdir = $(shell pkg-config --variable=systemdsystemunitdir systemd | sed s,^/,,) +deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,) endif %: @@ -40,6 +41,7 @@ ifeq ($(DEB_HOST_ARCH_OS),linux) # this file is only conditionally created (clang availablility, enabled systemd filters) cp -f debian/ir-keytable.install debian/ir-keytable.install.$(DEB_HOST_ARCH) test ! -f debian/tmp/$(deb_systemdsystemunitdir)/systemd-udevd.service.d/50-rc_keymap.conf || echo $(deb_systemdsystemunitdir)/systemd-udevd.service.d/50-rc_keymap.conf >> debian/ir-keytable.install.$(DEB_HOST_ARCH) + echo $(deb_udevdir) >> debian/ir-keytable.install.$(DEB_HOST_ARCH) endif dh_install -- 2.39.2
Bug#1057246: open-vm-tools: will FTBFS when udev.pc changes udevdir
Source: open-vm-tools
Version: 12.3.5-3
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
Dear Maintainer,
your package installs a udev rule, great. For the ongoing UsrMerge
effort [1], we want to change "udevdir" in udev.pc. When this happens,
your package will FTBFS. The upstream build system will install the udev
rules into the new path, but the Debian packaging expects them in the
old path.
For your convenience I'm attaching a patch to fix this.
Please apply at your earliest convenience. Per the wiki [1], it is
useful to first upload to experimental and wait a few days for the dumat
tool evaluating the change, and only then upload to unstable.
I expect udev.pc will change soon, and then this bug will become
release-critical.
Note: one udev rules file (99-vmware-scsi-udev.rules) is installed
by upstream.
Another rules file is installed using debian/open-vm-tools.udev.
This file will move once dh_installudev gets updated.
Thanks for considering,
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru open-vm-tools-12.3.5/debian/changelog open-vm-tools-12.3.5/debian/changelog
--- open-vm-tools-12.3.5/debian/changelog 2023-11-27 16:29:44.0 +0100
+++ open-vm-tools-12.3.5/debian/changelog 2023-12-02 03:42:35.0 +0100
@@ -1,3 +1,10 @@
+open-vm-tools (2:12.3.5-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not hardcode udev rules install path.
+
+ -- Chris Sat, 02 Dec 2023 03:42:35 +0100
+
open-vm-tools (2:12.3.5-3) unstable; urgency=medium
* [7699f7a] Fix typo in last upload
diff -Nru open-vm-tools-12.3.5/debian/rules open-vm-tools-12.3.5/debian/rules
--- open-vm-tools-12.3.5/debian/rules 2023-11-27 16:29:44.0 +0100
+++ open-vm-tools-12.3.5/debian/rules 2023-12-02 03:42:22.0 +0100
@@ -32,7 +32,7 @@
# permissions
chmod 0644 debian/*/etc/pam.d/*
chmod 4755 debian/*/usr/bin/vmware-user-suid-wrapper
- chmod 0644 debian/*/lib/udev/rules.d/99-vmware-scsi-udev.rules
+ find debian -name 99-vmware-scsi-udev.rules -exec chmod 0644 {} \;
install -D -m 0644 debian/local/xautostart.conf debian/open-vm-tools-desktop/etc/vmware-tools/xautostart.conf
install -D -m 0644 debian/local/tools.conf debian/open-vm-tools/etc/vmware-tools/tools.conf
Bug#504793: [PATCH] Re: /etc/inputrc, once installed, is never replaced by newer versions
Dear Maintainer,
Attached is a patch which I believe fixes #504793 without requiring
dependencies on any additional packages.
Questions or comments are welcome.
Thanks,
--
Plasma
diff -Nru readline-8.2/debian/changelog readline-8.2/debian/changelog
--- readline-8.2/debian/changelog 2023-01-03 14:49:45.0 -0600
+++ readline-8.2/debian/changelog 2023-11-25 22:40:41.0 -0600
@@ -1,3 +1,13 @@
+readline (8.2-1.4) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Make inputrc a conffile. (Closes: #504793)
+ * d/readline-common.postinst: Remove, no longer needed.
+ * d/readline-common.postrm: Remove, no longer needed.
+ * d/rules: Remove empty /etc directory from libreadline8.
+
+ -- David (Plasma) Paul Sat, 25 Nov 2023 22:40:41 -0600
+
readline (8.2-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru readline-8.2/debian/readline-common.postinst readline-8.2/debian/readline-common.postinst
--- readline-8.2/debian/readline-common.postinst 2009-08-29 05:34:33.0 -0500
+++ readline-8.2/debian/readline-common.postinst 1969-12-31 18:00:00.0 -0600
@@ -1,13 +0,0 @@
-#! /bin/sh -e
-
-install_from_default() {
- if [ ! -f $2 ]; then
-cp -p $1 $2
- fi
-}
-
-if [ "$1" = "configure" ] && [ "$2" = "" ]; then
- install_from_default /usr/share/readline/inputrc /etc/inputrc
-fi
-
-#DEBHELPER#
--- readline-8.2/debian/readline-common.postrm 2009-08-29 05:34:33.0 -0500
+++ readline-8.2/debian/readline-common.postrm 1969-12-31 18:00:00.0 -0600
@@ -1,8 +0,0 @@
-#! /bin/sh -e
-
-case "$1" in
-purge)
- rm -f /etc/inputrc
-esac
-
-#DEBHELPER#
--- readline-8.2/debian/rules 2022-11-11 00:26:09.0 -0600
+++ readline-8.2/debian/rules 2023-11-25 22:40:41.0 -0600
@@ -250,7 +250,6 @@
: # move $(p_rl)
dh_installdirs -p$(p_rl) \
- etc \
lib/$(DEB_HOST_MULTIARCH) \
usr/share/doc
cp -a $(d)/usr/lib/$(DEB_HOST_MULTIARCH)/lib{history,readline}.so.* $(d_rl)/lib/$(DEB_HOST_MULTIARCH)/
@@ -273,6 +272,7 @@
$(d_comm)/usr/share/man/man3/readline.3readline
mv $(d)/usr/share/info/rluserman.info $(d_comm)/usr/share/info/.
install -m 644 debian/inputrc $(d_comm)/usr/share/readline/
+ install -m 644 debian/inputrc $(d_comm)/etc/
: # move $(p_rld)
dh_installdirs -p$(p_rld) \
@@ -338,6 +338,7 @@
dh_installdirs -p$(p_commu) \
usr/share/readline
install -m 644 debian/inputrc $(d_commu)/usr/share/readline/
+ install -m 644 debian/inputrc $(d_commu)/etc/
endif
ifneq ($(build32),)
Bug#1057245: gnome-settings-daemon: will FTBFS when udev.pc changes udevdir
Source: gnome-settings-daemon
Version: 45.0-1
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
Dear Maintainer,
your package installs a udev rule, great. For the ongoing UsrMerge
effort [1], we want to change "udevdir" in udev.pc. When this happens,
your package will FTBFS. The upstream build system will install the udev
rules into the new path, but the Debian packaging expects them in the
old path.
For your convenience I'm attaching a patch to fix this.
Please apply at your earliest convenience. Per the wiki [1], it is
useful to first upload to experimental and wait a few days for the dumat
tool evaluating the change, and only then upload to unstable.
I expect udev.pc will change soon, and then this bug will become
release-critical.
Thanks for considering,
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru gnome-settings-daemon-45.0/debian/changelog gnome-settings-daemon-45.0/debian/changelog
--- gnome-settings-daemon-45.0/debian/changelog 2023-09-18 20:32:16.0 +0200
+++ gnome-settings-daemon-45.0/debian/changelog 2023-12-02 02:35:20.0 +0100
@@ -1,3 +1,10 @@
+gnome-settings-daemon (45.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Use udevdir from udev.pc to determine udev rules install path.
+
+ -- Chris Sat, 02 Dec 2023 02:35:20 +0100
+
gnome-settings-daemon (45.0-1) unstable; urgency=medium
* New upstream release
diff -Nru gnome-settings-daemon-45.0/debian/control gnome-settings-daemon-45.0/debian/control
--- gnome-settings-daemon-45.0/debian/control 2023-09-18 20:32:16.0 +0200
+++ gnome-settings-daemon-45.0/debian/control 2023-12-02 02:35:20.0 +0100
@@ -6,7 +6,7 @@
Section: gnome
Priority: optional
Maintainer: Debian GNOME Maintainers
-Uploaders: Amin Bandali , Gunnar Hjalmarsson , Jeremy Bícha , Laurent Bigonville , Marco Trevisan (Treviño)
+Uploaders: Gunnar Hjalmarsson , Jeremy Bicha , Laurent Bigonville
Build-Depends: debhelper-compat (= 13),
dh-exec,
dh-sequence-gnome,
diff -Nru gnome-settings-daemon-45.0/debian/gnome-settings-daemon-common.install gnome-settings-daemon-45.0/debian/gnome-settings-daemon-common.install
--- gnome-settings-daemon-45.0/debian/gnome-settings-daemon-common.install 2023-09-18 20:32:16.0 +0200
+++ gnome-settings-daemon-45.0/debian/gnome-settings-daemon-common.install 2023-12-02 02:35:06.0 +0100
@@ -3,4 +3,4 @@
usr/share/glib-2.0
usr/share/locale
usr/lib/systemd/user
-[linux-any] lib/udev
+[linux-any] ${env:deb_udevdir}
diff -Nru gnome-settings-daemon-45.0/debian/rules gnome-settings-daemon-45.0/debian/rules
--- gnome-settings-daemon-45.0/debian/rules 2023-09-18 20:32:16.0 +0200
+++ gnome-settings-daemon-45.0/debian/rules 2023-12-02 02:34:51.0 +0100
@@ -8,6 +8,8 @@
export GSD_MAJOR_VERSION = $(shell echo $(DEB_VERSION_UPSTREAM) | cut -d~ -f1 | cut -d. -f1)
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+
%:
dh $@
Bug#1057244: hppa: All tests fail - /bin/stty: 'standard input': unable to perform all requested operations
Source: gcc-snapshot Version: 1:20231130-1 Severity: normal Dear Maintainer, This is with qemu. All tests fail. For example, Executing on host: /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/xg cc -B/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/ /build/gcc-sna pshot-qyFUuB/gcc-snapshot-20231130/src/gcc/testsuite/gcc.c-torture/execute/ieee/ pr29302-1.c-fdiagnostics-plain-output -w -O2 -fno-inline -lm -o /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/testsuite/gcc/pr29302-1.x2 (timeout = 300) spawn -ignore SIGHUP /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/xgcc -B/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/ /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/src/gcc/testsuite/gcc.c-torture/execute/ieee/pr29302-1.c -fdiagnostics-plain-output -w -O2 -fno-inline -lm -o /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/testsuite/gcc/pr29302-1.x2 /bin/stty: 'standard input': unable to perform all requested operations FAIL: gcc.c-torture/execute/ieee/pr29302-1.c compilation, -O2 UNRESOLVED: gcc.c-torture/execute/ieee/pr29302-1.c execution, -O2 Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.1.64+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1057233: pipewire-bin: installs files into /lib/udev/rules.d
Control: tags -1 + patch * Chris Hofstaedtler [231202 02:17]: > your package installs the file /lib/udev/rules.d/90-pipewire-alsa.rules. [..] Please find a patch attached, which delegates placement of the rules file to udev.pc. In a few weeks, udev.pc will change "udevdir" to /usr/lib/udev/rules.d, and then your package will pick the new path up on the next upload or binNMU. Additionaly, backports do not need to revert anything. Best, Chris diff -Nru pipewire-1.0.0/debian/changelog pipewire-1.0.0/debian/changelog --- pipewire-1.0.0/debian/changelog 2023-11-27 11:37:05.0 +0100 +++ pipewire-1.0.0/debian/changelog 2023-12-02 02:08:47.0 +0100 @@ -1,3 +1,10 @@ +pipewire (1.0.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Set udevrulesdir based on udev.pc content + + -- Chris Sat, 02 Dec 2023 02:08:47 +0100 + pipewire (1.0.0-1) unstable; urgency=medium * New upstream release diff -Nru pipewire-1.0.0/debian/control pipewire-1.0.0/debian/control --- pipewire-1.0.0/debian/control 2023-11-27 11:37:05.0 +0100 +++ pipewire-1.0.0/debian/control 2023-12-02 02:08:47.0 +0100 @@ -43,7 +43,8 @@ modemmanager-dev, pkg-config, python3-docutils, - systemd [linux-any] + systemd [linux-any], + udev [linux-any] Build-Conflicts: libfdk-aac-dev Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/utopia-team/pipewire diff -Nru pipewire-1.0.0/debian/pipewire-bin.install pipewire-1.0.0/debian/pipewire-bin.install --- pipewire-1.0.0/debian/pipewire-bin.install 2023-11-27 11:37:05.0 +0100 +++ pipewire-1.0.0/debian/pipewire-bin.install 2023-12-02 02:08:47.0 +0100 @@ -7,7 +7,6 @@ usr/share/pipewire/pipewire-aes67.conf usr/share/pipewire/pipewire-avb.conf usr/share/pipewire/minimal.conf -lib/udev/rules.d usr/bin/pipewire usr/bin/pipewire-aes67 usr/bin/pipewire-avb diff -Nru pipewire-1.0.0/debian/rules pipewire-1.0.0/debian/rules --- pipewire-1.0.0/debian/rules 2023-11-27 11:37:05.0 +0100 +++ pipewire-1.0.0/debian/rules 2023-12-02 02:08:47.0 +0100 @@ -45,6 +45,13 @@ LIBFFADO=enabled endif +ifneq (,$(filter hurd-i386,$(DEB_HOST_ARCH))) +UDEVRULESDIR= +else +UDEVRULESDIR=$(shell pkg-config --variable=udevdir udev)/rules.d +endif + + override_dh_auto_configure: dh_auto_configure -- \ -Daudiotestsrc=enabled \ @@ -69,6 +76,7 @@ -Dsdl2=$(SDL2) \ -Dsession-managers= \ -Dtest=enabled \ + -Dudevrulesdir=$(UDEVRULESDIR) \ -Dvideotestsrc=enabled \ -Dvulkan=disabled \ $(NULL) @@ -91,6 +99,10 @@ --timeout-multiplier $(test_timeout_multiplier) \ $(NULL) +override_dh_install: + dh_install + test -n "$(UDEVRULESDIR)" && dh_install -ppipewire-bin $(UDEVRULESDIR) + override_dh_missing: dh_missing --fail-missing
Bug#1057243: libnitrokey: will FTBFS when udev.pc changes udevdir
Source: libnitrokey
Version: 3.7-1
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
Dear Maintainer,
your package installs a udev rule, great. For the ongoing UsrMerge
effort [1], we want to change "udevdir" in udev.pc. When this happens,
your package will FTBFS. The upstream build system will install the udev
rules into the new path, but the Debian packaging expects them in the
old path.
For your convenience I'm attaching a patch to fix this.
Please apply at your earliest convenience. Per the wiki [1], it is
useful to first upload to experimental and wait a few days for the dumat
tool evaluating the change, and only then upload to unstable.
I expect udev.pc will change soon, and then this bug will become
release-critical.
Thanks for considering,
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru libnitrokey-3.7/debian/changelog libnitrokey-3.7/debian/changelog
--- libnitrokey-3.7/debian/changelog 2022-05-20 17:30:38.0 +0200
+++ libnitrokey-3.7/debian/changelog 2023-12-02 02:41:09.0 +0100
@@ -1,3 +1,10 @@
+libnitrokey (3.7-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Use udevdir from udev.pc to determine udev rules install path.
+
+ -- Chris Sat, 02 Dec 2023 02:41:09 +0100
+
libnitrokey (3.7-1) unstable; urgency=medium
* New upstream release.
diff -Nru libnitrokey-3.7/debian/libnitrokey-common.install libnitrokey-3.7/debian/libnitrokey-common.install
--- libnitrokey-3.7/debian/libnitrokey-common.install 2022-05-20 17:06:46.0 +0200
+++ libnitrokey-3.7/debian/libnitrokey-common.install 2023-12-02 02:41:09.0 +0100
@@ -1 +1 @@
-lib/udev/rules.d/41-nitrokey.rules
+${env:deb_udevdir}/rules.d
diff -Nru libnitrokey-3.7/debian/rules libnitrokey-3.7/debian/rules
--- libnitrokey-3.7/debian/rules 2022-05-20 17:06:46.0 +0200
+++ libnitrokey-3.7/debian/rules 2023-12-02 02:41:09.0 +0100
@@ -5,5 +5,7 @@
#export DH_VERBOSE=1
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+
%:
dh $@ --with pkgkde_symbolshelper
Bug#1038033: onscripter: Depends on SDL 1.2
Newer version are published here: https://github.com/Galladite27/ONScripter-EN/releases There is here a reference to libsdl2-dev but I don't think the port is complete: https://github.com/Galladite27/ONScripter-EN/blob/master/.github/workflows/build.yml
Bug#1057242: bmusb: will FTBFS when udev.pc changes udevdir
Source: bmusb
Version: 0.7.7-1
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
Dear Maintainer,
thank you for forwarding the Makefile changes from #1056997 to upstream.
The upstream change works as expected.
However, udev.pc will change udevdir soon. When this happens, bmusb will
FTBFS. The upstream build system will install the udev rules into the
new path, but the Debian packaging expects them in the old path.
For your convenience I'm attaching a patch to fix this.
Please apply at your earliest convenience. Per the wiki [1], it is useful
to first upload to experimental and wait a few days for the dumat tool
evaluating the change, and only then upload to unstable.
I expect this bug will become release-critical soon.
Thanks for considering,
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru bmusb-0.7.7/debian/changelog bmusb-0.7.7/debian/changelog
--- bmusb-0.7.7/debian/changelog 2023-11-30 22:11:56.0 +0100
+++ bmusb-0.7.7/debian/changelog 2023-12-02 01:30:33.0 +0100
@@ -1,3 +1,11 @@
+bmusb (0.7.7-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Use dh-compat 13 for substitutions in debhelper config files.
+ * Pick up udevdir from udev.pc, also for Debian packaging.
+
+ -- Chris Sat, 02 Dec 2023 01:30:33 +0100
+
bmusb (0.7.7-1) unstable; urgency=medium
* New upstream release.
diff -Nru bmusb-0.7.7/debian/compat bmusb-0.7.7/debian/compat
--- bmusb-0.7.7/debian/compat 2016-07-26 13:29:10.0 +0200
+++ bmusb-0.7.7/debian/compat 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru bmusb-0.7.7/debian/control bmusb-0.7.7/debian/control
--- bmusb-0.7.7/debian/control 2020-04-12 11:16:20.0 +0200
+++ bmusb-0.7.7/debian/control 2023-12-02 01:30:33.0 +0100
@@ -1,7 +1,7 @@
Source: bmusb
Priority: optional
Maintainer: Steinar H. Gunderson
-Build-Depends: debhelper (>= 9), libusb-1.0-0-dev, pkg-config, udev
+Build-Depends: debhelper-compat (= 13), libusb-1.0-0-dev, pkg-config, udev
Standards-Version: 3.9.8
Section: libs
diff -Nru bmusb-0.7.7/debian/libbmusb6.install bmusb-0.7.7/debian/libbmusb6.install
--- bmusb-0.7.7/debian/libbmusb6.install 2020-04-07 21:29:27.0 +0200
+++ bmusb-0.7.7/debian/libbmusb6.install 2023-12-02 01:30:25.0 +0100
@@ -1,2 +1,2 @@
usr/lib/*/*.so.*
-lib/udev/rules.d/*
+${env:deb_udevdir}/rules.d/*
diff -Nru bmusb-0.7.7/debian/rules bmusb-0.7.7/debian/rules
--- bmusb-0.7.7/debian/rules 2016-07-26 13:41:34.0 +0200
+++ bmusb-0.7.7/debian/rules 2023-12-02 01:30:25.0 +0100
@@ -1,4 +1,6 @@
#! /usr/bin/make -f
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+
%:
dh $@
Bug#1057241: fwupd: will FTBFS when udev.pc changes udevdir
Source: fwupd Version: 1.9.9-2 Severity: normal Tags: ftbfs patch User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs a udev rule, great. For the ongoing UsrMerge effort [1], we want to change "udevdir" in udev.pc. When this happens, your package will FTBFS. The upstream build system will install the udev rules into the new path, but the Debian packaging expects them in the old path. For your convenience I'm attaching a patch to fix this. Also available as a merge request on salsa: https://salsa.debian.org/efi-team/fwupd/-/merge_requests/12 Please apply at your earliest convenience. Per the wiki [1], it is useful to first upload to experimental and wait a few days for the dumat tool evaluating the change, and only then upload to unstable. I expect udev.pc will change soon, and then this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge diff -Nru fwupd-1.9.9/debian/changelog fwupd-1.9.9/debian/changelog --- fwupd-1.9.9/debian/changelog 2023-11-25 14:36:55.0 +0100 +++ fwupd-1.9.9/debian/changelog 2023-12-02 01:43:42.0 +0100 @@ -1,3 +1,10 @@ +fwupd (1.9.9-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use udevdir from udev.pc to determine udev rules install path. + + -- Chris Sat, 02 Dec 2023 01:43:42 +0100 + fwupd (1.9.9-2) unstable; urgency=medium * Backport a patch to fix probing on amd-gpu. diff -Nru fwupd-1.9.9/debian/fwupd.install fwupd-1.9.9/debian/fwupd.install --- fwupd-1.9.9/debian/fwupd.install 2023-11-25 14:36:49.0 +0100 +++ fwupd-1.9.9/debian/fwupd.install 2023-12-02 01:43:42.0 +0100 @@ -13,7 +13,6 @@ usr/libexec/fwupd/* usr/lib/sysusers.d/* usr/share/man/* -lib/udev/rules.d/* data/fwupd.conf etc/fwupd debian/fwupd.pkla /var/lib/polkit-1/localauthority/10-vendor.d usr/lib/*/fwupd-*/*.so
Bug#1057240: alsa-utils: will FTBFS when udev.pc changes udevdir
Source: alsa-utils
Version: 1.2.10-1
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
Dear Maintainer,
your package installs a udev rule, great. For the ongoing UsrMerge
effort [1], we want to change "udevdir" in udev.pc. When this happens,
your package will FTBFS. The upstream build system will install the udev
rules into the new path, but the Debian packaging expects them in the
old path.
For your convenience I'm attaching a patch to fix this.
Please apply at your earliest convenience. Per the wiki [1], it is
useful to first upload to experimental and wait a few days for the dumat
tool evaluating the change, and only then upload to unstable.
I expect udev.pc will change soon, and then this bug will become
release-critical.
Thanks for considering,
Chris
[1] https://wiki.debian.org/UsrMerge
PS: alsa-utils also seems to hardcode the install location of systemd
units, i.e. they always get installed into /lib/systemd/system. These
should also move to /usr; the patch does not change this for now. If you
can use dh_installsystemd, I would recommend using that.
diff -Nru alsa-utils-1.2.10/debian/changelog alsa-utils-1.2.10/debian/changelog
--- alsa-utils-1.2.10/debian/changelog 2023-09-13 15:45:59.0 +0200
+++ alsa-utils-1.2.10/debian/changelog 2023-12-02 01:32:07.0 +0100
@@ -1,3 +1,10 @@
+alsa-utils (1.2.10-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Use udevdir from udev.pc to determine udev rules install path.
+
+ -- Chris Sat, 02 Dec 2023 01:32:07 +0100
+
alsa-utils (1.2.10-1) unstable; urgency=medium
* New upstream release.
diff -Nru alsa-utils-1.2.10/debian/install alsa-utils-1.2.10/debian/install
--- alsa-utils-1.2.10/debian/install2022-07-06 03:17:35.0 +0200
+++ alsa-utils-1.2.10/debian/install2023-12-02 01:32:00.0 +0100
@@ -1,6 +1,6 @@
debian/utils.sh /usr/share/alsa
lib/systemd
-lib/udev
+${env:deb_udevdir}/rules.d
usr/bin
usr/lib/*/alsa-topology/*.so
usr/sbin
diff -Nru alsa-utils-1.2.10/debian/rules alsa-utils-1.2.10/debian/rules
--- alsa-utils-1.2.10/debian/rules 2023-09-13 15:45:07.0 +0200
+++ alsa-utils-1.2.10/debian/rules 2023-12-02 01:32:00.0 +0100
@@ -1,6 +1,7 @@
#!/usr/bin/make -f
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
%:
dh $@
Bug#1057239: bookworm-pu: cups/2.4.2-3+deb12u5
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
The attached debdiff for cups fixes a nasty bug in Bookworm.
If the PPD file for a printer has a ColorModel option and the only choice
for printing in color is not named RGB but CMYK instead, the printer
cannot be made printing in color with intuitive methods, usually
by selecting the color choice in the print dialog.
The fix was already applied in Unstable/Testing and also uploaded
to Ubuntu-Lunar and seems to work as expected.
Thorsten
diff -Nru cups-2.4.2/debian/changelog cups-2.4.2/debian/changelog
--- cups-2.4.2/debian/changelog 2023-10-05 16:35:27.0 +0200
+++ cups-2.4.2/debian/changelog 2023-12-01 20:35:27.0 +0100
@@ -1,3 +1,15 @@
+cups (2.4.2-3+deb12u5) bookworm; urgency=medium
+
+ * 0017-check-colormodel-also-for-CMYK.patch
+Take into account that on some printers the ColorModel option's
+choice for color printing is CMYK and not RGB.
+ * 0018-dont-override-color-settings-from-print-dialoag.patch
+Prioritize the ColorModel PPD file option over the print-color-mode
+IPP attribute. (Closes: #1056581)
+(Thanks a lot to Till Kamppeter for the patches)
+
+ -- Thorsten Alteholz Fri, 01 Dec 2023 20:35:27 +0100
+
cups (2.4.2-3+deb12u4) bookworm; urgency=medium
* remove debian/NEWS again to avoid too much information when only
diff -Nru cups-2.4.2/debian/patches/0017-check-colormodel-also-for-CMYK.patch
cups-2.4.2/debian/patches/0017-check-colormodel-also-for-CMYK.patch
--- cups-2.4.2/debian/patches/0017-check-colormodel-also-for-CMYK.patch
1970-01-01 01:00:00.0 +0100
+++ cups-2.4.2/debian/patches/0017-check-colormodel-also-for-CMYK.patch
2023-12-01 20:35:27.0 +0100
@@ -0,0 +1,21 @@
+From: Thorsten Alteholz
+Date: Sat, 2 Dec 2023 00:00:38 +0100
+Subject: check colormodel also for CMYK
+
+---
+ scheduler/printers.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/scheduler/printers.c b/scheduler/printers.c
+index 4efa613..2fbdaad 100644
+--- a/scheduler/printers.c
b/scheduler/printers.c
+@@ -4509,7 +4509,7 @@ load_ppd(cupsd_printer_t *p) /* I - Printer
*/
+ ppd_option_t *color_model = ppdFindOption(ppd, "ColorModel");
+ // ColorModel PPD option
+
+-if (color_model && strcmp(color_model->defchoice, "RGB"))
++if (color_model && strcmp(color_model->defchoice, "RGB") &&
strcmp(color_model->defchoice, "CMYK"))
+ p->num_options = cupsAddOption("print-color-mode", "monochrome",
p->num_options, >options);
+ }
+ }
diff -Nru
cups-2.4.2/debian/patches/0018-dont-override-color-settings-from-print-dialoag.patch
cups-2.4.2/debian/patches/0018-dont-override-color-settings-from-print-dialoag.patch
---
cups-2.4.2/debian/patches/0018-dont-override-color-settings-from-print-dialoag.patch
1970-01-01 01:00:00.0 +0100
+++
cups-2.4.2/debian/patches/0018-dont-override-color-settings-from-print-dialoag.patch
2023-12-01 20:35:27.0 +0100
@@ -0,0 +1,78 @@
+From: Thorsten Alteholz
+Date: Sat, 2 Dec 2023 00:01:23 +0100
+Subject: dont override color settings from print dialoag
+
+---
+ cups/ppd-cache.c | 39 +++
+ scheduler/ipp.c | 3 +++
+ 2 files changed, 38 insertions(+), 4 deletions(-)
+
+diff --git a/cups/ppd-cache.c b/cups/ppd-cache.c
+index 8861813..f72d834 100644
+--- a/cups/ppd-cache.c
b/cups/ppd-cache.c
+@@ -259,15 +259,46 @@ _cupsConvertOptions(
+
+ color_attr_name = print_color_mode_sup ? "print-color-mode" : "output-mode";
+
+- if ((keyword = cupsGetOption("print-color-mode", num_options, options)) ==
NULL)
++ /*
++ * If we use PPD with standardized PPD option for color support - ColorModel,
++ * prefer it to don't break color/grayscale support for PPDs, either classic
++ * or the ones generated from IPP Get-Printer-Attributes response.
++ */
++
++ if ((keyword = cupsGetOption("ColorModel", num_options, options)) == NULL)
+ {
++ /*
++* No ColorModel in options...
++*/
++
+ if ((choice = ppdFindMarkedChoice(ppd, "ColorModel")) != NULL)
+ {
+- if (!_cups_strcasecmp(choice->choice, "Gray"))
+- keyword = "monochrome";
++ /*
++ * ColorModel is taken from PPD as its default option.
++ */
++
++ if (!strcmp(choice->choice, "Gray") || !strcmp(choice->choice,
"FastGray") || !strcmp(choice->choice, "DeviceGray"))
++keyword = "monochrome";
+ else
+- keyword = "color";
++keyword = "color";
+ }
++else
++ /*
++ * print-color-mode is a default option since 2.4.1, use it as a
fallback if there is no
++ * ColorModel in options or PPD...
++ */
++ keyword = cupsGetOption("print-color-mode", num_options, options);
++ }
++ else
++ {
++ /*
++* ColorModel found in options...
++*/
++
++if (!strcmp(keyword, "Gray") ||
Bug#1057238: debian-policy: Take dpkg-build-api into account for Rules-Requires-Root
Package: debian-policy Version: 4.6.2.0 Severity: wishlist Hi! Starting with dpkg 1.22.0, it implements a dpkg-build-api mechanism similar in concept to the debhelper-compat levels. You can check its documentation in the dpkg-build-api(7) and dpkg-buildapi(1) manual pages. I think at least the part that involves the Rules-Requires-Root field which in level 1 defaults to value «no» instead of «binary-targets» should be documented in the Debian policy. I'm ambivalent on whether documenting the general mechanism in Debian policy makes sense though. [ I noticed I didn't update the deb-src-control(5) manual page, so I did that locally and will be part of the next dpkg release. ] Thanks, Guillem
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
Hi,
On Fri, 1 Dec 2023 13:27:58 +0100
tito wrote:
> Hi,
> but the file is still referenced in /etc/init.d/mdadm
>
> # grep /etc/default/mdadm /etc/init.d/mdadm*
> /etc/init.d/mdadm:DEBIANCONFIG=/etc/default/mdadm
>
> from the 5 variables set in /etc/default/mdadm:
>
> AUTOCHECK, AUTOSCAN, VERBOSE at a first glance are ignored
>
> START_DAEMON has already been moved to the initscript
> so that from the /etc/default/mdadm you can only turn
> the initscript off.
>
> I would propose to move DAEMON_OPTIONS="--syslog"
> to the initscript so that we can forget about
> /etc/default/mdadm.
I'm attaching the amended patch so that the script works without
/etc/default/mdadm, but it still includes the file if it's there
>
> The cronjob that will be removed soon is still a problem as it checks
> the arrays periodically
I'm not saying that it's not a problem, but I think it's a separate bug.
Also, before doing any attempts on this, Matthew has to say if he's ok
with maintaining cronjobs in this package and if yes, how this should
be done.
Best,
Lorenzo
From f748a8eb84b3331a7c0b71aa255064ab6810be02 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti
Date: Fri, 1 Dec 2023 02:19:27 +0100
Subject: [PATCH] Add mdadm and mdadm-waitidle scripts
Add scripts dropped from mdadm 4.2+20230227-1 on 28 Feb 2023
The script is changed so that it no longer needs /etc/default/mdadm
Closes: #1055645
---
debian/copyright | 8 +++
lib/mapping| 2 +
scripts/mdadm | 101 +
scripts/mdadm-waitidle | 60
scripts/mdadm-waitidle.md5sums | 1 +
scripts/mdadm.md5sums | 1 +
6 files changed, 173 insertions(+)
create mode 100755 scripts/mdadm
create mode 100755 scripts/mdadm-waitidle
create mode 100644 scripts/mdadm-waitidle.md5sums
create mode 100644 scripts/mdadm.md5sums
diff --git a/debian/copyright b/debian/copyright
index 905292d..6746261 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -37,6 +37,14 @@ Copyright: 1997-2002, Remco Treffkorn
License: BSD-3-clause
Comment: Salsa debian-gps-team/pkg-gpsd 026301b71
+Files: scripts/mdadm*
+Copyright: 2001-2005 Mario Jou/3en
+2005-2008 Martin F. Krafft
+2018 Dimitri John Ledkov
+2019 Felix Lechner
+License: GPL-2+
+Comment: Salsa debian/mdadm 140efd48
+
Files: scripts/network-manager
Copyright: 2004 - 2016 Red Hat, Inc.
2005 - 2009 Novell, Inc.
diff --git a/lib/mapping b/lib/mapping
index c1b867d..c0cf8cb 100644
--- a/lib/mapping
+++ b/lib/mapping
@@ -9,6 +9,8 @@ dirsrv.service dirsrv
dnscrypt-proxy.service dnscrypt-proxy
firewalld.service firewalld
gpsd.service gpsd
+mdadm-waitidle.service mdadm-waitidle
+mdadm.service mdadm
nftables.service nftables
pdns.service pdns
rsyslog.service rsyslog
diff --git a/scripts/mdadm b/scripts/mdadm
new file mode 100755
index 000..e98f74f
--- /dev/null
+++ b/scripts/mdadm
@@ -0,0 +1,101 @@
+#!/bin/sh
+#
+# Start the MD monitor daemon for all active MD arrays if desired.
+# This script is not used under systemd.
+#
+# Copyright © 2001-2005 Mario Jou/3en
+# Copyright © 2005-2009 Martin F. Krafft
+# Distributable under the terms of the GNU GPL version 2.
+#
+### BEGIN INIT INFO
+# Provides: mdadm
+# Required-Start:$local_fs $syslog
+# Required-Stop: $local_fs $syslog sendsigs
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: MD monitoring daemon
+# Description: mdadm provides a monitor mode, in which it will scan for
+#problems with the MD devices. If a problem is found, the
+#administrator is alerted via email, or a custom script is
+#run.
+### END INIT INFO
+#
+set -eu
+
+MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
+RUNDIR=/run/mdadm
+PIDFILE=$RUNDIR/monitor.pid
+DEBIANCONFIG=/etc/default/mdadm
+DAEMON_OPTIONS="--syslog"
+
+test -x "$MDADM" || exit 0
+
+test -f /proc/mdstat || exit 0
+
+START_DAEMON=true
+test -f $DEBIANCONFIG && . $DEBIANCONFIG
+
+. /lib/lsb/init-functions
+
+is_true()
+{
+ case "${1:-}" in
+[Yy]es|[Yy]|1|[Tt]|[Tt]rue) return 0;;
+*) return 1;
+ esac
+}
+
+case "${1:-}" in
+ start)
+if [ -x /usr/bin/systemd-detect-virt ] && /usr/bin/systemd-detect-virt --quiet --container; then
+ log_daemon_msg "Not starting MD monitoring service in container"
+ log_end_msg 0
+ exit 0
+fi
+
+if is_true $START_DAEMON; then
+ log_daemon_msg "Starting MD monitoring service" "mdadm --monitor"
+ mkdir -p $RUNDIR
+ set +e
+ start-stop-daemon -S -p $PIDFILE -x $MDADM -- \
+--monitor --pid-file $PIDFILE --daemonise --scan ${DAEMON_OPTIONS:-}
+ log_end_msg $?
+ set -e
+fi
+if [ "$(echo $RUNDIR/md[0-9]*.pid)" != "$RUNDIR/md[0-9]*.pid" ]; then
+ log_daemon_msg "Restarting MD external metadata monitor" "mdmon
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hej, Am Dienstag, 28. November 2023, 20:22:36 CET schrieb John Paul Adrian Glaubitz: [...] > With the above change, cmake defines the preprocessor macro > EIGEN_DONT_VECTORIZE and the build succeeds on powerpc. > > Could you apply this change for the next upload in order to fix the > build on powerpc? We're in the middle of packaging Qt 6.6 and I had not planned to do any more 6.4.2 updates unless absolutely necessary. Do you know whether this patch will also work on Qt 6.6.1 ? -- Med vänliga hälsningar Patrick Franz
Bug#1057231: btrfs-progs: installs files into /lib/udev/rules.d
Control: retitle -1 btrfs-progs: will FTBFS when udev.pc changes udevdir
Control: tags -1 + ftbfs
* Chris Hofstaedtler [231201 23:37]:
> Apparently these paths are hard-coded, either in the upstream build system
> or the packaging.
My apologies, the rebuild test failed to catch the real problem
here:
btrfs-progs upstream's configure(.ac) uses udevdir from udev.pc.
This is great.
However: the Debian packaging then hard-codes the /lib path. When
udev.pc changes udevdir, btrfs-progs will FTBFS. Build log snippet:
...
/usr/bin/install -c -m755 -d /<>/debian/tmp/usr/lib/udev/rules.d
/usr/bin/install -c -m644 64-btrfs-dm.rules 64-btrfs-zoned.rules
/<>/debian/tmp/usr/lib/udev/rules.d
...
make[1]: Leaving directory '/<>'
debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install
dh_install: warning: Cannot find (any matches for) "lib/" (tried in .,
debian/tmp)
dh_install: warning: btrfs-progs missing files: lib/
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:45: override_dh_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:18: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
A future proof option is to do something like this:
In d/rules, set:
export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed
s,^/,,)
In d/install, use:
${env:deb_udevdir}/rules.d
Best,
Chris
Bug#995809: libinput: please make the build reproducible
On 2021-10-06, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> libinput could not be built reproducibly.
>
> This is due to the use of the LIBINPUT_QUIRKS_DIR macro which includes
> the absolute build path.
>
> It is not entirely clear (during a very brief look) when/where this
> value is even used — the testsuite still passes even if this is set to
> a dummy value (see attached dummy patch). And, of course, the build
> path cannot be relied upon at runtime.
The attached patch is an alternate approach by removing the code that
actually references the build path from various source files. It also
makes the build reproducible and the package still builds (so I presume
the test suite passes).
As Chris pointed out, the build path is not something one can rely on at
runtime, so the installed package cannot rely on it anyways.
I would like to perform an NMU in the near future, unless there are
objections?
live well,
vagrant
From 6b78d6697661c497ae4ff2a3bbf1eea53ae60ccc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 1 Dec 2023 14:17:20 -0800
Subject: [PATCH] tools: Remove references to LIBINPUT_QUIRKS_SRCDIR. (Closes:
#995809)
This embeds the build path which is not generally available at runtime and
makes it more difficult to reproduce the build.
https://reproducible-builds.org/docs/build-path/
---
tools/libinput-quirks.c | 10 ++
tools/libinput-record.c | 9 -
tools/shared.c | 12
3 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/tools/libinput-quirks.c b/tools/libinput-quirks.c
index e97eff6..7f3e26f 100644
--- a/tools/libinput-quirks.c
+++ b/tools/libinput-quirks.c
@@ -166,14 +166,8 @@ main(int argc, char **argv)
/* Overriding the data dir means no custom override file */
if (!data_path) {
- char *builddir = builddir_lookup();
- if (builddir) {
- data_path = LIBINPUT_QUIRKS_SRCDIR;
- free(builddir);
- } else {
- data_path = LIBINPUT_QUIRKS_DIR;
- override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
- }
+ data_path = LIBINPUT_QUIRKS_DIR;
+ override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
}
quirks = quirks_init_subsystem(data_path,
diff --git a/tools/libinput-record.c b/tools/libinput-record.c
index 30b2900..1de63bc 100644
--- a/tools/libinput-record.c
+++ b/tools/libinput-record.c
@@ -1762,19 +1762,10 @@ print_device_quirks(struct record_device *dev)
struct quirks_context *quirks;
const char *data_path = LIBINPUT_QUIRKS_DIR;
const char *override_file = LIBINPUT_QUIRKS_OVERRIDE_FILE;
- char *builddir = NULL;
if (stat(dev->devnode, ) < 0)
return;
- if ((builddir = builddir_lookup())) {
- setenv("LIBINPUT_QUIRKS_DIR", LIBINPUT_QUIRKS_SRCDIR, 0);
- data_path = LIBINPUT_QUIRKS_SRCDIR;
- override_file = NULL;
- }
-
- free(builddir);
-
quirks = quirks_init_subsystem(data_path,
override_file,
quirks_log_handler,
diff --git a/tools/shared.c b/tools/shared.c
index 7a73027..fcacb03 100644
--- a/tools/shared.c
+++ b/tools/shared.c
@@ -411,16 +411,6 @@ tools_open_device(const char **paths, bool verbose, bool *grab)
return li;
}
-static void
-tools_setenv_quirks_dir(void)
-{
- char *builddir = builddir_lookup();
- if (builddir) {
- setenv("LIBINPUT_QUIRKS_DIR", LIBINPUT_QUIRKS_SRCDIR, 0);
- free(builddir);
- }
-}
-
struct libinput *
tools_open_backend(enum tools_backend which,
const char **seat_or_device,
@@ -429,8 +419,6 @@ tools_open_backend(enum tools_backend which,
{
struct libinput *li;
- tools_setenv_quirks_dir();
-
switch (which) {
case BACKEND_UDEV:
li = tools_open_udev(seat_or_device[0], verbose, grab);
--
2.39.2
signature.asc
Description: PGP signature
Bug#1057237: debian-installer: Debian 12 (Bookworm) on Ace Magic T8Plus: Installation Report
Package: debian-installer Severity: normal X-Debbugs-Cc: charlescur...@charlescurley.com Dear Maintainer, I took delivery of two Ace Magic T8+ computers recently. https://www.acemagic.com/products/t8plus I am bringing one up as a router running Debian 12.2 (Bookworm). A full hardware probe of the machine is at Linux Hardware. https://linux-hardware.org/?probe=d0bbc73e29 Note that this was run over SSH, so any monitor information is incorrect. However, it does work with an NEC EA244WMi connected directly. I first used a live CD to test the machine. I then used gparted to shrink the Windows partition to 60 G, giving me 177G for Linux, plenty for this application. I then booted to Windows so that it would do any necessary fixup on its partition. I then installed using a netinst image (debian-12.2.0-amd64-netinst.iso) on a USB stick, and a second USB stick for my preseed file and some post-installation scripts. All has gone well, with one glitch. The glitch was that after the installation the T8+ refused to boot to Linux, going directly into Windows. To make the grub bootloader active after installing Linux and GRUB, in the firmware: During boot, hit escape or delete to get into the firmware. Security -> Secure Boot -> Enabled Boot -> UEFI BBS Priorities -> Debian boot option Save & Exit -> Save Changes and Exit Note: Memtest86 does not appear to work. I believe this is a problem with Memtest86, per emails on the Debian User list. Power use: 5 watts when idle, .28 KWH. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1029060: closing, uploaded way back
Control: close -1 Debian has the plugin under its new pkg name now for a while. This ITP obviously did not get closed by the upload. Closing now... Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpBrmcDXh1lB.pgp Description: Digitale PGP-Signatur
Bug#1057236: bookworm-pu: package gosa-plugins-sudo/2.8~git20211022.7ff3ed2-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gosa-plugins-s...@packages.debian.org
Control: affects -1 + src:gosa-plugins-sudo
Please accept updated package gosa-plugins-sudo to bookworm.
[ Reason ]
Fix processing sudoUser regexp when processing LDAP sudo rules.
[ Impact ]
GOsa²'s sudo plugin will behave buggy. This will be noticed by sysadmins
of Debian Edu 12.
[ Tests ]
Manual tests.
[ Risks ]
Merely none, only for users of GOsa² and its sudo plugin.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
+ * debian/patches:
++ Add 1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch.
+ Assign variable before using it.
[ Other info ]
none
diff -Nru gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/changelog
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/changelog
--- gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/changelog 2023-01-23
13:03:23.0 +0100
+++ gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/changelog 2023-12-01
23:27:03.0 +0100
@@ -1,3 +1,11 @@
+gosa-plugins-sudo (2.8~git20211022.7ff3ed2-2+deb12u1) bookworm; urgency=medium
+
+ * debian/patches:
++ Add 1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch.
+ Assign variable before using it.
+
+ -- Mike Gabriel Fri, 01 Dec 2023 23:27:03 +0100
+
gosa-plugins-sudo (2.8~git20211022.7ff3ed2-2) unstable; urgency=medium
* Source-only upload to unstable.
diff -Nru
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch
---
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch
1970-01-01 01:00:00.0 +0100
+++
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch
2023-12-01 23:26:43.0 +0100
@@ -0,0 +1,33 @@
+From a82b03aa40ee147ddc2a2a440dad18da8be5b5e1 Mon Sep 17 00:00:00 2001
+From: root
+Date: Thu, 17 Aug 2023 22:16:03 +0200
+Subject: [PATCH 06/13] plugins/admin/sudo/class_sudoGeneric.inc: Assign
+ variable before using it.
+
+---
+ admin/sudo/class_sudoGeneric.inc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/admin/sudo/class_sudoGeneric.inc
b/admin/sudo/class_sudoGeneric.inc
+index f1b1f31..d55679f 100644
+--- a/admin/sudo/class_sudoGeneric.inc
b/admin/sudo/class_sudoGeneric.inc
+@@ -297,6 +297,7 @@ class sudo extends plugin
+ /* Acceptable characters for various fields */
+ $ipv4_regex =
"^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$";
+ $fqdn_regex =
"^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])$";
++$c = preg_quote(' *+-?_|!\'"()','/');
+ $attr_regex = array(
+ "sudoUser" => "/^[a-z0-9{$c}]*$/i",
+ "sudoHost" => "/$ipv4_regex|$fqdn_regex/i",
+@@ -310,7 +311,6 @@ class sudo extends plugin
+ isset($_POST['new_'.$attr]) &&
+ !empty($_POST['new_'.$attr])){
+
+-$c = preg_quote(' *+-?_|!\'"()','/');
+ if(preg_match($attr_regex[$attr],get_post('new_'.$attr))){
+ $attrs = $this->$attr;
+ $attrs[] = trim(get_post('new_'.$attr));
+--
+2.39.2
+
diff -Nru gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/README
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/README
--- gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/README
1970-01-01 01:00:00.0 +0100
+++ gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/README
2023-12-01 23:26:43.0 +0100
@@ -0,0 +1,3 @@
+0xxx: Grabbed from upstream development.
+1xxx: Possibly relevant for upstream adoption.
+2xxx: Only relevant for official Debian release.
diff -Nru gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/series
gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/series
--- gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/series
1970-01-01 01:00:00.0 +0100
+++ gosa-plugins-sudo-2.8~git20211022.7ff3ed2/debian/patches/series
2023-12-01 23:26:43.0 +0100
@@ -0,0 +1 @@
+1001_plugins-admin-sudo-class_sudoGeneric.inc-Assign-vari.patch
Bug#1057235: bullseye-pu: package tzdata/2021a-1+deb11u11
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: tzd...@packages.debian.org, debian-gl...@lists.debian.org
Control: affects -1 + src:tzdata
[ Reason ]
tzdata contains a leap second file which is updated twice a year, and
which has an expiration date on 28 December 2023. Usually this file is
updated along with timezones changes, but 2023 has seen surprising low
number of timezone changes. Therefore we need to do a specific upload to
update this file with only this change.
In addition a typo in the Egypt DST rules changes has slipped into
version 2021a-1+deb11u9 and is fixed by this new version.
[ Impact ]
There is no leap second added at the end of 2023, so the impact is
relatively low, but people using NTP servers started to complain about
about warning in their log.
[ Tests ]
There is no test for this change.
[ Risks ]
The risk is quite low, the changes are minimal and routinely done twice
a year.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
This is the full changelog entry with explanations:
* Cherry-pick patches from upstream:
- 25-no-leap-second-on-2023-12-31.patch: Update leap-seconds.list from
upstream. The new expiration date is 28 June 2024. Closes: #1057185,
#1057186.
The leap-seconds.list change is taken from upstream, who took it from
NIST following an IERS Bulletin.
- 26-egypt-dst-fix.patch: Fix a typo in the Egypt change introduced in
tzdata 2021a-1+deb11u9. Closes: #1036104.
The patch 20-egypt-dst.patch added from upstream in tzdata 2021a-1+deb11u9
contains a single letter typo ('M' instead of 'm'), causing issues with some
parsers. This has been fixed upstream in subsequent commit, which is backported
here.
* debian/clean: Remove leapseconds during clean target.
The cleanup of the leapseconds file, is needed as following the above
change, the one shipped in the upstream tarball do not match anymore the
one generated during build from leap-seconds.list. This is needed to
avoid a FTBFS after successful build.
[ Other info ]
Given the limited changes, I have already uploaded the package to the
archive. Thanks for considering. It might be a good idea to release a
SUA given the next bullseye point release is not yet scheduled.
diff -Nru tzdata-2021a/debian/changelog tzdata-2021a/debian/changelog
--- tzdata-2021a/debian/changelog 2023-04-18 20:03:16.0 +
+++ tzdata-2021a/debian/changelog 2023-12-01 21:51:38.0 +
@@ -1,3 +1,15 @@
+tzdata (2021a-1+deb11u11) bullseye; urgency=medium
+
+ * Cherry-pick patches from upstream:
+- 25-no-leap-second-on-2023-12-31.patch: Update leap-seconds.list from
+ upstream. The new expiration date is 28 June 2024. Closes: #1057185,
+ #1057186.
+- 26-egypt-dst-fix.patch: Fix a typo in the Egypt change introduced in
+ tzdata 2021a-1+deb11u9. Closes: #1036104.
+ * debian/clean: Remove leapseconds during clean target.
+
+ -- Aurelien Jarno Fri, 01 Dec 2023 22:51:38 +0100
+
tzdata (2021a-1+deb11u10) bullseye; urgency=medium
* Cherry-pick patch from upstream:
diff -Nru tzdata-2021a/debian/clean tzdata-2021a/debian/clean
--- tzdata-2021a/debian/clean 1970-01-01 00:00:00.0 +
+++ tzdata-2021a/debian/clean 2023-12-01 21:32:18.0 +
@@ -0,0 +1 @@
+leapseconds
diff -Nru tzdata-2021a/debian/patches/25-no-leap-second-on-2023-12-31.patch
tzdata-2021a/debian/patches/25-no-leap-second-on-2023-12-31.patch
--- tzdata-2021a/debian/patches/25-no-leap-second-on-2023-12-31.patch
1970-01-01 00:00:00.0 +
+++ tzdata-2021a/debian/patches/25-no-leap-second-on-2023-12-31.patch
2023-12-01 20:47:11.0 +
@@ -0,0 +1,41 @@
+From c3e966c59b02b1f47f0b7b0e4aa6a86563c07062 Mon Sep 17 00:00:00 2001
+From: Tim Parenti
+Date: Mon, 14 Aug 2023 15:29:57 -0400
+Subject: [PATCH] No leap second on 2023-12-31
+
+Per IERS Bulletin C 66 (2023-07-04).
+https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.66
+
+* leap-seconds.list: Update file from NIST, retrieved from
+ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list
+---
+ leap-seconds.list | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/leap-seconds.list b/leap-seconds.list
+index 17e3a100..3fe9a121 100644
+--- a/leap-seconds.list
b/leap-seconds.list
+@@ -204,10 +204,10 @@
+ # current -- the update time stamp, the data and the name of the file
+ # will not change.
+ #
+-# Updated through IERS Bulletin C65
+-# File expires on: 28 December 2023
++# Updated through IERS Bulletin C66
++# File expires on: 28 June 2024
+ #
+-#@3912710400
++#@3928521600
+ #
+ 227206080010 # 1 Jan 1972
+ 228778560011 # 1 Jul 1972
+@@ -252,4 +252,4 @@
+ # the hash
Bug#1057234: sbuild: Generates weird messages in /var/log/syslog
Package: sbuild
Version: 0.85.0
Severity: normal
I run sbuild as following:
sbuild --no-run-lintian --arch-all --dist=sid *.dsc -d unstable-amd64-sbuild
, where unstable-amd64-sbuild references a chroot. Updating the chroot is done:
sudo sbuild-update -udcar unstable-amd64-sbuild
Both commands generate weird messages in /var/log/syslog like this:
2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]: [unstable-
amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot] (root->root) Running
command: "perl -e #012use strict;#012
use warnings;#012use POSIX;#012
Sample file is attached. These #012 are page feed chars IIRC. Unfortunately
logcheck is not able to handle the situation and generates E-Mails, which
report the full command line by line. There is definitely a white list rule for
schroot in /etc/logcheck/ignore.d.server/schroot, but it is not able to handle
the lot of special characters. Consider to not print the full perl script into
the log file (if possible).
It may be an issue in logcheck, but rather prefer to avoid message instead of
trying to white list afterwards.
Hilmar
-- System Information:
Debian Release: 12.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sbuild depends on:
ii adduser 3.134
ii libsbuild-perl 0.85.0
ii perl5.36.0-7
Versions of packages sbuild recommends:
ii autopkgtest 5.28
ii debootstrap 1.0.128+nmu2
ii schroot 1.6.13-3+b2
pn uidmap
Versions of packages sbuild suggests:
ii deborphan 1.7.35
ii e2fsprogs 1.47.0-2
ii kmod 30+20221128-1
ii wget 1.21.3-1+b2
-- no debconf information
2023-12-01T09:36:51.872961+01:00 haka2 schroot[3159]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "getent group sbuild"
2023-12-01T09:36:51.903873+01:00 haka2 schroot[3161]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "getent passwd sbuild"
2023-12-01T09:36:51.918894+01:00 haka2 schroot[3163]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "getent passwd root"
2023-12-01T09:36:51.933531+01:00 haka2 schroot[3165]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "/bin/sh -c set -e; if [ ! -d /build ] ; then
mkdir -p -m 0775 /build; fi"
2023-12-01T09:36:51.953954+01:00 haka2 schroot[3167]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "chown sbuild:sbuild /build"
2023-12-01T09:36:51.969383+01:00 haka2 schroot[3169]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "chmod 02770 /build"
2023-12-01T09:36:51.984742+01:00 haka2 schroot[3171]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "/bin/sh -c set -e; if [ ! -d /var/lib/sbuild ] ;
then mkdir -m 2775 /var/lib/sbuild; fi"
2023-12-01T09:36:51.999574+01:00 haka2 schroot[3173]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "/bin/sh -c set -e; if [ ! -d
/var/lib/sbuild/srcdep-lock ] ; then mkdir -m 2770 /var/lib/sbuild/srcdep-lock;
fi"
2023-12-01T09:36:52.014331+01:00 haka2 schroot[3175]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "chown -R sbuild:sbuild /var/lib/sbuild"
2023-12-01T09:36:52.030178+01:00 haka2 schroot[3177]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "chmod 02775 /var/lib/sbuild"
2023-12-01T09:36:52.044707+01:00 haka2 schroot[3179]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "/usr/bin/debconf-set-selections"
2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]:
[unstable-amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot]
(root->root) Running command: "perl -e #012use strict;#012use
warnings;#012use POSIX;#012use FileHandle;#012#012my
$lockfile="/var/lock/sbuild";#012my $try = 0;#012#012 repeat:#012if
(!sysopen( F, $lockfile, O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0644 )){#012#011if
($! == EEXIST) {#012#011# lock file exists, wait#012#011goto repeat if
!open( F, "<$lockfile" );#012#011my $line = ;#012#011my ($job, $pid,
$user);#012#011close( F );#012#011if ($line !~
/^(\S+)\s+(\S+)\s+(\S+)/) {#012#011#011print STDERR "Bad lock
Bug#1057233: pipewire-bin: installs files into /lib/udev/rules.d
Package: pipewire-bin Version: 1.0.0-1 Severity: normal User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs the file /lib/udev/rules.d/90-pipewire-alsa.rules. For the ongoing UsrMerge effort [1], /lib needs to become "empty", IOW no package should install a file there. Instead, files should be installed into /usr/lib. Apparently the path in /lib is hard-coded, either in the upstream build system or the packaging. Please change your package to install into /usr/lib/udev/rules.d at your earliest convenience. Per the wiki, it is useful to first upload to experimental and wait a few days for the dumat tool to evaluate the change, and only then upload to unstable. At a later point during the trixie cycle, I expect this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge
Bug#1057232: casync: installs files into /lib/udev/rules.d
Package: casync Version: 2+20201210-1 Severity: normal User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs the file /lib/udev/rules.d/75-casync.rules. For the ongoing UsrMerge effort [1], /lib needs to become "empty", IOW no package should install a file there. Instead, files should be installed into /usr/lib. Apparently the path in /lib is hard-coded, either in the upstream build system or the packaging. Please change your package to install into /usr/lib/udev/rules.d at your earliest convenience. Per the wiki, it is useful to first upload to experimental and wait a few days for the dumat tool to evaluate the change, and only then upload to unstable. At a later point during the trixie cycle, I expect this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge
Bug#1057231: btrfs-progs: installs files into /lib/udev/rules.d
Package: btrfs-progs Version: 6.3.2-1 Severity: normal User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs the files /lib/udev/rules.d/64-btrfs-dm.rules and /lib/udev/rules.d/64-btrfs-zoned.rules. For the ongoing UsrMerge effort [1], /lib needs to become "empty", IOW no package should install a file there. Instead, files should be installed into /usr/lib. Apparently these paths are hard-coded, either in the upstream build system or the packaging. Please change your package to install into /usr/lib/udev/rules.d at your earliest convenience. Per the wiki, it is useful to first upload to experimental and wait a few days for the dumat tool to evaluate the change, and only then upload to unstable. At a later point during the trixie cycle, I expect this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge
Bug#1057230: pygtkspellcheck: Please update to latest.
Package: pygtkspellcheck Dear Python Team, Please update pygtkspellcheck to latest. Interesting bugs: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042663 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041994 Wants: * GTK 4 support from latest. Regards Phil -- Playing the game for the games sake. * Debian Maintainer Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org Social: * Instagram: kathenasorg * Threads: @kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1057229: brightness-udev: installs file into /lib/udev/rules.d
Package: brightness-udev Version: 0.5.1-3 Severity: normal User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs the file /lib/udev/rules.d/90-brightnessctl.rules. Apparently this path is hard-coded, either in the upstream build system or the packaging. For the ongoing UsrMerge effort [1], /lib needs to become "empty", IOW no package should install a file there. Instead, files should be installed into /usr/lib. Please change your package to install into /usr/lib/udev/rules.d at your earliest convenience. Per the wiki, it is useful to first upload to experimental and wait a few days for the dumat tool to evaluate the change, and only then upload to unstable. At a later point during the trixie cycle, I expect this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge
Bug#1057228: dolphin-emu: Installs file into /lib/udev/rules.d
Package: dolphin-emu Version: 5.0-19870+dfsg-1 Severity: normal User: helm...@debian.org Usertags: dep17m2 Dear Maintainer, your package installs a file into /lib/udev/rules.d (a udev rule). Apparently this location is hard-coded. For the ongoing UsrMerge effort [1], /lib needs to become "empty", IOW no package should install a file there. Instead, files should be installed into /usr/lib. Please change your package to install into /usr/lib/udev/rules.d at your earliest convenience. Per the wiki, it is useful to first upload to experimental and wait a few days for the dumat tool to evaluate the change, and only then upload to unstable. At a later point during the trixie cycle, I expect this bug will become release-critical. Thanks for considering, Chris [1] https://wiki.debian.org/UsrMerge
Bug#1056992: freerdp2: Please package version 3
On Tue, Nov 28, 2023 at 12:39 PM Mike Gabriel wrote: > my overall idea would be to upload a new freerdp3 src:pkg like we did > for freerdp(1) -> freerd2. That's fine with me. Here are the release notes: https://github.com/FreeRDP/FreeRDP/releases Thank you, Jeremy Bícha
Bug#1057227: gnuradio: gr_filter_design crashes with type error
Package: gnuradio Version: 3.10.8.0-1+b2 Severity: normal X-Debbugs-Cc: deb...@isomer.meta.net.nz Dear Maintainer, Running gr_filter_design from the command line fails with: $ gr_filter_design QSettings::value: Empty key passed QSettings::value: Empty key passed Traceback (most recent call last): File "/usr/bin/gr_filter_design", line 15, in filter_design.main(sys.argv) File "/usr/lib/python3/dist-packages/gnuradio/filter/filter_design.py", line 2375, in main gplt = gr_plot_filter(options) ^^^ File "/usr/lib/python3/dist-packages/gnuradio/filter/filter_design.py", line 114, in __init__ self.gui.setupUi(self) File "/usr/lib/python3/dist-packages/gnuradio/filter/pyqt_filter_stacked.py", line 71, in setupUi self.freqPlot = GrFilterPlotWidget(self.freqTab) File "/usr/lib/python3/dist-packages/gnuradio/filter/GrFilterPlotWidget.py", line 7, in __init__ PlotWidget.__init__(self, parent, background, File "/usr/lib/python3/dist-packages/pyqtgraph/widgets/PlotWidget.py", line 51, in __init__ GraphicsView.__init__(self, parent, background=background) File "/usr/lib/python3/dist-packages/pyqtgraph/widgets/GraphicsView.py", line 61, in __init__ QtWidgets.QGraphicsView.__init__(self, parent) TypeError: arguments did not match any overloaded call: QGraphicsView(parent: Optional[QWidget] = None): argument 1 has unexpected type 'QWidget' QGraphicsView(scene: Optional[QGraphicsScene], parent: Optional[QWidget] = None): argument 1 has unexpected type 'QWidget' -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnuradio depends on: ii konsole [x-terminal-emulator] 4:23.08.1-1 ii libboost-program-options1.74.0 1.74.0+ds1-23 ii libc6 2.37-12 ii libfmt9 9.1.0+ds1-2 ii libgcc-s1 13.2.0-7 ii libgmp102:6.3.0+dfsg-2 ii libgnuradio-analog3.10.83.10.8.0-1+b2 ii libgnuradio-audio3.10.8 3.10.8.0-1+b2 ii libgnuradio-blocks3.10.83.10.8.0-1+b2 ii libgnuradio-channels3.10.8 3.10.8.0-1+b2 ii libgnuradio-digital3.10.8 3.10.8.0-1+b2 ii libgnuradio-dtv3.10.8 3.10.8.0-1+b2 ii libgnuradio-fec3.10.8 3.10.8.0-1+b2 ii libgnuradio-fft3.10.8 3.10.8.0-1+b2 ii libgnuradio-filter3.10.83.10.8.0-1+b2 ii libgnuradio-iio3.10.8 3.10.8.0-1+b2 ii libgnuradio-network3.10.8 3.10.8.0-1+b2 ii libgnuradio-pdu3.10.8 3.10.8.0-1+b2 ii libgnuradio-pmt3.10.8 3.10.8.0-1+b2 ii libgnuradio-qtgui3.10.8 3.10.8.0-1+b2 ii libgnuradio-runtime3.10.8 3.10.8.0-1+b2 ii libgnuradio-soapy3.10.8 3.10.8.0-1+b2 ii libgnuradio-trellis3.10.8 3.10.8.0-1+b2 ii libgnuradio-uhd3.10.8 3.10.8.0-1+b2 ii libgnuradio-video-sdl3.10.8 3.10.8.0-1+b2 ii libgnuradio-vocoder3.10.8 3.10.8.0-1+b2 ii libgnuradio-wavelet3.10.8 3.10.8.0-1+b2 ii libgnuradio-zeromq3.10.83.10.8.0-1+b2 ii libjs-mathjax 2.7.9+dfsg-1 ii libqt5core5a5.15.10+dfsg-5 ii libqt5widgets5 5.15.10+dfsg-5 ii libsoapysdr0.8 0.8.1-4 ii libspdlog1.12 [libspdlog1.12-fmt9] 1:1.12.0+ds-2 ii libstdc++6 13.2.0-7 ii libuhd4.6.0 4.6.0.0+ds1-3 ii libvolk-bin 3.0.0-2 ii libvolk3.0 3.0.0-2 ii mlterm [x-terminal-emulator]3.9.3-1 ii python3 3.11.4-5+b1 ii python3-click 8.1.6-1 ii python3-click-plugins 1.1.1-4 ii python3-gi 3.46.0-1 ii python3-gi-cairo3.46.0-1 ii python3-jsonschema 4.10.3-2 ii python3-lxml4.9.3-1 ii python3-mako1.2.4+ds-2 ii python3-numpy [python3-numpy-abi9] 1:1.24.2-1 ii python3-opengl 3.1.6+dfsg-4 ii python3-packaging 23.2-1 ii python3-pygccxml2.4.0-1 ii python3-pyqt5 5.15.10+dfsg-1 ii python3-pyqtgraph 0.13.3-1 ii python3-schema 0.7.5-1 ii python3-sip 4.19.25+dfsg-5+b1 ii python3-thrift 0.19.0-2 ii python3-yaml6.0.1-1 ii
Bug#1057226: golang-github-go-resty-resty: CVE-2023-45286
Source: golang-github-go-resty-resty Version: 2.10.0-1 Severity: important Tags: security upstream Forwarded: https://github.com/go-resty/resty/pull/745 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-github-go-resty-resty. CVE-2023-45286[0]: | A race condition in go-resty can result in HTTP request body | disclosure across requests. This condition can be triggered by | calling sync.Pool.Put with the same *bytes.Buffer more than once, | when request retries are enabled and a retry occurs. The call to | sync.Pool.Get will then return a bytes.Buffer that hasn't had | bytes.Buffer.Reset called on it. This dirty buffer will contain the | HTTP request body from an unrelated request, and go-resty will | append the current HTTP request body to it, sending two bodies in | one request. The sync.Pool in question is defined at package level | scope, so a completely unrelated server could receive the request | body. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-45286 https://www.cve.org/CVERecord?id=CVE-2023-45286 [1] https://github.com/go-resty/resty/pull/745 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1053800: transition: libgit2
Hi Timo On 2023-11-04 21:34:29 +0100, Timo Röhling wrote: > * Sebastian Ramacher [2023-11-01 12:14]: > > There are no replies on the bug report. Are there any news regarding the > > rust bindings? > No, nothing yet. All uploads in the past two years came from Peter Michael > Green, so I am going to ping him directly. > > > > golang-github-libgit2-git2go upstream has fallen behind and > > Same as above. Are there any news here? > No. I was prepared to ignore the Go bindings completely after they got > removed from trixie, but Mohammed Bilal did an upload to fix the RC bug, > presumably because they are a build dependency of gitlab. > I'll ping him, too. Hoping that there are some good news regarding the bindings. What's the current status? Cheers -- Sebastian Ramacher
Bug#1057175: transition: libsfml
Control: tags -1 confirmed On 2023-12-01 01:34:53 +, James Cowgill wrote: > Package: release.debian.org > Control: affects -1 + src:libsfml > X-Debbugs-Cc: libs...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Hi, > > libsfml needs a transition due to an ABI bump from 2.5 to 2.6. It's > currently in experimental and built everywhere except mips64el where > it's waiting to be built. Please go ahead. Cheers -- Sebastian Ramacher
Bug#986713: gpsd: please stop build-depending on makedev
Hi, * Chris Hofstaedtler [231201 21:06]: > * Chris Hofstaedtler [210820 11:47]: > > your package build-depends on makedev, which itself is long > > obsolete. Please consider replacing makedev. > > I know that this was tried in gpsd 3.5-5, and apparently caused an > issue on mips. However, mips itself is long gone, and the mipsel > build log for 3.5-5 doesn't show a problem. > > Would you consider trying removing makedev from Build-Depends once > again? Pinging this bug; I'd really like gpsd to drop its Build-Depends on makedev. Various efforts in Debian are trying to avoid necessarily having "real root" powers during package build. However, makedev creates device nodes at install time, which fails in all of these "reduced root" build environments. Thanks for considering, Chris
Bug#1057117:
Neil, Thank you for taking to time to test my packaging efforts and submit a bug report. I just did a quick test and was unable to reproduce your bug on Debian testing. This weekend when I have a little more time I'll try setting up a clean Debian unstable environment and try again. $ mkdir hello && cd hello && swift package init --type executable Creating executable package: hello Creating Package.swift Creating README.md Creating .gitignore Creating Sources/ Creating Sources/hello/main.swift Creating Tests/ Creating Tests/helloTests/ Creating Tests/helloTests/helloTests.swift $ swift build Building for debugging... [6/6] Linking hello Build complete! (1.16s) $ .build/x86_64-pc-linux-gnu/debug/hello Hello, world! $ -Steve
Bug#1057225: scribus: Laggy interface
Package: scribus Version: 1.5.8+dfsg-4+b4 Severity: important X-Debbugs-Cc: g.fic...@stardata.it Dear Maintainer, I've been trying to create a photobook with Scribus, but the interface is extremely laggy, so much so that I can't use the software. The easiest way to reproduce the bug on my system has been to: * create a new doc: 32 pages, A4 format, with facing pages and units in millimeters * try to add an image box in the first page on my system (AMD Ryzen 7 7700, 32G ram, Radeon RX 6800, 4k LG monitor) it takes one or two seconds for the tool to follow the movement of the mouse cursor and draw the image box shape. Even the rulers on top and left of the main window lag behind the mouse movement, so it might be an issue with another layer of the graphic stack, but I have noticed the problem only in Scribus (Krita works ok for example). Please let me know if I can provide more info that will help you. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages scribus depends on: ii ghostscript 10.02.1~dfsg-1 ii libc62.37-12 ii libcairo21.18.0-1 ii libcdr-0.1-1 0.1.7-1 ii libcups2 2.4.7-1 ii libfontconfig1 2.14.2-6 ii libfreehand-0.1-10.1.2-3 ii libfreetype6 2.13.2+dfsg-1 ii libgcc-s113.2.0-7 ii libgraphicsmagick-q16-3 1.4+really1.3.42-1 ii libharfbuzz-icu0 8.0.1-1 ii libharfbuzz-subset0 8.0.1-1 ii libharfbuzz0b8.0.1-1 ii libhunspell-1.7-01.7.2+really1.7.2-10 ii libicu72 72.1-4 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-2 2.14-2 ii libmspub-0.1-1 0.1.4-3+b3 ii libopenscenegraph161 3.6.5+dfsg1-8+b4 ii libopenthreads21 3.6.5+dfsg1-8+b4 ii libpagemaker-0.0-0 0.0.4-1 ii libpng16-16 1.6.40-2 ii libpodofo0.9.8 0.9.8+dfsg-3+b2 ii libpoppler12622.12.0-2+b1 ii libpython3.113.11.6-3 ii libqt5core5a 5.15.10+dfsg-5 ii libqt5gui5 5.15.10+dfsg-5 ii libqt5network5 5.15.10+dfsg-5 ii libqt5opengl55.15.10+dfsg-5 ii libqt5printsupport5 5.15.10+dfsg-5 ii libqt5widgets5 5.15.10+dfsg-5 ii libqt5xml5 5.15.10+dfsg-5 ii libqxp-0.0-0 0.0.2-1+b3 ii librevenge-0.0-0 0.0.5-3 ii libstdc++6 13.2.0-7 ii libtiff6 4.5.1+git230720-2 ii libvisio-0.1-1 0.1.7-1+b3 ii libxml2 2.9.14+dfsg-1.3 ii libzmf-0.0-0 0.0.2-1+b5 ii scribus-data 1.5.8+dfsg-4 ii zlib1g 1:1.3.dfsg-3 Versions of packages scribus recommends: ii cups-bsd2.4.7-1 ii fonts-dejavu2.37-8 ii fonts-liberation1:2.1.5-3 ii hyphen-en-us [hyphen-hyphenation-patterns] 2.8.8-7 ii icc-profiles-free 2.0.1+dfsg-1.1 ii xfonts-scalable 1:1.0.3-1.3 Versions of packages scribus suggests: pn icc-profiles pn scribus-doc pn scribus-template pn texlive-latex-recommended -- no debconf information
Bug#1057185: tzdata: leap-seconds.list expires in 28 December 2023 for Bullseye
Hello, thank you. You are correct that there is no impact besides the warning message for this year. This message triggering many emails multiple times a day from 60 logcheck supervised machines is an impact, though. Thus, may I kindly ask what circumstances are prohibiting an update *before* this message starts to appear? For future occasions. Again, thank you. :wq! PoC
Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test
Santiago Vila wrote: > The message about jobserver disappeared when I disabled parallel build. > I guess it is some kind of Makefile bug. The message was: warning: jobserver unavailable: using -j1. To me, this sounds like 'make' could not create a jobserver, because the jobservers rely on named pipes [1] and the reporter says he's in a chroot. Some file names may not be allowed in a chroot, or some directory may be missing. I don't see this as a Makefile bug, but rather as a limitation of the specific chroot environment. Bruno [1] https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html
Bug#1057185: tzdata: leap-seconds.list expires in 28 December 2023 for Bullseye
Hi,
On 2023-12-01 10:23, Vincas Dargis wrote:
> Package: tzdata
> Version: 2021a-1+deb11u10
> Severity: important
>
> Dear Maintainer,
>
> I've started seeing these kind of log messages via logcheck on our
> oldstable machines:
>
> ```
> Dec 1 08:06:43 dev ntpd[963]: leapsecond file
> ('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 27
> days
> ```
>
> It will expire at the end of the year:
>
> ```
> $ fgrep expires /usr/share/zoneinfo/leap-seconds.list
> # File expires on: 28 December 2023
> ```
There is an update in progress that should arrive in a few days. Note
that there is no leap second at the end of the yes, so there is no
impact besides the warning message.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1057186: tzdata: NTP complains about an expiring leap-seconds.list
control: fixed 1057186 2023c-5+deb12u1
Hi,
On 2023-12-02 06:16, Paul Szabo wrote:
> found 1057186 2023c-5
> thanks
>
> Same issue on bookworm, syslog shows:
>
> Dec 1 11:04:23 machine ntpd[PID]: CLOCK: leapsecond file
> ('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 27 days
>
> with tzdata version 2023c-5.
For bookworm, this is bug is fixed in version 2023c-5+deb12u1 that will
be available in the next point release.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1057223: librust-futures-util-dev: fails to install: depends on missing librust-h2-0.3+default-dev (>= 0.3.17-~~)
Control: retitle -1 librust-futures-util-dev: fails to install: depends on missing librust-futures-io-0.3+std-dev Quoting Jonas Smedegaard (2023-12-01 20:46:33) > Impossible to install, as it depends on non-existent package > librust-h2-0.3+default-dev (>= 0.3.17-~~). Correction: librust-futures-io-0.3+std-dev (>= 0.3.29-~~) is the missing package (librust-h2 is instead affected by it, along with 66 other direct reverse dpeendencies). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
On Fri, 1 Dec 2023, Lorenzo wrote:
>> > > Even the cronjob is gone.
>> >
>> > sorry, the patch does not include cronjob since o-s-s does not have
>> > a way to handle it.
>>
>> Couldn't it be appended to crontab?
>there is no mechanism to selectively add (and remove/purge) additional
>file or snippets such as cronjobs or /etc/default/*
But you can write the cronjobs so that they are inert if the
dæmon is absent (which should be done anyway), and users can
chmod -x files in /etc/cron.{hourly,daily,weekly,monthly} to
disable them (however not for /etc/cron.d/ though).
OTOH, the cronjob removal is n̲o̲t̲ something agreed upon. This
is maybe something to take to d-devel.
bye,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1057224: ITP: golang-github-microsoft-dev-tunnels -- Dev Tunnels SDK
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-microsoft-dev-tunnels Version : 0.0.25-1 Upstream Author : Microsoft Corporation * URL : https://github.com/microsoft/dev-tunnels * License : Expat Programming Lang: Go Description : Dev Tunnels SDK (Go library) Dev tunnels allows developers to securely expose local web services to the Internet, control who has access, and easily & debug your web applications from anywhere. Learn more at https://aka.ms/devtunnels/docs Reason for packaging: Dependency of gh (>= 2.36.0)
Bug#1057223: librust-futures-util-dev: fails to install: depends on missing librust-h2-0.3+default-dev (>= 0.3.17-~~)
Package: librust-futures-util-dev Version: 0.3.29-1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Impossible to install, as it depends on non-existent package librust-h2-0.3+default-dev (>= 0.3.17-~~). -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVqOBYACgkQLHwxRsGg ASGxPw/+JeFgGm4jAUIt9lkK/nmYRrYLKWTbXF+/A6KC+ba+d9oNNN4Fd+JqdkOr 2L1Ij4A7wbivOITr8bJ4jVX4fOtp7fE/d6EjkuZ0X+RmdKgf/t8cFByCI1YL8Jz8 NXSRrhLH+UrXTqWL+9tuDMe9MFjU8FWwzAQ+Rb5dFAZtEv2uVXfDISP73YqLAnSO C0DiuwRf5Jjn+qkN27IHcbQtQY3wQY6um5XHy9Um0h3Bxhku+/id4LYNezz/0Mqm 3VAYWclRU0BU82mbQr/Sf1YYDTxpUOQVLXVqcwwHAWGIXqUWzqZyPODo527W8Mqz bNi5e+i42fcwjvezf69mPK0dzXgLWl2sybaW3UrixZYvsmvPLMjC/D4JmZnb9zSO scLQXUn9qdv2J31VWc/tpc3vpKQChxE5OA03X0FyEOh7sotCWLIGBOHqwbfQcOmD 9s6UBacUBgKbSVVoauqjAhiCX0RGjCXTQBu7nvh+FZ68IfBxFshNtCOtK/oyIH6w IOSr6UpAh9tn+R+m0TjyUsUGk7/9OfN/3Oe560o5fRsWviSeQ+3p5xVP826Cccjc K/T3x6QBvps+Nug7Hu0D555U7V96WVKLVe5tDk2ui8mTpgcAqkrCmvyf4venbwIx Law5m80NFK2bnoTpSgnK1M/aE/eXf2ZZ45jnrEmwIAHeDjQkNJs= =A/wq -END PGP SIGNATURE-
Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test
El 30/11/23 a las 19:26, Bruno Haible escribió:
hello.c: In function 'main':
hello.c:31:63: warning: implicit declaration of function 'getpid'
[-Wimplicit-function-declaration]
31 | printf (_("This program is running as process number %d."), getpid
());
| ^~
This warning was fixed by the gettext-tools/examples/hello-c/hello.c change in
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=eb0ded32dbcd7bf6ccffc038509983ccca52631b
Thanks a lot. Yes, the warning disappeared when I applied such commit.
The message about jobserver disappeared when I disabled parallel build.
I guess it is some kind of Makefile bug.
But I did not manage to make it work, so I decided to disable the test
for now.
Thanks.
Bug#1057186: tzdata: NTP complains about an expiring leap-seconds.list
found 1057186 2023c-5
thanks
Same issue on bookworm, syslog shows:
Dec 1 11:04:23 machine ntpd[PID]: CLOCK: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 27 days
with tzdata version 2023c-5.
Thanks, Paul
--
Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics University of SydneyAustralia
Join the Union and fight for a better University: www.nteu.au/join
Bug#1055020: further informations
El 29/10/23 a las 14:08, cage escribió: Maybe this reports could be useful someway: https://savannah.gnu.org/bugs/?64748 Yes, it helped. But I was unable to reproduce the bug. So what I did is to apply all the patches for po-mode from git (the one in the URL above and others). I assume that will work in your case, but I'm not sure. If it does not work, please reopen. Thanks.
Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management
Hi Colin,
Colin King (gmail) ezt írta (időpont: 2023.
dec. 1., P, 18:47):
>
> Hi Balint,
>
>
> On 16/11/2023 18:55, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Colin King (gmail) ezt írta (időpont: 2023.
> > nov. 16., Cs, 17:46):
> >>
> >> Hi Balint,
> >>>
> >>> Since libtypec installs include files and libs to the standard
> >>> locations actually there is no need to set those paths.
> >>> I think I would use the following patch:
> >>>
> >>> --- a/libtypec.pc.in
> >>> +++ b/libtypec.pc.in
> >>> @@ -1,12 +1,9 @@
> >>>prefix=/usr
> >>>exec_prefix=/usr
> >>> -libdir=${exec_prefix}/lib/x86_64-linux-gnu
> >>> -includedir=${prefix}/
> >>>
> >>>Name: libtypec
> >>>Description: USB-Type C and USB Power Delivery class devices
> >>>Version: 0.4.0
> >>>
> >>>Requires:
> >>> -Libs: -L${libdir} -llibtypec
> >>> -Cflags: -I${includedir}
> >>> +Libs: -llibtypec
> >>>
> >
> > I think this patch application did not work out as intended, please
> > check the patched file.
> >
> > The symbols file's first line is also still off and now the symbos
> > have debian package revisions.
> >
> > Those are issues automatically detected by Lintian. I suggest running
> > lintian on the built binary packages' .changes file or populating the
> > packaging repository on Salsa where CI runs include lintian and many
> > other checks.
>
> I ran lintian but I didn't see the errors, I used:
>
> lintian --profile=debian --pedantic libtypec_0.4-3_source.changes
>
> perhaps there are some extra lintian flags or config settings that I'm
> missing. Any suggestions?
Yes, please run Lintian on the _binary_ packages. You ran
dpkg-buildpackage with -S, that generated a source only build.
This can be seen from the *_source.changes name.
If you don't pass -S to dpkg it will build the binaries as well, with
the *_amd64.changes file (assuming you build on amd64)
Cheers,
Balint
>
> Colin
>
>
>
> >
> > Cheers,
> > Balint
> >
> >> Ah, good idea. I've refreshed package with this change. Also updated the
> >> .symbols file and uploaded a -4 to mentors.
> >>
> >> Colin
>
>
>
Bug#1057222: pwnam: couldn't get password of "loginname" xscreensaver-auth exited with signal 6
Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: important
Hi,
we are using Debian 12.2 with XFCE/lightdm, NIS to authenticate
users.
xscreensaver -no-splash is started automatically during login
When manually locking the screen e.g. calling xscreensaver-setting ->
"Lock Screen Now" the screen will be locked successfully but unlocking
the screen pressing a key or mouse button will fail:
a) the unlock screen doesn't pop up
b) also typing the password blindly doesn't unlock the screen
These messages can be found in ~/.xsession-errors when activating
verbose xscreensaver messages:
xscreensaver: 19:21:58: pid 12151: launched xscreensaver-auth --verbose
xscreensaver-auth: 19:21:58: pwnam: couldn't get password of "loginname"
xscreensaver-auth: 19:21:58: initial effective uid/gid was root/thp (0/5000)
xscreensaver-auth: 19:21:58: changed uid/gid to loginname/thp (uid/5000)
xscreensaver-auth: 19:21:58: running as user "loginname"
xscreensaver-auth: 19:21:58: PAM: pam_start ("xscreensaver", "loginname", ...)
==> 0 (Success)
xscreensaver-auth: 19:21:58: pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)
xscreensaver-auth: 19:21:58: pam_authenticate (...) ...
xscreensaver-auth: 19:21:58: pam_conversation (ECHO_OFF="Password: ") ...
xscreensaver-auth: 19:21:58: mouse is at 416,457 on monitor 3 2560x1440+0+0
"HDMI2"
xscreensaver-auth: 19:21:58: theme: default
xscreensaver: 19:21:58: pid 12151: xscreensaver-auth exited with signal 6
xscreensaver: 19:21:58: authorization failed
On the web I couldn't find any solutions for
- xscreensaver-auth exited with signal 6
- pwnam: couldn't get password of "loginname"
I'm not sure how to investigate possible pam issues with xscreensaver...
-- System Information:
Debian Release: 12.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xscreensaver depends on:
ii init-system-helpers 1.65.2
ii libatk1.0-0 2.46.0-5
ii libc62.36-9+deb12u3
ii libcrypt11:4.4.33-2
ii libglib2.0-0 2.74.6-2
ii libgtk-3-0 3.24.38-2~deb12u1
ii libpam0g 1.5.2-6+deb12u1
ii libsystemd0 252.17-1~deb12u1
ii libx11-6 2:1.8.4-2+deb12u2
ii libxext6 2:1.3.4-1+b1
ii libxft2 2.3.6-1
ii libxi6 2:1.8-1+b1
ii libxinerama1 2:1.1.4-3
ii libxml2 2.9.14+dfsg-1.3~deb12u1
ii libxrandr2 2:1.5.2-2+b1
ii libxt6 1:1.2.1-1.1
ii libxxf86vm1 1:1.1.4-1+b2
ii xscreensaver-data6.06+dfsg1-3
Bug#1057221: bullseye-pu: package opendkim/2.11.0~beta2-4+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: opend...@packages.debian.org
Control: affects -1 + src:opendkim
(The same as #1056732, this time targeting oldstable)
After sponsoring the maintainer David Bürgin I've offered them to tackle
s-p-u and o-s-p-u, addressing CVE-2022-48521. (Details: RFS #1056285)
Before the upload, stable and sid were at the same version,
namely 2.11.0~beta2-8, so the patch could been applied as is,
without changes needed. Additional changes, not suitable for s-p-u
have been dropped.
The patch is authored by David Bürgin and they confirm that they have
tested the patch and it indeeds fix the issue (quote from #1056285#19):
> Hello Tobi,
>
> > A question to that: Can you elaborate a bit on the testing you have
> > done to verify that this patch indeed fixes the vulnerability?
> > (Asking, becasue unfortunatly there is not lot of information available
> > e.g from the upstream issue and upstream seems to be generally very
> > silent…
> I developed the upstream patch, and so did do the necessary testing
> locally. You can simply prepare a crafted message containing some
> Authentication-Results headers and then see if the right ones get
> deleted.
(I've uploaded the package to the s-p-u queue already.)
debdiff attached.
diff -Nru opendkim-2.11.0~beta2/debian/changelog opendkim-2.11.0~beta2/debian/changelog
--- opendkim-2.11.0~beta2/debian/changelog 2020-10-12 15:15:30.0 +0200
+++ opendkim-2.11.0~beta2/debian/changelog 2023-12-01 19:17:01.0 +0100
@@ -1,3 +1,13 @@
+opendkim (2.11.0~beta2-4+deb11u1) bullseye; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+
+ [ David Bürgin ]
+ * Add patch "rev-ares-deletion.patch" for CVE-2022-48521:
+Delete Authentication-Results headers in reverse (Closes: #1041107).
+
+ -- Tobias Frost Fri, 01 Dec 2023 19:17:01 +0100
+
opendkim (2.11.0~beta2-4) unstable; urgency=medium
* Update debhelper-compat to compatibility level 13.
diff -Nru opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch
--- opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch 1970-01-01 01:00:00.0 +0100
+++ opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch 2023-12-01 19:11:21.0 +0100
@@ -0,0 +1,33 @@
+Description: Delete Authentication-Results headers in reverse (CVE-2022-48521)
+Author: David Bürgin
+Bug: https://github.com/trusteddomainproject/OpenDKIM/pull/189
+
+--- a/opendkim/opendkim.c
b/opendkim/opendkim.c
+@@ -13651,9 +13651,16 @@
+ return SMFIS_TEMPFAIL;
+ }
+
+- c = 0;
++ c = 1;
++
+ for (hdr = dfc->mctx_hqhead; hdr != NULL; hdr = hdr->hdr_next)
+ {
++ if (strcasecmp(hdr->hdr_hdr, AUTHRESULTSHDR) == 0)
++c++;
++ }
++
++ for (hdr = dfc->mctx_hqtail; hdr != NULL; hdr = hdr->hdr_prev)
++ {
+ memset(ares, '\0', sizeof(struct authres));
+
+ if (strcasecmp(hdr->hdr_hdr, AUTHRESULTSHDR) == 0)
+@@ -13664,7 +13671,7 @@
+ char *slash;
+
+ /* remember index */
+-c++;
++c--;
+
+ /* parse the header */
+ arstat = ares_parse((u_char *) hdr->hdr_val,
diff -Nru opendkim-2.11.0~beta2/debian/patches/series opendkim-2.11.0~beta2/debian/patches/series
--- opendkim-2.11.0~beta2/debian/patches/series 2020-07-24 10:48:27.0 +0200
+++ opendkim-2.11.0~beta2/debian/patches/series 2023-12-01 19:14:10.0 +0100
@@ -4,3 +4,4 @@
fix-miltertest-eom-check-smtpreply.patch
fix-genzone-subdomains.patch
suppress-brackets-syslog.patch
+rev-ares-deletion.patch
signature.asc
Description: PGP signature
Bug#622947: per-maintainer insights into migrations and transitions
Control: reopen 622947 Control: reassign 622947 tracker.debian.org Hi pabs, On 01-12-2023 04:10, Paul Wise wrote: On Thu, 2023-11-30 at 14:14 +0100, Paul Gevers wrote: The tracker has been doing this for years now. distro-tracker doesn't have per-maintainer pages at all But it could and I think it's the right place. Similar to how it does that for teams: https://tracker.debian.org/teams/debian-accessibility/ I agree that transitions are missing in that overview. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056279: Looks like the systemctl links are gone but not the pm-utils ones
Hi Francois, On Mon, Nov 27, 2023 at 04:05:55PM -0800, Francois Marier wrote: > On 2023-11-27 at 03:54:16, Helmut Grohne (hel...@subdivi.de) wrote: > > I don't have time to update the patch right now. Let me promise an update > > this week, ok? I am very sorry to break this promise. It's complicated. > My apologies for not responding earlier, but this is a rather thorny problem > to solve and I have not had the mental "bandwidth" to dig into this yet. > > I wanted however to express my sincere appreciation for all of the work you > have put into both understanding this problem and coming up with a solution. Well, in essence I am driving the completion of the /usr-merge transition. You may argue that I have caused all this trouble even if that is an oversimplification. The way you support solving this matter is appreciated. I fully understand that fixing this requires significant effort that you cannot just provide spontaneously. So there will be no patch for now, because there still are unsolved problems. While looking into Emilio's problem and fixing the version constraints, I figured that test cases are failing. In particular, there are situations where dpkg unpacks systemd-sysv from unstable at a time where molly-guard from bookworm is still unpacked. This causes files from systemd-sysv to be irrevocably lost. I fear we're going back to the drawing board. If you want details, try #1057199, but I caution that it's not for the faint of heart and I already have apt and dpkg developers assist, which is awesome. Among the ideas circulated by multiple DDs, the one that seems most promising to me was from Julian Andres Klode. He suggests that we add a "barrier" package "usrmerge-support". It would have versioned Conflicts with molly-guard and systemd-sysv would declare Pre-Depends on usrmerge-support. This approach can be used to emulate the semantics that I hoped to get from Conflicts, because Pre-Depends imply that at the time usrmerge-support.postinst runs, molly-guard must be removed or upgraded and systemd-sysv is not yet unpacked. Totally untested though. I fear there is not much you can do at this point. Let me also clarify that I am not really looking into this for molly-guard's sake. For one thing, molly-guard provides an instance of a problem class repeated multiple times in the archive. I hope that once we get molly-guard right, the other instances become easier. For another, your responsiveness and care is appreciated. Stay tuned Helmut
Bug#1057220: systemd-sysv: may loose files in upgrade from bookworm
Package: systemd-sysv Version: 255~rc1-4 Severity: serious Justification: silent file loss in upgrade User: helm...@debian.org Usertags: dep17p7 Hi Luca and Michael et al, while preparing patches for molly-guard, I figured an upgrade file loss scenario for systemd-sysv. This is unfortunate on multiple accounts and I cannot offer a solution at this time. Let me start with a reproducer and move on to an explanation. mmdebstrap \ bookworm \ /dev/null \ http://deb.debian.org/debian \ --variant=apt \ --include=molly-guard,systemd-sysv \ --customize-hook='sed -i -e s/bookworm/sid/ "$1/etc/apt/sources.list"' \ --chrooted-customize-hook="apt update" \ --chrooted-customize-hook='apt-get -y upgrade --with-new-pkgs' \ --chrooted-customize-hook='apt-get download libsystemd-shared libsystemd0 libudev1 systemd systemd-sysv' \ --chrooted-customize-hook='echo "molly-guard:all deinstall" | dpkg --set-selections' \ --chrooted-customize-hook='dpkg --auto-deconfigure --unpack *.deb' \ --chrooted-customize-hook="dpkg --configure -a" \ --customize-hook='ls -la "$1/usr/sbin/halt"' In testing the molly-guard patches I noticed an odd behaviour. Occasionally, dpkg would unpack sid's systemd-sysv before removing or upgrading bookworm's molly-guard. This is surprising given that systemd-sysv declares versioned Conflicts for molly-guard. I reduced this into a minimal test case and discussed it with Guillem Jover. He suggested that this behaviour is covered by debian policy section §6.6 and after reading it over and over, I agree. I now consider the explanation of Conflicts in §7.4 misleading. Since apt developers were also surprised, I filed #1057199 against debian-policy to ask for clarification. That said, we won't be changing how dpkg works in bookworm and hence have to find a solution that works with the current implementation. Fundamentally, we allow unpacking a package (e.g. systemd-sysv) while conflicting packages are still installed as long as those conflicting packages are scheduled for (temporary or permanent) removal. Hence the test case above crafts a bookworm installation containing both systemd-sysv and molly-guard. It then proceeds to upgrading systemd-sysv and removing molly-guard. While this is a bit of an artificial reproducer bypassing apt, I managed to reproduce this with apt in more complex upgrades. While the moratorium is formally lifted, the release team still classifies file loss due to /usr-merge as RC bugs. Let me stress that this scenario does not involve a molly-guard from trixie or sid. It relies purely on the molly-guard released with bookworm. So there is nothing that molly-guard can do to assist here. A similar situation happens when upgrading molly-guard rather than removing it. The updated molly-guard.preinst is only run after systemd-sysv has been unpacked and files have been lost. I appreciate ideas, proof of concepts and other forms of help. I do request patience with uploading a fix though. I've got the molly-guard patch wrong about four times already. Please let us pass a solution through review and extensive testing before uploading. Helmut
Bug#1057219: busybox: possible file loss during upgrade arising from /usr-merge
Package: busybox Version: 1:1.36.1-6 Severity: serious User: helm...@debian.org Usertags: dep17p1 Hi Chris and Michael, I am very sorry to tell you that I found a contrieved /usr-merge problem with the busybox upload. In essence, Conflicts allow for concurrent unpacks in weired situations. As a consequence, you may miss the busybox binary if you upgrade from bookworm to trixie and change from busybox-static to busybox or vice versa in the process. I do not have a solution at this time and file this bug as a migration blocker. If you want to get rid of the rc bug, you may upload a revert. Otherwise, please wait until we have a better understanding of the problem. I am filing a detailed report for systemd-sysv with a very similar issue. Helmut
Bug#1057218: resolvconf: possible file loss in upgrades due to /usr-merge
Package: resolvconf Version: 1.92 Severity: serious User: helm...@debian.org Usertags: dep17p1 Hi Andrej, I am very sorry for not having seen this earlier. There is a tricky case where upgrading from bookworm to sid may loose files if you simultaneously change implementation. I am working on the analysis and it probably looks like: resolvconf: 1.91+nmu1: issues: - files: - /sbin/resolvconf others: systemd-resolved: 255~rc3-3: unstable what: ineffective conflicts suites: bookworm|trixie '1.92': issues: - files: - /usr/sbin/resolvconf others: openresolv: 3.12.0-1: bullseye 3.12.0-3: bookworm 3.13.1-1: trixie|unstable systemd-resolved: 252.17-1~deb12u1: bookworm 252.19-1~deb12u1: bookworm-proposed-updates 252.5-2~bpo11+1: bullseye-backports 254.5-1: trixie 254.5-1~bpo12+2: bookworm-backports what: ineffective conflicts suites: unstable This is a meant as a migration blocker. If you want to migrate resolvconf for other reasons, consider uploading a revert. Otherwise, please wait a bit for me to better understand the situation. I am filing a similar bug with way more details against systemd-sysv. Helmut
Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management
Hi Balint,
On 16/11/2023 18:55, Bálint Réczey wrote:
Hi Colin,
Colin King (gmail) ezt írta (időpont: 2023.
nov. 16., Cs, 17:46):
Hi Balint,
Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:
--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
prefix=/usr
exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/
Name: libtypec
Description: USB-Type C and USB Power Delivery class devices
Version: 0.4.0
Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec
I think this patch application did not work out as intended, please
check the patched file.
The symbols file's first line is also still off and now the symbos
have debian package revisions.
Those are issues automatically detected by Lintian. I suggest running
lintian on the built binary packages' .changes file or populating the
packaging repository on Salsa where CI runs include lintian and many
other checks.
I ran lintian but I didn't see the errors, I used:
lintian --profile=debian --pedantic libtypec_0.4-3_source.changes
perhaps there are some extra lintian flags or config settings that I'm
missing. Any suggestions?
Colin
Cheers,
Balint
Ah, good idea. I've refreshed package with this change. Also updated the
.symbols file and uploaded a -4 to mentors.
Colin
Bug#1055566:
Salsa MP at https://salsa.debian.org/python-team/packages/mod-wsgi/-/merge_requests/1
Bug#1053991: Further information
Hi Since filing the above report, I have been using the 6.1.0-12 (6.1.0-12-rt) kernel [version 6.1.52-1], on which the system displays on both monitors. This morning I booted the computer and the system was only displaying on one monitor. I checked physical connections and apt update log since the last time I used the computer. I could not see anything obvious to explain why I was only getting one monitor. As an extreme measure, I reinstalled Debian, formatting / and /swap partitions but keeping /home. The system rebooted into 6.1.0-13 [version 6.1.55-1], which displayed on both monitors and is expected behaviour. I'm guessing the problem lies elsewhere so please feel free to close the bug. Kind regards, R
Bug#619328: console-setup-freebsd: Uninstallable on Linux hosts
Hi, Paul Gevers wrote (Sat, 28 Oct 2023 20:14:13 +0200): > Hi, > > On Mon, 24 Jul 2023 17:17:54 +0200 Paul Gevers wrote: > > On Wed, 23 Mar 2011 10:49:42 +0100 Julien Cristau > > wrote: > > > On Wed, Mar 23, 2011 at 11:36:00 +0200, Anton Zinoviev wrote: > > > > Does this mean the > > > > architectures are not equal in rights - an 'all' package is allowed to > > > > be uninsallable on kFreeBSD but not on Linux? > > > > > > > No, it's fine. > > > > While I totally stand behind this, with the kfreebsd's removed now even > > from the ports [1], maybe it's time to stop building console-setup-freebsd? > > And now, due to changes in our migration software, this issue has caused > console-setup to be blocked for 34 days already [1]: > uninstallable on arch amd64, not running autopkgtest there > > I'll hint it through now, but it would be nicer if console-setup-freebsd > would be dropped next time (as it would ensure src:console-setup gets > the normal autopkgtest treatment). > > Paul > > [1] https://qa.debian.org/excuses.php?package=console-setup While cleaning up the whole code of console-setup from kfreebsd parts is out of my skills, I managed to get it so far, that the kfreebsd packages are no longer beeing built, and those packages removed from control file. Could this be enough for now? I filed this as MR [1]. The pipeline on that push went fine first [2], while there was a job within the pipeline named "D-I" which I triggered manually and that failed, however I'm not exactly sure what this job does, and what failed there; a mini.iso image was however successfully created. I did not notice this pipeline funtionality before. Is this expected to work? Comparing all the remaining packages with debdiff shows no unexpected differences compared to the previous version, so for me it looks ok. Maybe someone wants to take a look? Holger [1] https://salsa.debian.org/installer-team/console-setup/-/merge_requests/21 [2] https://salsa.debian.org/holgerw/console-setup/-/pipelines/608351 -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1057217: RM: haskell-cipher-aes -- ROM; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: haskell-cipher-...@packages.debian.org Control: affects -1 + src:haskell-cipher-aes Please remove haskell-cipher-aes from unstable. See #1018196 for more information about this removal request. Thanks, Ilias
Bug#1057216: RM: haskell-cprng-aes -- ROM; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: haskell-cprng-...@packages.debian.org Control: affects -1 + src:haskell-cprng-aes Please remove haskell-cprng-aes from unstable. See #1018197 for more information about this removal request. Thanks, Ilias
Bug#1054358: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-mbox -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 04:33PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * Seems unmaintained; Last upload more than 5 years ago > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-mbox from unstable. -- Ilias
Bug#1054319: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-ixset -- ROM; obsolete Control: severity -2 normal On Sat, Oct 21, 2023 at 08:38PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS (depends on broken haskell-syb-with-class) > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-ixset from unstable. -- Ilias
Bug#1054357: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-fclabels -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 04:31PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-fclabels from unstable. -- Ilias
Bug#967519: haskell-diagrams-gtk: depends on deprecated GTK 2
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-diagrams-gtk -- ROM; obsolete Control: severity -2 normal On Mon, Jul 24, 2023 at 01:43AM, Simon McVittie wrote: > It seems nothing in Debian depends or build-depends on > haskell-diagrams-gtk. Is it still useful? If not, can we remove it from > unstable before the Debian 13 release, to discourage the addition of > new software that depends on GTK 2? Dear FTP masters, please remove haskell-diagrams-gtk from unstable. -- Ilias
Bug#1054356: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-data-tree-print -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 04:28PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * Seems unmaintained; Last upload more than 5 years ago > * It's not part of the latest Stackage LTS > > If you believe we should keep this package in Debian, please close this > bug report. Dear FTP masters, please remove haskell-data-tree-print from unstable. -- Ilias
Bug#1054316: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-czipwith -- ROM; obsolete Control: severity -2 normal On Sat, Oct 21, 2023 at 08:07PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS with GHC 9.4 > * It's not part of the latest Stackage LTS > > If you believe we should keep this package in Debian, please close this > bug report. Dear FTP masters, please remove haskell-czipwith from unstable. -- Ilias
Bug#1018196: Bug#1018197: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-cipher-aes -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 07:19PM, Adrian Bunk wrote: > #1022681 has now been fixed. Dear FTP masters, please remove haskell-cipher-aes from unstable. -- Ilias
Bug#956226: Not fixed in Debian 12 D-I as of 2024-12-01
Hi, I still found this bug with the installer shipped in Bookworm. I'm using the image debian-live-12.2.0-amd64-gnome.iso, and I also had a LVM-Thin Physical Volume previously created by a Proxmox-VE installer ISO, which could not be removed by the Debian Installer. Thanks for working on that! Bests, Tassia.
Bug#1018197: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-cprng-aes -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 07:19PM, Adrian Bunk wrote: > #1022681 has now been fixed. Dear FTP masters, please remove haskell-cprng-aes from unstable. -- Ilias
Bug#1057207: Please ship JetBrainsMono.woff2
Package: fonts-jetbrains-mono Severity: wishlist Control: affects -1 php-symfony-web-profiler-bundle X-Debbugs-Cc: Debian PHP PEAR Maintainers Hi! The php-symfony-web-profiler-bundle package since the recent symfony 6.4 version is shipping JetBrainsMono.woff2. If it can be properly built from source, it would be nice to have it shipped from this package (and “just” symlinked from php-symfony-web-profiler-bundle). Thanks in advance for considering. Regards taffit signature.asc Description: PGP signature
Bug#1054498: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-butcher -- ROM; obsolete Control: severity -2 normal On Tue, Oct 24, 2023 at 06:30PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * It's not part of the latest Stackage LTS > > If you believe we should keep this package in Debian, please close this > bug report. Dear FTP masters, please remove haskell-butcher from unstable. -- Ilias
Bug#1057205: systemtap: version 5.0-1 FTBFS on i386, ppc64el, riscv64
Package: systemtap Version: 5.0-1 Severity: serious g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"' -DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"' -DLOCALEDIR='"/usr/share/locale"' -DDOCDIR='"/usr/share/doc/systemtap"' -DPYEXECDIR='""' -DPY3EXECDIR='""' -I./includes -I./includes/sys -DSTAP_SDT_V2 -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -faligned-new -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o stap-tapset-mark.o `test -f 'tapset-mark.cxx' || echo './'`tapset-mark.cxx In constructor ‘symresolution_info::symresolution_info(systemtap_session&, bool)’, inlined from ‘int semantic_pass_symbols(systemtap_session&)’ at elaborate.cxx:1872:28: elaborate.cxx:2659:21: error: storing the address of local variable ‘sym’ in ‘*s.systemtap_session::symbol_resolver’ [-Werror=dangling-pointer=] 2659 | s.symbol_resolver = this; // save resolver for early PR25841 function resolution | ~~^~ elaborate.cxx: In function ‘int semantic_pass_symbols(systemtap_session&)’: elaborate.cxx:1872:22: note: ‘sym’ declared here 1872 | symresolution_info sym (s); | ^~~ elaborate.cxx:1870:43: note: ‘s’ declared here 1870 | semantic_pass_symbols (systemtap_session& s) |~~~^ g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"' -DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"' -DLOCALEDIR='"/usr/share/locale"' -DDOCDIR='"/usr/share/doc/systemtap"' -DPYEXECDIR='""' -DPY3EXECDIR='""' -I./includes -I./includes/sys -DSTAP_SDT_V2 -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -faligned-new -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o stap-tapset-utrace.o `test -f 'tapset-utrace.cxx' || echo './'`tapset-utrace.cxx g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"' -DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"' -DLOCALEDIR='"/usr/share/locale"' -DDOCDIR='"/usr/share/doc/systemtap"' -DPYEXECDIR='""' -DPY3EXECDIR='""' -I./includes -I./includes/sys -DSTAP_SDT_V2 -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -faligned-new -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o stap-task_finder.o `test -f 'task_finder.cxx' || echo './'`task_finder.cxx g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"' -DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"' -DLOCALEDIR='"/usr/share/locale"' -DDOCDIR='"/usr/share/doc/systemtap"' -DPYEXECDIR='""' -DPY3EXECDIR='""' -I./includes -I./includes/sys -DSTAP_SDT_V2 -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -faligned-new -D_REENTRANT -I/usr/include/nss -I/usr/include/nspr -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o stap-dwflpp.o `test -f 'dwflpp.cxx' || echo './'`dwflpp.cxx cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1297: stap-elaborate.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/<>' make[2]: *** [Makefile:2216: all-recursive] Error 1 make[2]: Leaving directory '/<>' make[1]: *** [Makefile:816: all] Error 2 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j8 returned exit code 2 make: *** [debian/rules:30: build-arch] Error 25 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
Bug#1057204: RM: r-bioc-rhdf5filters [s390x] -- ROM; Build-Depends missing on s390x
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: r-bioc-rhdf5filt...@packages.debian.org, 1056...@bugs.debian.org Control: affects -1 + src:r-bioc-rhdf5filters Hi ftpmasters, given that as reported in bug #1056497 the situation has not changed for the new version of r-bioc-rhdf5filters I hereby ask for removal of the binary package for s390x architecture. Kind regards and thanks for working as ftpmaster Andreas.
Bug#1057203: r-bioc-rhdf5filters: missing build-dependency on big-endian architectures
Source: r-bioc-rhdf5filters Version: 1.12.1+dfsg2-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: debian-s...@lists.debian.org Hi Maintainer A commit on 2023-08-01 [1] added a build-dependency on libvbz-hdf-plugin-dev, which is not available on big-endian architectures, and prevents r-bioc-rhdf5filters from building on s390x [2], where it built previously, thus blocking migration. The package libvbz-hdf-plugin does not build on big-endian architectures [3] due to a missing build-dependency on libstreamvbyte-dev, and libstreamvbyte itself FTBFS on big-endian architectures [4]. According to: reverse-depends --release sid --recursive r-bioc-rhdf5filters r-bioc-rhdf5filters has many reverse-dependencies on s390x, so rather than dealing with all of these, it may be simplest to fix libstreamvbyte. Regards Graham [1] https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5filters/-/commit/78ced3f3c70fe29db3ba16bc2b57da5ab0e4fa6c [2] https://buildd.debian.org/status/package.php?p=r-bioc-rhdf5filters [3] https://buildd.debian.org/status/package.php?p=libvbz-hdf-plugin [4] https://buildd.debian.org/status/package.php?p=libstreamvbyte
Bug#1054596: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-binary-parsers -- ROM; obsolete Control: severity -2 normal On Thu, Oct 26, 2023 at 06:16PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * Seems unmaintained; Last upload more than 4 years ago > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-binary-parsers from unstable. -- Ilias
Bug#1042376: Will this bug ever been fixed?
Will this bug ever been fixed? 7 of 11 machines here are fast enough for digikam, but they all are exiting with "Illegal Instruction". I guess it doesn't care if SSE4 is enabled or not, but older hardware could be upcycled without that. With best regards, Andreas
Bug#1036051: bpfcc: Please enable build on riscv64
Source: bpfcc
Version: 0.26.0+ds-1
Followup-For: Bug #1036051
Dear Maintainer,
Sorry, i forget the debdiff file in previous email.
--
Regards,
--
Bo YU
diff -Nru bpfcc-0.26.0+ds/debian/changelog bpfcc-0.26.0+ds/debian/changelog
--- bpfcc-0.26.0+ds/debian/changelog2023-02-13 12:19:33.0 +0800
+++ bpfcc-0.26.0+ds/debian/changelog2023-11-30 21:37:36.0 +0800
@@ -1,3 +1,10 @@
+bpfcc (0.26.0+ds-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Support riscv64. (Closes: #-1)
+
+ -- Bo YU Thu, 30 Nov 2023 21:37:36 +0800
+
bpfcc (0.26.0+ds-1) unstable; urgency=medium
* [b4a876d] New upstream version 0.26.0+ds
diff -Nru bpfcc-0.26.0+ds/debian/control bpfcc-0.26.0+ds/debian/control
--- bpfcc-0.26.0+ds/debian/control 2023-02-13 12:19:11.0 +0800
+++ bpfcc-0.26.0+ds/debian/control 2023-11-30 21:37:32.0 +0800
@@ -38,7 +38,7 @@
Rules-Requires-Root: no
Package: libbpfcc
-Architecture: amd64 arm64 ppc64el ppc64 s390x armhf
+Architecture: amd64 arm64 ppc64el ppc64 s390x armhf riscv64
Depends: ${misc:Depends}, ${shlibs:Depends}
Multi-Arch: same
Description: shared library for BPF Compiler Collection (BCC)
@@ -52,7 +52,7 @@
to control BPF programs from userspace.
Package: libbpfcc-dev
-Architecture: amd64 arm64 ppc64el ppc64 s390x armhf
+Architecture: amd64 arm64 ppc64el ppc64 s390x armhf riscv64
Section: libdevel
Depends: ${misc:Depends},
libbpfcc (= ${binary:Version})
@@ -97,7 +97,7 @@
This package provides the command-line tools and examples
Package: libbpf-tools
-Architecture: amd64 arm64 ppc64el
+Architecture: amd64 arm64 ppc64el riscv64
Depends: ${misc:Depends},
${shlibs:Depends}
Description: tools for BPF Compiler Collection based on libbpf (BTF and CO-RE)
@@ -114,7 +114,7 @@
At this time this package contains subset of tools from bpfcc-tools
Package: bpfcc-introspection
-Architecture: amd64 arm64 ppc64el ppc64
+Architecture: amd64 arm64 ppc64el ppc64 riscv64
Depends: ${misc:Depends},
${shlibs:Depends},
libbpfcc (= ${binary:Version})
signature.asc
Description: PGP signature
Bug#1036051: bpfcc: Please enable build on riscv64
Source: bpfcc Version: 0.26.0+ds-1 Followup-For: Bug #1036051 Dear Maintainer, I can built it with the debdiff file so could you apply it on next uplaod? -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1021584: ldc: add support for riscv64
Source: ldc
Version: 1:1.35.0-1
Tags: patch
Followup-For: Bug #1021584
Dear Maintainer,
Now ldc has been built on riscv64 without any code change. So can we
enable riscv64 support on build target on next upload?
Bo
--
Regards,
--
Bo YU
diff -Nru ldc-1.35.0/debian/changelog ldc-1.35.0/debian/changelog
--- ldc-1.35.0/debian/changelog 2023-11-05 01:40:54.0 +0800
+++ ldc-1.35.0/debian/changelog 2023-11-30 19:37:16.0 +0800
@@ -1,3 +1,10 @@
+ldc (1:1.35.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Support riscv64. (Closes: #1021584)
+
+ -- Bo YU Thu, 30 Nov 2023 19:37:16 +0800
+
ldc (1:1.35.0-1) unstable; urgency=medium
[ Matthias Klumpp ]
diff -Nru ldc-1.35.0/debian/control ldc-1.35.0/debian/control
--- ldc-1.35.0/debian/control 2023-11-05 01:40:54.0 +0800
+++ ldc-1.35.0/debian/control 2023-11-30 19:37:12.0 +0800
@@ -26,7 +26,7 @@
Vcs-Browser: https://salsa.debian.org/d-team/ldc
Package: ldc
-Architecture: amd64 arm64 armhf i386
+Architecture: amd64 arm64 armhf i386 riscv64
Provides: d-compiler,
d-v2-compiler
Depends: libphobos2-ldc-shared-dev (= ${binary:Version}),
@@ -41,7 +41,7 @@
Package: libphobos2-ldc-shared105
Section: libs
-Architecture: amd64 arm64 armhf i386
+Architecture: amd64 arm64 armhf i386 riscv64
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends}
@@ -56,7 +56,7 @@
Package: libphobos2-ldc-shared-dev
Section: libdevel
-Architecture: amd64 arm64 armhf i386
+Architecture: amd64 arm64 armhf i386 riscv64
Depends: libphobos2-ldc-shared105 (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
signature.asc
Description: PGP signature
Bug#1057201: ITP: rl-renderpm -- contains the ReportLab accelerator module
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rl-renderpm Version : 4.0.3 Upstream Contact: the ReportLab team * URL : https://www.reportlab.org/ * License : LGPL,MIT/X Programming Lang: C, Python3 Description : contains the ReportLab accelerator module rl_renderPM is a package containing the ReportLab accelerator module _renderPM which can be used to speedup the reportlab.graphics.renderPM functions. . The python bitmap render module reportlab.graphics.renderPM can either use rlPyCairo, pycairo and freetype-py or rl_renderPM + built in freetype libraries. . The choice is made by overriding the reportlab.rl_settings module value _renderPMBackend using one of the settings files reportlab/local_reportlab_settings.py, reportlab_settings.py or ~/.reportlab_settings, which are searched for in that order. . The default value of _renderPMBackend is 'rlPyCairo', but it can be set to '_renderPM' to use this extension which is based on an older library libart_lgpl. . Deprecation notice: --- . As from version 4.0, the package python-reportlab removes the renderPM extension which lets one create bitmap versions of complex graphics. It now uses other python libraries which wrap up freetype, the font rendering engine, so that one doesn't need to worry about linking to it. Under the hood it uses PyCairo as a renderer by default (rather than the no-longer-supported libart), and freetype-py to render text glyphs. See more at: https://docs.reportlab.com/releases/notes/whats-new-40/ This package makes it easier for people who were using python-reportlab << 4.0 to let their programs upgrade to python-reportlab >= 4.0 without modifying the configuration. It is maitained at https://salsa.debian.org/python- team/packages/rl-renderpm and I intend to keep it up to date (I am already uploader for the package python-reportlab)
Bug#1057200: uhd: FTBFS with dpdk 23.11
Source: uhd Version: 4.5.0.0+ds1-3 Severity: important Tags: patch Dear Maintainer, We are preparing the dpdk transition 22.11 -> 23.11. uhd fails to build against the new version, and the required patch is very simple. A MR has been opened: https://salsa.debian.org/bottoms/pkg-uhd/-/merge_requests/4 This patch makes it compatible with both 22.11 and 23.11, so we would highly appreciate it if you could please merge it and upload it asap, so that we do not have to do synced source uploads, but binNMU will be sufficient to bring dpdk 23.11 into unstable from experimental. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#960382: pushover: Renamed to Domino-Chain
Hi, I'm working on this. I'v also added _Pushover_ support to upcoming game-data-packager. Here I really mean Pushover and not Domino-Chain, it's about the original assets. By design GDP creates .deb files that install assets into /usr/share/games/ The Debian domino-chain package will need to be patched to look there first before looking into $HOME. It would be very nice of you that this would be supported upstream from the go. GDP has built in support for automatic download from GOG.com & Steam but I miss some metadata for this game on both platforms (one need to actually buy the game to provides the metadata) so if you're interested you might give it a try. So on Debian platforms you can point to this instead of building & maintain your own lgogdownloader/innoextract scripts. Greetings. Sample generated "pushover-data...deb": drwxr-xr-x root/root 0 2023-12-01 14:20 ./usr/share/games/pushover/ -rw-r--r-- root/root 341 1992-06-07 16:29 ./usr/share/games/pushover/P0.SCR -rw-r--r-- root/root 517 1992-06-07 16:29 ./usr/share/games/pushover/P1.SCR -rw-r--r-- root/root 675 1992-06-07 16:29 ./usr/share/games/pushover/P2.SCR -rw-r--r-- root/root 707 1992-06-07 16:29 ./usr/share/games/pushover/P3.SCR
Bug#1055229: bookworm-pu: package redis/5:7.0.11-1+deb12u1
Adam D. Barratt wrote: >> redis (5:7.0.11-1+deb12u1) bookworm; urgency=medium >> . >> * Drop ProcSubset=pid hardening flag from the systemd unit files it >> causes >> difficult-to-reproduce crashes with memory allocation errors. A big >> thanks >> to Arnaud Rebillout for the extensive investigation. >> (Closes: #1055039) >> * Update debian/gbp.conf for the debian/bookworm branch. > > Please go ahead. Uploaded. :) -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks
Package: debian-policy Version: 4.6.2.0 X-Debbugs-Cc: debian-d...@lists.debian.org, de...@lists.debian.org Hi, first of all huge thanks to David, Guillem and Julian for all of their explanations. In large parts, this bug report is yours and I'm just the one writing it down. §7.4 currently starts with: When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time. I believe this is technically wrong. There are situations where dpkg will allow such unpacks to temporarily co-exist. §6.6 goes into further detail and is accurate. Suppose we have two arch:all packages a version 1 and b version 1 both of which are installed. Now we attempt to install a version 2, which happens to declare "Conflicts: b (<< 2)". We may therefore mark b for removal echo "b:all deinstall" | dpkg --set-selections and proceed to installing a: dpkg --auto-deconfigure --unpack a_2.deb When we do this, dpkg will unpack a version 2 before removing the files of b version 1. I argue this is very briefly allowing these packages to be unpacked at the same time as the next thing dpkg does is removing b's files. This situation can be forced if we add package b version 2, which declares "Breaks: a (<< 2)" and attempt to install both. apt figures that it has to temporarily remove b and hence issues the selection above. Then it proceeds to unpacking both packages. The difference actually is rather subtle. As dpkg is tracking ownership of files, one should not be observing a difference. What one can see is that a.preinst version 2 is run at a time where b version 1 is still unpacked (and that's fine as the statement only talks about unpack). The effects of concurrent unpack are theoretically not observable, due to dpkg tracking files. However when you add aliasing to the mix, dpkg can now delete files that are still needed via differences in aliasing. That way - and I am fully aware that this violates fundamental assumptions of dpkg - we can make the order of unpacks visible and demonstrate that indeed a version 2 is unpacked before b version 1 has its files removed. All of this is fully in line with the long description in §6.6. What I take issue with is the executive summary at the start of §7.4. In case you like some kind of test case to tinker with, I'm attaching a script that demonstrates the situation. Helmut conflict-demo.sh Description: Bourne shell script
Bug#1057198: rust-wasmtime: FTBFS error[E0599]: no function or associated item named `from_str` found for struct `Triple` in the current scope
Package: rust-wasmtime Version: 15.0.0+dfsg-3 Severity: serious Control: block 1055090 by -1 https://buildd.debian.org/status/fetch.php?pkg=rust-wasmtime=all=15.0.0%2Bdfsg-3=1701097543=0 error[E0599]: no function or associated item named `from_str` found for struct `Triple` in the current scope --> cranelift/codegen/src/isa/mod.rs:118:12 | 118 | lookup(triple!(name)) |^ function or associated item not found in `Triple` | = help: items from traits can only be used if the trait is in scope = note: this error originates in the macro `triple` (in Nightly builds, run with -Z macro-backtrace for more info) help: the following trait is implemented but not in scope; perhaps add a `use` for it: | 46 + use core::str::FromStr; | For more information about this error, try `rustc --explain E0599`. The following warnings were emitted during compilation:
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
On Fri, 1 Dec 2023 09:48:50 +0100 Lorenzo wrote: > On Fri, 1 Dec 2023 07:53:57 +0100 > tito wrote: > > > > > > > > > Even the cronjob is gone. > > > > > > sorry, the patch does not include cronjob since o-s-s does not have > > > a way to handle it. > > > > Couldn't it be appended to crontab? > there is no mechanism to selectively add (and remove/purge) additional > file or snippets such as cronjobs or /etc/default/* > > > Hi, > > shouldn't /etc/default/mdadm be moved also to o-s-s? > > I bet it is the next file to be dropped after timers > > can't find the file, even in buster > https://packages.debian.org/buster/amd64/mdadm/filelist > > Well, I have it on my system but same problem as for the cronjob Hi, but the file is still referenced in /etc/init.d/mdadm # grep /etc/default/mdadm /etc/init.d/mdadm* /etc/init.d/mdadm:DEBIANCONFIG=/etc/default/mdadm from the 5 variables set in /etc/default/mdadm: AUTOCHECK, AUTOSCAN, VERBOSE at a first glance are ignored START_DAEMON has already been moved to the initscript so that from the /etc/default/mdadm you can only turn the initscript off. I would propose to move DAEMON_OPTIONS="--syslog" to the initscript so that we can forget about /etc/default/mdadm. The cronjob that will be removed soon is still a problem as it checks the arrays periodically # By default, run at 00:57 on every Sunday, but do nothing unless the day of # the month is less than or equal to 7. Thus, only run on the first Sunday of # each month. crontab(5) sucks, unfortunately, in this regard; therefore this # hack (see #380425). 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi There will be other cron jobs like this that will be susbtituted by systemd timers so we need to find how to handle this. Ciao, Tito > > $ cat /etc/default/mdadm > # mdadm Debian configuration > # > # You can run 'dpkg-reconfigure mdadm' to modify the values in this file, if > # you want. You can also change the values here and changes will be preserved. > # Do note that only the values are preserved; the rest of the file is > # rewritten. > # > > # AUTOCHECK: > # should mdadm run periodic redundancy checks over your arrays? See > # /etc/cron.d/mdadm. > AUTOCHECK=true > > # AUTOSCAN: > # should mdadm check once a day for degraded arrays? See > # /lib/systemd/system/mdmonitor-oneshot.service > AUTOSCAN=true > > # START_DAEMON: > # should mdadm start the MD monitoring daemon during boot? > START_DAEMON=true > > # DAEMON_OPTIONS: > # additional options to pass to the daemon. > DAEMON_OPTIONS="--syslog" > > # VERBOSE: > # if this variable is set to true, mdadm will be a little more verbose e.g. > # when creating the initramfs. > VERBOSE=false > > > Lorenzo > > > > > Ciao, > > Tito >
Bug#1057197: borgbackup2: Package cannot be installed due to an upper limit on the depedency 'python3-platformdirs'
Package: borgbackup2 Version: 2.0.0b5-1 Severity: grave Tags: newcomer Justification: renders package unusable Dear Maintainer, there is a version conflict in the dependencies: $ apt install borgbackup2 Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: borgbackup2 : Depends: python3-platformdirs (< 4.0.0) but 4.0.0-1 is to be installed Recommends: python3-llfuse (< 2.0) but it is not going to be installed Recommends: python3-pyfuse3 but it is not going to be installed E: Unable to correct problems, you have held broken packages. This is because `platformdirs` has a new version which borg is not yet allowing. This has already been fixed upstream: https://github.com/borgbackup/borg/issues/7950 Please provide a suitable patch for the debian package. Thanks in advance! Adrian -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages borgbackup2 depends on: ii libacl12.3.1-3 ii libc6 2.37-12 ii liblz4-1 1.9.4-1 ii libssl33.1.4-2 ii libxxhash0 0.8.2-2 ii libzstd1 1.5.5+dfsg2-2 ii python33.11.4-5+b1 ii python3-argon2 21.1.0-2 ii python3-msgpack1.0.3-3 ii python3-packaging 23.2-1 ii python3-pkg-resources 68.1.2-2 ii python3-platformdirs 4.0.0-1 Versions of packages borgbackup2 recommends: ii fuse3 [fuse] 3.14.0-4 pn python3-llfuse pn python3-pyfuse3 Versions of packages borgbackup2 suggests: pn borgbackup2-doc
Bug#1055626: cabal-install: pkg-config package gtk4-any, not found in the pkg-config database
Hi again, On Thu, Nov 09, 2023 at 08:53PM, Ilias Tsitsimpis wrote: > I tried this in a clean unstable environment and cannot reproduce it. > Here is what I did: > > $ docker run --rm -ti debian:sid > # apt update > # apt upgrade -y > # apt install -y cabal-install pkg-config libgtk-4-dev libatk1.0-dev > # cabal update > # cabal get gi-gtk-4.0.8 > # cd gi-gtk-4.0.8 > # cabal build > > The above builds gi-gtk-4.0.8 successfully. Maybe something is wrong > with your environment? I am going to close this bug report, since it looks like something is wrong with your environment. Please re-open if this persists. Best, -- Ilias
Bug#1057196: Reference to external PDF in documentation is a broken link
Package: opendkim Version: 2.11.0~beta2-8 Severity: minor X-Debbugs-Cc: j...@infodrom.org In the documentation /usr/share/doc/opendkim/README.Debian.gz an external PDF resource is referenced: https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_DKIM_Key_Rotation_BP-2013-12.pdf This document does not seem to be available under that particular URL anymore. Please adjust the URL or remove the reference. Regards Joey -- Computers are not intelligent. They only think they are.
Bug#933264: gradle: Nearly 3-year-old version almost useless
On 01.12.23 13:16, Markus Koschany wrote: Am Freitag, dem 01.12.2023 um 13:06 +0100 schrieb Matthias Geiger: Kotlin is now in debian, is there anything else blocking the update ? As a start I have built Gradle 4.6 from source with almost only system libraries but I hit a wall because there seems to be a bug in our Kotlin version or rather 4.6 requires a different version, so this version still relies on upstream's binary distribution of Kotlin. I will push this in a few days and then let's see how we can proceed from here on. Why still 4.6? Jumping to a newer version like 6.x (which is already superseded by 8.x) requires updates of many different system libraries which in turn requires updates of reverse-dependencies of said libraries and so on. So whenever you change something in Debian's Java eco system you have to be prepared to fix a bunch of other seemingly (un)related stuff as well. More details follow soon. Markus Awesome, thanks for your work on this ! best, -- Matthias Geiger Debian Maintainer "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
