Bug#1070486: nbtscan: autopkgtest not safe to run

[Helmut Grohne]

Source: nbtscan
Version: 1.7.2-2
Tags: patch

Hi,

I was running the autopkgtest of nbtscan on a dedicated server and the
relevant provider captured the scanning and was not happy. Given that
the test does not actually evaluate any responses, I think it would not
degrade the test in any way if it were scanning the loopback interface
instead and thus avoid tripping up paranoid hosters. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru nbtscan-1.7.2/debian/changelog 
nbtscan-1.7.2/debian/changelog
--- nbtscan-1.7.2/debian/changelog  2022-10-29 19:17:25.0 +0200
+++ nbtscan-1.7.2/debian/changelog  2024-05-06 11:28:15.0 +0200
@@ -1,3 +1,10 @@
+nbtscan (1.7.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * autopkgtest: Scan loopback rather than the internet. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 06 May 2024 11:28:15 +0200
+
 nbtscan (1.7.2-2) unstable; urgency=medium
 
   * debian/control: bumped Standards-Version to 4.6.1.
diff --minimal -Nru nbtscan-1.7.2/debian/tests/control 
nbtscan-1.7.2/debian/tests/control
--- nbtscan-1.7.2/debian/tests/control  2022-10-29 19:17:22.0 +0200
+++ nbtscan-1.7.2/debian/tests/control  2024-05-06 11:28:15.0 +0200
@@ -1,6 +1,6 @@
 Test-Command: nbtscan | grep Usage
 Restrictions: superficial
 
-Test-Command: nbtscan -v 203.0.113.0/24
+Test-Command: nbtscan -v 127.1.0.0/24
 
-Test-Command: nbtscan -d -b 10 -t 2000 203.0.113.0-220
+Test-Command: nbtscan -d -b 10 -t 2000 127.1.0.0-220

Bug#1064003: patch for c-t-b build

[Helmut Grohne]

Control: tags -1 + patch

Hi Matthias,

I'm attaching a patch for the c-t-b FTBFS. Note that due to the
glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
timely upload is appreciated. Due to linux-libc-dev currently providing
the -$arch-cross packages, we have to remove the Build-Conflicts or make
rename the Provides on linux-libc-dev. I'm ok with both approaches and
offer dropping the conflict here.

Helmut
diff --minimal -Nru cross-toolchain-base-68/debian/changelog 
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/changelog   2024-05-04 
09:23:39.0 +0200
@@ -1,3 +1,12 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using linux 6.7. Closes: #1064003, #1067370.
+  * Build using glibc 2.38.
+  * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+ -- Helmut Grohne   Sat, 04 May 2024 09:23:39 +0200
+
 cross-toolchain-base (68) unstable; urgency=medium
 
   * Build using linux 6.5.8. Closes: #1042118.
diff --minimal -Nru cross-toolchain-base-68/debian/control 
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control  2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 09:23:39.0 
+0200
@@ -9,9 +9,9 @@
 Build-Depends: binutils-multiarch,
   dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
   binutils-source (>= 2.41-6~),
-  glibc-source (>= 2.37-3~),
+  glibc-source (>= 2.38),
   gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
-  linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+  linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
   autoconf (>= 2.69), autoconf2.69, autogen,
   automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
   dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
   libjansson-dev, pkg-config,
 Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
   binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386], 
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el], 
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf], 
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
-  libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross, 
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross, 
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross, 
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross, 
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross, 
linux-libc-dev-riscv64-cross,
+  libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross, 
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
   libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
 
 Package: linux-libc-dev-amd64-cross
diff --minimal -Nru cross-toolchain-base-68/debian/rules 
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/rules   2024-05-04 09:23:39.0 
+0200
@@ -61,8 +61,8 @@
 CROSS_GNU_TYPE   = $(call _gnu_type,${CROSS_ARCH})
 CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
 
-MIN_VER_GLIBC  := 2.37-3~
-MIN_VER_LINUX  := 6.5.8
+MIN_VER_GLIBC  := 2.38
+MIN_VER_LINUX  := 6.7.0
 MIN_VER_GCC:= 12.3.0-11~
 MIN_VER_BINUTILS   := 2.41-6~
 VER_GCC_BASE   := 12
@@ -110,7 +110,7 @@
 
 # FIXME: No conflict for the host == cross case ...
 BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst 
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,) 
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
 
 # taken from gcc packaging
 define unpack_tarball

Bug#1070328: libopenscap-perl misbuilds during cross build: wrong multiarch directory

[Helmut Grohne]

Source: openscap
Version: 1.3.10+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Cross building openscap successfully results in a broken
libopenscap-perl. It uses the build architecture multiarch directory.
When building a perl extension, you should Build-Depends: perl-xs-dev
rather than libperl-dev these days and then you can pass a suitable
PERL5LIB supplying the cross configuration. I'm attaching a patch for
your convenience.

Helmut
diff --minimal -Nru openscap-1.3.10+dfsg/debian/changelog 
openscap-1.3.10+dfsg/debian/changelog
--- openscap-1.3.10+dfsg/debian/changelog   2024-04-05 07:40:35.0 
+0200
+++ openscap-1.3.10+dfsg/debian/changelog   2024-05-03 08:23:56.0 
+0200
@@ -1,3 +1,12 @@
+openscap (1.3.10+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix cross misbuild: (Closes: #-1)
++ Build-Depends: perl-xs-dev for building a perl extension.
++ Supply a cross PERL5LIB.
+
+ -- Helmut Grohne   Fri, 03 May 2024 08:23:56 +0200
+
 openscap (1.3.10+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru openscap-1.3.10+dfsg/debian/control 
openscap-1.3.10+dfsg/debian/control
--- openscap-1.3.10+dfsg/debian/control 2024-04-05 07:40:35.0 +0200
+++ openscap-1.3.10+dfsg/debian/control 2024-05-03 08:23:55.0 +0200
@@ -18,7 +18,6 @@
libldap2-dev,
libopendbx1-dev,
libpcre2-dev,
-   libperl-dev,
libpopt-dev,
libpython3-all-dev,
librpm-dev,
@@ -29,6 +28,7 @@
libxmlsec1-dev,
libxslt1-dev,
libyaml-dev,
+   perl-xs-dev,
pkgconf,
python3-all-dev:native,
python3-pytest ,
diff --minimal -Nru openscap-1.3.10+dfsg/debian/rules 
openscap-1.3.10+dfsg/debian/rules
--- openscap-1.3.10+dfsg/debian/rules   2024-04-05 07:40:35.0 +0200
+++ openscap-1.3.10+dfsg/debian/rules   2024-05-03 08:23:56.0 +0200
@@ -6,6 +6,14 @@
 
 export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 
+include /usr/share/dpkg/architecture.mk
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
+PERL5LIB := /usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(PERLVER)$(if 
$(PERL5LIB),:$(PERL5LIB))
+export PERL5LIB
+endif
+
 PYVERS=$(shell py3versions --supported --version)
 CMAKE_OPTS = \
 -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \

Bug#1070327: libauparse0t64 fails piuparts: missing postrm for /usr-move mitigation

[Helmut Grohne]

Source: audit
Version: 1:3.1.2-2.1
Severity: serious
Justification: fails piuparts, blocks testing migration
Tags: patch
X-Debbugs-Cc: z...@debian.org

Hi,

I looked into why audit fails to migrate and noticed that it fails
piuparts as it leaves diversions behind after purge. The patch provided
by the /usr-move team failed to account for package removal and lacks
the postrm bit. I'm attaching a patch that fixes this problem. It also
removes the manual interpolation in favour of relying on dh_installdeb's
builtin interpolation. I'd appreciate a timely upload, because audit is
one of the last missing pieces moving forward with the /usr-move. Would
you mind a NMU?

Helmut
diff --minimal -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
--- audit-3.1.2/debian/changelog2024-02-28 04:02:13.0 +0100
+++ audit-3.1.2/debian/changelog2024-05-03 07:49:46.0 +0200
@@ -1,3 +1,10 @@
+audit (1:3.1.2-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix piuparts failure arising from /usr-move mitigation. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 May 2024 07:49:46 +0200
+
 audit (1:3.1.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.lintian-overrides 
audit-3.1.2/debian/libauparse0t64.lintian-overrides
--- audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-02-28 
03:58:37.0 +0100
+++ audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-05-03 
07:49:46.0 +0200
@@ -1 +1,2 @@
 libauparse0t64: package-name-doesnt-match-sonames libauparse0
+libauparse0t64: remove-of-unknown-diversion lib/* [postrm:*]
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.postrm 
audit-3.1.2/debian/libauparse0t64.postrm
--- audit-3.1.2/debian/libauparse0t64.postrm1970-01-01 01:00:00.0 
+0100
+++ audit-3.1.2/debian/libauparse0t64.postrm2024-05-03 07:49:40.0 
+0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+   remove|disappear)
+   for file in libauparse.so.0 libauparse.so.0.0.0; do
+   dpkg-divert --package libauparse0t64 --no-rename \
+   --remove --divert \
+   "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" 
\
+   "/lib/#DEB_HOST_MULTIARCH#/$file"
+   done
+   ;;
+esac
+
+#DEBHELPER#
+
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst 
audit-3.1.2/debian/libauparse0t64.preinst
--- audit-3.1.2/debian/libauparse0t64.preinst   1970-01-01 01:00:00.0 
+0100
+++ audit-3.1.2/debian/libauparse0t64.preinst   2024-05-03 07:49:46.0 
+0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+   install)
+   for file in libauparse.so.0 libauparse.so.0.0.0; do
+   dpkg-divert --package libauparse0t64 --no-rename \
+   --add --divert \
+   "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" 
\
+   "/lib/#DEB_HOST_MULTIARCH#/$file"
+   done
+   ;;
+esac
+
+#DEBHELPER#
+
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst.in 
audit-3.1.2/debian/libauparse0t64.preinst.in
--- audit-3.1.2/debian/libauparse0t64.preinst.in2024-02-28 
04:02:11.0 +0100
+++ audit-3.1.2/debian/libauparse0t64.preinst.in1970-01-01 
01:00:00.0 +0100
@@ -1,17 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case $1 in
-   install)
-   for file in libauparse.so.0 libauparse.so.0.0.0; do
-   dpkg-divert --package libauparse0t64 --no-rename \
-   --divert \
-   /lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged \
-   /lib/#DEB_HOST_MULTIARCH#/$file
-   done
-   ;;
-esac
-
-#DEBHELPER#
-
diff --minimal -Nru audit-3.1.2/debian/rules audit-3.1.2/debian/rules
--- audit-3.1.2/debian/rules2024-02-28 04:02:11.0 +0100
+++ audit-3.1.2/debian/rules2024-05-03 07:47:04.0 +0200
@@ -109,11 +109,6 @@
chgrp adm debian/auditd/var/log/audit
chmod -R o-rwx debian/auditd/etc/audit debian/audispd-plugins/etc/audit
 
-override_dh_installdeb:
-   sed -e"s/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/" \
-   debian/libauparse0t64.preinst.in > debian/libauparse0t64.preinst
-   dh_installdeb
-
 get-orig-source:
-uscan --upstream-version 0
 

Bug#1070326: kexec-tools: move aliased files to /usr for DEP17

[Helmut Grohne]

Package: kexec-tools
Version: 1:2.0.27-1.1
Severity: important
Tags: patch

Hi,

kexec-tools is part of the /usr-move (DEP17) migration due to installing
files into /sbin, which is an aliased location. We want to eliminate
(bad) aliasing effects by not installing any aliased files anymore.
Hence, kexec-tools also needs to move and since it doesn't use dh, it
cannot be moved using dh-sequence-movetousr. Therefore, I'm attaching a
patch to perform the move manualy. Note that this patch must not be
backported to bookworm-backports or earlier. kexec-tools isn't usually
backported, so this likely is not a problem.

Helmut
diff --minimal -Nru kexec-tools-2.0.27/debian/changelog 
kexec-tools-2.0.27/debian/changelog
--- kexec-tools-2.0.27/debian/changelog 2024-04-27 14:49:56.0 +0200
+++ kexec-tools-2.0.27/debian/changelog 2024-05-03 12:35:57.0 +0200
@@ -1,3 +1,10 @@
+kexec-tools (1:2.0.27-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr for DEP17. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 May 2024 12:35:57 +0200
+
 kexec-tools (1:2.0.27-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru kexec-tools-2.0.27/debian/kexec-tools.dirs 
kexec-tools-2.0.27/debian/kexec-tools.dirs
--- kexec-tools-2.0.27/debian/kexec-tools.dirs  2023-08-22 18:53:02.0 
+0200
+++ kexec-tools-2.0.27/debian/kexec-tools.dirs  2024-05-03 12:34:38.0 
+0200
@@ -1,2 +1,2 @@
-sbin
+usr/sbin
 etc/default/kexec.d
diff --minimal -Nru kexec-tools-2.0.27/debian/patches/coldreboot.patch 
kexec-tools-2.0.27/debian/patches/coldreboot.patch
--- kexec-tools-2.0.27/debian/patches/coldreboot.patch  2023-09-17 
19:09:53.0 +0200
+++ kexec-tools-2.0.27/debian/patches/coldreboot.patch  2024-05-03 
12:35:21.0 +0200
@@ -57,7 +57,7 @@
 +
 +/bin/rm -f $NOKEXECFILE
 +touch $NOKEXECFILE
-+/sbin/reboot $*
++/usr/sbin/reboot $*
 --- /dev/null
 +++ b/kexec/coldreboot.8
 @@ -0,0 +1,25 @@
diff --minimal -Nru kexec-tools-2.0.27/debian/patches/systemd-support.patch 
kexec-tools-2.0.27/debian/patches/systemd-support.patch
--- kexec-tools-2.0.27/debian/patches/systemd-support.patch 2023-10-04 
18:22:02.0 +0200
+++ kexec-tools-2.0.27/debian/patches/systemd-support.patch 2024-05-03 
12:35:38.0 +0200
@@ -121,7 +121,7 @@
 +}
 +
 +load_kernel () {
-+  test -x /sbin/kexec || exit 0
++  test -x /usr/sbin/kexec || exit 0
 +  test "x`cat /sys/kernel/kexec_loaded`y" = "x1y" && exit 0
 +
 +  if [ -f $NOKEXECFILE ]
@@ -138,9 +138,9 @@
 +  echo "Loading new kernel image into memory"
 +  if [ -z "$INITRD" ]
 +  then
-+  /sbin/kexec -l "$KERNEL_IMAGE" --append="$REAL_APPEND"
++  /usr/sbin/kexec -l "$KERNEL_IMAGE" --append="$REAL_APPEND"
 +  else
-+  /sbin/kexec -l "$KERNEL_IMAGE" --initrd="$INITRD" 
--append="$REAL_APPEND"
++  /usr/sbin/kexec -l "$KERNEL_IMAGE" --initrd="$INITRD" 
--append="$REAL_APPEND"
 +  fi
 +  echo "kexec kernel loaded"
 +}
diff --minimal -Nru kexec-tools-2.0.27/debian/rules 
kexec-tools-2.0.27/debian/rules
--- kexec-tools-2.0.27/debian/rules 2023-10-04 19:59:38.0 +0200
+++ kexec-tools-2.0.27/debian/rules 2024-05-03 12:34:51.0 +0200
@@ -27,7 +27,7 @@
dh_testdir
dh_update_autotools_config
dh_autoreconf
-   CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell 
dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" 
dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/sbin 
--mandir=/usr/share/man --datadir=/usr/share
+   CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell 
dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" 
dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/usr/sbin 
--mandir=/usr/share/man --datadir=/usr/share
touch configure-stamp
 
 build: build-arch build-indep
@@ -63,7 +63,7 @@
[ ! -f 
$(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static ] || 
strip $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static
 endif
 
-   install -D -m 0755 debian/kexec-tools/sbin/kexec 
debian/kexec-tools-udeb/sbin/kexec
+   install -D -m 0755 debian/kexec-tools/usr/sbin/kexec 
debian/kexec-tools-udeb/usr/sbin/kexec
 
 binary-indep: build install
 

Bug#1070256: libcxx-serial FTBFS with the nocheck build profile

[Helmut Grohne]

Source: libcxx-serial
Version: 1.2.1-5
Severity: serious
Justification: nocheck ftbfs is rc since trixie
Tags: ftbfs trixie sid

libcxx-serial fails to build from source when enabling the nocheck build
profile. I think the relevant part is:

| -- catkin 0.8.10
| -- BUILD_SHARED_LIBS is on
| CMake Error at /usr/share/catkin/cmake/test/tests.cmake:21 (message):
|   () is not available when tests are not enabled.  The CMake code should only
|   use it inside a conditional block which checks that testing is enabled:
| 
|   if(CATKIN_ENABLE_TESTING)
| 
| (...)
| 
|   endif()
| 
| Call Stack (most recent call first):
|   tests/CMakeLists.txt:20 (catkin_add_gtest)
| 
| 
| -- Configuring incomplete, errors occurred!
| cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
| ==> CMakeCache.txt <==

Helmut

Bug#1070255: midish FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: midish
Version: 1.0.4-1.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

midish fails to cross build from source, because it builds for the build
architecture. It's configure script doesn't take architecture into
account and mostly configures paths. Cross tools need to be passed to
make just as is done in a traditional make-only project. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru midish-1.0.4/debian/changelog midish-1.0.4/debian/changelog
--- midish-1.0.4/debian/changelog   2022-11-03 22:49:04.0 +0100
+++ midish-1.0.4/debian/changelog   2024-05-02 07:37:47.0 +0200
@@ -1,3 +1,10 @@
+midish (1.0.4-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 02 May 2024 07:37:47 +0200
+
 midish (1.0.4-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru midish-1.0.4/debian/rules midish-1.0.4/debian/rules
--- midish-1.0.4/debian/rules   2022-11-03 22:49:04.0 +0100
+++ midish-1.0.4/debian/rules   2024-05-02 07:37:47.0 +0200
@@ -12,7 +12,7 @@
 build: build-stamp
 build-stamp: configure-stamp
dh_testdir
-   $(MAKE)
+   dh_auto_build --buildsystem=makefile
touch build-stamp
 
 clean:

Bug#1070254: ktp-text-ui FTBFS: undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)'

[Helmut Grohne]

Source: ktp-text-ui
Version: 22.12.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

ktp-text-ui fails to build from source in unstable on amd64. The
relevant log probably is:

| [ 76%] Linking CXX executable ktp-text-ui
| cd /<>/obj-x86_64-linux-gnu/app && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/ktp-text-ui.dir/link.txt --verbose=1
| /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self 
-Wvla -Wdate-time -Wsuggest-override -Wlogical-op -Wl,--enable-new-dtags 
-Wl,-z,relro 
"CMakeFiles/ktp-text-ui.dir/ktp-text-ui_autogen/mocs_compilation.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/main.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/telepathy-chat-ui.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/chat-window.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/chat-tab.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/emoticon-text-edit-action.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/emoticon-text-edit-selector.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/invite-contact-dialog.cpp.o" -o ktp-text-ui  
-Wl,-rpath,/<>/obj-x86_64-linux-gnu/lib:/<>/obj-x86_64-linux-gnu/image-sharer:
 /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.15.15 ../lib/libktpchat.so 
/usr/lib/x86_64-linux-gnu/libKF5PeopleWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Emoticons.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKTpWidgets.so.22.12.3 
/usr/lib/x86_64-linux-gnu/libKTpModels.so.22.12.3.abi1 
/usr/lib/x86_64-linux-gnu/libKF5NotifyConfig.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5KCMUtils.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5TextWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5SonnetUi.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5SonnetCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKTpLogger.so.22.12.3.abi1 
/usr/lib/x86_64-linux-gnu/libKTpCommonInternals.so.22.12.3.abi1 
/usr/lib/x86_64-linux-gnu/libKF5Wallet.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Notifications.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libtelepathy-logger-qt.so.0.9.80.0 
/usr/lib/x86_64-linux-gnu/libtelepathy-qt5.so.0.0.9.8 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5.15.15 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15 
/usr/lib/x86_64-linux-gnu/libQt5WebChannel.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Positioning.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5QmlModels.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5.15.10 
../image-sharer/libktpimagesharer.so 
/usr/lib/x86_64-linux-gnu/libKF5KIOWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5KIOGui.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5JobWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Service.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Solid.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Completion.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigGui.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Codecs.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Auth.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5AuthCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Archive.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libX11.so 
/usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libKTpOTR.so.22.12.3 
/usr/lib/x86_64-linux-gnu/libtelepathy-qt5.so.0.0.9.8 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.15.10 -fPIC 
/usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5People.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5I18n.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10
| /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15: 
undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, 
unsigned long*)'
| collect2: error: ld returned 1 exit status
| make[3]: *** [app/CMakeFiles/ktp-text-ui.dir/build.make:220: app/ktp-text-ui] 
Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:1633: app/CMakeFiles/ktp-text-ui.dir/all] 
Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:149: all] Error 2
| 

Bug#1070253: ddnet FTCBFS: upstream has rather un-Debiann-ish ideas about how cross compilation should work

[Helmut Grohne]

Source: ddnet
Version: 16.4-1.3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi,

ddnet fails to cross build from source. Digging into this I found that
ddnet upstream has a very different idea about cross building from
Debian. For instance, ddnet stops using any kind of system libraries and
expects that you vendor them all into the ddnet source code. Also they
immediately opt out of using pkgconf for cross compilation. This is very
much not what we do in Debian. I managed to make it cross buildable, but
given how ddnet upstream has chosen to implement cross building, I
expect that they very much won't like this patch. Possibly, there could
be some kind of global switch between that vendoring-world that they
want and that "like native" world that Debian's cross build environment
is? Do you mind maintaining this patch in the source package?

Helmut
--- ddnet-16.4.orig/CMakeLists.txt
+++ ddnet-16.4/CMakeLists.txt
@@ -493,7 +493,7 @@
 # be more aggressive with android toolchain
 set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PATH NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
   else()
-set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PATH)
+set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH)
   endif()
 else()
   set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH)
@@ -512,11 +512,9 @@
   endif()
 endfunction()
 
-if(NOT CMAKE_CROSSCOMPILING)
-  # Check for PkgConfig once so all the other `find_package` calls can do it
-  # quietly.
-  find_package(PkgConfig)
-endif()
+# Check for PkgConfig once so all the other `find_package` calls can do it
+# quietly.
+find_package(PkgConfig)
 if(TARGET_OS STREQUAL "android")
   find_package(Android)
 endif()
--- ddnet-16.4.orig/cmake/FindMySQL.cmake
+++ ddnet-16.4/cmake/FindMySQL.cmake
@@ -1,3 +1,7 @@
+find_package(PkgConfig QUIET)
+pkg_check_modules(MYSQLCLIENT mysqlclient)
+pkg_check_modules(LIBMARIADB libmariadb)
+
 if(NOT CMAKE_CROSSCOMPILING)
   find_program(MYSQL_CONFIG
 NAMES mysql_config mariadb_config
@@ -39,13 +43,13 @@
 set_extra_dirs_lib(MYSQL mysql)
 find_library(MYSQL_LIBRARY
   NAMES "mysqlclient" "mysqlclient_r" "mariadbclient"
-  HINTS ${MYSQL_CONFIG_LIBRARY_PATH}
+  HINTS ${MYSQL_CONFIG_LIBRARY_PATH} ${MYSQLCLIENT_LIBRARY_DIRS} ${LIBMARIADB_LIBRARY_DIRS}
   ${CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH}
 )
 set_extra_dirs_include(MYSQL mysql "${MYSQL_LIBRARY}")
 find_path(MYSQL_INCLUDEDIR
   NAMES "mysql.h"
-  HINTS ${MYSQL_CONFIG_INCLUDE_DIR}
+  HINTS ${MYSQL_CONFIG_INCLUDE_DIR} ${MYSQLCLIENT_INCLUDE_DIRS} ${LIBMARIADB_INCLUDE_DIRS}
   ${CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH}
 )
 

Bug#1070166: google-compute-engine-oslogin FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: google-compute-engine-oslogin
Version: 20240415.00-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

google-compute-engine-oslogin fails to cross build from source, because
it uses the build architecture compiler. Looking closer, this happens
during dh_auto_install where debhelper does not pass cross tools.
Apparently, it performs some of the build steps during dh_auto_install.
I tracked this down to not setting the VERSION variable during
dh_auto_build. Once setting it, make install doesn't build anything
anymore and the cross build succeeds. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru google-compute-engine-oslogin-20240415.00/debian/changelog 
google-compute-engine-oslogin-20240415.00/debian/changelog
--- google-compute-engine-oslogin-20240415.00/debian/changelog  2024-04-22 
09:01:53.0 +0200
+++ google-compute-engine-oslogin-20240415.00/debian/changelog  2024-05-01 
09:16:48.0 +0200
@@ -1,3 +1,10 @@
+google-compute-engine-oslogin (20240415.00-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build during dh_auto_build. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 01 May 2024 09:16:48 +0200
+
 google-compute-engine-oslogin (20240415.00-1) unstable; urgency=medium
 
   * New upstream release. (closes: #1041130)
diff --minimal -Nru google-compute-engine-oslogin-20240415.00/debian/rules 
google-compute-engine-oslogin-20240415.00/debian/rules
--- google-compute-engine-oslogin-20240415.00/debian/rules  2024-04-22 
09:01:53.0 +0200
+++ google-compute-engine-oslogin-20240415.00/debian/rules  2024-05-01 
09:16:48.0 +0200
@@ -7,6 +7,10 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- \
+   VERSION=$(DEB_VERSION_UPSTREAM)
+
 override_dh_auto_install:
dh_auto_install -- \
LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \

Bug#1070049: closed by Debian FTP Masters (reply to Carlos Henrique Lima Melara ) (Bug#1070049: fixed in kristall 0.4+dfsg-3)

[Helmut Grohne]

Control: reopen -1

On Mon, Apr 29, 2024 at 07:51:03PM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Carlos Henrique Lima Melara ).

Unfortunately, my patch got mangled during application to the point
where it no longer achieves the desired effect. The QMAKE_COMMAND
assignment was moved to dh, which causes it to become
-O--=QMAKE_COMMAND=... on the relevant dh_auto_* invocations and is
being ignored. I'd appreciate if you could correctly apply the patch.
Also consider performing a test build (sbuild --host=... or pbuilder
--host-arch=...) to see whether your update retains the intended
effects. Thank you.

Helmut

Bug#1069890: Resignation & call for votes to elect the Chair

[Helmut Grohne]

On Tue, Apr 30, 2024 at 11:09:26AM +0100, Matthew Vernon wrote:
> > ===BEGIN
> > 
> > A: Christoph Berg 
> > B: Matthew Garrett 
> > C: Helmut Grohne 
> > D: Stefano Rivera 
> > E: Timo Röhling 
> > F: Craig Small 
> > G: Matthew Vernon 
> > H: Sean Whitton 
> > 
> > ===END
> 
> I vote H > A = B = C = D = E = G > F
> 
> If no-one else wants to be chair when Sean leaves, I'd be willing to do so.

Thanks for volunteering. I prefer having a longer hand-over period over
a shorter one. Therefore, I change my earlier vote on this matter to the
following assuming that you are also volunteering now already.

G > H > AB > CDE > F

Helmut


signature.asc
Description: PGP signature

Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?

[Helmut Grohne]

On Mon, Apr 15, 2024 at 06:10:16PM +0200, Helmut Grohne wrote:
> In any case, I looked into prototyping this suggested move as a patch to
> the gcc packaging. I am attaching a proof-of-concept of this, but I'm
> not particularly fond of it as it noticeably increases the packaging
> complexity. I am adding a lot of "addons" and pull a bit of code from
> various debian/rules.d/binary-*.mk to a new
> debian/rules.d/binary-forhost.mk such that prefixes that were only used
> in a particular file are now spread to multiple. For instance, all
> ?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier
> and are now spread out to debian/rules.d/binary-forhost.mk. This move is
> rooted in the fact that inclusion of debian/rules.d/binary-*.mk is
> conditionalized.
> 
> So initially, I am more interested in figuring out whether this is the
> right direction and as a secondary question conditional to the answer of
> the first, how to improve the patch to make that work.

I have added this patch to rebootstrap now and it has generally improved
bootstrapping. In particular, gcc-N-for-host is practically
coinstallable. I am more and more convinced that this is the right
direction. Do you have fundamental objections? Do you see ways to
improve the patch?

Helmut

Bug#1070125: dmucs FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: dmucs
Version: 0.6.1+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dmucs fails to cross build from source, because it uses the build
architecture compiler. override_dh_auto_configure now invokes
./configure without passing --host and hence configure uses the wrong
compiler. Moreover, the upstream build system fails to forward the
detected compiler to the COSMIC subdirectory. I'm attaching a patch to
fix both for your convenience.

Helmut
diff -Nru dmucs-0.6.1+dfsg/debian/changelog dmucs-0.6.1+dfsg/debian/changelog
--- dmucs-0.6.1+dfsg/debian/changelog   2024-04-22 02:19:52.0 +0200
+++ dmucs-0.6.1+dfsg/debian/changelog   2024-04-30 13:31:33.0 +0200
@@ -1,3 +1,11 @@
+dmucs (0.6.1+dfsg-2) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: (Closes: #-1)
++ Pass --host to configure.
++ cross.patch: Forward CC to COSMIC subdir.
+
+ -- Helmut Grohne   Tue, 30 Apr 2024 13:31:33 +0200
+
 dmucs (0.6.1+dfsg-1) unstable; urgency=medium
 
   * QA upload.
diff -Nru dmucs-0.6.1+dfsg/debian/patches/cross.patch 
dmucs-0.6.1+dfsg/debian/patches/cross.patch
--- dmucs-0.6.1+dfsg/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ dmucs-0.6.1+dfsg/debian/patches/cross.patch 2024-04-30 13:31:33.0 
+0200
@@ -0,0 +1,19 @@
+--- dmucs-0.6.1+dfsg.orig/COSMIC/Makefile
 dmucs-0.6.1+dfsg/COSMIC/Makefile
+@@ -29,7 +29,7 @@
+ # One may also start up the PortMaster (Spm -f firewallfilename).
+ # Please read the documentation on this.
+ 
+-CC = cc
++CC ?= cc
+ 
+ OBJ = Saccept.o  Sprintf.o  Stest.ooutofmem.o \
+   Sclose.o   Sprtskt.o  Stimeoutwait.o rdcolor.o  \
+--- dmucs-0.6.1+dfsg.orig/Makefile.am
 dmucs-0.6.1+dfsg/Makefile.am
+@@ -1,3 +1,5 @@
++export CC
++
+ SUBDIRS = COSMIC
+ 
+ bin_PROGRAMS = gethost loadavg monitor remhost
diff -Nru dmucs-0.6.1+dfsg/debian/patches/series 
dmucs-0.6.1+dfsg/debian/patches/series
--- dmucs-0.6.1+dfsg/debian/patches/series  2024-04-20 05:31:05.0 
+0200
+++ dmucs-0.6.1+dfsg/debian/patches/series  2024-04-30 13:31:33.0 
+0200
@@ -3,3 +3,4 @@
 03_gcc-7.patch
 40_reproducible.patch
 50_fix-FTBS-GCC-13.patch
+cross.patch
diff -Nru dmucs-0.6.1+dfsg/debian/rules dmucs-0.6.1+dfsg/debian/rules
--- dmucs-0.6.1+dfsg/debian/rules   2024-04-22 02:09:44.0 +0200
+++ dmucs-0.6.1+dfsg/debian/rules   2024-04-30 13:31:30.0 +0200
@@ -3,11 +3,13 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall
 
+include /usr/share/dpkg/architecture.mk
+
 override_dh_auto_install:
cp -a remhost addhost
 
 override_dh_auto_configure:
-   ./configure
+   ./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 
 override_dh_clean:
dh_clean

Bug#1070124: gpm FTBFS: -Werror=implicit-function-declaration makes missing #includes fatal

[Helmut Grohne]

Source: gpm
Version: 1.20.7-11
Severity: important
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

We recently made -Werror=implicit-function-declaration the default.
Unfortunately src/daemon/old_main.c is missing some crucial #includes
and that makes the build fail in some configurations. It notably misses:

 *  for strcmp, strcpy and strerror
 *  for bzero

I'm attaching a patch for your convenience.

Helmut
--- gpm-1.20.7.orig/src/daemon/old_main.c
+++ gpm-1.20.7/src/daemon/old_main.c
@@ -19,6 +19,8 @@
  *
  /
 
+#include  /* str*  */
+#include /* bzero */
 #include  /* UNIX  */
 #include  /* SOCKET*/
 #include   /* open  */

Bug#1070123: attr FTBFS: -Werror=implicit-function-declaration triggers on basefile for missing libgen.h

[Helmut Grohne]

Source: attr
Version: 1:2.5.2-1
Severity: important
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

attr may fail to build from source with
-Werror=implicit-function-declaration due to using basename without
including libgen.h. I'm attaching a patch for your convenience.

Helmut
--- attr-2.5.2.orig/tools/attr.c
+++ attr-2.5.2/tools/attr.c
@@ -18,6 +18,7 @@
 
 #include "config.h"
 
+#include 
 #include 
 #include 
 #include 

Bug#1070007: sbuild/unshare: writing to /dev/stdout denied

[Helmut Grohne]

Control: tags -1 + confirmed

On Sun, Apr 28, 2024 at 10:59:14PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Aurelien Jarno (2024-04-28 15:57:29)
> > When running sbuild in unshare chroot mode, it is not possible to write to
> > /dev/stdout:
> > 
> > | echo test > /dev/stdout
> > | sh: 1: cannot create /dev/stdout: Permission denied
> > 
> > This is the reason of the FTBFS of at least clisp and supervisor when using
> > the unshare chroot mode of sbuild.

Jochen asked me to look into this. Let me write down what I have for the
benefit of the next person dumping brain cells into it.

I used bookworm's sbuild to reproduce it using the supervisor package
and that readily reproduced. I added an execute_before_dh_auto_test with
a few diagnostics:

| ls -la /dev/stdout
| lrwxrwxrwx 1 root root 15 Apr 30 07:36 /dev/stdout -> /proc/self/fd/1
| ls -la /proc/self/fd
| total 0
| dr-x-- 2 helmut sbuild  0 Apr 30 07:36 .
| dr-xr-xr-x 9 helmut sbuild  0 Apr 30 07:36 ..
| lrwx-- 1 helmut sbuild 64 Apr 30 07:36 0 -> /dev/null
| l-wx-- 1 helmut sbuild 64 Apr 30 07:36 1 -> pipe:[135566170]
| l-wx-- 1 helmut sbuild 64 Apr 30 07:36 2 -> pipe:[135566170]
| lr-x-- 1 helmut sbuild 64 Apr 30 07:36 3 -> /proc/123/fd
| echo hello > /proc/self/fd/1
| /bin/sh: 1: cannot create /proc/self/fd/1: Permission denied

I also added --anything-failed-commands=%SBUILD_SHELL and there things
look different.

| # ls -la /proc/self/fd/1
| l-wx-- 1 root root 64 Apr 30 07:44 /proc/self/fd/1 -> /dev/tty
| # runuser -u helmut bash
| $ ls -la /proc/self/fd/1
| l-wx-- 1 helmut sbuild 64 Apr 30 07:48 /proc/self/fd/1 -> /dev/tty

Running supervisor's test suite succeeds here.

Quite certainly, the cause is connected to that pipe. The pipe in
question is connecting the build log to a process that filters the build
log and replaces PKGBUILDDIR and stuff. As far as I understand it, the
crucial bit is that this process runs outside of the namespace.

To confirm this hypothesis, I tried the following override:

| override_dh_auto_test:
|   dh_auto_test | cat

In essence, I am placing another process (cat) inside the namespace such
that the stdout pipe of the test resides fully inside the namespace and
cat is responsible for writing to the pipe outside without going via
/proc/self/fd. With this modification, the build works again.

> This works in podman. So somehow it's possible to connect /dev/stdout in a way
> which preserves its intended functionality. Probably it would be useful to 
> find
> out how podman does this. For what its worth, mmdebstrap itself suffers from
> the same problem, so whatever fix is used in sbuild should probably also be
> added to mmdebstrap.

This does not work in podman
https://github.com/containers/podman/issues/16870 nor on docker
https://github.com/moby/moby/issues/31243. It sometimes works and that
sometimes is when you run it interactively and thus stdout points to a
tty device. As soon as it is a that pipe thingy, it fails.

This is actually something I researched more deeply a while ago without
success. I was trying to open a regular file in the initial namespace,
inherit the open file across unshare into a user and mount namespace and
then open /proc/self/fd/N. Likewise, I get -EACCES there in the very
same way. Some part of permission management prevents this kind of
(intentional) leakage of file descriptors, but I cannot tell which or
why.

The lesson learned seems to be that when you run a container workload,
your stdout or stderr should either connect to a tty or to a process
that lives inside your namespace (not sure which of them).

It also seems possible to change permission of those pipes
https://github.com/containers/conmon/pull/112 but I do not understand
what it means to do so and whether that technically is a good idea. If
you

chmod(0666, *STDOUT);

right before unsharing in Sbuild/Utility.pm, the supervisor test also
passes, but this can also have undesired effects if stdout is connected
to a regular file. So we really should check that STDOUT is a pipe
before doing so. There is protection in the sense that /proc/self/fd by
default is mode 0500. I also note that posix says that fchmod should
return -EINVAL when it is performed on a pipe, so doing this very much
is a linux-ism (but namespaces already are).

To see whether stdout is a pipe, we may fstat it and figure out whether
its st_mode has S_IFIFO. In perl, that's:

use Fcntl ':mode';
... if (((stat(*STDOUT))[2] & S_IFMT) == S_IFIFO);

Going deeper with research, think this is actually not a namespace
problem. https://groups.google.com/g/fa.linux.kernel/c/WVFgFngkJZw
indicates a very similar problem with doing setuid. We can emulate this
locally and reproduce the failure

unshare -U --map-auto -S 0 -G 0 sh -c \
'/sbin/runuser -u daemon -- sh -c ": >/proc/self/fd/1" | cat'

noting that the use of unshare here is purely added for the benefit of
running the test code unprivileged. You 

Bug#1070059: p11-kit FTBFS with gcc-14 due to -Wincompatible-pointer-types having become an error

[Helmut Grohne]

Control: tags -1 patch upstream fixed-upstream
Control: forwarded -1 
https://github.com/p11-glue/p11-kit/commit/d49c92c8420db6ee4c88515bdb014f68f4d471d9

On Mon, Apr 29, 2024 at 03:02:07PM +0200, Helmut Grohne wrote:
> This will become a hard failure once we swicth to gcc-14.

It's already fixed upstream!

Helmut

Bug#1070059: p11-kit FTBFS with gcc-14 due to -Wincompatible-pointer-types having become an error

[Helmut Grohne]

Source: p11-kit
Version: 0.25.3-4
Severity: important
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

p11-kit fails to build from source when built with gcc-14. In gcc-14,
-Wincompatible-pointer-types has become an error. For instance, the
armel build currently says:

| p11-kit/import-object.c: In function ‘add_attrs_pubkey_rsa’:
| p11-kit/import-object.c:223:62: warning: passing argument 3 of 
‘p11_asn1_read’ from incompatible pointer type [-Wincompatible-pointer-types]
|   223 | attr_modulus.pValue = p11_asn1_read (asn, "modulus", 
_modulus.ulValueLen);
|   |  
^~~~
|   |  |
|   |  long 
unsigned int *
| In file included from p11-kit/import-object.c:53:
| ./common/asn1.h:60:62: note: expected ‘size_t *’ {aka ‘unsigned int *’} but 
argument is of type ‘long unsigned int *’
|60 |  size_t *length);
|   |  ^~
| p11-kit/import-object.c:229:70: warning: passing argument 3 of 
‘p11_asn1_read’ from incompatible pointer type [-Wincompatible-pointer-types]
|   229 | attr_exponent.pValue = p11_asn1_read (asn, "publicExponent", 
_exponent.ulValueLen);
|   |  
^
|   |  |
|   |  
long unsigned int *
| ./common/asn1.h:60:62: note: expected ‘size_t *’ {aka ‘unsigned int *’} but 
argument is of type ‘long unsigned int *’
|60 |  size_t *length);
|   |  ^~
| p11-kit/import-object.c: In function ‘add_attrs_pubkey_ec’:
| p11-kit/import-object.c:264:78: warning: passing argument 3 of 
‘p11_asn1_read’ from incompatible pointer type [-Wincompatible-pointer-types]
|   264 | attr_ec_params.pValue = p11_asn1_read (info, 
"algorithm.parameters", _ec_params.ulValueLen);
|   |   
   ^~
|   |   
   |
|   |   
   long unsigned int *
| ./common/asn1.h:60:62: note: expected ‘size_t *’ {aka ‘unsigned int *’} but 
argument is of type ‘long unsigned int *’
|60 |  size_t *length);
|   |  ^~

This will become a hard failure once we swicth to gcc-14.

Helmut

Bug#1070047: python3-django-pipeline: installs files into aliased locations

[Helmut Grohne]

Control: tags -1 - patch

Hi Alexandre,

On Mon, Apr 29, 2024 at 12:35:02PM +0200, Alexandre Detiste wrote:
> If I revert the NAME change autodep8 breaks on Salsa

Dang. I was looking for what I could have broken and didn't see this.

> Is there an easy way to have one name for pybuild and another one for
> autodep8 ... ? I ll search.

I looked at man pybuild and https://wiki.debian.org/Python/Pybuild and
neither was particularly enlightening to me. Possibly setting
PYBUILD_NAME=pipeline and PYBUILD_DESTDIR=debian/python3-django-pipeline
works?

Helmut

Bug#1069890: Resignation & call for votes to elect the Chair

[Helmut Grohne]

On Fri, Apr 26, 2024 at 02:04:56PM +0100, Sean Whitton wrote:
> Package: tech-ctte
> 
> Dear committee members,
> 
> As the membership of the committee has changed, in accordance with
> convention I hereby resign as Chair, effective one week from now, and
> call for votes to elect the Chair of the Technical Committee.
> Per the Debian Constitution, the vote runs until all members have voted,
> or until my resignation takes effect.
> 
> I am happy to continue to volunteer for the role, if the committee agrees.
> 
> The ballot:
> 
> ===BEGIN
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Stefano Rivera 
> E: Timo Röhling 
> F: Craig Small 
> G: Matthew Vernon 
> H: Sean Whitton 
> 
> ===END

I vote:

   H > ABG > CDE > F

In this case, I want to give a rationale.

While Sean's term ends this year, no one but Sean volunteered to take
the chair position yet and I'd rather not volunteer myself. It also is
customary to not become a chair quickly after joining the committee. So
at this time, continuing with Sean seems like the best option to me
though I'd prefer an earlier handover over choosing a chair when Sean's
membership expires. I suggest raising another vote around August.

Last but not least, I want to thank Sean for having served as chair and
taking on the relevant bureaucracy.

Helmut


signature.asc
Description: PGP signature

Bug#1070049: kristall FTCBFS: uses the build architecture qmake

[Helmut Grohne]

Source: kristall
Version: 0.4+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kristall fails to cross build from source, because it runs qmake from a
Makefile without taking care to use a host one. I'm attaching a patch
that makes the build use a triplet-prefixed qmake when indicated for
your convenience.

Helmut
diff --minimal -Nru kristall-0.4+dfsg/debian/changelog 
kristall-0.4+dfsg/debian/changelog
--- kristall-0.4+dfsg/debian/changelog  2023-06-12 04:10:13.0 +0200
+++ kristall-0.4+dfsg/debian/changelog  2024-04-29 12:13:41.0 +0200
@@ -1,3 +1,10 @@
+kristall (0.4+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Apr 2024 12:13:41 +0200
+
 kristall (0.4+dfsg-2) unstable; urgency=medium
 
   * debian/control: update maintainer's email.
diff --minimal -Nru kristall-0.4+dfsg/debian/rules 
kristall-0.4+dfsg/debian/rules
--- kristall-0.4+dfsg/debian/rules  2022-12-30 14:32:08.0 +0100
+++ kristall-0.4+dfsg/debian/rules  2024-04-29 12:13:41.0 +0200
@@ -2,6 +2,7 @@
 #export DH_VERBOSE = 1
 
 include /usr/share/dpkg/pkg-info.mk
+include /usr/share/dpkg/buildtools.mk
 
 export PREFIX=/usr
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
@@ -14,3 +15,9 @@
 
 %:
dh $@
+
+override_dh_auto_build:
+   dh_auto_build -- QMAKE_COMMAND='$(QMAKE)'
+
+override_dh_auto_install:
+   dh_auto_install -- QMAKE_COMMAND='$(QMAKE)'

Bug#1070050: hpcc FTCBFS: uses mpicc

[Helmut Grohne]

Source: hpcc
Version: 1.5.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

hpcc fails to cross build from source, because it uses mpicc. mpicc is
completely unsupportable during cross builds, because there are no
triplet-prefixed variants of mpicc. Instead, common wisdom is to use
pkgconf and use it to look up the required compiler and linker flags.
I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru hpcc-1.5.0/debian/changelog hpcc-1.5.0/debian/changelog
--- hpcc-1.5.0/debian/changelog 2022-07-28 22:21:34.0 +0200
+++ hpcc-1.5.0/debian/changelog 2024-04-29 10:39:50.0 +0200
@@ -1,3 +1,10 @@
+hpcc (1.5.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use pkgconf instead of mpicc. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Apr 2024 10:39:50 +0200
+
 hpcc (1.5.0-3) unstable; urgency=medium
 
   * Refresh patches using gbp pq import/export
diff --minimal -Nru hpcc-1.5.0/debian/control hpcc-1.5.0/debian/control
--- hpcc-1.5.0/debian/control   2022-07-28 22:21:34.0 +0200
+++ hpcc-1.5.0/debian/control   2024-04-29 10:39:50.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Science Maintainers 

 Uploaders: Lucas Nussbaum 
-Build-Depends: debhelper-compat (= 12), libatlas-base-dev, mpi-default-dev, 
mpi-default-bin
+Build-Depends: debhelper-compat (= 12), libatlas-base-dev, mpi-default-dev, 
mpi-default-bin, pkgconf
 Standards-Version: 4.3.0
 Homepage: https://hpcchallenge.org/hpcc/
 Vcs-Git: https://salsa.debian.org/hpc-team/hpcc.git
diff --minimal -Nru hpcc-1.5.0/debian/patches/add-Make.Debian.patch 
hpcc-1.5.0/debian/patches/add-Make.Debian.patch
--- hpcc-1.5.0/debian/patches/add-Make.Debian.patch 2022-07-28 
22:21:34.0 +0200
+++ hpcc-1.5.0/debian/patches/add-Make.Debian.patch 2024-04-29 
10:39:50.0 +0200
@@ -14,7 +14,7 @@
 index 000..d19bbdf
 --- /dev/null
 +++ b/hpl/Make.Debian
-@@ -0,0 +1,181 @@
+@@ -0,0 +1,185 @@
 +# -*- makefile -*-
 +#
 +#  -- High Performance Computing Linpack Benchmark (HPL)
@@ -184,12 +181,16 @@
 +# - Compilers / linkers - Optimization flags ---
 +# --
 +#
-+CC   = mpicc
-+CCNOOPT  = $(HPL_DEFS)
-+CCFLAGS  = $(HPL_DEFS) -fomit-frame-pointer -O3 -funroll-loops -W -Wall 
$(shell dpkg-buildflags --get CFLAGS)
++PKG_CONFIG   = pkg-config
++CC   = cc
++MPI_CFLAGS   = $(shell $(PKG_CONFIG) --cflags mpi)
++MPI_LIBS = $(shell $(PKG_CONFIG) --libs mpi)
++CCNOOPT  = $(MPI_CFLAGS) $(HPL_DEFS)
++CCFLAGS  = $(MPI_CFLAGS) $(HPL_DEFS) -fomit-frame-pointer -O3 
-funroll-loops -W -Wall $(shell dpkg-buildflags --get CFLAGS)
 +#
-+LINKER   = mpicc
++LINKER   = $(CC)
 +LINKFLAGS= $(CCFLAGS) $(shell dpkg-buildflags --get LDFLAGS)
++HPL_LIBS += $(MPI_LIBS)
 +#
 +ARCHIVER = ar
 +ARFLAGS  = r

Bug#1070048: python3-distutils: empty directory loss /usr/lib/python3.12 due to /usr-move

[Helmut Grohne]

Package: python3-distutils
Version: 3.12.3-1
Severity: important
Tags: patch

Hi Matthias,

python3-distutils installs an empty directory /usr/lib/python3.12. This
is prone to loss when removing another package containing
/lib/python3.12 such as python3-django-pipeline is being removed.

My understanding is that distutils is removed from Python in version
3.12 and thus this empty directory is not required and rather an
oversight. I am attaching a patch that removes the empty directory from
the package.

Helmut
diff --minimal -Nru python3-stdlib-extensions-3.12.3/debian/changelog 
python3-stdlib-extensions-3.12.3/debian/changelog
--- python3-stdlib-extensions-3.12.3/debian/changelog   2024-04-12 
15:08:54.0 +0200
+++ python3-stdlib-extensions-3.12.3/debian/changelog   2024-04-29 
08:37:11.0 +0200
@@ -1,3 +1,11 @@
+python3-stdlib-extensions (3.12.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop empty directory /usr/lib/python3.12 from python3-distutils.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Apr 2024 08:37:11 +0200
+
 python3-stdlib-extensions (3.12.3-1) unstable; urgency=medium
 
   * Update 3.11 extensions and modules to 3.11.9 release.
diff --minimal -Nru python3-stdlib-extensions-3.12.3/debian/rules 
python3-stdlib-extensions-3.12.3/debian/rules
--- python3-stdlib-extensions-3.12.3/debian/rules   2024-03-03 
14:41:25.0 +0100
+++ python3-stdlib-extensions-3.12.3/debian/rules   2024-04-29 
08:37:09.0 +0200
@@ -209,9 +209,6 @@
cp -r 3.12/Lib/tkinter $(d_tk)/usr/lib/python3.12/.
rm -rf $(d_tk)/usr/lib/python3.12/tkinter/test
 
-   mkdir -p $(d_dist)/usr/lib/python3.12
-   find $(d_dist) -name __pycache__ | xargs -r rm -rf
-
mkdir -p $(d_2to3)/usr/lib/python3.12
cp -r 3.12/Lib/lib2to3 $(d_2to3)/usr/lib/python3.12/.
rm -rf $(d_2to3)/usr/lib/python3.12/lib2to3/tests

Bug#1070047: python3-django-pipeline: installs files into aliased locations

[Helmut Grohne]

Package: python3-django-pipeline
Version: 3.0.0-1
Severity: serious
Justification: introduces new aliasing
Tags: patch
Control: affects -1 + python3-distutils
User: helm...@debian.org
Usertags: dep17p6

The last upload of python3-django-pipeline moved all of its files from
/usr/lib to /lib. Whils this works somewhat on a /usr-merged
installations, it causes subtle bugs due to dpkg not being prepared with
aliasing. In DEP17, we're resolving this by moving all files out of
aliased locations and python3-django-pipelines has just introduced new.
Hence, I'm filing this at RC severity. I think the move was accidental
and can be fixed by dropping the faulty "mv" command in favour of
setting PYBUILD_NAME to the package name rather than the module name.
I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru django-pipeline-3.0.0/debian/changelog 
django-pipeline-3.0.0/debian/changelog
--- django-pipeline-3.0.0/debian/changelog  2024-04-28 19:35:05.0 
+0200
+++ django-pipeline-3.0.0/debian/changelog  2024-04-29 10:17:13.0 
+0200
@@ -1,3 +1,10 @@
+django-pipeline (3.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install into /lib. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Apr 2024 10:17:13 +0200
+
 django-pipeline (3.0.0-1) unstable; urgency=medium
 
   * Team Upload
diff --minimal -Nru django-pipeline-3.0.0/debian/rules 
django-pipeline-3.0.0/debian/rules
--- django-pipeline-3.0.0/debian/rules  2024-04-28 19:35:05.0 +0200
+++ django-pipeline-3.0.0/debian/rules  2024-04-29 10:17:13.0 +0200
@@ -4,7 +4,7 @@
 include /usr/share/dpkg/pkg-info.mk
 export SETUPTOOLS_SCM_PRETEND_VERSION=${DEB_VERSION_UPSTREAM}
 
-export PYBUILD_NAME=pipeline
+export PYBUILD_NAME=django-pipeline
 export PYBUILD_AFTER_BUILD_python3=PYTHONPATH=. sphinx-build -b html -d 
docs/.build/.doctrees -N docs docs/.build/html
 
 # Uncomment this to turn on verbose mode.
@@ -25,6 +25,5 @@
PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version} 
/usr/bin/django-admin test --settings=tests.settings" dh_auto_test
 
 execute_after_dh_auto_install:
-   mv debian/python3-pipeline/* debian/python3-django-pipeline/
find -type f -name '*.pyc' -delete
find -type d -name __pycache__ -empty -delete

Bug#1070046: edflib: consider expressing the little endian constraint via Build-Depends: architecture-is-little-endian

[Helmut Grohne]

Source: edflib
Version: 1.25-1
Severity: wishlist
Tags: patch

Hi,

edflib fails to build on big endian architectures. While it fails
quickly, it still requires creating a chroot and it looks like a real
failure. Would you mind lifting this into a build dependency expressing
the constraint? Thus edflib would become permanently bd-uninstallable on
all big endian architectures. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru edflib-1.25/debian/changelog edflib-1.25/debian/changelog
--- edflib-1.25/debian/changelog2024-01-13 16:37:31.0 +0100
+++ edflib-1.25/debian/changelog2024-04-29 12:02:22.0 +0200
@@ -1,3 +1,10 @@
+edflib (1.25-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Express little-endian constraint via Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Apr 2024 12:02:22 +0200
+
 edflib (1.25-1) unstable; urgency=medium
 
   * New upstream version 1.25
diff --minimal -Nru edflib-1.25/debian/control edflib-1.25/debian/control
--- edflib-1.25/debian/control  2024-01-13 16:37:31.0 +0100
+++ edflib-1.25/debian/control  2024-04-29 12:02:17.0 +0200
@@ -4,7 +4,8 @@
Étienne Mollier 
 Section: science
 Priority: optional
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: architecture-is-little-endian,
+   debhelper-compat (= 13),
cmake,
d-shlibs
 Standards-Version: 4.6.2
diff --minimal -Nru edflib-1.25/debian/rules edflib-1.25/debian/rules
--- edflib-1.25/debian/rules2024-01-13 16:37:31.0 +0100
+++ edflib-1.25/debian/rules2024-04-29 12:02:00.0 +0200
@@ -8,10 +8,6 @@
dh $@ --buildsystem=cmake
 
 override_dh_auto_configure:
-ifeq ($(DEB_HOST_ARCH_ENDIAN),big)
-   @ echo "E: edflib doesn't support big endian systems, bailing out!"
-   @ exit 1
-endif
dh_auto_configure -- -DEDFLIB_INSTALL_PATH=lib/${DEB_HOST_MULTIARCH}
 
 

Bug#1070025: mesaflash FTCBFS: multiple reasons

[Helmut Grohne]

Source: mesaflash
Version: 3.4.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mesaflash fails to cross build from source for multiple reasons. The
immediate failure is misdetections due to using the build architecture
pkg-config as it is hard coded in the upstream Makefile. Turning it
substitutable helps a bit, but only dh_auto_build provides a
substitution by default so clean fails unless exporting it for all
targets. Beyond that, MESAFLASH_IO detection relies on uname, which will
produce wrong results during cross builds, so provide a result for it.
I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru mesaflash-3.4.6/debian/changelog 
mesaflash-3.4.6/debian/changelog
--- mesaflash-3.4.6/debian/changelog2022-11-05 19:38:09.0 +0100
+++ mesaflash-3.4.6/debian/changelog2024-04-28 21:16:32.0 +0200
@@ -1,3 +1,13 @@
+mesaflash (3.4.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Seed MESAFLASH_IO as the Makefile misdetects it.
++ Export PKG_CONFIG for all targets as clean needs it.
+
+ -- Helmut Grohne   Sun, 28 Apr 2024 21:16:32 +0200
+
 mesaflash (3.4.6-1) unstable; urgency=medium
 
   * Add new Mesa boards: 7C81, 7I96S, 7I92T
diff --minimal -Nru mesaflash-3.4.6/debian/patches/cross.patch 
mesaflash-3.4.6/debian/patches/cross.patch
--- mesaflash-3.4.6/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ mesaflash-3.4.6/debian/patches/cross.patch  2024-04-28 21:16:32.0 
+0200
@@ -0,0 +1,43 @@
+--- mesaflash-3.4.6.orig/Makefile
 mesaflash-3.4.6/Makefile
+@@ -25,6 +25,7 @@
+ RM = rm -f
+ AR = ar
+ RANLIB = ranlib
++PKG_CONFIG ?= pkg-config
+ 
+ OWNERSHIP ?= --owner root --group root
+ 
+@@ -46,25 +47,25 @@
+ CFLAGS += -std=c99
+ 
+ ifeq ($(TARGET),linux)
+-$(shell which pkg-config > /dev/null)
++$(shell which $(PKG_CONFIG) > /dev/null)
+ ifeq ($(.SHELLSTATUS), 1)
+ $(error "can't find pkg-config")
+ endif
+ 
+-$(shell pkg-config --exists libpci > /dev/null)
++$(shell $(PKG_CONFIG) --exists libpci > /dev/null)
+ ifeq ($(.SHELLSTATUS), 1)
+ $(error "pkg-config can't find libpci")
+ endif
+ 
+-$(shell pkg-config --exists libmd > /dev/null)
++$(shell $(PKG_CONFIG) --exists libmd > /dev/null)
+ ifeq ($(.SHELLSTATUS), 1)
+ $(error "pkg-config can't find libmd")
+ endif
+ 
+-LIBPCI_CFLAGS := $(shell pkg-config --cflags libpci)
+-LIBPCI_LDFLAGS := $(shell pkg-config --libs libpci)
+-LIBMD_CFLAGS := $(shell pkg-config --cflags libmd)
+-LIBMD_LDFLAGS := $(shell pkg-config --libs libmd)
++LIBPCI_CFLAGS := $(shell $(PKG_CONFIG) --cflags libpci)
++LIBPCI_LDFLAGS := $(shell $(PKG_CONFIG) --libs libpci)
++LIBMD_CFLAGS := $(shell $(PKG_CONFIG) --cflags libmd)
++LIBMD_LDFLAGS := $(shell $(PKG_CONFIG) --libs libmd)
+ BIN = mesaflash
+ LDFLAGS = -lm $(LIBPCI_LDFLAGS) $(LIBMD_LDFLAGS)
+ CFLAGS += -D_GNU_SOURCE $(LIBPCI_CFLAGS) $(LIBMD_CFLAGS) 
-D_FILE_OFFSET_BITS=64
diff --minimal -Nru mesaflash-3.4.6/debian/patches/series 
mesaflash-3.4.6/debian/patches/series
--- mesaflash-3.4.6/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ mesaflash-3.4.6/debian/patches/series   2024-04-28 21:10:03.0 
+0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru mesaflash-3.4.6/debian/rules mesaflash-3.4.6/debian/rules
--- mesaflash-3.4.6/debian/rules2022-01-15 20:13:35.0 +0100
+++ mesaflash-3.4.6/debian/rules2024-04-28 21:16:27.0 +0200
@@ -1,6 +1,13 @@
 #!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
 include /usr/share/dpkg/pkg-info.mk
 
+# Makefile uses uname, which is wrong for cross builds.
+MESAFLASH_IO:=$(if $(wildcard /usr/include/$(DEB_HOST_MULTIARCH)/asm/io.h),1,0)
+export MESAFLASH_IO
+
 %:
dh $@
 

Bug#1056192: slirp4netns: allow reusing an existing tap file descriptor

[Helmut Grohne]

On Mon, Mar 25, 2024 at 07:53:22AM +0100, Helmut Grohne wrote:
> In the mean time, I've sent the patch upstream.

I note that upstream released version 1.3.0 including this change.

Helmut

Bug#1070026: ifupdown-ng FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: ifupdown-ng
Version: 0.12.1-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ifupdown-ng fails to cross build from source, because debian/rules hard
codes the build architecture pkg-config and thus fails locating libbsd.
This happens to be a silent failure and thus manifests in
-Werror=implicit-function-declaration. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru ifupdown-ng-0.12.1/debian/changelog 
ifupdown-ng-0.12.1/debian/changelog
--- ifupdown-ng-0.12.1/debian/changelog 2024-03-13 15:56:58.0 +0100
+++ ifupdown-ng-0.12.1/debian/changelog 2024-04-28 13:15:51.0 +0200
@@ -1,3 +1,10 @@
+ifupdown-ng (0.12.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Apr 2024 13:15:51 +0200
+
 ifupdown-ng (0.12.1-4) unstable; urgency=medium
 
   * Fix FTBFS due to libbsd header location change (Closes: #1066707)
diff --minimal -Nru ifupdown-ng-0.12.1/debian/rules 
ifupdown-ng-0.12.1/debian/rules
--- ifupdown-ng-0.12.1/debian/rules 2024-03-13 15:54:18.0 +0100
+++ ifupdown-ng-0.12.1/debian/rules 2024-04-28 13:15:50.0 +0200
@@ -1,13 +1,14 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/buildtools.mk
 SHELL := /bin/bash
 
 %:
dh $@
 
 MAKE_VARS := \
-   LIBBSD_CFLAGS="$(shell pkg-config --cflags libbsd-overlay)" \
-   LIBBSD_LIBS="$(shell pkg-config --cflags --libs libbsd-overlay)"
+   LIBBSD_CFLAGS="$(shell $(PKG_CONFIG) --cflags libbsd-overlay)" \
+   LIBBSD_LIBS="$(shell $(PKG_CONFIG) --cflags --libs 
libbsd-overlay)"
 
 override_dh_auto_build:
# Compatiblity glue for libbsd (strlcpy 'n friends)

Bug#1069926: laurel: move from dh-sysuser to standard dh_installsysusers

[Helmut Grohne]

Package: laurel
Version: 0.6.1-1
Severity: wishlist
Tags: patch

Hi,

dh-sysusers exists since 7 years and has gained 9 users in that time -
laurel being one of them. Still it has a number of deficiencies such as
using useradd instead of the policy-recommended adduser or removing
users during package removal against project consensus and is not making
progress on addressing them. Meanwhile, a viable alternative with larger
adoption exists: sysusers.d. This mechanism is built into debhelper and
it no longer requires using systemd as multiple implementations now
exist. I therefore think it is time to call dh-sysusers a failed
experiment and move on. Do you agree with this reasoning? I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru rust-laurel-0.6.1/debian/changelog 
rust-laurel-0.6.1/debian/changelog
--- rust-laurel-0.6.1/debian/changelog  2024-04-03 17:52:57.0 +0200
+++ rust-laurel-0.6.1/debian/changelog  2024-04-27 10:16:01.0 +0200
@@ -1,3 +1,10 @@
+rust-laurel (0.6.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move from dh-sysuser to standard dh_installsysusers. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Apr 2024 10:16:01 +0200
+
 rust-laurel (0.6.1-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru rust-laurel-0.6.1/debian/control 
rust-laurel-0.6.1/debian/control
--- rust-laurel-0.6.1/debian/control2024-04-03 17:52:57.0 +0200
+++ rust-laurel-0.6.1/debian/control2024-04-27 10:14:59.0 +0200
@@ -1,7 +1,7 @@
 Source: rust-laurel
 Section: admin
 Priority: optional
-Build-Depends: debhelper (>= 12),
+Build-Depends: debhelper (>= 13.3),
  dh-cargo (>= 25),
  cargo:native,
  rustc:native (>= 1.56),
@@ -36,7 +36,6 @@
  librust-tinyvec-1+default-dev,
  librust-tinyvec-1+serde-dev,
  librust-toml-0.5+default-dev,
- dh-sysuser,
  pandoc
 Maintainer: Debian Rust Maintainers 

 Uploaders:
diff --minimal -Nru rust-laurel-0.6.1/debian/laurel.sysuser 
rust-laurel-0.6.1/debian/laurel.sysuser
--- rust-laurel-0.6.1/debian/laurel.sysuser 2024-04-03 17:52:57.0 
+0200
+++ rust-laurel-0.6.1/debian/laurel.sysuser 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-_laurel home=/var/log/laurel
diff --minimal -Nru rust-laurel-0.6.1/debian/laurel.sysusers 
rust-laurel-0.6.1/debian/laurel.sysusers
--- rust-laurel-0.6.1/debian/laurel.sysusers1970-01-01 01:00:00.0 
+0100
+++ rust-laurel-0.6.1/debian/laurel.sysusers2024-04-27 10:14:39.0 
+0200
@@ -0,0 +1 @@
+u  _laurel -   "daemon user for laurel"/var/log/laurel 
/usr/sbin/nologin
diff --minimal -Nru rust-laurel-0.6.1/debian/rules 
rust-laurel-0.6.1/debian/rules
--- rust-laurel-0.6.1/debian/rules  2024-04-03 17:52:57.0 +0200
+++ rust-laurel-0.6.1/debian/rules  2024-04-27 10:15:36.0 +0200
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 %:
-   dh $@ --buildsystem cargo --with sysuser
+   dh $@ --buildsystem cargo
 
 override_dh_auto_build:
dh_auto_build
@@ -18,3 +18,7 @@
dh_install
sed -i 's/usr\/local/usr/' debian/laurel/etc/audit/plugins.d/laurel.conf
sed -i 's/^read-users/# read-users/' 
debian/laurel/etc/laurel/config.toml
+
+# Can be dropped in compat 14:
+execute_after_dh_installinit:
+   dh_installsysusers

Bug#1069925: swupdate: move from dh-sysuser to standard dh_installsysusers

[Helmut Grohne]

Source: swupdate
Version: 2023.12.1+dfsg-1
Severity: wishlist
Tags: patch

Hi,

dh-sysuser is in operation for 7 years now and has gotten 9 users -
swupdate being one of them. In that time, it didn't quite mature and
still has a number of deficiencies such as using useradd instead of
policy-recommended adduser or removing users on package removal against
project consensus for keeping users. I think it is time to call
dh-sysuser a failed experiment and move to the standard sysusers.d
mechanism used by many more packages. It has multiple implementations
now such that it does not force systemd onto installations anymore. Do
you agree with my reasoning? I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/changelog 
swupdate-2023.12.1+dfsg/debian/changelog
--- swupdate-2023.12.1+dfsg/debian/changelog2024-02-13 00:12:48.0 
+0100
+++ swupdate-2023.12.1+dfsg/debian/changelog2024-04-27 10:00:05.0 
+0200
@@ -1,3 +1,10 @@
+swupdate (2023.12.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move from dh-sysuser to standard dh_installsysusers (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Apr 2024 10:00:05 +0200
+
 swupdate (2023.12.1+dfsg-1) unstable; urgency=medium
 
   * Enable new options, primarily docker support
diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/control 
swupdate-2023.12.1+dfsg/debian/control
--- swupdate-2023.12.1+dfsg/debian/control  2024-02-13 00:10:23.0 
+0100
+++ swupdate-2023.12.1+dfsg/debian/control  2024-04-27 09:58:25.0 
+0200
@@ -4,10 +4,10 @@
 Maintainer: Bastian Germann 
 Uploaders: SZ Lin (林上智) ,
Nobuhiro Iwamatsu 
-Build-Depends: debhelper-compat (= 13),
-   dh-lua:native ,
+Build-Depends: debhelper (>= 13.3),
+   debhelper-compat (= 13),
+   dh-sequence-lua:native ,
dh-nodejs | dh-nodejs:any,
-   dh-sysuser,
graphviz ,
liblua5.4-dev ,
libfdisk-dev,
diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/rules 
swupdate-2023.12.1+dfsg/debian/rules
--- swupdate-2023.12.1+dfsg/debian/rules2024-02-13 00:10:23.0 
+0100
+++ swupdate-2023.12.1+dfsg/debian/rules2024-04-27 09:59:54.0 
+0200
@@ -13,7 +13,6 @@
 export LUA_VERSION=5.4
 export LUA_MODNAME=lua_swupdate
 export PKG_NAME=swupdate
-export DH_WITH=,lua
 export HAVE_LUA=y
 endif
 
@@ -95,6 +94,10 @@
 override_dh_auto_install:
dh_auto_install -- V=1
 
+# Can be dropped in compat level 14
+execute_after_dh_installinit:
+   dh_installsysusers
+
 override_dh_installsystemd:
dh_installsystemd --no-start
dh_installsystemd --name=swupdate-progress
@@ -110,4 +113,4 @@
dh_missing --fail-missing
 
 %:
-   dh $@ --with sysuser$(DH_WITH)
+   dh $@
diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/swupdate.sysuser 
swupdate-2023.12.1+dfsg/debian/swupdate.sysuser
--- swupdate-2023.12.1+dfsg/debian/swupdate.sysuser 2024-02-13 
00:10:23.0 +0100
+++ swupdate-2023.12.1+dfsg/debian/swupdate.sysuser 1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-swupdate defaults
diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/swupdate.sysusers 
swupdate-2023.12.1+dfsg/debian/swupdate.sysusers
--- swupdate-2023.12.1+dfsg/debian/swupdate.sysusers1970-01-01 
01:00:00.0 +0100
+++ swupdate-2023.12.1+dfsg/debian/swupdate.sysusers2024-04-27 
09:56:56.0 +0200
@@ -0,0 +1 @@
+u  swupdate-   "swupdate system user"  /nonexistent
/usr/sbin/nologin

Bug#1069924: galileo-daemon: switch from dh-sysuser to standard dh_installsysusers

[Helmut Grohne]

Package: galileo-daemon
Version: 0.5.1-9.1
Severity: wishlist
Tags: patch

Hi,

dh-sysusers exists since about 7 years and has gotten 9 users in that
time - galileo-daemon being one of them. It still has a number of
deficiencies such as using useradd instead of policy-recommended adduser
or removing users on package removal against project consensus. I think
it is time to call this a failed experiment and move to the declarative
sysusers.d mechanism used by many more packages which also is available
in multiple implementations now such that it can be used with
non-systemd systems. Do you agree with the reasoning? I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru galileo-0.5.1/debian/changelog 
galileo-0.5.1/debian/changelog
--- galileo-0.5.1/debian/changelog  2022-10-15 12:06:41.0 +0200
+++ galileo-0.5.1/debian/changelog  2024-04-27 09:49:06.0 +0200
@@ -1,3 +1,10 @@
+galileo (0.5.1-9.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from dh-sysuser to standard dh_installsysusers (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Apr 2024 09:49:06 +0200
+
 galileo (0.5.1-9.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru galileo-0.5.1/debian/control galileo-0.5.1/debian/control
--- galileo-0.5.1/debian/control2022-04-09 22:36:10.0 +0200
+++ galileo-0.5.1/debian/control2024-04-27 09:48:23.0 +0200
@@ -3,9 +3,9 @@
 Uploaders: Dylan Aïssi 
 Section: science
 Priority: optional
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: debhelper (>= 13.3),
+   debhelper-compat (= 13),
dh-sequence-python3,
-   dh-sysuser,
python3,
python3-requests,
python3-setuptools,
diff --minimal -Nru galileo-0.5.1/debian/galileo-daemon.sysusers 
galileo-0.5.1/debian/galileo-daemon.sysusers
--- galileo-0.5.1/debian/galileo-daemon.sysusers1970-01-01 
01:00:00.0 +0100
+++ galileo-0.5.1/debian/galileo-daemon.sysusers2024-04-27 
09:49:06.0 +0200
@@ -0,0 +1 @@
+u  galileo -   "system user for galileo-daemon"/nonexistent
/usr/sbin/nologin
diff --minimal -Nru galileo-0.5.1/debian/rules galileo-0.5.1/debian/rules
--- galileo-0.5.1/debian/rules  2022-04-09 22:36:10.0 +0200
+++ galileo-0.5.1/debian/rules  2024-04-27 09:47:11.0 +0200
@@ -5,10 +5,7 @@
 export PYBUILD_DESTDIR_python3=debian/galileo/
 
 %:
-   dh $@ --with sysuser --buildsystem=pybuild
-
-override_dh_sysuser:
-   dh_sysuser -pgalileo-daemon galileo
+   dh $@ --buildsystem=pybuild
 
 override_dh_installudev:
dh_installudev -pgalileo --priority=98
@@ -16,3 +13,5 @@
 
 override_dh_installinit:
dh_installinit --noscripts
+   # Can be dropped in compat >= 14:
+   dh_installsysusers

Bug#1069923: util-linux-extra: /usr-move mitigation fails to cover ctrlaltdel

[Helmut Grohne]

Package: util-linux-extra
Version: 2.40-7
Severity: serious
Tags: patch
Control: affects -1 + util-linux
User: helm...@debian.org
Usertags: dep17p1

Hi Chris,

in my last patch, I trusted your earlier changes too much and failed to
notice that it didn't cover ctrlaltdel. I'm attaching a patch to also
cover that.

Helmut
diff --minimal -Nru util-linux-2.40/debian/changelog 
util-linux-2.40/debian/changelog
--- util-linux-2.40/debian/changelog2024-04-26 11:41:02.0 +0200
+++ util-linux-2.40/debian/changelog2024-04-27 08:46:20.0 +0200
@@ -1,3 +1,10 @@
+util-linux (2.40-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Also cover ctrlaltdel in /usr-move mitigation (Closes: #-1).
+
+ -- Helmut Grohne   Sat, 27 Apr 2024 08:46:20 +0200
+
 util-linux (2.40-7) unstable; urgency=medium
 
   [ Chris Hofstaedtler ]
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.lintian-overrides 
util-linux-2.40/debian/util-linux-extra.lintian-overrides
--- util-linux-2.40/debian/util-linux-extra.lintian-overrides   2024-04-26 
11:41:02.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.lintian-overrides   1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# DEP17 P1 mitigation
-diversion-for-unknown-file sbin/* [preinst:*]
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postrm 
util-linux-2.40/debian/util-linux-extra.postrm
--- util-linux-2.40/debian/util-linux-extra.postrm  2024-04-26 
11:41:02.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.postrm  2024-04-27 
08:46:12.0 +0200
@@ -3,11 +3,9 @@
 set -e
 
 if test "$1" = remove || test "$1" = disappear; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --remove /sbin/mkfs.minix
+  for f in ctrlaltdel fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs.minix; 
do
+dpkg-divert --no-rename --package util-linux-extra --divert 
"/sbin/$f.usr-is-merged" --remove "/sbin/$f"
+  done
 fi
 
 #DEBHELPER#
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.preinst 
util-linux-2.40/debian/util-linux-extra.preinst
--- util-linux-2.40/debian/util-linux-extra.preinst 2024-04-26 
11:41:02.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.preinst 2024-04-27 
08:45:19.0 +0200
@@ -3,11 +3,9 @@
 set -e
 
 if test "$1" = upgrade || test "$1" = install; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --add /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --add /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --add /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --add /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --add /sbin/mkfs.minix
+  for f in ctrlaltdel fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs.minix; 
do
+dpkg-divert --no-rename --package util-linux-extra --divert 
"/sbin/$f.usr-is-merged" --add "/sbin/$f"
+  done
 fi
 
 #DEBHELPER#

Bug#1069922: bcron: stop using dh-sysuser

[Helmut Grohne]

Package: bcron
Version: 0.11-21
Severity: wishlist
Tags: patch

Hi,

please stop using dh-sysuser. dh-sysuser is in operation since 7 years
and has only gotten 9 reverse dependencies in that time. The vast
majority of packages use the /usr/lib/sysusers.d mechanism supported by
debhelper. dh-sysuser has a number of deficiencies such as using using
useradd instead of policy-recommended adduser, removing users on purge
when project consensus is that users should not be removed. With the
availability of multiple implementations of the sysusers.d format even
for non-linux systems, I think it is time to settle on that standard and
call dh-sysuser failed. I'm attaching a patch for your convenience. Do
you agree with the reasoning?

Helmut
diff --minimal -Nru bcron-0.11/debian/bcron.postinst 
bcron-0.11/debian/bcron.postinst
--- bcron-0.11/debian/bcron.postinst2023-06-27 14:57:38.0 +0200
+++ bcron-0.11/debian/bcron.postinst2024-04-27 09:10:46.0 +0200
@@ -7,11 +7,10 @@
 
 CRONTABDIR=/var/spool/cron/crontabs
 
+#DEBHELPER#
+
 case "$1" in
 configure)
-   # create user cron now when it doe not exist
-   # this may bypass bcron.sysuser
-   getent passwd cron || adduser --system --group --home /var/spool/cron 
cron
# add acls for user and group cron
setfacl -m u:cron:rwx $CRONTABDIR
setfacl -m g:cron:rwx $CRONTABDIR
@@ -30,6 +29,4 @@
 ;;
 esac
 
-#DEBHELPER#
-
 exit 0
diff --minimal -Nru bcron-0.11/debian/bcron.sysuser 
bcron-0.11/debian/bcron.sysuser
--- bcron-0.11/debian/bcron.sysuser 2023-06-27 14:57:38.0 +0200
+++ bcron-0.11/debian/bcron.sysuser 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-cron home=/var/spool/cron
diff --minimal -Nru bcron-0.11/debian/bcron.sysusers 
bcron-0.11/debian/bcron.sysusers
--- bcron-0.11/debian/bcron.sysusers1970-01-01 01:00:00.0 +0100
+++ bcron-0.11/debian/bcron.sysusers2024-04-27 09:08:59.0 +0200
@@ -0,0 +1 @@
+u  cron-   "Cron daemon user"  /var/spool/cron
diff --minimal -Nru bcron-0.11/debian/changelog bcron-0.11/debian/changelog
--- bcron-0.11/debian/changelog 2023-07-17 16:20:52.0 +0200
+++ bcron-0.11/debian/changelog 2024-04-27 09:10:54.0 +0200
@@ -1,3 +1,10 @@
+bcron (0.11-21.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move from dh-sysuser to standard dh_installsysuser. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Apr 2024 09:10:54 +0200
+
 bcron (0.11-21) unstable; urgency=medium
 
   * implemented as much as I could understand from Michael Biebl's and
diff --minimal -Nru bcron-0.11/debian/control bcron-0.11/debian/control
--- bcron-0.11/debian/control   2023-06-27 16:24:17.0 +0200
+++ bcron-0.11/debian/control   2024-04-27 09:10:54.0 +0200
@@ -3,10 +3,10 @@
 Priority: optional
 Maintainer: Georges Khaznadar 
 Build-Depends:
+ debhelper (>= 13.3),
  debhelper-compat (= 13),
  dh-buildinfo (>= 0.11+nmu1),
  dh-runit (>= 2.8.1~),
- dh-sysuser (>= 1.3),
  dpkg-dev (>= 1.18.11),
  groff,
  libbg-dev (>= 2),
@@ -27,7 +27,6 @@
  ${misc:Depends},
  ${shlibs:Depends},
  daemon,
- adduser
 Recommends:
  default-mta | mail-transport-agent,
  runit
diff --minimal -Nru bcron-0.11/debian/rules bcron-0.11/debian/rules
--- bcron-0.11/debian/rules 2023-06-27 16:42:02.0 +0200
+++ bcron-0.11/debian/rules 2024-04-27 09:10:54.0 +0200
@@ -12,7 +12,7 @@
 endef
 
 %:
-   dh $@ --with runit,buildinfo,sysuser
+   dh $@ --with runit,buildinfo
 
 override_dh_auto_build:
rm -f bcron.info
@@ -33,6 +33,10 @@
$(call initscript,bcron-sched)
$(call initscript,bcron-spool)
 
+# Drop override when bumping to compat 14 or later.
+execute_after_dh_installinit:
+   dh_installsysusers
+
 override_dh_installchangelogs:
dh_installchangelogs NEWS
 

Bug#1069921: libusb-java FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: libusb-java
Version: 0.8+ztex20090101-9
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libusb-java fails to cross build from source, because the upstream
Makefile uses a non-standard variable (GCC) for the C compiler and
because debian/rules does not pass cross tools to make. I propose
renaming the variable to the usual CC variable and using dh_auto_build.
Please find a patch attached.

Helmut
diff --minimal -Nru libusb-java-0.8+ztex20090101/debian/changelog 
libusb-java-0.8+ztex20090101/debian/changelog
--- libusb-java-0.8+ztex20090101/debian/changelog   2021-02-07 
23:29:30.0 +0100
+++ libusb-java-0.8+ztex20090101/debian/changelog   2024-04-26 
11:25:31.0 +0200
@@ -1,3 +1,10 @@
+libusb-java (0.8+ztex20090101-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use cross tools for build. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 26 Apr 2024 11:25:31 +0200
+
 libusb-java (0.8+ztex20090101-9) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libusb-java-0.8+ztex20090101/debian/patches/cross.patch 
libusb-java-0.8+ztex20090101/debian/patches/cross.patch
--- libusb-java-0.8+ztex20090101/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ libusb-java-0.8+ztex20090101/debian/patches/cross.patch 2024-04-26 
11:25:31.0 +0200
@@ -0,0 +1,50 @@
+--- libusb-java-0.8+ztex20090101.orig/Makefile
 libusb-java-0.8+ztex20090101/Makefile
+@@ -21,7 +21,7 @@
+ ###
+ # this should not be modified #
+ ###
+-GCC=gcc
++CC?=gcc
+ STRIP=strip
+ CHMOD=chmod -x
+ JAVAC=javac -source 7 -target 7 -encoding ISO-8859-1
+@@ -51,7 +51,7 @@
+ libs: $(LIBTARGET_SH)
+ 
+ %.o: %.c LibusbJava.h
+-  $(GCC) -fPIC -g -c -std=c99 -Wall -Wno-pointer-to-int-cast $(LIBINCS) 
$< -o$@
++  $(CC) -fPIC -g -c -std=c99 -Wall -Wno-pointer-to-int-cast $(LIBINCS) $< 
-o$@
+ 
+ $(LIBTARGET_ST): $(LIBSRCS)
+ 
+@@ -64,25 +64,25 @@
+ 
+ 
+ $(LIBTARGET_ST)$(VERSIONSUFFIX): $(LIBSRCS)
+-  $(GCC) -shared -Wl,-soname,$(LIBTARGET_ST),-static $(LIBINCS) 
$(LIBSRCS) -static -o $(LIBTARGET_ST)$(VERSIONSUFFIX) $(LIBLIBS)
++  $(CC) -shared -Wl,-soname,$(LIBTARGET_ST),-static $(LIBINCS) $(LIBSRCS) 
-static -o $(LIBTARGET_ST)$(VERSIONSUFFIX) $(LIBLIBS)
+   [ -r $(LIBTARGET_ST) ] || ln -s $(LIBTARGET_ST)$(VERSIONSUFFIX) 
$(LIBTARGET_ST)
+   $(STRIP) $(LIBTARGET_ST)
+   $(CHMOD) $(LIBTARGET_ST)
+ 
+ $(LIBTARGET_SH)$(VERSIONSUFFIX): $(LIBSRCS)
+-  $(GCC) -fPIC -shared -Wl,-soname,$(LIBTARGET_SH) $(LIBINCS) $(LIBSRCS) 
-o $(LIBTARGET_SH)$(VERSIONSUFFIX) $(LIBLIBS)
++  $(CC) -fPIC -shared -Wl,-soname,$(LIBTARGET_SH) $(LIBINCS) $(LIBSRCS) 
-o $(LIBTARGET_SH)$(VERSIONSUFFIX) $(LIBLIBS)
+   [ -r $(LIBTARGET_SH) ] || ln -s $(LIBTARGET_SH)$(VERSIONSUFFIX) 
$(LIBTARGET_SH)
+   $(STRIP) $(LIBTARGET_SH)
+   $(CHMOD) $(LIBTARGET_SH)
+ 
+ $(LIBTARGET)$(VERSIONSUFFIX): $(LIBSRCS)
+-  $(GCC) -fPIC -shared -Wl,-soname,$(LIBTARGET) $(LIBINCS) $(LIBSRCS) -o 
$(LIBTARGET)$(VERSIONSUFFIX) $(LIBLIBS)
++  $(CC) -fPIC -shared -Wl,-soname,$(LIBTARGET) $(LIBINCS) $(LIBSRCS) -o 
$(LIBTARGET)$(VERSIONSUFFIX) $(LIBLIBS)
+   [ -r $(LIBTARGET) ] || ln -s $(LIBTARGET)$(VERSIONSUFFIX) $(LIBTARGET)
+   $(STRIP) $(LIBTARGET)
+   $(CHMOD) $(LIBTARGET)
+ 
+ $(LIBTARGET_64)$(VERSIONSUFFIX): $(LIBSRCS64)
+-  $(GCC) -fPIC -m64 -shared -std=c99 -Wall -Wno-pointer-to-int-cast 
-Wl,-soname,$(LIBTARGET_64) $(LIBINCS) $(LIBSRCS64) $(LIBLIBS) -o 
$(LIBTARGET_64)$(VERSIONSUFFIX)
++  $(CC) -fPIC -m64 -shared -std=c99 -Wall -Wno-pointer-to-int-cast 
-Wl,-soname,$(LIBTARGET_64) $(LIBINCS) $(LIBSRCS64) $(LIBLIBS) -o 
$(LIBTARGET_64)$(VERSIONSUFFIX)
+   [ -r $(LIBTARGET_64) ] || ln -s $(LIBTARGET_64)$(VERSIONSUFFIX) 
$(LIBTARGET_64)
+   $(STRIP) $(LIBTARGET_64)
+   $(CHMOD) $(LIBTARGET_64)
diff --minimal -Nru libusb-java-0.8+ztex20090101/debian/patches/series 
libusb-java-0.8+ztex20090101/debian/patches/series
--- libusb-java-0.8+ztex20090101/debian/patches/series  2020-09-05 
14:43:49.0 +0200
+++ libusb-java-0.8+ztex20090101/debian/patches/series  2024-04-26 
11:25:31.0 +0200
@@ -1,3 +1,4 @@
 jniInclude.patch
 sharedLibraries.patch
 java-compat.patch
+cross.patch
diff --minimal -Nru libusb-java-0.8+ztex20090101/debian/rules 
libusb-java-0.8+ztex20090101/debian/rules
--- libusb-java-0.8+ztex20090101/debian/rules   2021-02-07 23:27:55.0 
+0100
+++ libusb-java-0.8+ztex20090101/debian/rules   2024-04-26 11:25:27.0 
+0200
@@ -15,7 +15,7 @@
 
 DOCPATH=doc/html
 override_dh_auto_build-arch:
-   $(MAKE) STRIP="# not stripping: " libs
+   dh_auto_build -- STRIP="# not stripping: " libs
touch build-arch-stamp
 
 override_dh_auto_build-indep:

Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move

[Helmut Grohne]

Control: tags -1 + patch

Hi Chris,

On Tue, Apr 16, 2024 at 09:44:13AM +0200, Chris Hofstaedtler wrote:
> I think half of 2) exists now, but Conflicts: util-linux will
> probably end badly as you note. I'd welcome a patch implementing 3).
> 
> Initially I favored 1), but then u-l will never make progress on
> moving the non-essential files.

Thanks for pinging me. I observe that util-linux-extra already had
mitigations except that preinst and postinst were swapped. Additionally,
it did not have Conflicts, which allow for unpacking an aliased
util-linux concurrently with a moved util-linux-extra despite the
protective diversions being removed. Since we want to avoid the
Conflicts, I've extended the protective diversions until postrm. In
trixie's postinst we can then remove them for good. Unfortunately, that
also means that we cannot use begin-remove-after magic.

Helmut
diff --minimal -Nru util-linux-2.40/debian/changelog 
util-linux-2.40/debian/changelog
--- util-linux-2.40/debian/changelog2024-04-15 09:51:01.0 +0200
+++ util-linux-2.40/debian/changelog2024-04-26 07:32:56.0 +0200
@@ -1,3 +1,10 @@
+util-linux (2.40-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix /usr-move mitigation. (Closes: #1069064)
+
+ -- Helmut Grohne   Fri, 26 Apr 2024 07:32:56 +0200
+
 util-linux (2.40-6) unstable; urgency=medium
 
   * Add upstream patches fixing enosys on m68k, sh and dmesg -H output
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.lintian-overrides 
util-linux-2.40/debian/util-linux-extra.lintian-overrides
--- util-linux-2.40/debian/util-linux-extra.lintian-overrides   1970-01-01 
01:00:00.0 +0100
+++ util-linux-2.40/debian/util-linux-extra.lintian-overrides   2024-04-26 
07:32:56.0 +0200
@@ -0,0 +1,2 @@
+# DEP17 P1 mitigation
+diversion-for-unknown-file sbin/* [preinst:*]
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postinst 
util-linux-2.40/debian/util-linux-extra.postinst
--- util-linux-2.40/debian/util-linux-extra.postinst2024-04-15 
09:51:01.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.postinst1970-01-01 
01:00:00.0 +0100
@@ -1,15 +0,0 @@
-#!/bin/sh
-
-set -e
-
-# begin-remove-after: released:trixie
-if test "$1" = upgrade || test "$1" = install; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --add /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --add /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --add /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --add /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --add /sbin/mkfs.minix
-fi
-# end-remove-after
-
-#DEBHELPER#
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postrm 
util-linux-2.40/debian/util-linux-extra.postrm
--- util-linux-2.40/debian/util-linux-extra.postrm  1970-01-01 
01:00:00.0 +0100
+++ util-linux-2.40/debian/util-linux-extra.postrm  2024-04-26 
07:32:56.0 +0200
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+if test "$1" = remove || test "$1" = disappear; then
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --remove /sbin/mkfs.minix
+fi
+
+#DEBHELPER#
+
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.preinst 
util-linux-2.40/debian/util-linux-extra.preinst
--- util-linux-2.40/debian/util-linux-extra.preinst 2024-04-15 
09:51:01.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.preinst 2024-04-26 
07:32:56.0 +0200
@@ -2,15 +2,12 @@
 
 set -e
 
-# begin-remove-after: released:trixie
-if test "$1" = configure; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is

Bug#1069848: vonsh FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: vonsh
Version: 1.0+ds-0.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vonsh fails to cross build from source, because it strips with the build
architecture strip. Once I looked into the package, I encountered more
issues. It does not generate a -dbgsym package. It does not honour
DEB_BUILD_OPTIONS=nostrip. It does not honour dpkg-buildflags and thus
uses 32bit time still. The attached patch fixes all of this.

Is this really a package worth keeping in Debian? No maintainer upload
in 5 years, 2 NMUs. Consider RoQA.

Helmut
--- vonsh-1.0+ds/debian/changelog
+++ vonsh-1.0+ds/debian/changelog
@@ -1,3 +1,12 @@
+vonsh (1.0+ds-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make CFLAGS, LDFLAGS and strip configurable.
++ Force a non-stripping strip
+
+ -- Helmut Grohne   Thu, 25 Apr 2024 16:40:11 +0200
+
 vonsh (1.0+ds-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
--- vonsh-1.0+ds/debian/patches/cross.patch
+++ vonsh-1.0+ds/debian/patches/cross.patch
@@ -0,0 +1,22 @@
+--- vonsh-1.0+ds.orig/Makefile
 vonsh-1.0+ds/Makefile
+@@ -9,14 +9,16 @@
+ SRC = $(wildcard $(SRC_DIR)/*.c)
+ OBJ = $(SRC:$(SRC_DIR)/%.c=$(OBJ_DIR)/%.o)
+ EXE = $(EXE_DIR)/vonsh
+-CFLAGS = -I$(INC_DIR) -DVERSION_STR=\"$(VERSION_STR)\" -Wall -Wformat 
-Werror=format-security
+-LDFLAGS = -Wl,-z,relro,-z,now
++STRIP ?= strip
++CFLAGS ?= -Wall -Wformat -Werror=format-security
++CFLAGS += -I$(INC_DIR) -DVERSION_STR=\"$(VERSION_STR)\"
++LDFLAGS ?= -Wl,-z,relro,-z,now
+ LDLIBS = -lSDL2 -lSDL2main -lSDL2_image -lSDL2_mixer
+ .PHONY: all clean install
+ all: release
+ release: CFLAGS += -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong
+ release: $(EXE)
+-  strip --strip-all $^
++  $(STRIP) --strip-all $^
+ debug: CFLAGS += -g
+ debug: $(EXE)
+ $(EXE): $(OBJ)
--- vonsh-1.0+ds/debian/patches/series
+++ vonsh-1.0+ds/debian/patches/series
@@ -0,0 +1 @@
+cross.patch
--- vonsh-1.0+ds/debian/rules
+++ vonsh-1.0+ds/debian/rules
@@ -3,6 +3,8 @@
 #export DH_VERBOSE=1
 include /usr/share/dpkg/pkg-info.mk
 export VERSION_STR=$(DEB_VERSION)
+# Do not strip.
+export STRIP=true
 
 %:
dh $@

Bug#1069847: rolo FTCBFS: multiple issues

[Helmut Grohne]

Source: rolo
Version: 019-4.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rolo fails to cross build from source for two distinct reasons.

For one thing, configure.ac hard codes the build architecture
pkg-config. It is recommended to use the PKG_CHECK_MODULES macro which
automatically gets this right.

For another, tests/Makefile.am runs tests during the all target which is
usually run during build. Hence tests fail despite passing
DEB_BUILD_OPTIONS=nocheck. Moving tests to the check target causes tests
to not be run during all, but still be run in a debian package build as
dh_auto_test runs make check (unless DEB_BUILD_OPTIONS contains
nocheck).

I'm attaching a patch for your convenience.

Helmut
--- rolo-019.orig/configure.ac
+++ rolo-019/configure.ac
@@ -19,12 +19,13 @@
 CFLAGS="$CFLAGS -I/usr/include/ncursesw/"
 
 # Glib settings
-LIBS="$LIBS $(pkg-config glib-2.0 --libs)"
-CFLAGS="$CFLAGS $(pkg-config glib-2.0 --cflags)"
+PKG_CHECK_MODULES([GLIB],[glib-2.0])
 
 # Libunac settings
-LIBS="$LIBS $(pkg-config unac --libs)"
-CFLAGS="$CFLAGS $(pkg-config unac --cflags)"
+PKG_CHECK_MODULES([UNAC],[unac])
+
+LIBS="$LIBS $GLIB_LIBS $UNAC_LIBS"
+CFLAGS="$CFLAGS $GLIB_CFLAGS $UNAC_CFLAGS"
 
 # Checks for header files.
 AC_CHECK_INCLUDES_DEFAULT
--- rolo-019.orig/test/Makefile.am
+++ rolo-019/test/Makefile.am
@@ -1,4 +1,4 @@
-all:
+check:
 	@if [ "$(HAS_SHUNIT2)" = yes ] ; then	\
 	./run-tests ; 			\
 	else	\

Bug#1069815: wesnoth-1.8-server: new package installs systemd unit in aliased location

[Helmut Grohne]

Package: wesnoth-1.18-server
Version: 1:1.17.26-1
Severity: serious
Justification: do not introduce aliased files into Debian

Hi,

I noticed that wesnoth-1.18-server is a new package and installs a file
below /lib, which is an aliased location that we try to empty to
complete the /usr-move transition via DEP17. I am filing this bug at
RC-severity to stop it from migrating to trixie and hope you agree with
this. Please downgrade if you disagree though note that this kind of
issue will become an RC-bug for all packages later in the trixie cycle.

The simplest fix to this problem is changing

SYSTEMD_SERVICE = 
debian/wesnoth-$(BRANCH_VERSION)-server/lib/systemd/system/wesnoth-$(BRANCH_VERSION)-server.service

in debian/rules and move the file to /usr/lib. This is mostly safe for
backports, except that bookworm's debhelper will fail to generate
necessary maintainer scripts. Please bump your debhelper dependency to
13.11.6 (available in bookworm-backports).

Alternatively, adding dh-sequence-movetousr to Build-Depends should also
resolve the matter, but for a new package I'd prefer to fix this right
from the start.

Both solutions are likely applicable to other wesnoth versions as well,
though we don't consider those RC-bugs yet.

Helmut

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Helmut Grohne]

Hi Matthias,

On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> This is the same situation as in #1040477. This is an issue wrt how we
> generate the semvers. I image rust-proc-macro-crate-1 would pose the same
> problem. Quoting you from 1040477:

Right!

> Is the only workaround dropping Ma:same here ?

I see very little alternatives. We must choose:

 * Do not combine M-A:same + Provides: foo + Breaks: foo.
 * Fix dose/apt/dpkg to agree on what this means.

If we were to adapt dose and apt, they's simply arrive at the conclusion
that M-A:same would not work here so that really is not what you'd want
here. This amounts to fixing dpkg to allow this very combination in the
same way that apt and dose allow it. So yeah, changing dpkg could be an
option. Ccing dpkg-devel about it.

The first alternative means that we must not combine them at the same
time. As we very much want M-A:same, we must not have this combination
of Provides and Brekas. Keep in mind that they serve slightly different
purposes. We have Breaks + Replaces and you can only replace a real
package but Provides introduce a virtual package. In effect we're
dealing with a package that sometimes is virtual and other times is
real. We can choose different names for these uses. The real package
could be renamed and also provide the virtual facility. All of them
would now provide the virtual one as virtual only and none of them would
have the virtual name. The Breaks and Replaces would be updated to match
the real name.

This may not work for the in-archive situations right now as Breaks and
Replaces may still be necessary for upgrades, but it is something that
may work in future situations of the same kind.

In the mean time, consider that M-A:same presently is a lie. Removing it
is better than continuing to lie. It's not like we must have everything
in perfect multiarch. Even for cross compilation, we often can get away
without M-A:same by only requiring a package for the host architecture.
M-A:same is not the goal. It's a tool and way may consider using other
tools.

Helmut

Bug#956080: closed by Debian FTP Masters (reply to Andreas Rönnquist ) (Bug#956080: fixed in gamazons 0.83-12)

[Helmut Grohne]

Control: reopen -1
Control: retitle -1 gamazons contains a broken, outdated, embeded copy of 
PKG_CHECK_MODULES

On Sun, Apr 21, 2024 at 03:51:10PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:gamazons package:
> 
> #956080: gamazons FTCBFS: multiple reasons
> 
> It has been closed by Debian FTP Masters  
> (reply to Andreas Rönnquist ).

Half of the problem is fixed.

> gamazons fails to cross build from source. The immediate failure happens
> during dh_auto_clean. It invokes make distclean. The makefile figures
> that its config.status is outdated and that it needs to configure again.
> It does so for the build architecture, misses dependencies (which are
> only requested for the host architecture) and fails. A simple way around
> this is touching config.status before invoking make distclean. The
> attached patch implements that.

This is fixed.

> Then, ./configure uses the build architecture pkg-config. This is a bug
> in the PKG_CHECK_MODULES macro. The file aclocal.m4 ships a broken,
> outdated, embedded copy this macro. The upstream macro as shipped by
> pkg-config is fixed. Please remove this copy to use the fixed upstream
> version. Failing that, please update your embedded copy and register it
> with the security tracker. Please refer to
> https://wiki.debian.org/EmbeddedCodeCopies for details on the process.
> Please remember that since ./configure is not regenerated during a
> package build, you must do so manually before your upload in both cases.
> I'm not including a patch for this second issue, because it is already
> fixed in pkg-config itself.

This is unfixed.

Helmut

Bug#1069689: mandos lost mandos.service systemd unit

[Helmut Grohne]

Source: mandos
Version: 1.8.16-1.1
Severity: serious
Tags: patch
Justification: prevent testing migration after unintentional deletion of 
systemd unit
X-Debbugs-Cc: Bastian Germann 
User: helm...@debian.org
Usertags: dep17p6

The last mandos upload is the first after systemd.pc having moved
systemdsystemunitdir from /lib to /usr/lib. mandos' upstream Makefile
uses this to see where to install units to, but it also only does that
if the relevant directory exists. Now since the new location wasn't
created, it ceased installing the unit. We need to create the new
location to reinstate the unit. Patch attached. I think the loss of the
unit is unintantional and for that reason file this as rc bug. Please
adjust if you disagree.

This change makes mandos backports-unsafe. I don't expect mandos to be
backported.

Helmut
diff --minimal -Nru mandos-1.8.16/debian/changelog 
mandos-1.8.16/debian/changelog
--- mandos-1.8.16/debian/changelog  2024-04-19 13:08:30.0 +0200
+++ mandos-1.8.16/debian/changelog  2024-04-22 21:13:43.0 +0200
@@ -1,3 +1,10 @@
+mandos (1.8.16-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install mandos.service again. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 22 Apr 2024 21:13:43 +0200
+
 mandos (1.8.16-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru mandos-1.8.16/debian/mandos.dirs 
mandos-1.8.16/debian/mandos.dirs
--- mandos-1.8.16/debian/mandos.dirs2019-08-18 21:51:02.0 +0200
+++ mandos-1.8.16/debian/mandos.dirs2024-04-22 21:13:43.0 +0200
@@ -5,6 +5,6 @@
 etc/dbus-1/system.d
 usr/sbin
 var/lib/mandos
-lib/systemd/system
 usr/lib/tmpfiles.d
 usr/lib/sysusers.d
+usr/lib/systemd/system

Bug#1069688: libsequoia-octopus-librnp has an undeclared file conflict on /usr/lib/thunderbird/librnp.so

[Helmut Grohne]

Package: libsequoia-octopus-librnp
Version: 1.8.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + thunderbird

libsequoia-octopus-librnp has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/thunderbird/librnp.so is contained in the packages
 * libsequoia-octopus-librnp/1.8.1-3 as present in unstable
 * thunderbird/1:122.0~b2-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Helmut Grohne]

Package: librust-bitflags-1-dev
Version: 1.3.2-5+b1
Severity: serious
Justification: causes an installation failure

Hi,

Attempting to install librust-bitflags-1-dev for multiple architectures
fails, because apt and dpkg disagree about how breaks and provides work.
apt thinks that self-breaks can be ignored, but dpkg thinks that since
librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it
cannot be coinstalled and gives up. You cannot combine such
breaks+provides with m-a:same. The simplest workaround here is dropping
m-a:same as it cannot be exercised anyway.

Helmut

Bug#1064459: refining DEP17 patches for glibc and base-files

[Helmut Grohne]

Hi Santiago,

On Fri, Apr 19, 2024 at 07:24:15PM +0200, Santiago Vila wrote:
> I've added two commits, one to create symlinks with a "shell" for, and the 
> last
> one for a sample changelog (because this is really a "team upload" or a 
> "guest upload"
> more than a NMU). I think for simplicity it's ok if you skip the changelog 
> part
> in your repo.

I've updated my demo repository with your patch.

https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo/-/commit/6425c8cde53596199cd37bb1625d1dfb2a4b74d0

I'm happy to call it guest upload while I find team upload slightly
misleading.

I avoid patching changelogs in the demo to avoid the need for
unnecessary rebasing. It's a functional demo.

For util-linux, I think Chris will send me an encrypted version of a
signed .changes file such that I only perform the upload not even the
signing. Please let me know if you prefer that approach.

Helmut

Bug#1069630: libcupsfilters-dev and libcupsfilters2-dev have an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libcupsfilters.a, /usr/lib/x86_64-linux-gnu/libcupsfilters.so and /usr/lib/x86_64-

[Helmut Grohne]

Package: libcupsfilters2-dev
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libcupsfilters-dev

The files
 * /usr/lib/x86_64-linux-gnu/libcupsfilters.a
 * /usr/lib/x86_64-linux-gnu/libcupsfilters.so
 * /usr/lib/x86_64-linux-gnu/pkgconfig/libcupsfilters.pc
are contained in the packages
 * libcupsfilters-dev/1.28.17-4 as present in unstable
 * libcupsfilters2-dev/2.0.0-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Please figure out which of these packages should properly own the
affected files and reassign the bug as appropriate. When doing so,
please add the other package to the set of affected packages using
"Control: affects -1 + " to avoid the filing of duplicates.

The other package should stop installing the files. In case the files
are being moved between packages, Breaks and Replaces should be
declared. In this case, please refer to policy section 7.6 for details.
Another useful resource is https://wiki.debian.org/PackageTransition.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1069578: mir FTCBFS: runs host arch code

[Helmut Grohne]

Source: mir
Version: 2.14.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mir fails to cross build from source as it fails running the built
mir_wayland_generator. This is a typical problem for cmake based
projects as cmake has very little idea of what a build architecture is
or what a native executable is. mir_wayland_generator happens to be
installed into libmirwayland-bin and that's what should be used during a
cross build. I'm attaching a patch implementing this and it is
conditional to the cross build profile in order to not affect native
builds. While at it, I noticed that the noinsttest build profile FTBFS
and I think mir-wlcs-integration should also be disabled by that
profile. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru mir-2.14.1/debian/changelog mir-2.14.1/debian/changelog
--- mir-2.14.1/debian/changelog 2024-03-23 07:29:01.0 +0100
+++ mir-2.14.1/debian/changelog 2024-04-19 11:04:42.0 +0200
@@ -1,3 +1,12 @@
+mir (2.14.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Use packages mir_wayland_generator during cross
+builds. (Closes: #-1)
+  * Fix noinsttest build profile: skip package mir-wlcs-integration.
+
+ -- Helmut Grohne   Fri, 19 Apr 2024 11:04:42 +0200
+
 mir (2.14.1-5) unstable; urgency=medium
 
   [ Matthias Klose ]
diff --minimal -Nru mir-2.14.1/debian/control mir-2.14.1/debian/control
--- mir-2.14.1/debian/control   2024-02-28 21:03:56.0 +0100
+++ mir-2.14.1/debian/control   2024-04-19 11:04:42.0 +0200
@@ -27,6 +27,7 @@
libglm-dev,
libgoogle-glog-dev,
liblttng-ust-dev,
+   libmirwayland-bin ,
libxkbcommon-dev (>= 0.5),
libumockdev-dev (>= 0.6) ,
umockdev (>= 0.8.7) ,
@@ -238,6 +239,7 @@
 
 Package: mir-wlcs-integration
 Architecture: linux-any
+Build-Profiles: 
 Pre-Depends: ${misc:Pre-Depends}
 Breaks: mir-test-tools (<< 2.0.0.0+dev148~)
 Replaces: mir-test-tools (<< 2.0.0.0+dev148~)
diff --minimal -Nru mir-2.14.1/debian/patches/cross.patch 
mir-2.14.1/debian/patches/cross.patch
--- mir-2.14.1/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ mir-2.14.1/debian/patches/cross.patch   2024-04-19 11:04:42.0 
+0200
@@ -0,0 +1,43 @@
+--- mir-2.14.1.orig/cmake/MirCommon.cmake
 mir-2.14.1/cmake/MirCommon.cmake
+@@ -310,6 +310,14 @@
+   add_dependencies(${DEPENDENT_TARGET} ${TARGET_NAME})
+ endfunction()
+ 
++set(
++  MIR_WAYLAND_GENERATOR_EXECUTABLE
++  "${CMAKE_BINARY_DIR}/bin/mir_wayland_generator"
++  CACHE
++  STRING
++  "Location of an externally supplied mir_wayland_generator executable"
++)
++
+ function (mir_generate_protocol_wrapper TARGET_NAME NAME_PREFIX PROTOCOL_FILE)
+   if (NAME_PREFIX STREQUAL "")
+ set(NAME_PREFIX "@") # won't match anything
+@@ -322,9 +330,9 @@
+ OUTPUT "${OUTPUT_PATH_HEADER}" "${OUTPUT_PATH_SRC}"
+ VERBATIM
+ COMMAND "sh" "-c"
+-"${CMAKE_BINARY_DIR}/bin/mir_wayland_generator ${NAME_PREFIX} 
${PROTOCOL_PATH} header > ${OUTPUT_PATH_HEADER}"
++"${MIR_WAYLAND_GENERATOR_EXECUTABLE} ${NAME_PREFIX} ${PROTOCOL_PATH} 
header > ${OUTPUT_PATH_HEADER}"
+ COMMAND "sh" "-c"
+-"${CMAKE_BINARY_DIR}/bin/mir_wayland_generator ${NAME_PREFIX} 
${PROTOCOL_PATH} source > ${OUTPUT_PATH_SRC}"
++"${MIR_WAYLAND_GENERATOR_EXECUTABLE} ${NAME_PREFIX} ${PROTOCOL_PATH} 
source > ${OUTPUT_PATH_SRC}"
+ DEPENDS mir_wayland_generator "${PROTOCOL_PATH}"
+   )
+   target_sources("${TARGET_NAME}" PRIVATE "${OUTPUT_PATH_HEADER}" 
"${OUTPUT_PATH_SRC}")
+--- mir-2.14.1.orig/tests/acceptance-tests/wayland-generator/CMakeLists.txt
 mir-2.14.1/tests/acceptance-tests/wayland-generator/CMakeLists.txt
+@@ -5,9 +5,9 @@
+   OUTPUT "${GENERATED_HEADER}" "${GENERATED_SRC}"
+   VERBATIM
+   COMMAND "sh" "-c"
+-  "${CMAKE_BINARY_DIR}/bin/mir_wayland_generator wl_ ${PROTOCOL_PATH} header 
> ${GENERATED_HEADER}"
++  "${MIR_WAYLAND_GENERATOR_EXECUTABLE} wl_ ${PROTOCOL_PATH} header > 
${GENERATED_HEADER}"
+   COMMAND "sh" "-c"
+-  "${CMAKE_BINARY_DIR}/bin/mir_wayland_generator wl_ ${PROTOCOL_PATH} source 
> ${GENERATED_SRC}"
++  "${MIR_WAYLAND_GENERATOR_EXECUTABLE} wl_ ${PROTOCOL_PATH} source > 
${GENERATED_SRC}"
+   DEPENDS mir_wayland_generator "${PROTOCOL_PATH}"
+ )
+ add_custom_target(wayland_generator_test_generated_files ALL DEPENDS 
"${GENERATED_SRC}" "${GENERATED_HEADER}")
diff --minimal -Nru mir-2.14.1/debian/patches/series 
mir-2.14.1/debian/patches/series
--- mir-2.14.1/debian/patches/series2024-03-23 07:29:01.0 +0100
+++ mir

Bug#1069572: firmware-nonfree: activate update-initramfs trigger declaratively

[Helmut Grohne]

Source: firmware-nonfree
Version: 20230625-2
Severity: wishlist
Tags: patch

This is the same bug as #1069571 (firmware-linux-free). The
update-initramfs trigger is activated procedurally and in postinst only.
Hence, removing a firmware package does not update the initramfs. I
propose activating the trigger declaratively to have dpkg figure out
when to activate.

Helmut
diff -Nru firmware-nonfree-20230625/debian/changelog 
firmware-nonfree-20230625/debian/changelog
--- firmware-nonfree-20230625/debian/changelog  2023-12-19 18:01:10.0 
+0100
+++ firmware-nonfree-20230625/debian/changelog  2024-04-20 18:11:28.0 
+0200
@@ -1,3 +1,10 @@
+firmware-nonfree (20230625-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Activate update-initramfs trigger declaratively. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 20 Apr 2024 18:11:28 +0200
+
 firmware-nonfree (20230625-2) unstable; urgency=medium
 
   [ Diederik de Haas ]
diff -Nru firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 
firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst
--- firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 
2023-12-19 18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 
1970-01-01 01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 
firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers
--- firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 
1970-01-01 01:00:00.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 
2024-04-20 18:11:28.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2.postinst 
firmware-nonfree-20230625/debian/firmware-bnx2.postinst
--- firmware-nonfree-20230625/debian/firmware-bnx2.postinst 2023-12-19 
18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2.postinst 1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2.triggers 
firmware-nonfree-20230625/debian/firmware-bnx2.triggers
--- firmware-nonfree-20230625/debian/firmware-bnx2.triggers 1970-01-01 
01:00:00.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2.triggers 2024-04-20 
18:11:28.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2x.postinst 
firmware-nonfree-20230625/debian/firmware-bnx2x.postinst
--- firmware-nonfree-20230625/debian/firmware-bnx2x.postinst2023-12-19 
18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2x.postinst1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2x.triggers 
firmware-nonfree-20230625/debian/firmware-bnx2x.triggers
--- firmware-nonfree-20230625/debian/firmware-bnx2x.triggers1970-01-01 
01:00:00.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2x.triggers2024-04-20 
18:11:28.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru firmware-nonfree-20230625/debian/firmware-cavium.postinst 
firmware-nonfree-20230625/debian/firmware-cavium.postinst
--- firmware-nonfree-20230625/debian/firmware-cavium.postinst   2023-12-19 
18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-cavium.postinst   1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmw

Bug#1069571: firmware-linux-free: activate update-initramfs trigger declaratively

[Helmut Grohne]

Package: firmware-linux-free
Version: 20200122-4
Severity: wishlist
Tags: patch

Removing firmware-linux-free does not activate the update-initramfs
trigger. This is due to being done procedurally in postinst without
matching postrm. I propose using declarative activation let dpkg figure
out when to activate the trigger.

Helmut
diff -Nru firmware-free-20200122/debian/changelog 
firmware-free-20200122/debian/changelog
--- firmware-free-20200122/debian/changelog 2024-02-18 20:56:32.0 
+0100
+++ firmware-free-20200122/debian/changelog 2024-04-20 17:27:53.0 
+0200
@@ -1,3 +1,10 @@
+firmware-free (20200122-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Activate trigger declaratively. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 20 Apr 2024 17:27:53 +0200
+
 firmware-free (20200122-4) unstable; urgency=medium
 
   * Update to linux-support 6.6.15
diff -Nru firmware-free-20200122/debian/firmware-linux-free.postinst 
firmware-free-20200122/debian/firmware-linux-free.postinst
--- firmware-free-20200122/debian/firmware-linux-free.postinst  2024-02-18 
20:56:32.0 +0100
+++ firmware-free-20200122/debian/firmware-linux-free.postinst  1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-free-20200122/debian/firmware-linux-free.triggers 
firmware-free-20200122/debian/firmware-linux-free.triggers
--- firmware-free-20200122/debian/firmware-linux-free.triggers  1970-01-01 
01:00:00.0 +0100
+++ firmware-free-20200122/debian/firmware-linux-free.triggers  2024-04-20 
17:27:36.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs

Bug#1064459: refining DEP17 patches for glibc and base-files

[Helmut Grohne]

Hi Santiago,

On Wed, Apr 17, 2024 at 01:40:21PM +0200, Santiago Vila wrote:
> Nice feature indeed. To simplify the usr-merge patch, I've adopted
> the -D change in debian/postinst *before* we apply the usr-merge patch.

Thank you.

> Please take a look at branch "wip-202404-usrmerge" here:
> 
> https://salsa.debian.org/sanvila/base-files-not-yet/-/tree/wip-202404-usrmerge?ref_type=heads
> 
> (The repository name speaks for itself... I'm still not comfortable enough
> with salsa, but I'd like to experiment and see how it goes).
> 
> I've rebased the patch relative to version 13.1 which I have just uploaded.

Yeah, looks reasonable.

> If the rebase is ok, I'd like to make some minor editorial changes there as 
> well.

I noticed your upload before your mail and already updated the
integration branch:

https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo/-/blob/main/patches/base-files

Please let me know when you did your editorial changes such that I can
replace my patch with yours and retest.

At this time, we're down to the 5 planned packages base-files, bash,
dash, glibc and util-linux and could upload in principle, but we really
want time64 to migrate first and it's not clear when that'll happen. I'm
negotiating a transition slot.

Helmut

Bug#1069299: kodi-visualization-waveform FTBFS on arm*: does not agree on gl vs gles

[Helmut Grohne]

Source: kodi-visualization-waveform
Version: 20.2.1+ds1-1
Severity: serious
Tags: ftbfs

kodi-visualization-waveform fails to build from source on arm
architectures. A build fails like this:

| CMake Error at 
/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
|   Could NOT find OpenGLES (missing: OPENGLES_gl_LIBRARY OPENGLES_INCLUDE_DIR)
| Call Stack (most recent call first):
|   /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
|   FindOpenGLES.cmake:37 (find_package_handle_standard_args)
|   CMakeLists.txt:41 (find_package)

Looking into CMakeLists.txt, one can see that it takes the
APP_RENDER_SYSTEM=gles path. I guess this is rooted in kodi recently
having changed this for all arm architectures via #1056563. Now
kodi-visualization-waveform does not have any dependency on gles
libraries but happens to pull gl libraries transitively. As a result the
build now fails.

I'm not sure whether this is to be fixed in kodi-visualization-waveform
or kodi. The end result is that this very package FTBFS. Hence filing
here initially, but reassigning may still make sense.

Helmut

Bug#1069298: libsfml FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libsfml
Version: 2.6.1+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libsfml fails to cross build from source, because it fails running its
test suite despite being given DEB_BUILD_OPTIONS=nocheck. I'm attaching
a patch to add support for disabling tests and verified that doing so
does not affect the output artifacst via reproducible builds.

Helmut
diff --minimal -Nru libsfml-2.6.1+dfsg/debian/changelog 
libsfml-2.6.1+dfsg/debian/changelog
--- libsfml-2.6.1+dfsg/debian/changelog 2023-12-02 12:33:22.0 +0100
+++ libsfml-2.6.1+dfsg/debian/changelog 2024-04-19 08:28:52.0 +0200
@@ -1,3 +1,10 @@
+libsfml (2.6.1+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Support DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 19 Apr 2024 08:28:52 +0200
+
 libsfml (2.6.1+dfsg-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru libsfml-2.6.1+dfsg/debian/control 
libsfml-2.6.1+dfsg/debian/control
--- libsfml-2.6.1+dfsg/debian/control   2023-12-02 12:33:22.0 +0100
+++ libsfml-2.6.1+dfsg/debian/control   2024-04-19 08:28:27.0 +0200
@@ -6,7 +6,7 @@
  James Cowgill 
 Build-Depends: debhelper-compat (= 13),
  cmake,
- catch,
+ catch ,
  doxygen,
  libflac-dev,
  libfreetype-dev,
diff --minimal -Nru libsfml-2.6.1+dfsg/debian/rules 
libsfml-2.6.1+dfsg/debian/rules
--- libsfml-2.6.1+dfsg/debian/rules 2023-12-02 12:33:22.0 +0100
+++ libsfml-2.6.1+dfsg/debian/rules 2024-04-19 08:28:50.0 +0200
@@ -8,7 +8,7 @@
dh_auto_configure -- \
-DSFML_BUILD_DOC=ON \
-DSFML_BUILD_EXAMPLES=ON \
-   -DSFML_BUILD_TEST_SUITE=ON
+   -DSFML_BUILD_TEST_SUITE=$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON)
 
 override_dh_auto_build:
dh_auto_build -- all doc

Bug#826193: Please add a check if '-sa' is needed for security uploads

[Helmut Grohne]

Control: forwarded -1 
https://salsa.debian.org/debian/dput-ng/-/merge_requests/35

Hi Guido,

On Fri, Jun 03, 2016 at 09:16:13AM +0200, Guido Günther wrote:
> it would be great if dput-ng would check if a security upload needs the
> upstream source included when doing a security upload. This is necessary
> if the upload is the first security upload for an upstream version not
> yet present on security-master since upstream tarballs are not shared
> with the regular archive.
> 
> The check could either be done by looking into the changelog or by
> looking at https://qa.debian.org/madison.php or similar.

Or simply by guessing?

> This would make notifications by the security team about a missing
> upstream tarball (and a rebuilt with -sa) superfluous.

I've created a MR that implements the basic functionality of checking
for a possibly missing .orig.tar and some guesswork that hopefully
matches how security-master works without calling out to madison, but I
imagine that pointing the include_orig configuration item at a madison
url would be the next step if the heuristic doesn't work well enough.

Is this worth including already? If not, you can now install it
locally. Into ~/.dput.d/scripts/ and ~/.dput.d/hooks/ and profit.

Helmut

Bug#1069154: RM: fsprotect -- RoQA; depends on dead aufs, low popcon, no rdeps

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: fsprot...@packages.debian.org, Stefanos Harhalakis 
Control: affects -1 + src:fsprotect
Control: block 1069153 by -1
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of fsprotect from Debian unstable for the following
reasons:
 * Chris Hofstaedler suggested removal in January, no reply: #1061369
 * We should remove aufs from unstable: #1069153
 * Low popcon (6)
 * No reverse dependencies

Helmut

Bug#1069153: RM: aufs -- RoQA; FTBFS since 2020, not part of bullseye, bookworm or trixie, dead upstream

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: a...@packages.debian.org, Jan Luca Naumann 

Control: affects -1 + src:aufs
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of aufs from Debian unstable for the following
reasons:
 * FTBFS since 2020
 * Alternative overlayfs exists
 * No maintainer upload since 2019
 * Dead upstream: https://marc.info/?l=linux-kernel=123938442923108
 * aufs-tools also being removed: #1069146

Helmut

Bug#1069152: RM: xorp -- RoQA; FTBFS since 2019, not part of bullseye, bookworm or trixie, popcon 2

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: x...@packages.debian.org, Jose M Calhariz , 
Javier Fernandez-Sanguino Pen~a , Mattia Rizzolo 

Control: affects -1 + src:xorp
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removing xorp from unstable for the following reasons:
 * FTBFS since 2019
 * No maintainer upload since 2016
 * Not part of bullseye, bookworm or trixie
 * Low popcon (2)
 * No reverse dependencies
 * Requires changes for the /usr-move transition

Helmut

Bug#1069151: RM: netopeer2 -- RoQA; FTBFS since 2021, not part of any release, low popcon

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: netope...@packages.debian.org, Ondřej Surý 
Control: affects -1 + src:netopeer2
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of netopeer2 from Debian unstable for the following
reasons:
 * FTBFS since 2021
 * 4 open RC-bugs
 * It only ever received two uploads in 2021 and nothing ever happened
   since
 * Low popcon (2)
 * No reverse dependencies
 * Requires changes for the /usr-move transition

Helmut

Bug#1069150: RM: libvma -- RoQA; FTBFS since 2022, not part of any stable release, low popcon

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: lib...@packages.debian.org, Debian HPC Team 
, Tzafrir Cohen 
Control: affects -1 + src:libvma
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of libvma from Debian unstable for the following
reasons:
 * FTBFS since 2022
 * No maintainer upload since 2021
 * Not part of any stable release
 * No reverse dependencies
 * Low popcon (5)
 * Requires changes for the /usr-move transition

Helmut

Bug#1069149: RM: cadvisor -- RoQA; FTBFS since 2022, not part of bookworm nor trixie, does not work on bullseye

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: cadvi...@packages.debian.org, Debian Go Packaging Team 
, Shengjing Zhu 
Control: affects -1 + src:cadvisor
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of cadvisor from Debian unstable for the following
reasons:
 * FTBFS since 2022
 * Not part of bookworm or trixie
 * Does not work on bullseye (#1027994)
 * Last maintainer upload in 2021
 * No reverse dependencies
 * Low popcon (23)
 * Requires changes for the /usr-move transition

Helmut

Bug#1069148: RM: lockdown -- RoQA; FTBFS since 2020, not part of bullseye, bookworm or trixie

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: lockd...@packages.debian.org, Matt Taggart 
Control: affects -1 + src:lockdown
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of lockdown from unstable for the following reasons:
 * FTBFS since 2020
 * Not part of bullseye, bookworm or trixie
 * Similar package hardening-runtime exists
 * No maintainer upload since 2017
 * Chris Hofstaedler raised an RC bug in December 2023 suggesting
   removal and received no replies (#1058075)
 * Low popcon (1)
 * Requires changes for the /usr-move transition

Helmtu

Bug#1069147: RM: srslte -- RoQA; FTBFS since 2020, not part of bullseye, bookworm or trixie, low popcon

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: srs...@packages.debian.org, Debian Mobcom Maintainers 
, Ruben Undheim 

Control: affects -1 + src:srslte
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of srslte from unstable for the following reasons:
 * FTBFS since 2020
 * Not part of bullseye, bookworm or trixie
 * No reverse dependencies
 * Low popcon (0)
 * No maintainer upload since 2021
 * Requires changes for /usr-move transition

Helmut

Bug#1069146: RM: aufs-tools -- RoQA; FTBFS since 2019, overlayfs available, not in bullseye, bookworm, trixie

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: aufs-to...@packages.debian.org, Jan Luca Naumann 

Control: affects -1 + src:aufs-tools
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of aufs-tools from unstable for the following reasons:
 * FTBFS since 2019
 * No maintainer upload since 2019
 * Not part of bullseye, bookworm, trixie
 * Similar functionality available via standard kernel module overlayfs
 * Requires changes to complete the /usr-move transition

Helmut

Bug#1069145: RM: vast -- RoQA; FTBFS since 2021, not part of bookworm or trixie, low popcon

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: v...@packages.debian.org, Sascha Steinbiss 
Control: affects -1 + src:vast
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I request removal of vast from Debian unstable for the following
reasons:
 * FTBFS since 2021
 * Not part of bookworm or trixie
 * No maintainer upload since 2021
 * Low popcon (2)
 * No reverse dependencies
 * Requires changes for the /usr-move transition

Helmut

Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?

[Helmut Grohne]

Source: gcc-14
Version: 14-20240121-1
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hello Matthias,

the -for-host stuff doesn't quite work for architecture cross bootstrap
yet and I'm looking into why. What initially seemed like a trivial
question turned out be a bit subtle.

Which gcc builds should emit -for-host packages?

This may sound like an obvious question initially, but looking beneath
makes it a little less obvious. It is relatively obvious that native
builds and cross builds (build!=host=target) should both emit -for-host
packages. The question becomes more interesting when you look into cross
toolchain builds.

>From an end-user pov using a cross toolchain, there is no need for
-for-host packages. They can use a built cross toolchain entirely
without these packages as -for-host packages effectively are
metapackages. If we look at e.g.  src:gcc-14-cross, it builds e.g.
gcc-14-aarch64-linux-gnu, so in principle it could be emitting
gcc-14-for-host:arm64, but since host!=target, we can never include this
binary package in a .changes files nor upload it to the archive. We can
see that cross toolchain builds via src:gcc-14-cross must not include
-for-host packages. Likewise, cross-toolchain-base cannot include them.

The point where we really need -for-host packages is when we need to
satisfy Debian package dependencies in a cross build setting. In this
setting, we also need libstdc++-14-dev and others. This is not something
you get from a cross toolchain build (unless you patch in the
with_deps_on_target_arch_pkgs patch that you removed and is now
available in cross-gcc-dev). So when you need libstdc++-14-dev, you end
up building DEB_STAGE=rtlibs (or using natively built packages for your
target architecture) and when you do not need libstdc++-14-dev, you
almost certainly also won't need -for-host packages.

Quite clearly, doing both a cross toolchain build and a DEB_STAGE=rtlibs
build should result in -for-host packages and ideally should produce
them only once. Currently, the cross toolchain build produces them and
the DEB_STAGE=rtlibs build does not produce them. Given my reasoning in
the previous paragraph, it would also be plausible to emit them from
DEB_STAGE=rtlibs only.

Another aspect is the content of -for-host packages. They install their
doc directory as a symbolic link to $(p_xbase). In a cross toolchain
build (without with_deps_on_target_arch_pkgs), p_xbase ends up being
target-dependent. Hence, the symlink target in these -for-host packages
differs. While native builds and cross builds link to gcc-14-base, cross
toolchains link to gcc-14$(cross_bin_arch)-base and dpkg very much does
not like Multi-Arch: same packages to install conflicting symbolic
links.

As a result, the -for-host packages we emit from cross toolchain builds
cannot be installed concurrently with any other -for-host package
significantly defeating their purpose.

I looked into fixing this problem and the obvious thing to try is
changing the symlink targets in cross toolchain builds to also point to
gcc-14-base. As a consequence, they also depend on gcc-14-base, but a
cross toolchain build does not currently produce a gcc-14-base package
for the target architecture. If we were producing it, both the cross
toolchain build and the DEB_STAGE=rtlibs build were producing them and a
user would have to choose which one of them to use. It also means
introducing another variant of naming base packages besides p_base,
p_lbase and p_xbase which already are non-trivial to understand.

If we were moving the -for-host packages from the cross toolchain build
to the DEB_STAGE=rtlibs build, they would automatically reference the
right base package, because the runtime libraries also link their
documentation to it. On the flip side, the resulting -for-host packages
would not have satisfiable dependencies unless combining with a cross
toolchain build (or a native compiler for the target architecture), so
the DEB_STAGE=rtlibs would no longer be self-contained in a sense.

This move would not affect gcc-14-cross nor cross-toolchain-base,
because neither of them include -for-host packages (as we saw earlier).

In writing this, I am providing arguments that rather strongly suggest
that we should move them from the cross toolchain build to the
DEB_STAGE=rtlibs build, but is this really the right conclusion or am I
missing something?

In any case, I looked into prototyping this suggested move as a patch to
the gcc packaging. I am attaching a proof-of-concept of this, but I'm
not particularly fond of it as it noticeably increases the packaging
complexity. I am adding a lot of "addons" and pull a bit of code from
various debian/rules.d/binary-*.mk to a new
debian/rules.d/binary-forhost.mk such that prefixes that were only used
in a particular file are now spread to multiple. For instance, all
?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier
and are now 

Bug#1069066: LIMITS_H_TEST is frequently wrong on Debian

[Helmut Grohne]

Source: gcc-14
Tags: patch upstream
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hi Matthias,

I've been fighting LIMITS_H_TEST for a long time. The basic problem with
it is that it uses different search paths from the actual compiler and
thus ends up occasionally detecting absence of limits.h when limits.h
really does exist. There have been various attempts to rectify this and
most of them are documented in the forwarded gcc ticket. Ultimately
though, I think the best course of action is deferring the check from a
build-time check to a run-time check thus using the actual compiler's
search path removing any possibility for misdetection. This can be done
using has_include_next in principle, but until recently,
has_include_next was broken on gcc in ways that would make this solution
inapplicable. These problems with has_include_next have recently been
resolved in gcc-14 and the Debian package includes a working version. As
a result I suggest that we also move forward with my proposed
LIMITS_H_TEST replacement in Debian. Upstream gcc fails to move forward
here and the problem affects Debian in particular due to our use of
multiarch and our changing of the compiler search path. Would you agree
to carry this as a Debian patch until gcc manages to fix it one way or
another? I've been using this last iteration of the patch for quite a
while now and didn't have any misdetections since.

Helmut
--- a/src/gcc/limitx.h
+++ b/src/gcc/limitx.h
@@ -29,7 +29,7 @@
 #ifndef _GCC_LIMITS_H_  /* Terminated in limity.h.  */
 #define _GCC_LIMITS_H_

-#ifndef _LIBC_LIMITS_H_
+#if !defined(_LIBC_LIMITS_H_) && __has_include_next()
 /* Use "..." so that we find syslimits.h only in this same directory.  */
 #include "syslimits.h"
 #endif
--- a/src/gcc/limity.h
+++ b/src/gcc/limity.h
@@ -3,7 +3,7 @@

 #else /* not _GCC_LIMITS_H_ */

-#ifdef _GCC_NEXT_LIMITS_H
+#if defined(_GCC_NEXT_LIMITS_H) && __has_include_next()
 #include_next 		/* recurse down to the real one */
 #endif

--- a/src/gcc/Makefile.in
+++ b/src/gcc/Makefile.in
@@ -3139,11 +3139,7 @@
 	  sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
 	  multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
	  include_dir=include$${multi_dir}; \
-	  if $(LIMITS_H_TEST) ; then \
-	cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
-	  else \
-	cat $(T_GLIMITS_H) > tmp-xlimits.h; \
-	  fi; \
+	  cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
	  $(mkinstalldirs) $${include_dir}; \
	  chmod a+rx $${include_dir} || true; \
 	  $(SHELL) $(srcdir)/../move-if-change \

Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move

[Helmut Grohne]

Package: util-linux-extra
Version: 2.40-6
Severity: serious
User: helm...@debian.org
Usertags: dep17p1
Control: affects -1 + util-linux

Hi Chris,

I think I mentioned this on IRC already and you intended to revert, but
nothing happened, so lets turn this into a bug for tracking purposes at
least.

util-linux-extra gained the utils ctrlaltdel, fsck.cramfs, fsck.minix,
mkfs.bfs, mkfs.cramfs, and mkfs.minix. In util-linux-extra, these now
reside below /usr/sbin while they used to reside in /sbin in util-linux
in bookworm and earlier. Hence upgrading from bookworm to sid can cause
these files to be lost.

I think we have three ways to address this:

 1. Revert the move and retry after trixie. I think you favoured this?
 2. Upgrade Breaks to Conflicts and issue a temporary protective
diversion from u-l-e.preinst to u-l-e.postinst. In theory, apt can
first unpack u-l, then unpack u-l-e and then configure both, so
there is a safe solution. However, there is a risk that apt could
decide to temporarily remove u-l and that would be really bad.
 3. Keep Breaks and issue temporary diversions to be removed in forky's
u-l-e.postinst.

Please let me know your choice and I can do a patch.

Helmut

Bug#1069034: openfst FTCBFS: multiple reasons

[Helmut Grohne]

Source: openfst
Version: 1.7.9-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

openfst fails to cross build from source for two reasons. One is that it
has an unskippable AC_RUN_IFELSE check. Reading configure.ac reveals
that this is a safety check that is also being done in the test suite.
We have no chance of running this test in a cross build so the only
option is to skip it in cross builds. The other is that debian/rules
passes sse flags whenever building on x86, but it should only pass the
flags when building for x86. I'm attaching a patch to fix both for your
convenience.

Helmut
diff --minimal -Nru openfst-1.7.9/debian/changelog 
openfst-1.7.9/debian/changelog
--- openfst-1.7.9/debian/changelog  2022-08-16 16:58:50.0 +0200
+++ openfst-1.7.9/debian/changelog  2024-04-15 13:06:02.0 +0200
@@ -1,3 +1,12 @@
+openfst (1.7.9-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Allow skipping equality reflexivity test.
++ debian/rules: Fix build vs host confusion.
+
+ -- Helmut Grohne   Mon, 15 Apr 2024 13:06:02 +0200
+
 openfst (1.7.9-5) unstable; urgency=low
 
   * debian/rules: Set --max-parallel=2 in override_dh_auto_test to avoid
diff --minimal -Nru openfst-1.7.9/debian/patches/cross.patch 
openfst-1.7.9/debian/patches/cross.patch
--- openfst-1.7.9/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ openfst-1.7.9/debian/patches/cross.patch2024-04-15 13:06:01.0 
+0200
@@ -0,0 +1,12 @@
+--- openfst-1.7.9.orig/configure.ac
 openfst-1.7.9/configure.ac
+@@ -180,7 +180,8 @@
+   [AC_MSG_FAILURE(m4_normalize([
+Test float equality failed!
+Compile with -msse -mfpmath=sse if using g++.
+-  ]))])
++  ]))],
++  [echo "Skipping float equality test for cross compilation"])
+ 
+ AC_CHECK_LIB([dl], dlopen, [DL_LIBS=-ldl])
+ AC_SUBST([DL_LIBS])
diff --minimal -Nru openfst-1.7.9/debian/patches/series 
openfst-1.7.9/debian/patches/series
--- openfst-1.7.9/debian/patches/series 2022-08-16 16:58:50.0 +0200
+++ openfst-1.7.9/debian/patches/series 2024-04-15 13:05:31.0 +0200
@@ -1,3 +1,4 @@
 openfst-atomic.diff
 openfst-cxx17.diff
 #openfst-sse.diff # Only applied on non-x86 archs
+cross.patch
diff --minimal -Nru openfst-1.7.9/debian/rules openfst-1.7.9/debian/rules
--- openfst-1.7.9/debian/rules  2022-08-16 16:58:50.0 +0200
+++ openfst-1.7.9/debian/rules  2024-04-15 13:06:02.0 +0200
@@ -13,9 +13,9 @@
dh $@
 
 override_dh_autoreconf:
-ifeq ($(DEB_BUILD_ARCH),i386)
+ifeq ($(DEB_HOST_ARCH),i386)
patch -p1 < debian/patches/openfst-sse.diff
-else ifeq ($(DEB_BUILD_ARCH),amd64)
+else ifeq ($(DEB_HOST_ARCH),amd64)
patch -p1 < debian/patches/openfst-sse.diff
 endif
dh_autoreconf

Bug#1069031: gearmand contains a broken, oudated, embedded copy of AX_BOOST_BASE

[Helmut Grohne]

Source: gearmand
Version: 1.1.20+ds-1.3
Tags: security
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gearmand contains an outdated, broken, embedded copy of AX_BOOST_BASE in
m4/ax_boost_base.m4 that contains a copy of #872256. Please remove this
copy and use the fixed one from autoconf-archive. Failing that, please
update your copy and register it with the security tracker. For more
information on registering your copy, please refer to:

https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies?ref_type=heads

Helmut

Bug#1069029: libxml-bare-perl FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: libxml-bare-perl
Version: 0.53-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libxml-bare-perl fails to cross build from source, because it uses the
build architecture compiler. The compiler detection in Makefile.PL
actually is not very smart and just uses "gcc". I am attaching a patch
that makes the CC configurable via environment and falls back to the
detection mechanism of perl itself. While this improves cross building,
I fear the patch will regress msvc builds as is, because earlier getcc
used to return 0 for msvc and now it'll really return a compiler there.
So the patch will work on Debian, but upstream may want to refine it.

Helmut
--- libxml-bare-perl-0.53.orig/Makefile.PL
+++ libxml-bare-perl-0.53/Makefile.PL
@@ -1,4 +1,5 @@
 #!/usr/bin/perl
+use Config;
 use ExtUtils::MakeMaker;
 require 5.006;
 my @basics = ( 
@@ -90,13 +91,8 @@
   );
 }
 sub getcc {
-  my $div = (substr($ENV{'PATH'},0,1) eq '/') ? ':' : ';';
-  my @path = split($div,$ENV{'PATH'});
-  foreach my $dir ( @path ) {
-return 'gcc' if( -e "$dir/gcc" || -e "$dir/gcc.exe" ); # prefer gcc
-return 'cc'  if( -e "$dir/cc"  || -e "$dir/cc.exe"  );
-  }   
-  return 0;
+  return $ENV{'CC'} if defined $ENV{'CC'};
+  return $Config::Config{cc};
 }
 
 # The following are hacks to force static linking and so remove need for msvcr## dll

Bug#1069030: subread FTBFS on 32bit architectures: -Werror=implicit-function-declaration

[Helmut Grohne]

Source: subread
Version: 2.0.6+dfsg-2
Severity: serious
Tags: ftbfs

subread fails to build from source on 32bit architectures: A
non-parallel build contains:

| i686-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -mtune=generic -msse3 -O3 -fsigned-char -Wall 
-DMAKE_FOR_EXON  -D MAKE_STANDALONE -D SUBREAD_VERSION=\""2.0.6"\"  
-D_FILE_OFFSET_BITS=64  -fmessage-length=0 -ggdb -Wdate-time 
-D_FORTIFY_SOURCE=2  -c -o input-files.o input-files.c
| input-files.c: In function ‘f_subr_open’:
| input-files.c:54:24: error: implicit declaration of function ‘fopen64’; did 
you mean ‘gzopen64’? [-Werror=implicit-function-declaration]
|54 | return fopen64(fname, mode);
|   |^~~
|   |gzopen64

Helmut

Bug#1069028: mark golang-github-rivo-uniseg Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-rivo-uniseg-dev
Version: 0.4.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:acmetool src:aerc src:amfora src:aptly src:boohu 
src:caddy src:crowdsec src:crowdsec-custom-bouncer 
src:crowdsec-firewall-bouncer src:dh-make-golang src:distrobuilder 
src:docker.io src:duf src:etcd src:fdroidcl src:fq src:fzf src:gh src:gitaly 
src:gitbatch src:gitlab src:gitlab-ci-multi-runner src:gitlab-shell 
src:gitleaks src:glab src:go-containerregistry src:go-cve-dictionary 
src:go-exploitdb src:golang-github-checkpoint-restore-checkpointctl 
src:golang-github-containerd-stargz-snapshotter 
src:golang-github-containers-buildah src:golang-github-containers-storage 
src:golang-github-crc-org-crc src:golang-github-micromdm-scep 
src:golang-github-openshift-imagebuilder src:golang-github-rubenv-sql-migrate 
src:golang-github-xordataexchange-crypt src:gomuks src:gost src:hcloud-cli 
src:hugo src:incus src:influxdb src:invidtui src:jid src:lf src:libpod src:lxd 
src:mender-cli src:micro src:nextcloud-spreed-signaling src:nncp 
src:oci-seccomp-bpf-hook src:pat src:peco src:prometheus 
src:prometheus-mqtt-exporter src:prometheus-postfix-exporter 
src:prometheus-sql-exporter src:rclone src:seqkit src:singularity-container 
src:skeema src:skopeo src:tea-cli src:terminews src:termshark src:unikmer 
src:victoriametrics src:vip-manager src:vip-manager2 src:vuls 
src:wormhole-william src:wuzz src:yggdrasil

golang-github-rivo-uniseg-dev is a pure go library with no
architecture-dependent parts and thus is packaged as Arch:all package.
That renders it unusable in a cross compilation setting unless it also
is marked Multi-Arch: foreign. The multiarch hinter already indicates
that adding Multi-Arch: foreign is safe. All of the affected packages
currently have unsatisfiable cross Build-Depends due to this.

Helmut
diff --minimal -Nru golang-github-rivo-uniseg-0.4.4/debian/changelog 
golang-github-rivo-uniseg-0.4.4/debian/changelog
--- golang-github-rivo-uniseg-0.4.4/debian/changelog2023-10-15 
09:55:47.0 +0200
+++ golang-github-rivo-uniseg-0.4.4/debian/changelog2024-04-15 
12:28:29.0 +0200
@@ -1,3 +1,10 @@
+golang-github-rivo-uniseg (0.4.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-rivo-uniseg-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 15 Apr 2024 12:28:29 +0200
+
 golang-github-rivo-uniseg (0.4.4-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru golang-github-rivo-uniseg-0.4.4/debian/control 
golang-github-rivo-uniseg-0.4.4/debian/control
--- golang-github-rivo-uniseg-0.4.4/debian/control  2023-10-15 
09:55:21.0 +0200
+++ golang-github-rivo-uniseg-0.4.4/debian/control  2024-04-15 
12:28:28.0 +0200
@@ -21,6 +21,7 @@
 
 Package: golang-github-rivo-uniseg-dev
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
 Description: Unicode Text Segmentation for Go

Bug#1060267: -qmake: emits wrong QT_HOST_LIBEXECS - fix

[Helmut Grohne]

Control: tags -1 + patch
Control: affects -1 + qpdfview

On Thu, Feb 15, 2024 at 01:55:53AM +, Maarten van der Schrieck wrote:
> Cross building with qmake6 fails due to QT_HOST_LIBEXECS having a wrong
> value. For completeness: QT_HOST_LIBEXECS refers to the config file
> variable HostLibraryExecutables, and is internally referred to as
> QMakeLibraryInfo::HostLibraryExecutablesPath and
> QMakeLibraryInfo::LibraryPathQMakeExtras::HostLibraryExecutablesPath in
> the qmake source code.
> 
> The issue is that HostLibraryExecutables defaults to the *default* value
> of LibraryExecutables. LibraryExecutables is set to the right value (a
> concatenation of Prefix + LibraryExecutables with the value
> "/usr/lib/qt6/libexec"), but its default value is Prefix + "libexec".
> 
> As the cross build config /usr/lib//qt6/qt6.conf specifies
> Prefix as "/usr", the default of LibraryExecutables, and hence the
> default of HostLibraryExecutables, is now "/usr/libexec", which is the
> wrong value.
> 
> The simple fix is to supply the value of HostLibraryExecutables in
> /usr/lib//qt6/qt6.conf explicitly:
> 
> ...
> HostLibraryExecutables=lib/qt6/libexec
> ...

Thank you so much for locating the fix and taking the time to explain it
in so much detail.

I ran into this problem with qpdfview again and confirm that what you
propose here makes it just work.

Helmut

Bug#1068809: dh-buildinfo: consider deprecating and removing the package

[Helmut Grohne]

Package: dh-buildinfo
Version: 0.11+nmu3
X-Debbugs-Cc: hol...@debian.org

Hi,

dh-buildinfo much predates the reproducible builds effort and the
.buildinfo file and probably laid ground to it. I am now raising the
question whether it is time to get rid of dh-buildinfo in Debian.

Essentially I am arguing that the use case of dh-buildinfo is now served
by dpkg-genbuildinfo and the generated .buildinfo files on every package
build. Besides the difference in formatting, the main difference is that
dh-buildinfo embeds this information into the binary package rather than
next to it (where it can be lost). I argue that all of the uses of
dh-buildinfo can now be met with examining .buildinfo files.

At the same time, dh-genbuildinfo reduces reproducibility. When cross
building a package, we necessarily install different packages from a
native build. This difference manifests in the embedded buildinfo files
and thus comparing a natively built package with a cross built package
needs to ignore the embedded buildinfo file where we would like cross
builds to exactly reproduce native builds where possible.

As such I am proposing to call dh-buildinfo deprecated, then to actively
remove dependencies on it and finally remove it from Debian.

If you agree with this vision, please tag this bug confirmed. If you
disagree with this vision, please tag it wontfix and explain the added
value that I fail to see.

Thank you

Helmut

Bug#1068808: openmpi-bin has an undeclared file conflict on /usr/bin/pterm

[Helmut Grohne]

Package: openmpi-bin
Version: 5.0.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pterm

openmpi-bin has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/bin/pterm is contained in the packages
 * openmpi-bin/5.0.3-1 as present in experimental
 * pterm
   * 0.74-1+deb11u1 as present in bullseye|bullseye-security
   * 0.78-2+deb12u1 as present in bookworm|bookworm-security
   * 0.80-1 as present in trixie
   * 0.80-1+b1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Helmut Grohne]

Hi Aurelien,

On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> Thanks for you analysis and your patch. In short your proposal is to
> extend the initial patch from Steve to fully hide the fact that the
> compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
> 
> This indeed works and fixes the FTBFS. However it seems that, at least
> for some of the issues, it just hides them. For instance the wrong type
> for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> conformance tests. Quoting utmpx.h/conform.out:

I think this needs a more nuanced look. From the comments in the
conformance test suite, it is evident that it expects to be run without
_FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
exist only exist when these macros are unset. The conformance test suite
has a comment saying that it should be testing the case where
_FILE_OFFSET_BITS is defined, but it currently does not provide
expectations for that case.

Before we can reasonably run the conformance test suite with these
macros set (and really, the test suite should be in control of these
macros), we cannot reasonably use it with them set. Let us now imagine a
future where the conformance test suite has been extended to provide
expectations (which in lots of cases means that *64 symbols disappear
when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:

> | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have 
> ‘__suseconds64_t’ {aka ‘long long int’}
> | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> |   |   ^
> | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with 
> type ‘suseconds_t’ {aka ‘long int’}
> | 3 | extern suseconds_t b2_10;
> |   |^
> | FAIL: Type of member tv_usec

Indeed, this is not something that can easily be fixed and where
upstream is still debating on what the correct solution should be. It
also is an issue that existed for a long time. If you head over to a
bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
it is not one that is directly related to Debian changing the default.
We merely increased the visibility of this problem that existed earlier
already.

Given that
 * the issue is already present in bookworm,
 * there are two mutually exclusive solutions and
 * upstream is still discussing the best solution
I recommend deferring this aspect.

> And we know it is the reason for the FTBFS of libflorist [2], so should
> we just ignore that issue anyway?

The libflorist issue likely is a consequence. It arises from
gnat_to_gnu_field where GNAT verifies that the value (of type
suseconds_t) to be assigned to a field (tv_usec) has the matching size.
This is directly based on the POSIX expectation and will be fixed with
the glibc issue.

How about filing a separate bug with glibc that tracks this POSIX
divergence and mark the libflorist bug as being blocked by this other
glibc bug? It can be RC or not, but since it affects bookworm, it won't
block testing migration.

Helmut

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Helmut Grohne]

Control: tags -1 + patch

Hi Aurelien and Canonical folks,

On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> except i386.
> 
> This has been partially fixed in the 2.37-15.1 NMU by adding
> -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:

There are two subtleties about -U_TIME_BITS in a moment.

> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: conform/ISO/stdio.h/linknamespace

The detail for this failure is:

| [initial] fgetpos64
| [initial] fopen64
| [initial] freopen64
| [initial] fsetpos64
| [initial] tmpfile64

What linknamespace.py wants to tell us here is that it expected
fgetpos64, but no fgetpos64 was declared. It was not declared, because
there is no difference between fgetpos and fgetpos64 after defining
-D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).

The other failures are of very similar kind, but there also is another
kind.

> | FAIL: conform/POSIX/sys/stat.h/conform

The detail for this failure contains:

| /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have 
'__time64_t' {aka 'long long int'}
|90 | extern __typeof__ (a2_8.st_atime) b2_8;
|   |   ^~~~
| /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with type 
'__time_t' {aka 'long int'}
|89 | extern __time_t b2_8;
|   | ^~~~

Here, it tells us that it expected the st_atime field of struct stat to
have type __time_t (the 32 bit one), but it really has __time64_t.

Looking at the invocation of linknamespace.py you can see:

| python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12' 
--flags='-I../include  
-I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc  
-I../sysdeps/unix/sysv/linux/arm/le  -I../sysdeps/unix/sysv/linux/arm  
-I../sysdeps/arm/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix  
-I../sysdeps/arm/le/armv7/multiarch  -I../sysdeps/arm/armv7/multiarch  
-I../sysdeps/arm/le/armv7  -I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2  
-I../sysdeps/arm/armv6  -I../sysdeps/arm/le  -I../sysdeps/arm/include 
-I../sysdeps/arm  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic 
-nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem 
/build/reproducible-path/glibc-2.37/debian/include -I..' ...

In particular, what you do not see is -U_TIME_BITS inside --flags.

> Ubuntu has just ignored those failures for now, but I am just afraid
> that if we do the same, nobody will fix them.

Armed with this knowledge, I think we need two changes. For one thing
debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
to revert any possible ABI changing effects. For another, the
conformance tests use independent compiler flags defined in
conform/Makefile. There, a naive patch seems to be:

-conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
+conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include 
$(+sysdep-includes) $(sysincludes) -I..

With these two changes, I am able to successfully build glibc on armhf
with the conformance test suite passing.

> In addition it means that upstream glibc does not build anymore by
> default on a 32-bit Debian. Not really a Debian issue, but that is not
> nice either and should probably be fixed.

I think that latter change may be applicable upstream. Running the
conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
is not expected nor supported. This is partially evident from
conform/linknamespace.py in a comment:

| # * Header inclusions should be compiled several times with
| # different options such as -O2, -D_FORTIFY_SOURCE and
| # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
| # from such a compilation; this is not yet implemented.

The conformance test suite clearly wants to manage these macros (and its
effects on symbols) explicitly and does not expect them to be
pre-defined.

Hope this helps

Helmut

Bug#1068312: piuparts: Error when Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged' (bullseye)

[Helmut Grohne]

Control: tags -1 + confirmd patch
Control: forwarded -1 
https://salsa.debian.org/debian/piuparts/-/merge_requests/56

On Wed, Apr 03, 2024 at 01:40:28PM +0200, Fab Stz wrote:
> I have a CI job on salsa running piuparts with bullseye.
> Recently it started failing with this error:
> 
> 0m4.3s DUMP:
>   Enabling dpkg --force-unsafe-io.
>   Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged'
>   ln: failed to create symbolic link '/bin/sync': File exists
> 0m4.3s ERROR: Command failed (status=1): ['chroot', '/tmp/tmpoj1y68a1',
> 'eatmydata', 'tmp/scripts/post_setup_force-unsafe-io']
>   Enabling dpkg --force-unsafe-io.
>   Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged'
>   ln: failed to create symbolic link '/bin/sync': File exists
> 
> 
> Maybe this is somehow related to the latest changes in 1.4.1 mentioned as 
> "also fix /bin/sync diversion for bookworm"?

I confirm the problem and understand the failure. Mea culpa.

When I adapted the code for bookworm (which is /usr-merged, but has
/bin/sync), I failed to notice that I also conditionalized the moving
code, so the unmerged-/usr path would now divert with --no-rename and
not move /bin/sync either. That makes ln unhappy as we can see.

I've created a merge request to address this regression and am sorry for
having broken piuparts so many times.

Helmut

Bug#1068635: screen FTCBFS: pty.c:338:7: error: implicit declaration of function ‘openpty’; did you mean ‘OpenPTY’? [-Werror=implicit-function-declaration]

[Helmut Grohne]

Source: screen
Version: 4.9.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi,

screen fails to cross build from source:

| mips64el-linux-gnuabi64-gcc -c -I. -I..  -Wdate-time -D_FORTIFY_SOURCE=2 
-DETCSCREENRC='"/etc/screenrc"' 
-DSCREENENCODINGS='"/usr/share/screen/utf8encodings"' -DHAVE_CONFIG_H 
-DGIT_REV=\"\" \
|  -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -Wno-unused-parameter 
-Wno-missing-field-initializers -D_GNU_SOURCE ../pty.c
| ../pty.c: In function ‘OpenPTY’:
| ../pty.c:338:7: error: implicit declaration of function ‘openpty’; did you 
mean ‘OpenPTY’? [-Werror=implicit-function-declaration]
|   338 |   if (openpty(, , TtyName, NULL, NULL) != 0)
|   |   ^~~
|   |   OpenPTY

The real cause here is that screen exercises a non-standard code path
due to configure time misdetection. It skips the SVR4 /dev/ptmx check in
cross compilation and directly falls back to openpty, which apparently
no longer works.

The "test -c /dev/ptmx" is conditionalized to not being performed during
cross compilation and doing it there would be confusing build and host.
However, AC_CHECK_FILE exists for this very purpose. During native
compilation, it becomes a simple test and during cross compilation it
becomes a hard failure where a user must supply the check result. Then
also supplying the result makes screen cross buildable again. I'm
attaching a patch for your convenience.

Note that with this patch applied, crossqa.debian.net will always
report screen as failed, because it does not supply this check result.
If you want to do this explicitly, you may add the following snippet to
d/rules:

ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
ifeq ($(DEB_HOST_ARCH_OS),linux)
export ac_cv_file__dev_ptmx = yes
endif
endif

Or you may leave this to the builder at your choice, but there is no
sane way to detect this during build.

Helmut
--- screen-4.9.1.orig/configure.ac
+++ screen-4.9.1/configure.ac
@@ -756,10 +756,10 @@
 fi
 fi
 
-if test "$cross_compiling" = no ; then
+AC_CHECK_FILE([/dev/ptmx])
 AC_CHECKING(for SVR4 ptys)
 sysvr4ptys=
-if test -c /dev/ptmx ; then
+if test "x$ac_cv_file__dev_ptmx" = xyes ; then
 AC_TRY_LINK([
 #include 
 ], [
@@ -767,7 +767,6 @@
 ],[AC_DEFINE(HAVE_SVR4_PTYS)
 sysvr4ptys=1])
 fi
-fi
 
 AC_CHECK_FUNCS(getpt)
 

Bug#1068610: dico: binary-all FTBFS

[Helmut Grohne]

Control: tags -1 + patch

Hi Adrian,

On Mon, Apr 08, 2024 at 02:03:01AM +0300, Adrian Bunk wrote:
> Source: dico
> Version: 2.11-4
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: Helmut Grohne 

Thank you for notifying me. Mea culpa. Patch attached.

> https://buildd.debian.org/status/logs.php?pkg=dico=all
> 
> ...
>debian/rules execute_after_dh_installsystemd
> make[1]: Entering directory '/<>'
> ln -s dicod.service debian/dicod/`test -e 
> debian/dicod/lib/systemd/system/dicod.service || echo 
> usr/`lib/systemd/system/dictd.service
> ln: failed to create symbolic link 
> 'debian/dicod/usr/lib/systemd/system/dictd.service': No such file or directory
> make[1]: *** [debian/rules:52: execute_after_dh_installsystemd] Error 1

Helmut
diff --minimal -Nru dico-2.11/debian/changelog dico-2.11/debian/changelog
--- dico-2.11/debian/changelog  2024-03-01 12:57:59.0 +0100
+++ dico-2.11/debian/changelog  2024-04-08 09:21:47.0 +0200
@@ -1,3 +1,10 @@
+dico (2.11-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix indep-only FTBFS arising from #1054187. (Closes: #1068610)
+
+ -- Helmut Grohne   Mon, 08 Apr 2024 09:21:47 +0200
+
 dico (2.11-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru dico-2.11/debian/rules dico-2.11/debian/rules
--- dico-2.11/debian/rules  2023-11-20 17:26:32.0 +0100
+++ dico-2.11/debian/rules  2024-04-08 09:21:31.0 +0200
@@ -48,5 +48,5 @@
mkdir -p $(TEST_HOME)
HOME=$(TEST_HOME) dh_auto_test || cat dicod/tests/testsuite.log
 
-execute_after_dh_installsystemd:
+execute_after_dh_installsystemd-arch:
ln -s dicod.service debian/dicod/`test -e 
debian/dicod/lib/systemd/system/dicod.service || echo 
usr/`lib/systemd/system/dictd.service

Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a

[Helmut Grohne]

Package: libdialog-dev
Version: 1.3-20240307-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + dialog

libdialog-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/libdialog.a is contained in the
packages
 * dialog
   * 1.3-20201126-1 as present in bullseye
   * 1.3-20230209-1 as present in bookworm
   * 1.3-20240101-1 as present in trixie
 * libdialog-dev/1.3-20240307-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1027405: regina-rexx FTCBFS: builds for the build architecture

[Helmut Grohne]

Hi Agustin,

On Fri, Mar 29, 2024 at 01:29:04PM +0100, Agustin Martin wrote:
> All this seems needed just because CC is not exported by the build
> system . Adding export CC in the right place in debian/rules seems to
> make that uneeded.
> 
> With that changes I could cross compile i386 from my amd64 box.

Ok.

> However, there is another problem with other arches (e.g. arm64). Some
> binary files containing compiled error messages are built with a
> locally built program (msgcmp). Because of incompatible arches, it
> cannot be run and files cannot be built, and then, build fails when
> trying to install them (error is disabled during build). The first
> idea was to have a separate arch:all pakage with those messages, but
> it would not be arch:all because those messages binary files depend on
> arch endianness.

Does that mean that it vendors a gettext rather than using the system
gettext? There is a msgcmp in the gettext package and it is Multi-Arch:
foreign. If this is something different from gettext, you should likely
use CC_FOR_BUILD as set by dpkg's buildtools.mk for compiling msgcmp.c.
I don't think it is installed into any binary package so there likely is
no need to compile it twice in a cross build.

> I would like to close this bug report with above changes, even if a
> more specific bug report is open afterwards for the remaining stuff.

Yes, please close this bug with your next upload adressing substantial
aspects of a cross build even if not all issues are fixed. On my side,
this bug is a marker that makes me skip looking into cross build
failures. Once you close it, I'll likely retry building it and file a
new patch.

Helmut

Bug#1067904: $frontend-$version-for-host: versioned dependency too strict

[Helmut Grohne]

Source: gcc-14
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags rebootstrap

Hi Matthias,

thanks for merging my -for-host work. I'm looking into making practical
use of it and a major issue is the following dependency:

$FRONTEND-$VERSION-for-host:$DEB_HOST_ARCH -> 
$FRONTEND-$VERSION-$DEB_HOST_GNU_TYPE (= ${gcc:Version})

While this works nicely for native compilers, trying to use the
-for-host package with a cross toolchain is doomed to fail, because it
always has different version. The equal constraint is too strict to make
practical use of these -for-host packages. I think we should change (=
${gcc:Version}) to (>= ${gcc:SoftVersion}) as is done elsewhere. Do you
agree?

I'm attaching the obvious patch.

Helmut
commit 843e8ae7602a0ec16c67d7064396fa2acd1182cd
Author: Helmut Grohne 
Date:   Fri Mar 22 09:35:04 2024 +0100

use gcc:SoftVersion for -for-host dependencies

diff --git a/debian/control.m4 b/debian/control.m4
index 4b6c61b8..61a4d3a8 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -804,7 +804,7 @@ Package: gcc`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gcc`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gcc`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   cpp`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU C compiler for the host architecture
@@ -929,7 +929,7 @@ Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
 Section: ifdef(`TARGET',`devel',`interpreters')
-Depends: BASEDEP, cpp`'PV`'${target:suffix} (= ${gcc:Version}), ${misc:Depends}
+Depends: BASEDEP, cpp`'PV`'${target:suffix} (>= ${gcc:SoftVersion}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU C preprocessor for the host architecture
  A macro processor that is used automatically by the GNU C compiler
@@ -1019,7 +1019,7 @@ Package: g++`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, g++`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, g++`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU C++ compiler for the host architecture
@@ -2522,7 +2522,7 @@ Package: gobjc++`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gobjc++`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gobjc++`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gobjc`'PV`'-for-host (= ${gcc:Version}), g++`'PV`'-for-host (= ${gcc:Version}),
   ${misc:Depends}
 BUILT_USING`'dnl
@@ -2599,7 +2599,7 @@ Package: gobjc`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gobjc`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gobjc`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gobjc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU Objective-C compiler for the host architecture
@@ -2844,7 +2844,7 @@ Package: gfortran`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gfortran`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gfortran`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU Fortran compiler for the host architecture
@@ -3111,7 +3111,7 @@ Package: gccgo`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gccgo`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gccgo`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU Go compiler for the host architecture
@@ -3821,7 +3821,7 @@ Package: gnat`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gnat`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gnat`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU Ada compiler for the host architecture
@@ -3981,7 +3981,7 @@ Package: gdc`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gdc`'PV`'${target:suffix} (= ${gcc:Version}),
+Depends: BASEDEP, gdc`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
   gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
 BUILT_USING`'dnl
 Description: GNU D compiler (version 2) for the host architecture
@@ -4268,7 +4268,7 @@ Package: gm2`'PV`'-for-host
 Architecture: ifdef(`TARGET',`TARGET',`any')
 TARGET_PACKAGE`'dnl
 Multi-Arch: same
-Depends: BASEDEP, gm2`'PV`'${target:suffix} (= ${gcc:

Bug#1067903: RM: fuse3/experimental -- RoQA; time64 transition reverted

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: fu...@packages.debian.org
Control: affects -1 + src:fuse3

Please remove fuse3 version 3.14.0-5.1~exp1 from experimental. It
prepares a time64 transition that is not needed and will not propagate
to unstable. The package causes /usr-merge issues and should not be
installed. Therefore, the best course of action is removing it.

Helmut

Bug#1067817: libfuse2: move library to /usr (DEP17 P1)

[Helmut Grohne]

Package: libfuse2t64
Version: 2.9.9-8.1
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: dep17m2 dep17p1
Control: affects -1 + libfuse2

Hi,

fuse2 is involved in the /usr-move (DEP17) in multiple ways. In this bug
report, I am staying away from binaries to avoid interference with the
statoverride matter #1060229. That still has to be dealt with
separately. Here, it is about moving the fuse library having become
non-trivial due to the time64 transition. Simply moving it would cause a
DEP17 P1 problem incurring file loss on upgrade. I'm attaching a patch
implementing the library move in a mitigated (P8 protective diversions)
way.

I've tested this patch with piuparts and manually tried triggering the
problem:
mmdebstrap trixie /dev/null --variant apt --include libfuse-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libfuse2t64_2.9.9-8.2_amd64.deb /l.deb" 
--customize-hook="upload libfuse-dev_2.9.9-8.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb && 
apt-get -y install /l.deb /d.deb && dpkg --verify"

Note that none of this patch, #1060229 and the time64 rename is
appropriate for bookworm-backports or earlier. All of them must be
reverted in case of performing a backport. Please contact me if a need
for backporting arises.

I also appreciate feedback to Chris' questions on #1060229 as that
enables us to produce the necessary patches.

Helmut
diff -Nru fuse-2.9.9/debian/changelog fuse-2.9.9/debian/changelog
--- fuse-2.9.9/debian/changelog 2024-02-29 23:24:20.0 +0100
+++ fuse-2.9.9/debian/changelog 2024-03-27 07:29:06.0 +0100
@@ -1,3 +1,11 @@
+fuse (2.9.9-8.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move fuse library to /usr and add DEP17 P1 M8 protective diversions.
+(Closes: #-1)
+
+ -- Helmut Grohne   Wed, 27 Mar 2024 07:29:06 +0100
+
 fuse (2.9.9-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fuse-2.9.9/debian/control fuse-2.9.9/debian/control
--- fuse-2.9.9/debian/control   2024-02-29 23:24:11.0 +0100
+++ fuse-2.9.9/debian/control   2024-03-27 07:29:06.0 +0100
@@ -29,7 +29,6 @@
 Package: libfuse2t64
 Provides: ${t64:Provides}
 Replaces: libfuse2
-Breaks: libfuse2 (<< ${source:Version})
 Section: libs
 Architecture: linux-any kfreebsd-any
 Multi-Arch: same
@@ -37,7 +36,7 @@
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
-Conflicts: fuse (<< ${binary:Version})
+Conflicts: fuse (<< ${binary:Version}), libfuse2 (<< ${source:Version})
 Suggests: fuse
 Description: Filesystem in Userspace (library)
  Filesystem in Userspace (FUSE) is a simple interface for userspace programs to
diff -Nru fuse-2.9.9/debian/libfuse2-udeb.install 
fuse-2.9.9/debian/libfuse2-udeb.install
--- fuse-2.9.9/debian/libfuse2-udeb.install 2014-06-20 08:23:50.0 
+0200
+++ fuse-2.9.9/debian/libfuse2-udeb.install 2024-03-27 07:21:56.0 
+0100
@@ -1 +1 @@
-usr/lib/*/*.so.*   lib
+usr/lib/*/*.so.*
diff -Nru fuse-2.9.9/debian/libfuse2t64.install 
fuse-2.9.9/debian/libfuse2t64.install
--- fuse-2.9.9/debian/libfuse2t64.install   2024-02-29 23:24:11.0 
+0100
+++ fuse-2.9.9/debian/libfuse2t64.install   2024-03-27 07:20:59.0 
+0100
@@ -1 +1 @@
-usr/lib/*/*.so.*   lib
+usr/lib/*/*.so.*
diff -Nru fuse-2.9.9/debian/libfuse2t64.postinst 
fuse-2.9.9/debian/libfuse2t64.postinst
--- fuse-2.9.9/debian/libfuse2t64.postinst  1970-01-01 01:00:00.0 
+0100
+++ fuse-2.9.9/debian/libfuse2t64.postinst  2024-03-27 07:28:59.0 
+0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = configure; then
+   # Remove DEP17 P1 M8 protective diversions
+   for f in libfuse.so.2 libfuse.so.2.9.9 libulockmgr.so.1 
libulockmgr.so.1.0.1; do
+   dpkg-divert --no-rename --package libfuse2t64 --divert 
"/lib/#DEB_HOST_MULTIARCH#/$f.usr-is-merged" --remove 
"/lib/#DEB_HOST_MULTIARCH#/$f"
+   done
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru fuse-2.9.9/debian/libfuse2t64.preinst 
fuse-2.9.9/debian/libfuse2t64.preinst
--- fuse-2.9.9/debian/libfuse2t64.preinst   1970-01-01 01:00:00.0 
+0100
+++ fuse-2.9.9/debian/libfuse2t64.preinst   2024-03-27 07:28:02.0 
+0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = upgrade || test "$1" = install; then
+   # Add DEP17 P1 M8 protective diversions
+   for f in libfuse.so.2 libfuse.so.2.9.9 libulockmgr.so.1 
libulockmgr.so.1.0.1; do
+   dpkg-divert --no-rename --package libfuse2t64 --divert 
"/lib/#DEB_HOST_MULTIARCH#/$f.usr-is-merged" --add 
"/lib/#DEB_HOST_MULTI

Bug#1067816: libfuse3-3t46: move library to /usr (DEP17)

[Helmut Grohne]

Package: libfuse3-3t64
Version: 3.14.0-5.1~exp1
Severity: important
Tags: patch
X-Debbugs-Cc: Lukas Märdian , vor...@debian.org
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 + libfuse3-3

Hi Laszlo and Lukas,

Lukas' time64 upload introduces a latent /usr-move problem. It's not a
problem just yet, because libfuse3-3 didn't move yet, but it makes
dh-sequence-movetousr unsafe. Hence, I'm attaching a patch to move the
library and mitigate the file loss. In this patch I am deliberately not
moving the binaries to avoid interference with #1060229.

I've tested the patch with piuparts and attempted manually triggering
the loss:
mmdebstrap trixie /dev/null --variant apt --include libfuse3-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libfuse3-3t64_3.14.0-5.1~exp2_amd64.deb 
/l.deb" --customize-hook="upload libfuse3-dev_3.14.0-5.1~exp2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb && 
apt-get -y install /l.deb /d.deb && dpkg --verify"

Note that the patch (and the time64 migration) must not be uploaded to
bookworm-backports. fuse3 has never been backported, so that likely
isn't a problem. If you are in need of backporting it, please get in
touch with me.

Lukas, can you include this patch in your unstable upload?

Helmut
diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog
--- fuse3-3.14.0/debian/changelog   2024-01-31 11:29:25.0 +0100
+++ fuse3-3.14.0/debian/changelog   2024-03-27 08:35:49.0 +0100
@@ -1,3 +1,10 @@
+fuse3 (3.14.0-5.1~exp2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move library to /usr and mitigate file loss (DEP17 P1 M8) (closes: #-1).
+
+ -- Helmut Grohne   Wed, 27 Mar 2024 08:35:49 +0100
+
 fuse3 (3.14.0-5.1~exp1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fuse3-3.14.0/debian/control fuse3-3.14.0/debian/control
--- fuse3-3.14.0/debian/control 2024-01-31 11:29:25.0 +0100
+++ fuse3-3.14.0/debian/control 2024-03-27 08:35:49.0 +0100
@@ -35,7 +35,7 @@
 Package: libfuse3-3t64
 Provides: ${t64:Provides}
 Replaces: libfuse3-3
-Breaks: libfuse3-3 (<< ${source:Version})
+Conflicts: libfuse3-3 (<< ${source:Version})
 Section: libs
 Architecture: linux-any kfreebsd-any
 Multi-Arch: same
diff -Nru fuse3-3.14.0/debian/libfuse3-3-udeb.install 
fuse3-3.14.0/debian/libfuse3-3-udeb.install
--- fuse3-3.14.0/debian/libfuse3-3-udeb.install 2014-06-20 08:23:50.0 
+0200
+++ fuse3-3.14.0/debian/libfuse3-3-udeb.install 2024-03-27 08:35:49.0 
+0100
@@ -1 +1 @@
-usr/lib/*/*.so.*   lib
+usr/lib/*/*.so.*
diff -Nru fuse3-3.14.0/debian/libfuse3-3t64.install 
fuse3-3.14.0/debian/libfuse3-3t64.install
--- fuse3-3.14.0/debian/libfuse3-3t64.install   2024-01-31 11:29:25.0 
+0100
+++ fuse3-3.14.0/debian/libfuse3-3t64.install   2024-03-27 08:35:40.0 
+0100
@@ -1 +1 @@
-usr/lib/*/*.so.*   lib
+usr/lib/*/*.so.*
diff -Nru fuse3-3.14.0/debian/libfuse3-3t64.postinst 
fuse3-3.14.0/debian/libfuse3-3t64.postinst
--- fuse3-3.14.0/debian/libfuse3-3t64.postinst  1970-01-01 01:00:00.0 
+0100
+++ fuse3-3.14.0/debian/libfuse3-3t64.postinst  2024-03-27 08:35:49.0 
+0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = configure; then
+   # Remove DEP17 P1 M8 protective diversions
+   for f in libfuse3.so.3 libfuse3.so.3.14.0; do
+   dpkg-divert --no-rename --package libfuse3-3t64 --divert 
"/lib/#DEB_HOST_MULTIARCH#/$f.usr-is-merged" --remove 
"/lib/#DEB_HOST_MULTIARCH#/$f"
+   done
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru fuse3-3.14.0/debian/libfuse3-3t64.preinst 
fuse3-3.14.0/debian/libfuse3-3t64.preinst
--- fuse3-3.14.0/debian/libfuse3-3t64.preinst   1970-01-01 01:00:00.0 
+0100
+++ fuse3-3.14.0/debian/libfuse3-3t64.preinst   2024-03-27 08:35:49.0 
+0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = upgrade || test "$1" = install; then
+   # Add DEP17 P1 M8 protective diversions
+   for f in libfuse3.so.3 libfuse3.so.3.14.0; do
+   dpkg-divert --no-rename --package libfuse3-3t64 --divert 
"/lib/#DEB_HOST_MULTIARCH#/$f.usr-is-merged" --add 
"/lib/#DEB_HOST_MULTIARCH#/$f"
+   done
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru fuse3-3.14.0/debian/rules fuse3-3.14.0/debian/rules
--- fuse3-3.14.0/debian/rules   2024-01-31 11:29:25.0 +0100
+++ fuse3-3.14.0/debian/rules   2024-03-27 08:35:49.0 +0100
@@ -41,14 +41,6 @@
 
dh_install
 
-   # adjusting /lib for multiarch
-   mkdir -p debian/libfuse3-3t64/lib/$(DEB_HOST_MULTIARC

Bug#1067790: nut: move files to /usr (DEP17) and partially revert time64

[Helmut Grohne]

Package: libnutclient2t64,libnutscan2t64,libupsclient6t64
Version: 2.8.1-3.1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 + libnutclient2 libnutscan2 libupsclient6

Hi,

a number of packages from src:nut install files in aliased locations. In
order to finalize the /usr-merge, we want to move all of them below /usr
as doing so removes the bad effects arising from aliasing.
Unfortunately, the time64 transition renamed libraries built from nut,
so we are triggering a file loss scenario (DEP17 P1) - exactly the thing
we want to avoid in future by moving them. To complete this transition
in trixie, we have to add a mitigation (protective diversion) and this
is why I am sending a patch.

Said diversion incurs non-trivial maintainer scripts that are best
avoided if possible. Therefore, I reviewed the time64 transition and
concluded that the ABI of libnutscan did not change. I therefore propose
reverting the time64 transition for libnutscan only. The other two
libraries do change ABI and need to be renamed. In reverting libnutscan,
we also eliminate the need to mitigate the file loss. I have set the
severity of this bug to serious to prevent libnutscan2t64 from
transitioning to trixie. The time64 transition should either be reverted
before it transitions to trixie or not at all. If you think that it
should not be reverted, please lower the severity of this bug and I'll
send an updated patch. I note that having fewer library renames makes
the bookworm -> trixie upgrade easier, so reverting (when correct)
generally is a good thing (and it also reduces maintainer script
complexity).

I have tested this patch using piuparts. This happens to fail, because
some fontconfig files below /etc are not properly removed. I believe
this failure is unrelated to my change. I also tested for the particular
file loss scenario specifically.

mmdebstrap trixie /dev/null --variant=apt --include libnutclient-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libnutclient2t64_2.8.1-3.2_amd64.deb /l.deb" 
--customize-hook="upload libnutclient-dev_2.8.1-3.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb; 
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"
mmdebstrap trixie /dev/null --variant=apt --include libupsclient-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libupsclient6t64_2.8.1-3.2_amd64.deb /l.deb" 
--customize-hook="upload libupsclient-dev_2.8.1-3.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb; 
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"

Last but not least, this patch must not be uploaded to
bookworm-backports or earlier as it would violate the file move
moratorium there. If you plan to backport nut, you must revert both the
time64 transition and this patch.

Helmut
diff -Nru nut-2.8.1/debian/changelog nut-2.8.1/debian/changelog
--- nut-2.8.1/debian/changelog  2024-02-29 02:26:20.0 +0100
+++ nut-2.8.1/debian/changelog  2024-03-26 14:40:41.0 +0100
@@ -1,3 +1,11 @@
+nut (2.8.1-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert unnecessary time64 transition for libnutscan.
+  * Move files to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 14:40:41 +0100
+
 nut (2.8.1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nut-2.8.1/debian/control nut-2.8.1/debian/control
--- nut-2.8.1/debian/control2024-02-29 02:26:20.0 +0100
+++ nut-2.8.1/debian/control2024-03-26 14:40:41.0 +0100
@@ -203,7 +203,7 @@
 Package: libupsclient6t64
 Provides: ${t64:Provides}
 Replaces: libupsclient6
-Breaks: libupsclient6 (<< ${source:Version})
+Conflicts: libupsclient6 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -238,7 +238,7 @@
 Package: libnutclient2t64
 Provides: ${t64:Provides}
 Replaces: libnutclient2
-Breaks: libnutclient2 (<< ${source:Version})
+Conflicts: libnutclient2 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -269,10 +269,10 @@
  .
  This package provides the development files for the new client library.
 
-Package: libnutscan2t64
-Provides: ${t64:Provides}
-Replaces: libnutscan2
-Breaks: libnutscan2 (<< ${source:Version})
+Package: libnutscan2
+Provides: libnutscan2t64 (= ${binary:Version})
+Replaces: libnutscan2t64
+Breaks: libnutscan2t64 (<< ${source:Version})
 Section: libs
 Archi

Bug#1067776: openrc: move files to /usr (DEP17) and revert unnecessary time64 transition

[Helmut Grohne]

Package: openrc,libeinfo1,libeinfo1t64,librc1t64
Version: 0.53-1.1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 librc1

Hi,

I am sending you a patch for moving files to /usr for DEP17, because
doing so requires mitigations due to time64 having renamed libraries. In
particular, I verified that libeinfo did not actually break ABI.
Therefore, I am proposing to revert the time64 transition for libeinfo.
As a consequence of the reversion, we need fewer /usr-move mitigations.
We still need the mitigation for librc though. I have set the severity
of this bug to serious to prevent libeinfo1t64 from migrating to trixie.
It should either be reverted before migration or it should not be
reverted. If you disagree with the reversion, please lower the severity
of this bug and I'll send a patch that extends the mitigation to
libeinfo. That said, fewer library renames make upgrades less painful.

I've tested the patch using piuparts and with a manual test case
precisely triggering the DEP17 P1 file loss scenario:

mmdebstrap trixie /dev/null --variant=apt --include librc-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload librc1t64_0.53-1.2_amd64.deb /l.deb" 
--customize-hook="upload librc-dev_0.53-1.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb; 
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"

Do note that this patch must not be backported to bookworm-backports or
earlier. If you intend to backport, you must revert both this patch and
the time64 transition for your backport.

I recommend uploading this sooner rather than later, because the
reversion helps people who have not yet upgraded libeinfo to unstable.

Helmut
diff -Nru openrc-0.53/debian/changelog openrc-0.53/debian/changelog
--- openrc-0.53/debian/changelog2024-02-29 13:48:11.0 +0100
+++ openrc-0.53/debian/changelog2024-03-26 15:56:35.0 +0100
@@ -1,3 +1,11 @@
+openrc (0.53-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert unnecessary time64 transition for libeinfo
+  * Move files to /usr and mitigate file loss (DEP17) (Closes: #-1).
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 15:56:35 +0100
+
 openrc (0.53-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru openrc-0.53/debian/control openrc-0.53/debian/control
--- openrc-0.53/debian/control  2024-02-29 13:48:11.0 +0100
+++ openrc-0.53/debian/control  2024-03-26 15:56:35.0 +0100
@@ -47,7 +47,7 @@
 Package: librc1t64
 Provides: ${t64:Provides}
 Replaces: librc1
-Breaks: librc1 (<< ${source:Version})
+Conflicts: librc1 (<< ${source:Version})
 Architecture: any
 Section: libs
 Depends: ${misc:Depends},
@@ -84,10 +84,10 @@
  .
  This package provides development files for the runtime library.
 
-Package: libeinfo1t64
-Provides: ${t64:Provides}
-Replaces: libeinfo1
-Breaks: libeinfo1 (<< ${source:Version})
+Package: libeinfo1
+Provides: libeinfo1t64
+Replaces: libeinfo1t64
+Breaks: libeinfo1t64 (<< ${source:Version})
 Architecture: any
 Section: libs
 Depends: ${misc:Depends},
@@ -110,7 +110,7 @@
 Package: libeinfo-dev
 Architecture: any
 Section: libdevel
-Depends: libeinfo1t64 (=${binary:Version}),
+Depends: libeinfo1 (=${binary:Version}),
  ${misc:Depends},
 Multi-Arch: same
 Description: dependency based service manager (pretty console display 
development)
diff -Nru openrc-0.53/debian/libeinfo-dev.links 
openrc-0.53/debian/libeinfo-dev.links
--- openrc-0.53/debian/libeinfo-dev.links   2024-01-22 18:18:38.0 
+0100
+++ openrc-0.53/debian/libeinfo-dev.links   2024-03-26 15:56:35.0 
+0100
@@ -1,3 +1,3 @@
 #! /usr/bin/dh-exec
 
-lib/${DEB_HOST_MULTIARCH}/libeinfo.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so
+usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so
diff -Nru openrc-0.53/debian/libeinfo1.install 
openrc-0.53/debian/libeinfo1.install
--- openrc-0.53/debian/libeinfo1.install1970-01-01 01:00:00.0 
+0100
+++ openrc-0.53/debian/libeinfo1.install2024-03-26 15:56:35.0 
+0100
@@ -0,0 +1 @@
+usr/lib/*/libeinfo.so.*
diff -Nru openrc-0.53/debian/libeinfo1t64.install 
openrc-0.53/debian/libeinfo1t64.install
--- openrc-0.53/debian/libeinfo1t64.install 2024-01-22 18:18:38.0 
+0100
+++ openrc-0.53/debian/libeinfo1t64.install 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-lib/*/libeinfo.so.*
diff -Nru openrc-0.53/debian/libeinfo1t64.lintian-overrides 
openrc-0.53/debian/libeinfo1t64.lintian-overrides
--- openrc-0.53/debian/libeinfo1t64.lintian-overrides   2024-02-29 
13:48:06.0 +0100
+++ openrc-0.53/debian/libeinfo1t64.lintian-overrides   1970-01-01 

Bug#1067772: parted: move files to /usr for DEP17

[Helmut Grohne]

Package: parted,libparted2t64,libparted-fs-resize0t64
Version: 3.6-3.1
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 + libparted2 libparted-fs-resize0

Hi Colin,

I'm sending you a /usr-move conversion patch for parted, because it is
one ofthe packages where the interference with the time64 transition is
causing a DEP17 P1 problem. This is not a problem just yet in unstable,
but enabling dh-sequence-movetousr without mitigation would render
parted rc-buggy. The attached patch includes both the conversion and the
mitigation. Please remember that if you want to backport parted to
bookworm-backports or earlier, you must revert both this patch and the
time64 transition.

I looked into whether the time64 transition was avoidable for either
library and concluded that it is necessary for both. I tested the patch
both with piuparts and with a custom upgrade test exercising the
particular /usr-move problem.

mmdebstrap trixie /dev/null --variant=apt --include libparted-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libparted2t64_3.6-3.2_amd64.deb /l1.deb" 
--customize-hook="upload libparted-fs-resize0t64_3.6-3.2_amd64.deb /l2.deb" 
--customize-hook="upload libparted-dev_3.6-3.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l1.deb /l2.deb 
/d.deb; apt-get -y install /l1.deb /l2.deb /d.deb" 
--chrooted-customize-hook="dpkg --verify"

Helmut
diff -Nru parted-3.6/debian/changelog parted-3.6/debian/changelog
--- parted-3.6/debian/changelog 2024-02-29 20:58:31.0 +0100
+++ parted-3.6/debian/changelog 2024-03-26 15:00:20.0 +0100
@@ -1,3 +1,10 @@
+parted (3.6-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr and mitigate loss (DEP17) (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 15:00:20 +0100
+
 parted (3.6-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru parted-3.6/debian/control parted-3.6/debian/control
--- parted-3.6/debian/control   2024-02-29 20:58:31.0 +0100
+++ parted-3.6/debian/control   2024-03-26 15:00:14.0 +0100
@@ -62,7 +62,7 @@
 
 Package: libparted2t64
 Replaces: libparted2
-Breaks: libparted2 (<< ${source:Version})
+Conflicts: libparted2 (<< ${source:Version})
 Architecture: any
 Section: libs
 Pre-Depends: ${misc:Pre-Depends}
@@ -81,7 +81,7 @@
 Package: libparted-fs-resize0t64
 Provides: ${t64:Provides}
 Replaces: libparted-fs-resize0
-Breaks: libparted-fs-resize0 (<< ${source:Version})
+Conflicts: libparted-fs-resize0 (<< ${source:Version})
 Architecture: any
 Section: libs
 Pre-Depends: ${misc:Pre-Depends}
diff -Nru parted-3.6/debian/libparted-dev.links 
parted-3.6/debian/libparted-dev.links
--- parted-3.6/debian/libparted-dev.links   2023-06-27 00:34:57.0 
+0200
+++ parted-3.6/debian/libparted-dev.links   2024-03-26 15:00:20.0 
+0100
@@ -1,2 +1,2 @@
-lib/${DEB_HOST_MULTIARCH}/libparted.so.2 
usr/lib/${DEB_HOST_MULTIARCH}/libparted.so
-lib/${DEB_HOST_MULTIARCH}/libparted-fs-resize.so.0 
usr/lib/${DEB_HOST_MULTIARCH}/libparted-fs-resize.so
+usr/lib/${DEB_HOST_MULTIARCH}/libparted.so.2 
usr/lib/${DEB_HOST_MULTIARCH}/libparted.so
+usr/lib/${DEB_HOST_MULTIARCH}/libparted-fs-resize.so.0 
usr/lib/${DEB_HOST_MULTIARCH}/libparted-fs-resize.so
diff -Nru parted-3.6/debian/libparted-fs-resize0-udeb.install 
parted-3.6/debian/libparted-fs-resize0-udeb.install
--- parted-3.6/debian/libparted-fs-resize0-udeb.install 2023-06-27 
00:34:57.0 +0200
+++ parted-3.6/debian/libparted-fs-resize0-udeb.install 2024-03-26 
15:00:20.0 +0100
@@ -1 +1 @@
-lib/libparted-fs-resize.so.*
+usr/lib/libparted-fs-resize.so.*
diff -Nru parted-3.6/debian/libparted-fs-resize0t64.install 
parted-3.6/debian/libparted-fs-resize0t64.install
--- parted-3.6/debian/libparted-fs-resize0t64.install   2023-06-27 
00:34:57.0 +0200
+++ parted-3.6/debian/libparted-fs-resize0t64.install   2024-03-26 
15:00:20.0 +0100
@@ -1 +1 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libparted-fs-resize.so.* 
lib/${DEB_HOST_MULTIARCH}
+usr/lib/${DEB_HOST_MULTIARCH}/libparted-fs-resize.so.*
diff -Nru parted-3.6/debian/libparted-fs-resize0t64.postinst 
parted-3.6/debian/libparted-fs-resize0t64.postinst
--- parted-3.6/debian/libparted-fs-resize0t64.postinst  1970-01-01 
01:00:00.0 +0100
+++ parted-3.6/debian/libparted-fs-resize0t64.postinst  2024-03-26 
15:00:20.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = configure; then
+   for f in libparted-fs-resize.so.0 libparted-fs-resize.so.0.0.5; do
+   dpkg-divert --no-rename --package libparted-fs-resize0t64 
--divert "/lib/#DEB_HOST_MULTIARCH#/$f.usr-is

Bug#1059415: ntfs-3g: install files into /usr (instead of /)

[Helmut Grohne]

user helm...@debian.org
usertags 1059415 + dep17p1
reassign 1059415 ntfs-3,libntfs-3g89t64
found 1059415 1:2022.10.3-1.2
affects 1059415 libntfs-3g89
severity 1059415 important
thanks


On Sun, Dec 24, 2023 at 10:13:46PM +0100, Chris Hofstaedtler wrote:
> Your package installs files into /. For the ongoing Debian UsrMerge
> effort [1] these files should move to /usr in the trixie cycle.

This still applies.

> I'm attaching a patch to implement such a move. It is quite
> involved, but mostly undoes the move /usr -> /. The upstream
> Makefiles ignore --exec-prefix/rootsbindir for the mount.* symlinks,
> so I've chosen to re-create them using dh_link instead.
> 
> However, please still read the wiki page on moving files, especially
> if you intend to backport to bookworm or earlier. The patch has
> already been checked by a local dumat copy.

This patch should no longer be applied, because

> If during the trixie cycle your package will undergo structural
> changes or any other file moves, please also see the wiki and upload
> to experimental first when these changes are done.

time64 incurred structural changes. I'm attaching an updated patch that
mitigates these structural changes.

I've tested the patch using piuparts and using a manual upgrade test
via:

mmdebstrap trixie /dev/null --variant=apt --include ntfs-3g 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libntfs-3g89t64_2022.10.3-1.3_amd64.deb 
/l.deb" --customize-hook="upload ntfs-3g_2022.10.3-1.3_amd64.deb /d.deb" 
--chrooted-customize-hook="apt-get -y install libgnutls30t64; dpkg 
--auto-deconfigure --unpack /l.deb /d.deb; apt-get -y install /l.deb /d.deb" 
--chrooted-customize-hook="dpkg --verify"

Helmut
diff -Nru ntfs-3g-2022.10.3/debian/changelog ntfs-3g-2022.10.3/debian/changelog
--- ntfs-3g-2022.10.3/debian/changelog  2024-03-14 13:21:45.0 +0100
+++ ntfs-3g-2022.10.3/debian/changelog  2024-03-26 11:16:22.0 +0100
@@ -1,3 +1,12 @@
+ntfs-3g (1:2022.10.3-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Helmut Grohne and Chris Hofstaedtler ]
+  * Move files to /usr and mitigate file loss. (Closes: #1059415, #945923)
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 11:16:22 +0100
+
 ntfs-3g (1:2022.10.3-1.2) unstable; urgency=medium
 
   [ Zixing Liu ]
diff -Nru ntfs-3g-2022.10.3/debian/control ntfs-3g-2022.10.3/debian/control
--- ntfs-3g-2022.10.3/debian/control2024-03-01 13:40:21.0 +0100
+++ ntfs-3g-2022.10.3/debian/control2024-03-26 11:16:22.0 +0100
@@ -45,7 +45,7 @@
 Package: libntfs-3g89t64
 Provides: ${t64:Provides}
 Replaces: libntfs-3g89
-Breaks: libntfs-3g89 (<< ${source:Version})
+Conflicts: libntfs-3g89 (<< ${source:Version})
 Section: libs
 Architecture: linux-any kfreebsd-any
 Multi-Arch: same
diff -Nru ntfs-3g-2022.10.3/debian/libntfs-3g89t64.install 
ntfs-3g-2022.10.3/debian/libntfs-3g89t64.install
--- ntfs-3g-2022.10.3/debian/libntfs-3g89t64.install2015-10-24 
09:41:03.0 +0200
+++ ntfs-3g-2022.10.3/debian/libntfs-3g89t64.install2024-03-26 
11:16:22.0 +0100
@@ -1 +1 @@
-lib/*/*.so.*
+usr/lib/*/*.so.*
diff -Nru ntfs-3g-2022.10.3/debian/libntfs-3g89t64.lintian-overrides 
ntfs-3g-2022.10.3/debian/libntfs-3g89t64.lintian-overrides
--- ntfs-3g-2022.10.3/debian/libntfs-3g89t64.lintian-overrides  2024-03-01 
13:40:18.0 +0100
+++ ntfs-3g-2022.10.3/debian/libntfs-3g89t64.lintian-overrides  2024-03-26 
11:16:22.0 +0100
@@ -1 +1,5 @@
 libntfs-3g89t64: package-name-doesnt-match-sonames libntfs-3g89
+# begin-remove-after: released:trixie
+# DEP17 mitigation
+orphaned-diversion lib/x86_64-linux-gnu/*
+# end-remove-after
diff -Nru ntfs-3g-2022.10.3/debian/libntfs-3g89t64.postinst 
ntfs-3g-2022.10.3/debian/libntfs-3g89t64.postinst
--- ntfs-3g-2022.10.3/debian/libntfs-3g89t64.postinst   1970-01-01 
01:00:00.0 +0100
+++ ntfs-3g-2022.10.3/debian/libntfs-3g89t64.postinst   2024-03-26 
11:16:22.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = configure; then
+   for f in libntfs-3g.so.89 libntfs-3g.so.89.0.0; do
+   dpkg-divert --no-rename --package libntfs-3g89t64 --divert 
"/lib/#DEB_HOST_MULTIARCH#/$f.usr-is-merged" --remove 
"/lib/#DEB_HOST_MULTIARCH#/$f"
+   done
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru ntfs-3g-2022.10.3/debian/libntfs-3g89t64.preinst 
ntfs-3g-2022.10.3/debian/libntfs-3g89t64.preinst
--- ntfs-3g-2022.10.3/debian/libntfs-3g89t64.preinst1970-01-01 
01:00:00.0 +0100
+++ ntfs-3g-2022.10.3/debian/libntfs-3g89t64.preinst2024-03-26 
11:16:22.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test &qu

Bug#1063664: gcc-13-cross: file conflicts between gnat-13- and gnat-{9,10}-

[Helmut Grohne]

user debian...@lists.debian.org
usertags 1063664 + fileconflict
reassign 1063664 
gnat-13-aarch64-linux-gnu,gnat-13-arm-linux-gnueabihf,gnat-13-i686-linux-gnu,gnat-13-powerpc64le-linux-gnu,gnat-13-riscv64-linux-gnu,gnat-13-s390x-linux-gnu
found 1063664 10.5.0-1cross2
affects 1063664 + gnat-10-aarch64-linux-gnu gnat-10-arm-linux-gnueabihf 
gnat-10-i686-linux-gnu gnat-10-powerpc64le-linux-gnu gnat-10-riscv64-linux-gnu 
gnat-10-s390x-linux-gnu gnat-11-aarch64-linux-gnu gnat-11-arm-linux-gnueabihf 
gnat-11-i686-linux-gnu gnat-11-powerpc64le-linux-gnu gnat-11-riscv64-linux-gnu 
gnat-11-s390x-linux-gnu gnat-12-aarch64-linux-gnu gnat-12-arm-linux-gnueabihf 
gnat-12-i686-linux-gnu gnat-12-powerpc64le-linux-gnu gnat-12-riscv64-linux-gnu 
gnat-12-s390x-linux-gnu gnat-9-aarch64-linux-gnu gnat-9-arm-linux-gnueabihf 
gnat-9-i686-linux-gnu gnat-9-powerpc64le-linux-gnu gnat-9-riscv64-linux-gnu 
gnat-9-s390x-linux-gnu
tags 1063664 + patch
thanks

On Sat, Feb 10, 2024 at 07:55:09PM +0100, Andreas Beckmann wrote:
> there are undeclared file conflicts between gnat-13- and
> gnat-{9,10}- in sid. (but not between -9- and -10-).
> Maybe it would be sufficient to rebuild the package against gcc-13
> 13.2.0-13 which had some gnat conflict fixes.

I confirm. Usually, the higher gnat version declares Conflicts for the
lower one. Starting with gcc-14, the unversioned link is no longer
provided and gnat is part of gcc-defaults, so this problem will go away
in future. I also verified that src:gcc-13 already issues these
Conflicts and that a no-change upload of gcc-13-cross adds these
Conflicts to the cross toolchain packages. Hence tagging the issue as
patch.

Matthias, would you do that upload?

Helmut

Bug#1058848: comedilib: use udev.pc to place udev rules

[Helmut Grohne]

reassign 1058848 libcomedi0t64
found 1058848 comedilib/0.11.0+5-1.1
user helm...@debian.org
usertags dep17p1
affects 1058848 + libcomedi0t64
severity 1058848 important
thanks

On Sun, Dec 17, 2023 at 01:07:40AM +0100, Chris Hofstaedtler wrote:
> your package installs files related to udev, into /lib. These
> files need to be moved to /usr/lib as part of Debian's usr-merge
> effort [1].

This still holds.

> Attached you will find a patch using udev.pc to place the udev files
> (using pkg-config). This works today in unstable and also for
> bookworm, and is safe to do now.
> Once udev.pc in unstable points to /usr/lib, your package will
> benefit automatically after a binNMU or any other upload.

The original patch is no longer applicable, because:

> If during the trixie cycle your package will undergo structural
> changes or any other file moves, please see the wiki and upload
> to experimental first when these changes are done.

time64 caused those structural changes mentioned above. Uploading the
original patch would now cause comedilib to become rc-buggy.

I'm attaching an updated patch that addresses the structural changes
introduced in time64. I've tested it with piuparts and manually:

mmdebstrap trixie /dev/null --include libcomedi-dev --customize-hook='echo "deb 
http://deb.debian.org/debian sid main" > "$1/etc/apt/sources.list.d/sid.list"' 
--chrooted-customize-hook="apt-get update" --customize-hook="upload 
libcomedi0t64_0.11.0+5-1.2_amd64.deb /l.deb" --customize-hook="upload 
libcomedi-dev_0.11.0+5-1.2_amd64.deb /d.deb" --chrooted-customize-hook="dpkg 
--auto-deconfigure --unpack /l.deb /d.deb; dpkg -r libcomedi0; apt-get -y 
install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"

I also note that the earlier time64 upload failed to enabled
installation of lintian overrides. This is also rectified here.

Helmut
diff -Nru comedilib-0.11.0+5/debian/changelog 
comedilib-0.11.0+5/debian/changelog
--- comedilib-0.11.0+5/debian/changelog 2024-02-28 18:26:26.0 +0100
+++ comedilib-0.11.0+5/debian/changelog 2024-03-26 10:02:30.0 +0100
@@ -1,3 +1,10 @@
+comedilib (0.11.0+5-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr and mitigate loss (DEP17). (Closes: #1058848)
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 10:02:30 +0100
+
 comedilib (0.11.0+5-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru comedilib-0.11.0+5/debian/control comedilib-0.11.0+5/debian/control
--- comedilib-0.11.0+5/debian/control   2024-02-28 18:26:26.0 +0100
+++ comedilib-0.11.0+5/debian/control   2024-03-26 10:02:30.0 +0100
@@ -40,7 +40,7 @@
 Package: libcomedi0t64
 Provides: ${t64:Provides}
 Replaces: libcomedi0
-Breaks: libcomedi0 (<< ${source:Version})
+Conflicts: libcomedi0 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, 
diff -Nru comedilib-0.11.0+5/debian/libcomedi0t64.install 
comedilib-0.11.0+5/debian/libcomedi0t64.install
--- comedilib-0.11.0+5/debian/libcomedi0t64.install 2020-07-25 
10:48:45.0 +0200
+++ comedilib-0.11.0+5/debian/libcomedi0t64.install 2024-03-26 
10:02:27.0 +0100
@@ -10,5 +10,5 @@
 usr/share/man/man8/*
 usr/share/doc/comedilib/*.conf usr/share/doc/libcomedi0/
 etc/pcmcia/*
-lib/udev/*
+usr/lib/udev/*
 
diff -Nru comedilib-0.11.0+5/debian/libcomedi0t64.lintian-overrides 
comedilib-0.11.0+5/debian/libcomedi0t64.lintian-overrides
--- comedilib-0.11.0+5/debian/libcomedi0t64.lintian-overrides   2024-02-28 
18:20:47.0 +0100
+++ comedilib-0.11.0+5/debian/libcomedi0t64.lintian-overrides   2024-03-26 
10:02:30.0 +0100
@@ -1 +1,5 @@
 libcomedi0t64: package-name-doesnt-match-sonames libcomedi0
+# begin-remove-after: released:trixie
+# DEP17P7 mitigation
+diversion-for-unknown-file lib/udev/rules.d/90-comedi.rules [*]
+# end-remove-after
diff -Nru comedilib-0.11.0+5/debian/libcomedi0t64.postinst 
comedilib-0.11.0+5/debian/libcomedi0t64.postinst
--- comedilib-0.11.0+5/debian/libcomedi0t64.postinst2020-07-25 
10:48:45.0 +0200
+++ comedilib-0.11.0+5/debian/libcomedi0t64.postinst2024-03-26 
10:02:30.0 +0100
@@ -4,6 +4,13 @@
 
 test $DEBIAN_SCRIPT_DEBUG && set -v -x
 
+# begin-remove-after: released:trixie
+if test "$1" = configure; then
+   dpkg-divert --no-rename --package libcomedi0t64 --divert 
/lib/udev/rules.d/90-comedi.rules.usr-is-merged --remove 
/lib/udev/rules.d/90-comedi.rules
+fi
+# end-remove-after
+
+
 case "$1" in
   configure|upgrade)
 
diff -Nru comedilib-0.11.0+5/debian/libcomedi0t64.preinst 
comedilib-0.11.0+5/debian/libcomedi0t64.preinst
--- comedilib-0.11.0+5/debian/libcomedi0t64.preinst 1970-01-01 
01:00:00.0 +0100
+++ comedilib-0.11.0+5/debian/libcomedi0t64.preinst 2024-03-26 
10:02:30.0 +0100
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+

Bug#1067741: RM: libselinux1t64/experimental -- RoQA; time64 transition reverted

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove the package libselinux1t64 from experimental. You may
remove the entire source package libselinux/3.5-2.1~exp1. This
corresponds to a time64 transition that will not be uploaded to
unstable, because it would break dpkg. Installing it on any kind of
system or chroot causes difficult to repair harm.

Helmut

Bug#1067740: RM: kylin-process-manager/experimental -- RoQA; superseeded by unstable; undeclared file conflict

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove src:kylin-process-manager and its binary package from
experimental. The version is superseeded in unstable and upgrading from
experimental to unstable causes an undeclared file conflict (#1063399).
Fixing this bug is probably not worth the effort due to the small amount
of users using experimental packages. Rather let us prevent more people
from being affected by removing the outdated package and call it a day.

Helmut

Bug#1057800: libapogee3: let dh_installudev pick location of udev rules

[Helmut Grohne]

reassign 1057800 libapogee3t64
found 1057800 libapogee3/3.2+20221221183454-1.1
user helm...@debian.org
usertags 1057800 + dep17p1
affects 1057800 + libapogee3
severity 1057800 important
thanks

Hi,

On Fri, Dec 08, 2023 at 05:35:01PM +0100, Chris Hofstaedtler wrote:
> your package installs files related to udev, into /lib. These
> files need to be moved to /usr/lib as part of Debian's usr-merge
> effort [1].
> 
> Attached you will find a patch to use dh_installudev to install
> the udev rule. When dh_installudev gets changed in unstable, your
> package will benefit via a binNMU or the next normal upload.

Due to time64, a latent DEP17 P1 problem has been introduced. It does
not affect the version in unstable yet, because Chris patch has not been
applied yet. Applying it would now make libapogee3t64 rc-buggy.

Hence, I am attaching an updated patch that adds a mitigation. Unlike
the earlier patch, my patch must not be included in an upload to
bookworm-backports or earlier. If you plan to backport libapogee, you
must revert both time64 and this patch.

I've successfully tested the patch both with piuparts and with a
manually crafted upgrade:

mmdebstrap trixie /dev/null --include libapogee-dev --customize-hook='echo "deb 
http://deb.debian.org/debian sid main" > "$1/etc/apt/sources.list.d/sid.list"' 
--chrooted-customize-hook="apt-get update" --customize-hook="upload 
libapogee3t64_3.2+20221221183454-1.2_amd64.deb /l.deb" --customize-hook="upload 
libapogee-dev_3.2+20221221183454-1.2_amd64.deb /d.deb" 
--chrooted-customize-hook="apt-get -y install libcurl3t64-gnutls; dpkg 
--auto-deconfigure --unpack /l.deb /d.deb; dpkg -r libapogee3; apt-get -y 
install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"

Helmut
diff -Nru libapogee3-3.2+20221221183454/debian/changelog 
libapogee3-3.2+20221221183454/debian/changelog
--- libapogee3-3.2+20221221183454/debian/changelog  2024-02-29 
09:39:11.0 +0100
+++ libapogee3-3.2+20221221183454/debian/changelog  2024-03-26 
09:21:56.0 +0100
@@ -1,3 +1,10 @@
+libapogee3 (3.2+20221221183454-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr and mitigate file loss. (Closes: #1057800)
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 09:21:56 +0100
+
 libapogee3 (3.2+20221221183454-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libapogee3-3.2+20221221183454/debian/control 
libapogee3-3.2+20221221183454/debian/control
--- libapogee3-3.2+20221221183454/debian/control2024-02-29 
09:39:11.0 +0100
+++ libapogee3-3.2+20221221183454/debian/control2024-03-26 
09:21:56.0 +0100
@@ -17,7 +17,7 @@
 Package: libapogee3t64
 Provides: ${t64:Provides}
 Replaces: libapogee3
-Breaks: libapogee3 (<< ${source:Version})
+Conflicts: libapogee3 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Apogee Library for camera control
diff -Nru libapogee3-3.2+20221221183454/debian/libapogee3t64.install 
libapogee3-3.2+20221221183454/debian/libapogee3t64.install
--- libapogee3-3.2+20221221183454/debian/libapogee3t64.install  2022-12-21 
19:34:59.0 +0100
+++ libapogee3-3.2+20221221183454/debian/libapogee3t64.install  2024-03-26 
09:12:28.0 +0100
@@ -1,4 +1,4 @@
 usr/lib/*/libapogee.so.3.2
 usr/lib/*/libapogee.so.3
 etc/Apogee/camera/*.txt
-lib/udev/rules.d/99-apogee.rules lib/udev/rules.d
+lib/udev/rules.d/99-apogee.rules usr/lib/udev/rules.d
diff -Nru libapogee3-3.2+20221221183454/debian/libapogee3t64.lintian-overrides 
libapogee3-3.2+20221221183454/debian/libapogee3t64.lintian-overrides
--- libapogee3-3.2+20221221183454/debian/libapogee3t64.lintian-overrides
2024-02-29 09:39:05.0 +0100
+++ libapogee3-3.2+20221221183454/debian/libapogee3t64.lintian-overrides
2024-03-26 09:21:47.0 +0100
@@ -1 +1,5 @@
 libapogee3t64: package-name-doesnt-match-sonames libapogee3
+# begin-remove-after: released:trixie
+# DEP17P7 mitigation
+diversion-for-unknown-file lib/udev/rules.d/99-apogee.rules [*]
+# end-remove-after
diff -Nru libapogee3-3.2+20221221183454/debian/libapogee3t64.postinst 
libapogee3-3.2+20221221183454/debian/libapogee3t64.postinst
--- libapogee3-3.2+20221221183454/debian/libapogee3t64.postinst 1970-01-01 
01:00:00.0 +0100
+++ libapogee3-3.2+20221221183454/debian/libapogee3t64.postinst 2024-03-26 
09:21:56.0 +0100
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if test "$1" = configure; then
+   dpkg-divert --no-rename --package libapogee3t64 --divert 
/lib/udev/rules.d/99-apogee.rules.usr-is-merged --remove 
/lib/udev/rules.d/99-apogee.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
+
diff -Nru libapogee3-3.2+20221221183454/debian/libapogee3t64.preinst 
libapogee3-3.2+20221221183454/debian/libapogee3t64.preinst
--- libapogee3-3.2+202212

Bug#1067737: RM: libsbig4t64/experimental -- time64 transition not needed

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hi ftp team,

originally a time64 transition was planned for libsbig, but this turned
out to not be needed due to improved analysis. Still libsbig4t64 has
been uploaded to experimental. It now causes /usr-merge diagnostics in
dumat. Please remove the upload from experimental to both prevent people
from using the package and to remove the unneessary diagnostics.

Thanks in advance

Helmut

Bug#1067736: RM: libss2t64,libcom-err2t64 -- RoQA; time64 transition reverted

[Helmut Grohne]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hi ftp master,

I reverted the time64 transition for libss2t64 and libcom-err2t64, but
not for libext2fs2t64. As a consequence, apt has difficulties deciding
whether it should be using libss2 or libss2t64 and libcom-err2 or
libcom-err2t64. Please remove these two binary packages from unstable to
ease upgrading and installing packages. The non-t64 package now provides
the t64 ones, so this removal should not result in any unsatisfiable
dependencies (not even on 32bit archs, because ABI did not actually
change).

Helmut

Bug#1056192: slirp4netns: allow reusing an existing tap file descriptor

[Helmut Grohne]

Control: forwarded -1 
https://github.com/rootless-containers/slirp4netns/pull/340

On Sat, Nov 18, 2023 at 05:26:57PM +0100, Helmut Grohne wrote:
> Since patches speak louder than words, I am attaching a demo patch of
> how this is supposed to work. What do you think about it?

In the mean time, I've sent the patch upstream.

Helmut

Bug#1067710: libmtp FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: libmtp
Version: 1.1.21-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libmtp fails to cross build from source, because it configures for the
build architecture and thus fails finding required dependencies. It
actually configures twice. While the second time - issued by debhelper -
would configure for the host architecture, it is the first attempt
during autogen.sh that is both unnecessary and failing. Skipping it
makes the native build faster and the cross build succeed. I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru libmtp-1.1.21/debian/changelog 
libmtp-1.1.21/debian/changelog
--- libmtp-1.1.21/debian/changelog  2024-02-28 15:18:19.0 +0100
+++ libmtp-1.1.21/debian/changelog  2024-03-25 07:43:18.0 +0100
@@ -1,3 +1,10 @@
+libmtp (1.1.21-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Configure only once for the host architecture. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 25 Mar 2024 07:43:18 +0100
+
 libmtp (1.1.21-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru libmtp-1.1.21/debian/rules libmtp-1.1.21/debian/rules
--- libmtp-1.1.21/debian/rules  2024-02-28 15:18:18.0 +0100
+++ libmtp-1.1.21/debian/rules  2024-03-25 07:43:17.0 +0100
@@ -32,7 +32,7 @@
dh $@
 
 execute_before_dh_autoreconf:
-   ./autogen.sh
+   NOCONFIGURE=1 ./autogen.sh
 
 override_dh_auto_configure:
# Save file modified by configure

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian,

On Wed, Mar 06, 2024 at 07:52:09AM +0100, Bastian Blank wrote:
> On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > The problem arises in the reverse sense. If a file does not exist in
> > one, it is searched in the second and erroneously may be found. That may
> > make tests pass that should not pass and typically causes a link failure
> > later.
> 
> But you want /usr/include to be found.  Otherwise you would not be able
> to use most of the libraries for cross compiling.

This is a two-sided sword. When you want to use libraries, you don't get
around to using /usr/include, but as you use it your configure checks
become unreliable. You check for a header and it happens to exist there,
but the library is installed for a different architecture and you cannot
actually use it. For cross compilation (and for building cross
toolchains), it would actually be better if /usr/include were only
hosting header-only libraries and all other libraries were moved to
/usr/include/ to avoid such misdetections. This is particularly
the case for the cross toolchain build where such misdetections
historically have been a problem and LIMITS_H_TEST is still broken
today.

> >  . While I do not have a concrete example at hand, I have seen this
> > pattern repeatedly and generally favour moving stuff out of /usr/include
> > to avoid this kind of confusion that causes difficult to debug problems.
> > This also motivates #798955 (in addition to the problem with file
> > conflicts).
> 
> In this case here, this would just find kernel headers for a different
> version.  Those are essentially a headers only library, nothing is
> available for linking.  And all the headers provided in /usr/include are
> the same for all architectures.

As much as I'd like to see kernel headers as architecture-independent,
they really are not. When building a cross toolchain for say hurd, we
really want linux headers to not be found despite requiring
linux-libc-dev to be installed for the build architecture.

> So moving stuff out of /usr/include might be a good idea if the -dev
> package is itself arch dependent.

linux-libc-dev is architecture-dependent. Its annotation of being
Multi-Arch: foreign is a technical lie, that happens make a number of
things easier, but at the same time it breaks the dependency system by
claiming e.g.  linux-libc-dev:hurd-i386 to be a satisfiable dependency
while factually using it that way is broken and doesn't work.  It's not
only that, it also claims to satisfy linux-libc-dev:avr32 and doesn't
provide that functionality either.

That said, having this abstraction break in these corner cases may be a
reasonable compromise due to the benefits it brings in other areas.
Personally, I haven't reached a conclusion regarding this and accept
that you have. I note that libc6 being Multi-Arch: same also is a
technical lie (due to dynamic linker collisions), but a very useful one
in practice. Evidently, following the specification to the letter is not
always the right choice.

> Yep.  My problem is: I tested stuff, not everything of course, and did
> not see any breakage.  Also I checked the values I know could influence
> that and they say it is fine.  So at some point I have to assume it is
> not broken, as exhaustive search is simply not possible.

I locally reproduced the failure to build a cross toolchain and tell you
that something is broken right now. That something is fixable with the
7-line patch to gcc's debian/rules2 I sent yesterday. We don't have to
argue whether there is a known problem. We rightfully argue whether it
needs to be fixed in linux-libc-dev though.

> The only statement in this bug report is now: it is located in a
> different location, so it is broken.  No single piece of evidence is
> shown, like broken builds or some other ways to see the brokeness.

Having thought about this a little more, I may be seeing another angle
of this. In effect, *-dev-*-cross as a package names comes with an
implied contract of installing its things to
/usr//{include,lib,...}. Your providing of these package names
(that I suggested you to do not realizing what that would entail) is
breaking this contract and maybe this is what Matthias is complaining
about. Changing such a contract usually involves declaring Breaks, but
you cannot declare them for a source package and it is not clear that
there is consensus on changing this contract.

Keep in mind, that I suggested providing these provides as a workaround
for the technical lie of Multi-Arch:foreign. We may still rename these
provides.

Maybe we can disarm the whole situation by changing these virtual
facilities as we change the contract? If linux-libc-dev were to drop the
"-cross" suffix (but not the "-$arch" suffix) on its provides, it would
no longer be breaking the implied *-dev-*-cross contract by not
followi

Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird

[Helmut Grohne]

Hi Holger,

On Fri, Mar 22, 2024 at 07:36:37PM +, Holger Levsen wrote:
> < h01ger> helmut: re:  #1041832: i just could not reproduce this bug, see
>   https://paste.debian.net/1311659/ - though we "didnt change
>   anything" in sequoia-octopus, so what am i missing? :)
> 
> that paste had basically this content:
> 
> ± dpkg -L libsequoia-octopus-librnp |grep librnp.so
> /usr/lib/sequoia/libsequoia_octopus_librnp.so
> /usr/lib/thunderbird/librnp.so
> ± dpkg -L thunderbird|grep librnp.so
> 1 ±

You're faced with a relatively early dumat-generated report and I see
how the lack of detail makes diagnosing this difficult. Later reports
have been improved to include the missing detail.

Let me paste the machine-readable report and explain it.

libsequoia-octopus-librnp:
  1.4.1-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
thunderbird:
  1:115.7.0-1~deb11u1: bullseye
  1:115.7.0-1~deb12u1: bookworm
  1:115.8.0-1~deb12u1: bookworm-proposed-updates
  1:115.9.0-1~deb11u1: bullseye-security
  1:115.9.0-1~deb12u1: bookworm-security
  1:122.0~b2-1: experimental
  what: undeclared file conflict
source: rust-sequoia-octopus-librnp
suites: experimental
  1.8.1-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
thunderbird:
  1:115.7.0-1~deb11u1: bullseye
  1:115.7.0-1~deb12u1: bookworm
  1:115.8.0-1~deb12u1: bookworm-proposed-updates
  1:115.9.0-1~deb11u1: bullseye-security
  1:115.9.0-1~deb12u1: bookworm-security
  1:122.0~b2-1: experimental
  what: undeclared file conflict
source: rust-sequoia-octopus-librnp
suites: unstable
thunderbird:
  1:122.0~b2-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
libsequoia-octopus-librnp:
  1.4.1-1: experimental
  1.8.1-1: unstable
  what: undeclared file conflict
suites: experimental

Specifically, you need a version of libsequoia-octopus-librnp from
unstable or experimental and combine it with a thunderbird version from
bullseye, bookworm or experimental. If we disregard experimental and
assume that libsequoia-octopus-librnp to trixe, apt could choose to
first install libsequoia-octopus-librnp in a bookworm to trixie upgrade
before upgrading thunderbird to drop the file.

So to reproduce this, I recommend using a bookworm system, install
thunderbird, add unstable to apt sources, install
libsequoia-octopus-librnp.

Helmut