Bug#1081951: kannel: FTBFS on 32 bit architectures where time is time64_t

[Guillem Jover]

Hi!

On Mon, 2024-09-16 at 21:12:51 +0200, Chris Hofstaedtler wrote:
> On Mon, Sep 16, 2024 at 04:01:06PM +0200, Gianfranco Costamagna wrote:
> > Hello, after the time64_t transition, kannel started FTBFS on armel, armhf 
> > and where time_t is 64 bit defined.
> 
> With my ex-kannel-maintainer hat on, I have to say that is
> unsurprising.
> 
> > I don't know how to patch it, and I don't know if changing that struct size 
> > is source of troubles (is this a struct sent over network?)
> 
> Best case you'd have to introduce a new TIME_T macro and what not.
> Maybe best to just remove the old binaries on arm{el,hf} and
> whenever a porter comes along, they can fix it.

I started looking into this yesterday, and went with something along this
suggestion, but then while adding 64-bit versions of dumping and
parsing functions I've realized that I don't think even 64-bit arches
are time64 safe, as the time is serialized into 4-bytes. :/

I'll continue this next Monday, hopefully with a full fix (ideally
even for 64-bit arches). But I need how and whether it is possible at
all to modify the serialized data, because I'm not sure that's part of
a standard on-wire protocol or similar.

Thanks,
Guillem

Bug#1077904: ledmon FTBFS on 32-bit with gcc 14

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sun, 2024-08-04 at 12:24:24 +0300, Adrian Bunk wrote:
> Source: ledmon
> Version: 0.97-1.1
> Severity: serious
> Tags: ftbfs

> https://buildd.debian.org/status/logs.php?pkg=ledmon&ver=0.97-1.1
> 
> ...
> utils.c: In function ‘get_uint64’:
> utils.c:105:18: error: passing argument 1 of ‘str_toul’ from incompatible 
> pointer type [-Wincompatible-pointer-types]
>   105 | str_toul(&defval, p, NULL, 16);
>   |  ^~~
>   |  |
>   |  uint64_t * {aka long long unsigned int *}
> In file included from utils.c:48:
> utils.h:368:29: note: expected ‘long unsigned int *’ but argument is of type 
> ‘uint64_t *’ {aka ‘long long unsigned int *’}
>   368 | int str_toul(unsigned long *dest, const char *strptr, char **endptr, 
> int base);
>   |  ~~~^~~~
> ...

The attached patch, adapted from an upstream commit, should fix this issue
on 32-bit arches (tested on an i386 chroot). Personally I'm not very fond
of the "unsigned" strtou*() functions, but given that upstream went this
way, this seems like the less intrusive path.

Thanks,
Guillem
From ed747ac3540cb38797f56533f9f51f5627e6b994 Mon Sep 17 00:00:00 2001
From: Tony Asleson 
Date: Wed, 21 Aug 2024 12:27:28 -0500
Subject: [PATCH] Correct get_uint64

For large integer values, the existing implementation will be
incorrect.

The current implementation of converting strings to integer values
uses a signed integer for the intermediate conversion and performs
a range check. Since any value in an unsigned 64-bit integer is valid,
the range check seems unnecessary. To mimic the same code path, we would
need a larger integer type.

Signed-off-by: Tony Asleson 
Origin: upstream, commit:ed747ac3540cb38797f56533f9f51f5627e6b994
Applied-Upstream: 1.0.0+
Bug-Debian: https://bugs.debian.org/1077904
Forwarded: not-needed
Last-Update: 2024-09-16
---
 src/utils.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/src/utils.c
+++ b/src/utils.c
@@ -102,9 +102,13 @@ uint64_t get_uint64(const char *path, ui
 	if (!p)
 		return defval;
 
-	str_toul(&defval, p, NULL, 16);
+	errno = 0;
+	uint64_t t = strtoull(p, NULL, 16);
 	free(p);
-	return defval;
+
+	if (errno)
+		return defval;
+	return t;
 }
 
 int get_int(const char *path, int defval, const char *name)

Bug#1074954: ffproxy: ftbfs with GCC-14

[Guillem Jover]

Control: tag -1 patch

Hi

On Wed, 2024-07-03 at 12:26:27 +, Matthias Klose wrote:
> Package: src:ffproxy
> Version: 1.6-12
> Severity: important
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-14

> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.

> [...]
> gcc -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -DCFGFILE="\"/etc/ffproxy/ffproxy.conf\"" -DDATADIR="\"/usr/share/ffproxy\""  
> -Wdate-time -D_FORTIFY_SOURCE=2  -c -o msg.o msg.c
> msg.c: In function ‘err_msg’:
> msg.c:49:19: error: assignment to ‘char *’ from incompatible pointer type 
> ‘struct msg *’ [-Wincompatible-pointer-types]
>49 | p = e_inv;
>   |   ^
> msg.c:52:19: error: assignment to ‘char *’ from incompatible pointer type 
> ‘struct msg *’ [-Wincompatible-pointer-types]
>52 | p = e_res;
>   |   ^
> msg.c:55:19: error: assignment to ‘char *’ from incompatible pointer type 
> ‘struct msg *’ [-Wincompatible-pointer-types]
>55 | p = e_con;
>   |   ^
> msg.c:58:19: error: assignment to ‘char *’ from incompatible pointer type 
> ‘struct msg *’ [-Wincompatible-pointer-types]
>58 | p = e_post;
>   |   ^
> msg.c:61:19: error: assignment to ‘char *’ from incompatible pointer type 
> ‘struct msg *’ [-Wincompatible-pointer-types]
>61 | p = e_fil;
>   |   ^
> msg.c:98:24: warning: ignoring return value of ‘write’ declared with 
> attribute ‘warn_unused_result’ [-Wunused-result]
>98 | (void) write(s, msg, i - 1);
>   |^~~~
> make[1]: *** [: msg.o] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j1 returned exit code 2
> make: *** [debian/rules:12: build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The attached patch fixes the build.

Thanks,
Guillem
diff --git c/debian/patches/fix-incompat-ptr-types.patch i/debian/patches/fix-incompat-ptr-types.patch
new file mode 100644
index 000..42f3f48
--- /dev/null
+++ i/debian/patches/fix-incompat-ptr-types.patch
@@ -0,0 +1,40 @@
+Author: Guillem Jover 
+Description: Fix incompatible pointer type asssignment
+ We cannot assign a struct into a char *, even if the first member is a char *.
+ Instead assign that member into the variable.
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/1074954
+Forwarded: no
+Last-Update: 2024-09-16
+
+---
+ msg.c |   10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/msg.c
 b/msg.c
+@@ -46,19 +46,19 @@ err_msg(int s, struct req * r, int m)
+ 
+ 	switch (m) {
+ 	case E_INV:
+-		p = e_inv;
++		p = e_inv->c;
+ 		break;
+ 	case E_RES:
+-		p = e_res;
++		p = e_res->c;
+ 		break;
+ 	case E_CON:
+-		p = e_con;
++		p = e_con->c;
+ 		break;
+ 	case E_POST:
+-		p = e_post;
++		p = e_post->c;
+ 		break;
+ 	case E_FIL:
+-		p = e_fil;
++		p = e_fil->c;
+ 		break;
+ 	}
+ 
diff --git c/debian/patches/series i/debian/patches/series
index 1da3530..983d3b6 100644
--- c/debian/patches/series
+++ i/debian/patches/series
@@ -7,3 +7,4 @@
 06_handle-multibytes-headers
 07_fix_segfault_syslog_logrequests
 08_fix_variables_declaration_conflicts
+fix-incompat-ptr-types.patch

Bug#1079648: lvm2: Build fixes and improvements

[Guillem Jover]

Source: lvm2
Source-Version: 2.03.22-1
Severity: serious
Tags: patch

Hi!

This is an assortment of some packaging and build system fixes, one of
them fixes a current FTBFS, as the upstream Makefiles are left with
@GREP@ and @EGREP@ substitution placeholders due to the now missing
autoconf checks.

Attached the patches. The first one, I guess will need to be adapted
to whatever workflow the package is using, but the quilt patch is a
proper git formatted patch so can be applied as is wherever.

Thanks,
Guillem
From d5926716ac62c4cf506f17c0393397642081562a Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 25 Aug 2024 19:57:57 +0200
Subject: [PATCH 1/4] Check for grep and egrep explicitly in configure

These macros were being pulled out transitively from other projects, but
that has stopped happening now, and the build fails. As we explicitly use
both the GREP and EGREP make substitution variables, we need to make sure
we check for what we need.
---
 debian/patches/autoconf-grep.patch | 24 
 debian/patches/series  |  1 +
 2 files changed, 25 insertions(+)
 create mode 100644 debian/patches/autoconf-grep.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/autoconf-grep.patch b/debian/patches/autoconf-grep.patch
new file mode 100644
index 0..0cb5802c1
--- /dev/null
+++ b/debian/patches/autoconf-grep.patch
@@ -0,0 +1,24 @@
+From 739278f8557b18837804173958209430837818b8 Mon Sep 17 00:00:00 2001
+From: Guillem Jover 
+Date: Sun, 25 Aug 2024 19:57:57 +0200
+Subject: [PATCH] Check for grep and egrep explicitly in configure
+ These macros were being pulled out transitively from other projects, but
+ that has stopped happening now, and the build fails. As we explicitly use
+ both the GREP and EGREP make substitution variables, we need to make sure
+ we check for what we need.
+
+---
+ configure.ac |2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/configure.ac
 b/configure.ac
+@@ -61,6 +61,8 @@ AS_CASE(["$host_os"],
+ 
+ 
+ dnl -- Checks for programs.
++AC_PROG_GREP
++AC_PROG_EGREP
+ AC_PROG_SED
+ AC_PROG_AWK
+ save_CFLAGS=$CFLAGS
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 0..0836c06bf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+autoconf-grep.patch
-- 
2.45.2

From a45a91162a90c7145f6ea6bc3a65797b40a83d44 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 25 Aug 2024 15:53:18 +0200
Subject: [PATCH 2/4] Turn initramfs hooks into debhelper fragment files

The dh_installinitramfs command takes care of installing the initramfs
hooks automatically if they are named as pkgname.initramfs-hook, this
way we do not need to handle their installation ourselves.
---
 .../dmsetup/hooks/dmsetup => dmsetup.initramfs-hook} | 0
 debian/dmsetup.install   | 1 -
 debian/{initramfs-tools/lvm2/hooks/lvm2 => lvm2.initramfs-hook}  | 0
 debian/lvm2.install  | 1 -
 4 files changed, 2 deletions(-)
 rename debian/{initramfs-tools/dmsetup/hooks/dmsetup => dmsetup.initramfs-hook} (100%)
 mode change 100755 => 100644
 rename debian/{initramfs-tools/lvm2/hooks/lvm2 => lvm2.initramfs-hook} (100%)
 mode change 100755 => 100644

diff --git a/debian/initramfs-tools/dmsetup/hooks/dmsetup b/debian/dmsetup.initramfs-hook
old mode 100755
new mode 100644
similarity index 100%
rename from debian/initramfs-tools/dmsetup/hooks/dmsetup
rename to debian/dmsetup.initramfs-hook
diff --git a/debian/dmsetup.install b/debian/dmsetup.install
index 92b630233..aa9e7afb9 100644
--- a/debian/dmsetup.install
+++ b/debian/dmsetup.install
@@ -1,4 +1,3 @@
-../../initramfs-tools/dmsetup/* usr/share/initramfs-tools
 usr/lib/udev/rules.d/*-dm*.rules
 usr/sbin/blkdeactivate
 usr/sbin/dmsetup
diff --git a/debian/initramfs-tools/lvm2/hooks/lvm2 b/debian/lvm2.initramfs-hook
old mode 100755
new mode 100644
similarity index 100%
rename from debian/initramfs-tools/lvm2/hooks/lvm2
rename to debian/lvm2.initramfs-hook
diff --git a/debian/lvm2.install b/debian/lvm2.install
index f5f5ee412..243ce3c1a 100644
--- a/debian/lvm2.install
+++ b/debian/lvm2.install
@@ -1,4 +1,3 @@
-../../initramfs-tools/lvm2/* usr/share/initramfs-tools
 etc/lvm
 usr/lib/systemd/system/blk-availability*
 usr/lib/systemd/system/lvm2-lvmpolld*
-- 
2.45.2

From b3cc1a9502675cb5fdde21e9a98150212d3ee152 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 25 Aug 2024 15:53:20 +0200
Subject: [PATCH 3/4] Remove imperative activation of update-initramfs trigger

This is handled automatically by dh_installinitramfs by installing a
triggers control file that activates the trigger, on all relevant
package actions, not just configuration.
---
 debian/dmsetup.postinst | 13 -
 debian/lvm2.postinst|  1 -
 2 files changed, 14 deletions(-)
 delete mode 100644 d

Bug#1076924: metadata

[Guillem Jover]

Hi!

On Tue, 2024-08-13 at 17:33:58 +0200, Santiago Vila wrote:
> El 13/8/24 a las 16:30, Guillem Jover escribió:
> >  I'm now closing it, because only with the fixed marking is not
> > enough for the BTS, and it was being kept open. :)
> 
> Yes, I was aware that "fixed" did not close the bug.

Sorry, yes, I assumed you knew that. I was just stating it explicitly,
why I was closing it "for historical record".

> To clarify: I was keeping the bug open (but not
> in the list of bugs affecting trixie or sid) just
> in case you would be willing to do some final
> tidy up (merge, affects, etc) before closing.

> I usually (but not always) try to do that kind of tidying up,
> but I acknowledge that not everybody has the same standards
> for that. In particular, merging bugs which are essentially
> the same is often tricky and we can live without that.

I think doing that in general is ideal, and should perhaps have done
that, but I don't think it gave additional insight into the problem,
and having it out of the way, seemed better. :)

Thanks,
Guillem

Bug#1076067: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1076067 pending

Hi!

Bug #1076067 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=3e2046ecd

---
Dpkg::Shlibs::Cppfilt: Do not normalize angle brackets for operators

We should not normalize angle brackets for these operators, otherwise
we turn them into invalid syntax.

Closes: #1076067

Bug#1076892: libzen: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file

[Guillem Jover]

Control: reassign -1 libdpkg-perl 1.22.7
Control: retitle -1 "libdpkg-perl: Angle bracket symbol normalization 
incorrectly applies to operators"
Control: affects -1 libzen

Hi!

On Sun, 2024-07-28 at 15:16:58 +0800, Chow Loong Jin wrote:
> This looks like an issue with dpkg-gensymbols -- in the diff, there are
> the following lines:
> 
> - (c++)"ZenLib::int128::operator>>=(unsigned int)@Base" 0.4.23
> +#MISSING: 0.4.41-2.1~exp1# (c++)"ZenLib::int128::operator>>=(unsigned
> >>int)@Base" 0.4.23
> - (c++)"ZenLib::uint128::operator>>=(unsigned int)@Base" 0.4.23
> +#MISSING: 0.4.41-2.1~exp1# (c++)"ZenLib::uint128::operator>>=(unsigned
> >>int)@Base" 0.4.23
> + _ZN6ZenLib6int128rSEj@Base 0.4.41-2.1~exp1
> + _ZN6ZenLib7uint128rSEj@Base 0.4.41-2.1~exp1
> 
> Running the two new symbols through c++filt yields:
> + ZenLib::int128::operator>>=(unsigned int)@Base 0.4.41-2.1~exp1
> + ZenLib::uint128::operator>>=(unsigned int)@Base 0.4.41-2.1~exp1
> 
> These are exactly the same as the two missing symbols above, and
> dpkg-gensymbols used to match them but somehow is not doing so in the
> current version.

Ah, this is a regression from trying to normalize the angle brackets.
I've got a fix locally to special case "operator>>" (and "operator>>="),
but I'm adding some tests to catch this. Will be included in the next
upload, which I'll probably do later today or tomorrow.

Thanks,
Guillem

Bug#1076904: [Pkg-javascript-devel] Bug#1076904: pkg-js-tools: FTBFS: help2man: can't get `--version' info from ./tools/debcheck-node-repo

[Guillem Jover]

Control: reopen -1
Control: notfixed -1 dpkg/1.22.9
Control: affect -1 = src:pkg-js-tools
Control: retitle -1 dpkg-dev: Make fragments lack internal dpkg_lazy_eval macros
Control: tags -1 =

On Fri, 2024-07-26 at 15:21:16 +0200, Santiago Vila wrote:
> unmerge 1076904
> thanks

> Hi. I can indeed reproduce the error in unstable right now.
> (was your chroot uptodate?)
> 
> Maybe this is one of the other subtle bugs reported by Michael Tokarev?
> 
> In either case, please fix the metadata as necessary.
> 
> Sorry, I try to help maintainers to discover the root cause of the bugs I 
> report,
> when I can, but I don't always succeed.

This FTBFS in pkg-js-tools is caused by that package (and several
others), using the internal dpkg_lazy_eval macro from the dpkg
Makefile fragment files.

I'm going to revert the change that removed those macros, to avoid this
and other breakage, but these packages should ideally not have used
these macros. Although at this point I guess this has kind of become
part of the API for those files. :/ And making them stop using the
macros will require a coordinate transition or similar.

Thanks,
Guillem

Bug#1076863: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1076863 pending

Hi!

Bug #1076863 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=c05f82972

---
scripts/mk: Fix pkg-info.mk evaluation by adding new DEB_TIMESTAMP variable

Instead of handling the SOURCE_DATE_EPOCH conditional case from within
the dpkg_parsechangelog_run variable, and then trying to lazily evaluate
all other variables. Instead add a new DEB_TIMESTAMP variable that is
set unconditionally from dpkg_parsechangelog_run, and then conditionally
set SOURCE_DATE_EPOCH from it if not yet defined.

Fixes: commit e146a68a375453db89bc3b5e816d9405e5fd5634
Closes: #1076863

Bug#1076863: dpkg-deb: Weird errors from dpkg-deb while building some packages

[Guillem Jover]

Hi

On Wed, 2024-07-24 at 16:35:44 +0200, Guillem Jover wrote:
> On Wed, 2024-07-24 at 14:37:53 +0200, Guillem Jover wrote:
> > Both look like the same problem, which would be a regression from the
> > recent rework of the Makefile fragments. I'm CCing Nicolas as a
> > heads-up, and I'm looking into this to try to do a quick fix upload.
> 
> So there's something wrong with the variables evaluation, and the
> following change makes these packages build again, but I don't
> understand yet what's wrong with the first ifdef conditional arm.
> And neither why the test suite didn't catch this, as it is
> supposedly testing w/ and w/o SOURCE_DATE_EPOCH being set.
> (I'll go for lunch now, so if someone else can have a look that'd
> also be appreciated. :)

I think the attached patch might be better.

Thanks,
Guillem
diff --git i/scripts/mk/pkg-info.mk w/scripts/mk/pkg-info.mk
index ddda4f736..c999d2d3c 100644
--- i/scripts/mk/pkg-info.mk
+++ w/scripts/mk/pkg-info.mk
@@ -8,6 +8,9 @@
 #   DEB_VERSION_UPSTREAM: package's upstream version.
 #   DEB_DISTRIBUTION: distribution(s) listed in the current debian/changelog
 # entry.
+#   DEB_TIMESTAMP: source package relase date as seconds since the epoch as
+# specified in the latest debian/changelog entry (since dpkg 1.22.9),
+# although you are probably looking for SOURCE_DATE_EPOCH instead.
 #
 #   SOURCE_DATE_EPOCH: source release date as seconds since the epoch, as
 # specified by <https://reproducible-builds.org/specs/source-date-epoch/>
@@ -26,20 +29,12 @@ dpkg_parsechangelog_run = $(eval $(shell dpkg-parsechangelog | sed -n '\
 $$(eval DEB_VERSION_EPOCH_UPSTREAM:=\1\2\4)\
 $$(eval DEB_VERSION_UPSTREAM_REVISION:=\2\3)\
 $$(eval DEB_VERSION_UPSTREAM:=\2\4)/p;\
-  s/^Timestamp: \(.*\)/$$(eval SOURCE_DATE_EPOCH?=\1)/p'))
+  s/^Timestamp: \(.*\)/$$(eval DEB_TIMESTAMP:=\1)/p'))
 
-ifdef SOURCE_DATE_EPOCH
-  dpkg_lazy_eval ?= $(eval $(1) = $(2)$$($(1)))
-  $(call dpkg_lazy_eval,DEB_DISTRIBUTION,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_SOURCE,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_VERSION,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_VERSION_EPOCH_UPSTREAM,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_VERSION_UPSTREAM,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_UPSTREAM_REVISION,$$(dpkg_parsechangelog_run))
-else
-  # We need to compute the values right now.
-  $(dpkg_parsechangelog_run)
-endif
+# We need to compute the values right now.
+$(dpkg_parsechangelog_run)
+
+SOURCE_DATE_EPOCH ?= $(DEB_TIMESTAMP)
 export SOURCE_DATE_EPOCH
 
 endif # dpkg_pkg_info_mk_included
diff --git i/scripts/t/mk/pkg-info.mk w/scripts/t/mk/pkg-info.mk
index 6eb37866d..6863ebb80 100644
--- i/scripts/t/mk/pkg-info.mk
+++ w/scripts/t/mk/pkg-info.mk
@@ -6,6 +6,7 @@ TEST_DEB_VERSION_EPOCH_UPSTREAM = 1:2:3.4-5
 TEST_DEB_VERSION_UPSTREAM_REVISION = 2:3.4-5-6
 TEST_DEB_VERSION_UPSTREAM = 2:3.4-5
 TEST_DEB_DISTRIBUTION = suite
+TEST_DEB_TIMESTAMP = 1438697630
 
 test_vars := \
   DEB_SOURCE \
@@ -14,6 +15,7 @@ test_vars := \
   DEB_VERSION_UPSTREAM_REVISION \
   DEB_VERSION_UPSTREAM \
   DEB_DISTRIBUTION \
+  DEB_TIMESTAMP \
   SOURCE_DATE_EPOCH \
   # EOL
 

Bug#1076863: dpkg-deb: Weird errors from dpkg-deb while building some packages

[Guillem Jover]

Hi!

On Wed, 2024-07-24 at 14:37:53 +0200, Guillem Jover wrote:
> Both look like the same problem, which would be a regression from the
> recent rework of the Makefile fragments. I'm CCing Nicolas as a
> heads-up, and I'm looking into this to try to do a quick fix upload.

So there's something wrong with the variables evaluation, and the
following change makes these packages build again, but I don't
understand yet what's wrong with the first ifdef conditional arm.
And neither why the test suite didn't catch this, as it is
supposedly testing w/ and w/o SOURCE_DATE_EPOCH being set.
(I'll go for lunch now, so if someone else can have a look that'd
also be appreciated. :)

,---
diff --git i/scripts/mk/pkg-info.mk w/scripts/mk/pkg-info.mk
index ddda4f736..a2eb0d5fe 100644
--- i/scripts/mk/pkg-info.mk
+++ w/scripts/mk/pkg-info.mk
@@ -28,18 +28,8 @@ dpkg_parsechangelog_run = $(eval $(shell dpkg-parsechangelog 
| sed -n '\
 $$(eval DEB_VERSION_UPSTREAM:=\2\4)/p;\
   s/^Timestamp: \(.*\)/$$(eval SOURCE_DATE_EPOCH?=\1)/p'))

-ifdef SOURCE_DATE_EPOCH
-  dpkg_lazy_eval ?= $(eval $(1) = $(2)$$($(1)))
-  $(call dpkg_lazy_eval,DEB_DISTRIBUTION,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_SOURCE,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_VERSION,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_VERSION_EPOCH_UPSTREAM,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_VERSION_UPSTREAM,$$(dpkg_parsechangelog_run))
-  $(call dpkg_lazy_eval,DEB_UPSTREAM_REVISION,$$(dpkg_parsechangelog_run))
-else
-  # We need to compute the values right now.
-  $(dpkg_parsechangelog_run)
-endif
+# We need to compute the values right now.
+$(dpkg_parsechangelog_run)
 export SOURCE_DATE_EPOCH

 endif # dpkg_pkg_info_mk_included
`---

Thanks,
Guillem

Bug#1076863: dpkg-deb: Weird errors from dpkg-deb while building some packages

[Guillem Jover]

Control: forcemerge -1 1076939

Hi!

On Wed, 2024-07-24 at 12:17:21 +0200, Santiago Vila wrote:
> Package: dpkg
> Version: 1.22.8

> While building some packages I get weird errors like this:
> 
> dpkg-deb: building package 'aspell-nl' in '../aspell-nl_2.20.19-2_all.deb'.
> dpkg-deb: building package 'idutch' in '../idutch_2.20.19-2_all.deb'.
> dpkg-deb: error: parsing file 'debian/hunspell-nl/DEBIAN/control' near line 3 
> package 'hunspell-nl':
>  'Version' field value '2:': nothing after colon in version number
> dh_builddeb: error: dpkg-deb --build debian/hunspell-nl .. returned exit code 
> 2
> 
> (the above is for package "dutch")
> 
> This seems more a dpkg bug (maybe related with epoch handling) than a bug in 
> dutch,
> but I'm not sure. Can you check?
> 

On Wed, 2024-07-24 at 14:10:48 +0200, Jonas Smedegaard wrote:
> Package: dpkg-dev
> Version: 1.22.8
> Severity: important

> It looks like recent changes to dpkg-dev affects a bunch of packages
> that I maintain.
> 
> Concretely, the package radicale now fails to build, as it passes an
> empty version number to help2man. This was reported as bug#1076915.
> Seemingly related bug#1076568 made me try downgrade dpkg-dev, and
> indeed with dpkg-dev 1.22.6 the variable DEB_VERSION_UPSTREAM_REVISION
> again resolves correctly.
> 
> It looks like recent dpkg-dev offers variable expansion only inside
> make rules, not for make code declares "at the core", outside of make
> rules.
> 
> Many of the packages I maintain rely on the ability to resolve variables
> also at the core of the makefile. I am not furiously against changing my
> packaging patterns, but I imagine I am not the only one, so I guess such
> change needs more care and documentation (or perhaps just pointing me to
> the elaborate documentation that I have totally missed).

Both look like the same problem, which would be a regression from the
recent rework of the Makefile fragments. I'm CCing Nicolas as a
heads-up, and I'm looking into this to try to do a quick fix upload.

Thanks,
Guillem

Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext

[Guillem Jover]

Hi!

On Thu, 2024-06-13 at 00:45:14 +0200, Martin Quinson wrote:
> Le jeudi 13 juin 2024 à 00:29 +0200, Guillem Jover a écrit :
> > On Thu, 2024-06-13 at 00:02:43 +0200, Martin Quinson wrote:
> > > The problem is that Perl has a rather unexpected behavior wrt utf8, UTF-8
> > > and UTF8. These names are not aliases of others in Perl. See
> > > https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8
> > 
> > Sure, but here I think this does not matter (in theory), because it
> > depends on how the pod parser interprets the encoding name, and from
> > checking the perl code it seems it maps /utf-?8/i to ":encoding(UTF-8)".
> > So they are really treated the same, at least when it comes to POD, that
> > does not mean perl has that distinction for the encoding in other
> > contexts. 
> 
> Ok, ok. You are perfectly right. This distinction between utf8 and UTF-8 is
> perfectly useless in the context of POD files. I just pushed yet another 
> commit
> to not do that in POD.

Perfect, thanks! :)

> Please tell me whether it looks good to you now.

I just hot-fixed my installed po4a and it seems to be working fine
now. Thank you!

You might also perhaps want to update the NEWS file after that change
though? :)

Regards,
Guillem

Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext

[Guillem Jover]

Hi!

On Thu, 2024-06-13 at 00:02:43 +0200, Martin Quinson wrote:
> Le mercredi 12 juin 2024 à 17:14 +0200, Guillem Jover a écrit :
> > I think the charset comparison is too naive though, and does not cover
> > for example any aliases listed in «man Encode::Supported». I think a
> > better comparison logic could look like this:
> > 
> >   ,---
> >   use Encode;
> > 
> >   my $enc_charset = Encode::find_encoding($charset);
> >   my $enc_master_charset = Encode::find_encoding($master_charset);
> > 
> >   say 'match' if $enc_charset->mime_name eq $enc_master_charset->mime_name;
> >   `---
> > 
> > Unfortunately neither Encode::find_encoding()->name nor
> > Encode::resolve_alias() seem helpful here because they return
> > "utf-8-strict" for "UTF-8" which will not match against "utf-8" for
> > the canonical "utf8".
> 
> The problem is that Perl has a rather unexpected behavior wrt utf8, UTF-8 and
> UTF8. These names are not aliases of others in Perl. See
> https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8

Sure, but here I think this does not matter (in theory), because it
depends on how the pod parser interprets the encoding name, and from
checking the perl code it seems it maps /utf-?8/i to ":encoding(UTF-8)".
So they are really treated the same, at least when it comes to POD, that
does not mean perl has that distinction for the encoding in other
contexts. The following two places I found that are in charge of parsing
POD lowercase and remove or ignore - (and _) when parsing the encoding
name:

  perl/Pod-Perldoc/lib/Pod/Perldoc.pm:set_encoding
  
https://sources.debian.org/src/perl/5.38.2-5/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm/#L1054

  perl/Pod-Simple/lib/Pod/Simple/BlackBox.pm:_handle_encoding_line
  
https://sources.debian.org/src/perl/5.38.2-5/cpan/Pod-Simple/lib/Pod/Simple/BlackBox.pm/#L604

> So I don't think that you will find a piece of Perl code that will allow to
> merge these names to declare that they are equivalent. In some sense, that's
> the essence of all issues I introduced in po4a v0.70 when introducing perlIO 
> to
> control the encoding issues. I went from a lax system being utf8 by default 
> but
> happily taking latin-1 encoding files to a much stricter UTF-8 system by
> default and forcing the user to specify if they want another encoding.

I think the problem is that this might be conflating independent contexts,
such as IO, perl source code, POD, etc.

> Instead, I just pushed a commit changing the error message when charsets are
> utf8 and UTF-8 to insist on the difference between these encodings in Perl.
> https://github.com/mquinson/po4a/commit/afe6e1344ffad9d87dd807a81ed6467d6101b15f

I think this might break more than dpkg though. And from the above Pod
handling it might be unnecessary?

Thanks,
Guillem

Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext

[Guillem Jover]

Hi!

On Wed, 2024-06-12 at 15:42:57 +0200, Guillem Jover wrote:
> On Wed, 2024-06-12 at 10:36:52 +0200, Martin Quinson wrote:
> > Le mercredi 12 juin 2024 à 04:47 +0200, Guillem Jover a écrit :
> > > Package: po4a
> > > Version: 0.70
> > > Severity: serious

> > Could you please do the following steps, please?
> 
> >  * Try whether the failure still happens with the latest po4a
> >  * Try whether the attached patch applied to the latest po4a helps
> >  * Tell me more details about how to reproduce the failure
> > 
> > Thanks in advance, and sorry for the inconvenience. To me, this part of po4a
> > code was not changed in years, so I need help to understand the issue.
> 
> It looked like at least the initial regression was introduced in po4a
> commit b2333d54845976f4804f024b5cea61db16fb4f36.

Ah, and missed that the later error I got was precisely the one being
emitted by that commit, which if you do not trigger then you'd not see
the earlier undefined symbol errors.

> > diff --git a/lib/Locale/Po4a/Pod.pm b/lib/Locale/Po4a/Pod.pm
> > index 4b3dc042..bd3d5c1a 100644
> > --- a/lib/Locale/Po4a/Pod.pm
> > +++ b/lib/Locale/Po4a/Pod.pm
> > @@ -27,6 +27,8 @@ use vars qw(@ISA);
> >  
> >  use Carp qw(croak confess);
> >  
> > +use Locale::Po4a::Common qw(dgettext);
> > +
> >  sub initialize { }
> >  
> >  sub translate {
> 
> I hot-edited this in my installed system and then got:
> 
>   ,---
> PO4A   man.stamp
>   Undefined subroutine &Locale::Po4a::Pod::wrap_mod called at 
> /usr/share/perl5/Locale/Po4a/Pod.pm line 96, <$fh> line 21.
>   make[2]: *** [Makefile:902: man.stamp] Error 255
>   `---
> 
> I then instead removed the import restrictions and simply added:
> 
>   ,---
>   use Locale::Po4a::Common;
>   `---
> 
> That fixed that issue but then it fails with:
> 
>   ,---
> PO4A   man.stamp
>   po4a::pod: The file deb-buildinfo.pod declares utf8 as encoding, but you 
>  provided UTF-8 as master charset. Please change either setting.
>at /usr/bin/po4a line 1663.
>   make[2]: *** [Makefile:902: man.stamp] Error 255
>   `---

I think the charset comparison is too naive though, and does not cover
for example any aliases listed in «man Encode::Supported». I think a
better comparison logic could look like this:

  ,---
  use Encode;

  my $enc_charset = Encode::find_encoding($charset);
  my $enc_master_charset = Encode::find_encoding($master_charset);

  say 'match' if $enc_charset->mime_name eq $enc_master_charset->mime_name;
  `---

Unfortunately neither Encode::find_encoding()->name nor
Encode::resolve_alias() seem helpful here because they return
"utf-8-strict" for "UTF-8" which will not match against "utf-8" for
the canonical "utf8".

I'm not sure whether lib/Locale/Po4a/Xml.pod might need a similar
treatment, because that might depend on what encodings are supported
in there, against what is supported in po4a I guess.

Thanks,
Guillem

Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext

[Guillem Jover]

Hi!

On Wed, 2024-06-12 at 10:36:52 +0200, Martin Quinson wrote:
> Le mercredi 12 juin 2024 à 04:47 +0200, Guillem Jover a écrit :
> > Package: po4a
> > Version: 0.70
> > Severity: serious

> > When building dpkg, it now fails with something like this:
> > 
> >   ,---
> >   Making check in man
> >   make[1]: Entering directory '/dpkg/man'
> >   /usr/bin/po4a --previous --srcdir . --destdir . --no-backups --porefs file
> > --msgmerge-opt=--add-location=file --package-name dpkg-man --package-version
> > 1.22.6-80-gec07 --copyright-holder "Dpkg Developers" --msgid-bugs-address
> > debian-d...@lists.debian.org  ./po/po4a.cfg
> >   Undefined subroutine &Locale::Po4a::Pod::dgettext called at
> > /usr/share/perl5/Locale/Po4a/Pod.pm line 94, <$fh> line 21.
> >   make[1]: *** [Makefile:902: man.stamp] Error 255
> >   make[1]: Leaving directory '/dpkg/man'
> >   `---
> > 
> > It seems the module is missing some import.

> the attached patch could help, but I fail to reproduce the failure in the 
> first
> place. I built dpkg v1.22.6 against po4a v0.72 and it builds with no failure.
> The "Making check in man" section LGTM but I'm not sure of what it should look
> like.

I guess that's because the tarballl has already been bootstrapped. Building
from git should reproduce it. But in any case if that's too cumbersome I'm
happy to keep testing stuff.

> I tried the git version of po4a with git-pbuilder, but it complains about not
> being able to determine whether it's a git or a release build. I must be
> missing some config on my side.

Perhaps you meant you tried to build the git version of dpkg here?
(If so you'd need to run ./autogen first.)

> Could you please do the following steps, please?

>  * Try whether the failure still happens with the latest po4a
>  * Try whether the attached patch applied to the latest po4a helps
>  * Tell me more details about how to reproduce the failure
> 
> Thanks in advance, and sorry for the inconvenience. To me, this part of po4a
> code was not changed in years, so I need help to understand the issue.

It looked like at least the initial regression was introduced in po4a
commit b2333d54845976f4804f024b5cea61db16fb4f36.

> diff --git a/lib/Locale/Po4a/Pod.pm b/lib/Locale/Po4a/Pod.pm
> index 4b3dc042..bd3d5c1a 100644
> --- a/lib/Locale/Po4a/Pod.pm
> +++ b/lib/Locale/Po4a/Pod.pm
> @@ -27,6 +27,8 @@ use vars qw(@ISA);
>  
>  use Carp qw(croak confess);
>  
> +use Locale::Po4a::Common qw(dgettext);
> +
>  sub initialize { }
>  
>  sub translate {

I hot-edited this in my installed system and then got:

  ,---
PO4A   man.stamp
  Undefined subroutine &Locale::Po4a::Pod::wrap_mod called at 
/usr/share/perl5/Locale/Po4a/Pod.pm line 96, <$fh> line 21.
  make[2]: *** [Makefile:902: man.stamp] Error 255
  `---

I then instead removed the import restrictions and simply added:

  ,---
  use Locale::Po4a::Common;
  `---

That fixed that issue but then it fails with:

  ,---
PO4A   man.stamp
  po4a::pod: The file deb-buildinfo.pod declares utf8 as encoding, but you 
 provided UTF-8 as master charset. Please change either setting.
   at /usr/bin/po4a line 1663.
  make[2]: *** [Makefile:902: man.stamp] Error 255
  `---

Thanks,
Guillem

Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext

[Guillem Jover]

Package: po4a
Version: 0.70
Severity: serious

Hi!

When building dpkg, it now fails with something like this:

  ,---
  Making check in man
  make[1]: Entering directory '/dpkg/man'
  /usr/bin/po4a --previous --srcdir . --destdir . --no-backups --porefs file 
--msgmerge-opt=--add-location=file --package-name dpkg-man --package-version 
1.22.6-80-gec07 --copyright-holder "Dpkg Developers" --msgid-bugs-address 
debian-d...@lists.debian.org  ./po/po4a.cfg
  Undefined subroutine &Locale::Po4a::Pod::dgettext called at 
/usr/share/perl5/Locale/Po4a/Pod.pm line 94, <$fh> line 21.
  make[1]: *** [Makefile:902: man.stamp] Error 255
  make[1]: Leaving directory '/dpkg/man'
  `---

It seems the module is missing some import.

Thanks,
Guillem

Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

[ CCing debian-arm list to loop them into the porting issue. ]

Hi!

On Fri, 2024-06-07 at 14:42:18 +0200, Guillem Jover wrote:
> On Sat, 2024-04-20 at 14:56:40 +0200, Lucas Nussbaum wrote:
> > Source: libx86emu
> > Version: 3.5-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf
> 
> > During a rebuild of all packages in sid, your package failed to build
> > on armhf.

> > Relevant part (hopefully):
> > > cc -g -O2 -Werror=implicit-function-declaration 
> > > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > > -fstack-clash-protection -Wformat -Werror=format-security -g -O2 -fPIC 
> > > -fvisibility=hidden -fomit-frame-pointer -Wall -D_LARGEFILE_SOURCE 
> > > -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
> > > -Wl,-z,relro -Wl,-z,now -c ops.c
> > > mem.c: In function ‘vm_i_byte’:
> > > mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   581 | return inb(addr);
> > >   |^~~
> > >   |ins
> > > mem.c: In function ‘vm_i_word’:
> > > mem.c:619:10: error: implicit declaration of function ‘inw’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   619 |   return inw(addr);
> > >   |  ^~~
> > >   |  ins
> > > mem.c: In function ‘vm_i_dword’:
> > > mem.c:657:10: error: implicit declaration of function ‘inl’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   657 |   return inl(addr);
> > >   |  ^~~
> > >   |  ins
> > > mem.c: In function ‘vm_o_byte’:
> > > mem.c:676:5: error: implicit declaration of function ‘outb’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   676 | outb(val, addr);
> > >   | ^~~~
> > >   | outs
> > > mem.c: In function ‘vm_o_word’:
> > > mem.c:711:3: error: implicit declaration of function ‘outw’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   711 |   outw(val, addr);
> > >   |   ^~~~
> > >   |   outs
> > > mem.c: In function ‘vm_o_dword’:
> > > mem.c:748:3: error: implicit declaration of function ‘outl’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   748 |   outl(val, addr);
> > >   |   ^~~~
> > >   |   outs
> > > cc1: some warnings being treated as errors
> > > make[1]: *** [Makefile:22: mem.o] Error 1
> 
> I had a look at this, and it seems like this package has never really
> worked on ARM systems at all? And this was hidden due to the missing
> declarations not being an error.
> 
> AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other
> systems have instead memory mapped I/O, but the code in mem.c is
> unconditionally calling port I/O functions such as in*() and out*(),
> provided by glibc.
> 
> Until the upstream code is ported to systems with memory mapper I/O, I
> think the "best" way to resolve this would be to restrict the
> architecture list to:
> 
>   any-amd64 any-i386 alpha ia64

The attached patch implements this. It should not affect reverse build
depending packages (only hwinfo) which is already arch restricted to
«amd64 i386».

I'm including the arm list to confirm the above, but also in case
someone there feels like porting the library to support memory mapped
I/O? (But perhaps that's not worth the effort.)

Thanks,
Guillem
From bafb0ddee8942c60b17745547854b3ed53ca4545 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 11 Jun 2024 13:30:40 +0200
Subject: [PATCH] Do not build on ARM architectures where there is no port I/O

Only x86 (i386 and amd64), ia64 and alpha have port I/O, other systems
have instead memory mapped I/O, but the code in mem.c is unconditionally
calling port I/O functions such as in*() and out*(), provided by glibc.

Until the upstream code is ported to systems with memory mapped I/O, the
best way forward is to restrict to systems that are supported right now.

(The only current package build depending on libx86emu-dev is already
arch restricted to amd64 and i386.)
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index f10e3e2..e8c974b 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Homepage: https://github.com/wfeldt

Bug#1069426: nocache: FTBFS on armhf: ccsSPzHW.s:3650: Error: symbol `fopen64' is already defined

[Guillem Jover]

Control: tag -1 patch

Hi!

On Sat, 2024-04-20 at 15:01:27 +0200, Lucas Nussbaum wrote:
> Source: nocache
> Version: 1.1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf

> During a rebuild of all packages in sid, your package failed to build
> on armhf.
> 
> 
> Relevant part (hopefully):
> > cc -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -Wall 
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -fPIC -c -o pageinfo.o 
> > pageinfo.c
> > sed 's!##libdir##!$(dirname "$0")!' nocache
> > chmod a+x nocache
> > /tmp/ccsSPzHW.s: Assembler messages:
> > /tmp/ccsSPzHW.s:3650: Error: symbol `fopen64' is already defined
> > make[1]: *** [Makefile:27: nocache.o] Error 1

I've provided a PR upstream to fix this at:

  https://github.com/Feh/nocache/pull/55

Thanks,
Guillem

Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]

[Guillem Jover]

Hi!

On Sat, 2024-04-20 at 14:56:40 +0200, Lucas Nussbaum wrote:
> Source: libx86emu
> Version: 3.5-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf

> During a rebuild of all packages in sid, your package failed to build
> on armhf.
> 
> 
> Relevant part (hopefully):
> > cc -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -g -O2 -fPIC 
> > -fvisibility=hidden -fomit-frame-pointer -Wall -D_LARGEFILE_SOURCE 
> > -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
> > -Wl,-z,relro -Wl,-z,now -c ops.c
> > mem.c: In function ‘vm_i_byte’:
> > mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean 
> > ‘ins’? [-Werror=implicit-function-declaration]
> >   581 | return inb(addr);
> >   |^~~
> >   |ins
> > mem.c: In function ‘vm_i_word’:
> > mem.c:619:10: error: implicit declaration of function ‘inw’; did you mean 
> > ‘ins’? [-Werror=implicit-function-declaration]
> >   619 |   return inw(addr);
> >   |  ^~~
> >   |  ins
> > mem.c: In function ‘vm_i_dword’:
> > mem.c:657:10: error: implicit declaration of function ‘inl’; did you mean 
> > ‘ins’? [-Werror=implicit-function-declaration]
> >   657 |   return inl(addr);
> >   |  ^~~
> >   |  ins
> > mem.c: In function ‘vm_o_byte’:
> > mem.c:676:5: error: implicit declaration of function ‘outb’; did you mean 
> > ‘outs’? [-Werror=implicit-function-declaration]
> >   676 | outb(val, addr);
> >   | ^~~~
> >   | outs
> > mem.c: In function ‘vm_o_word’:
> > mem.c:711:3: error: implicit declaration of function ‘outw’; did you mean 
> > ‘outs’? [-Werror=implicit-function-declaration]
> >   711 |   outw(val, addr);
> >   |   ^~~~
> >   |   outs
> > mem.c: In function ‘vm_o_dword’:
> > mem.c:748:3: error: implicit declaration of function ‘outl’; did you mean 
> > ‘outs’? [-Werror=implicit-function-declaration]
> >   748 |   outl(val, addr);
> >   |   ^~~~
> >   |   outs
> > cc1: some warnings being treated as errors
> > make[1]: *** [Makefile:22: mem.o] Error 1

I had a look at this, and it seems like this package has never really
worked on ARM systems at all? And this was hidden due to the missing
declarations not being an error.

AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other
systems have instead memory mapped I/O, but the code in mem.c is
unconditionally calling port I/O functions such as in*() and out*(),
provided by glibc.

Until the upstream code is ported to systems with memory mapper I/O, I
think the "best" way to resolve this would be to restrict the
architecture list to:

  any-amd64 any-i386 alpha ia64

Thanks,
Guillem

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

[Guillem Jover]

Hi!

On Tue, 2024-04-23 at 07:51:36 +0200, Helmut Grohne wrote:
> On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> > 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.

So, is the proposal for the dpkg change to make it ignore
self-Provides within a pkgset (that is all arch instances for the
same package name)? (Also I guess we'd get into what does self-Provide
mean within a pkgset.)

While the behavior might seem like it makes sense in this specific
case, the new semantics might seem a bit wonky?

For starters Provides (unless arch-qualified) currently inherit the
arch from the providing package. Breaks (unless arch-qualified) assume
an arch-qualifier of "any".

Either we'd need to consider the Provides from one instance extend to
the whole pkgset (ignoring their arch-qualifiers or subverting them?),
and then installing new instances (with different Provides for example),
would affect what other instances are providing, which is action at a
distance and could have very surprising effects.

Or we might need to check that what is being broken from one instance
is being provided exactly in the same way (ignore arch qualifiers again,
and match version if present) by the current instance and the breaking
one?

(Although perhaps I've got all this wrong, or there's a better and
more obvious model for the semantics. :)

Thanks,
Guillem

Bug#1072163: libxmlrpc-core-c3-dev: Missing dependency on libxmlrpc-util-dev

[Guillem Jover]

Package: libxmlrpc-core-c3-dev
Version: 1.59.03-2
Severity: serious

Hi!

After the recent package split, the .pc file does not work anymore, as
there's a missing dependency on the libxmlrpc-util-dev package, which
the .pc file depends on. On a pristine system after installing only
the libxmlrpc-core-c3-dev package and running pkgconf to get its flags
one gets this:

  ,---
  $ pkgconf --libs xmlrpc
  Package xmlrpc_util was not found in the pkg-config search path.
  Perhaps you should add the directory containing `xmlrpc_util.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'xmlrpc_util', required by 'xmlrpc', not found
  Package 'xmlrpc_util', required by 'xmlrpc_expat', not found
  `---

After installing the missing dependency:

  ,---
  $ pkgconf --libs xmlrpc
  -lxmlrpc -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util
  `---

Setting to serious, because the intra-dependencies are an
implementation detail that packages depending on the core package or
using its .pc file should not need to be aware of, and this would
cause FTBFS issues now.

Thanks,
Guillem

Bug#1066397: lgeneral: FTBFS: ../config.h:566:12: fatal error: direct.h: No such file or directory

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 13:03:23 +0100, Lucas Nussbaum wrote:
> Source: lgeneral
> Version: 1.4.4-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie

> Relevant part (hopefully):
> > gcc -DHAVE_CONFIG_H -DDATADIR=\"/usr/share/games\" -DPREFIX=\"/usr\" -I. 
> > -I..   -I.. -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection -Wall -std=gnu89 -O0 -g -c -o 
> > portability.o portability.c
> > In file included from localize.h:31,
> >  from localize.c:27:
> > ../config.h:566:12: fatal error: direct.h: No such file or directory
> >   566 | #  include 
> >   |^~
> > In file included from portability.c:27:
> > ../config.h:566:12: fatal error: direct.h: No such file or directory
> >   566 | #  include 
> >   |^~
> > compilation terminated.
> > compilation terminated.
> > make[3]: *** [Makefile:418: portability.o] Error 1

The attached patch should workaround this problem. From the patch
description:

  Fix missing declaration for mkdir(2)

  The header where mkdir(2) is declared is  not ,
  which means that with new compilers that default to set
  -Werror=implicit-function-declaration, the configure check fails and
  causes the code to try to include a  header that does not·
  exist on the system
  .
  We currently need to only change the generated configure because
  the package disables the autoreconf sequence, due to the upstream
  build system being out-of-date and failing to autoreconf cleanly.
  To fix this properly the build system should get updated, then the
  sequence re-enabled, and the change from here applied to the
  configure.ac instead.

Thanks,
Guillem
diff -Nru lgeneral-1.4.4/debian/patches/implicit-decls.patch lgeneral-1.4.4/debian/patches/implicit-decls.patch
--- lgeneral-1.4.4/debian/patches/implicit-decls.patch	1970-01-01 01:00:00.0 +0100
+++ lgeneral-1.4.4/debian/patches/implicit-decls.patch	2024-05-03 20:54:06.0 +0200
@@ -0,0 +1,31 @@
+Description: Fix missing declaration for mkdir(2)
+ The header where mkdir(2) is declared is  not ,
+ which means that with new compilers that default to set
+ -Werror=implicit-function-declaration, the configure check fails and
+ causes the code to try to include a  header that does not 
+ exist on the system
+ .
+ We currently need to only change the generated configure because the
+ package disables the autoreconf sequence, due to the upstream build system
+ being out-of-date and failing to autoreconf cleanly. To fix this properly
+ the build system should get updated, then the sequence re-enabled, and the
+ change from here applied to the configure.ac instead.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: not-needed
+
+---
+ configure |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/configure
 b/configure
+@@ -5667,7 +5667,7 @@ $as_echo_n "checking if mkdir rejects pe
+ ac_mkdir_perm_broken=yes
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h.  */
+-#include 
++#include 
+ int
+ main ()
+ {
diff -Nru lgeneral-1.4.4/debian/patches/series lgeneral-1.4.4/debian/patches/series
--- lgeneral-1.4.4/debian/patches/series	2023-02-25 17:55:55.0 +0100
+++ lgeneral-1.4.4/debian/patches/series	2024-05-03 20:43:31.0 +0200
@@ -1 +1,2 @@
 fix_desktop_file_encoding.patch
+implicit-decls.patch

Bug#1066466: rlinetd: FTBFS: ../../src/cleanups.c:27:49: error: implicit declaration of function ‘pmap_unset’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:56:21 +0100, Lucas Nussbaum wrote:
> Source: rlinetd
> Version: 0.9.3-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > /bin/bash ../libtool  --tag=CC   --mode=link 
> > /<>/debian/gcc-wrapper gcc -I../.. -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection -Wall -Wextra  -Wwrite-strings 
> > -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes 
> > -Wstrict-prototypes -Wmissing-declarations -Wnested-externs -Wcast-align 
> > -Winline -Wshadow -Wredundant-decls -export-dynamic -Wl,-z,relro -Wl,-z,now 
> > -o rlinetd buffer.o bytecode.o connect.o db.o error.o engine.o main.o 
> > stack.o strings.o signals.o -ldl  ../port/libport.a -lcap
> > ../../src/cleanups.c: In function ‘rlp_cleanup’:
> > ../../src/cleanups.c:27:49: error: implicit declaration of function 
> > ‘pmap_unset’ [-Werror=implicit-function-declaration]
> >27 | 
> > pmap_unset(rlcu->prog, nl->num);
> >   | ^~
> > ../../src/cleanups.c:27:49: warning: nested extern declaration of 
> > ‘pmap_unset’ [-Wnested-externs]
> > cc1: some warnings being treated as errors
> > make[4]: *** [Makefile:603: cleanups.lo] Error 1

This is the symptom, but the actual problem is from the rpc code
having been removed from glibc, and packages now needing to link
against libtirpc instead. The attached patch solves this. Although for
upstream submission this should be done in configure.ac instead.

Thanks,
Guillem
diff -Nru rlinetd-0.9.3/debian/control rlinetd-0.9.3/debian/control
--- rlinetd-0.9.3/debian/control	2024-01-26 00:37:24.0 +0100
+++ rlinetd-0.9.3/debian/control	2024-05-03 20:30:29.0 +0200
@@ -7,6 +7,7 @@
debhelper-compat (= 13),
flex,
libcap2-dev [linux-any],
+   libtirpc-dev,
libwrap0-dev
 Rules-Requires-Root: no
 Homepage: https://salsa.debian.org/debian/rlinetd
diff -Nru rlinetd-0.9.3/debian/rules rlinetd-0.9.3/debian/rules
--- rlinetd-0.9.3/debian/rules	2024-01-26 00:37:24.0 +0100
+++ rlinetd-0.9.3/debian/rules	2024-05-03 20:34:21.0 +0200
@@ -7,7 +7,9 @@
 DESTDIR := $(CURDIR)/debian/$(shell dh_listpackages)
 
 DEB_BUILD_MAINT_OPTIONS := hardening=+all
+DEB_CPPFLAGS_MAINT_APPEND := $(shell pkgconf --cflags libtirpc)
 DEB_CFLAGS_MAINT_APPEND := $(shell getconf LFS_CFLAGS)
+DEB_LDFLAGS_MAINT_APPEND := $(shell pkgconf --libs libtirpc)
 DPKG_EXPORT_BUILDFLAGS  := 1
 
 include /usr/share/dpkg/buildflags.mk

Bug#1066470: kxl: FTBFS: KXLsound.c:75:9: error: implicit declaration of function 'read'; did you mean 'fread'? [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:52:04 +0100, Lucas Nussbaum wrote:
> Source: kxl
> Version: 1.1.7-17
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> >  gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"KXL\" 
> > -DVERSION=\"1.1.7\" -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
> > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
> > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
> > -DHAVE_FCNTL_H=1 -DHAVE_MALLOC_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 
> > -DHAVE_LINUX_JOYSTICK_H=1 -DHAVE_LINUX_SOUNDCARD_H=1 -DTIME_WITH_SYS_TIME=1 
> > -DRETSIGTYPE=void -DHAVE_SELECT=1 -I. -I. -Wdate-time -D_FORTIFY_SOURCE=2 
> > -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > -c KXLjoystick.c  -fPIC -DPIC -o .libs/KXLjoystick.o
> > KXLmisc.c: In function 'KXL_ReadU16':
> > KXLmisc.c:196:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   196 |   fread(c, 1, 2, fp);
> >   |   ^~
> > KXLmisc.c: In function 'KXL_ReadU32':
> > KXLmisc.c:209:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   209 |   fread(c, 1, 4, fp);
> >   |   ^~
> > KXLsound.c: In function 'KXL_SoundServer':
> > KXLsound.c:75:9: error: implicit declaration of function 'read'; did you 
> > mean 'fread'? [-Werror=implicit-function-declaration]
> >75 | if (read(KXL_SoundData.Pipe[0], &Command,sizeof(Command)) != 
> > sizeof(Command))
> >   | ^~~~
> >   | fread
> > KXLsound.c:165:9: error: implicit declaration of function 'write'; did you 
> > mean 'fwrite'? [-Werror=implicit-function-declaration]
> >   165 | write(KXL_SoundData.Device, KXL_SoundData.PBuff, 
> > fragment_size);
> >   | ^
> >   | fwrite
> > KXLimage.c: In function 'KXL_ReadBitmapHeader':
> > KXLimage.c:112:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   112 |   fread(hed->magic, 1, 2, fp);
> >   |   ^~~
> > KXLimage.c:166:7: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   166 |   fread(&(hed->data[i * hed->w]), hed->w, 1, fp);
> >   |   ^~
> > KXLsound.c: In function 'KXL_InitSound':
> > KXLsound.c:262:7: error: implicit declaration of function 'pipe' 
> > [-Werror=implicit-function-declaration]
> >   262 |   if (pipe(KXL_SoundData.Pipe) < 0) {
> >   |   ^~~~
> > KXLsound.c:267:27: error: implicit declaration of function 'fork' 
> > [-Werror=implicit-function-declaration]
> >   267 |   if ((KXL_SoundData.ID = fork()) < 0) {
> >   |   ^~~~
> > KXLsound.c:273:5: error: implicit declaration of function 'close'; did you 
> > mean 'pclose'? [-Werror=implicit-function-declaration]
> >   273 | close(KXL_SoundData.Pipe[1]);
> >   | ^
> >   | pclose
> > KXLsound.c: In function 'KXL_LoadSound':
> > KXLsound.c:213:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   213 |   fread(dummy, sizeof(Uint8), 40, file);
> >   |   ^
> > KXLsound.c:216:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   216 |   fread(new.Data, sizeof(Uint8), new.Length, file);
> >   |   ^~~~
> > KXLjoystick.c: In function 'KXL_CloseJoystick':
> > KXLjoystick.c:43:5: error: implicit declaration of function 'close'; did 
> > you mean 'pclose'? [-Werror=implicit-function-declaration]
> >43 | close(KXL_joydev);
> >   | ^
> >   | pclose
> > KXLjoystick.c: In function 'KXL_ReadJoystick':
> > KXLjoystick.c:55:9: error: implicit declaration of function 'read'; did you 
> > mean 'fread'? [-Werror=implicit-function-declaration]
> >55 | if (read(KXL_joydev, my, JS_RETURN) == JS_RETURN) {
> >   | ^~~~
> >   | fread
> >  gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"KXL\" 
> > -DVERSION=\"1.1.7\" -DHAVE_SYS_TYPES_

Bug#1066671: geki3: FTBFS: boss.c:205:11: error: implicit declaration of function ‘CreateEnemyBomb’; did you mean ‘CreateEnemyShot’? [-Werror=implicit-function-declaration]

[Guillem Jover]

Hi!

On Fri, 2024-05-03 at 12:57:21 +0200, Guillem Jover wrote:
> The attached patch should fix this FTBFS

Sorry, please use the attached patch instead which fixes some typos in
the patch description.

Thanks,
Guillem
diff --git c/debian/patches/020_headers.diff i/debian/patches/020_headers.diff
index 106a56b..23dfadb 100644
--- c/debian/patches/020_headers.diff
+++ i/debian/patches/020_headers.diff
@@ -1,22 +1,19 @@
-Index: geki3-1.0.3/src/ranking.c
-===
 geki3-1.0.3.orig/src/ranking.c 2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/ranking.c  2006-05-09 20:38:01.0 +0200
-@@ -1,4 +1,5 @@
- #include 
-+#include 
- #include "geki3.h"
- #include "extern.h"
- 
-Index: geki3-1.0.3/src/geki3.h
-===
 geki3-1.0.3.orig/src/geki3.h   2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/geki3.h2006-05-09 20:38:01.0 +0200
-@@ -9,6 +9,7 @@
+---
+ src/geki3.h |3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/src/geki3.h
 b/src/geki3.h
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include "KXL.h"
+ 
diff --git c/debian/patches/020_implicit-decl.patch 
i/debian/patches/020_implicit-decl.patch
new file mode 100644
index 000..ba22660
--- /dev/null
+++ i/debian/patches/020_implicit-decl.patch
@@ -0,0 +1,59 @@
+Description: Add and fix function declarations
+ With the compiler setting -Werror=implicit-function-declaration by default,
+ we need to properly declare all functions in the relevant headers.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+---
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.h |2 +-
+ src/your.h|2 ++
+ 4 files changed, 5 insertions(+), 2 deletions(-)
+
+--- a/src/your.h
 b/src/your.h
+@@ -6,9 +6,11 @@ void CreateItem(Sint16 x, Sint16 y, PixD
+ RcHitEnum HitEnemyToBall(CharacterData *my, CharacterData *your);
+ 
+ /** Bomb **/
++void CreateEnemyBomb(Sint16 x, Sint16 y, Uint16 direction, Uint16 speed);
+ RcHitEnum MoveBomb(CharacterData *my);
+ RcHitEnum HitEnemyToBomb(CharacterData *my, CharacterData *your);
+ RcHitEnum MoveEnemyBomb(CharacterData *my);
++void CreateMissile(CharacterData *my, Sint16 x, Sint16 y);
+ RcHitEnum MoveMissile(CharacterData *my);
+ void CreateEnemyShot(Sint16 x, Sint16 y, Uint16 direction, Uint16
+speed, Uint8 sel);
+--- a/src/load.c
 b/src/load.c
+@@ -221,7 +221,7 @@ void LoadStageData(void)
+ /**
+   ���ơǡ��
+  **/
+-void UnLoadStageData()
++void UnLoadStageData(void)
+ {
+   Uint16 bossmax[] = {3, 6, 4, 4};
+ 
+--- a/src/load.h
 b/src/load.h
+@@ -9,5 +9,6 @@ void UnLoadPixmaps(PixData **my, Uint16
+ void CreatePixmap(void);
+ void DeletePixmap(void);
+ void LoadStageData(void);
++void UnLoadStageData(void);
+ 
+ #endif
+--- a/src/ranking.h
 b/src/ranking.h
+@@ -1,7 +1,7 @@
+ #ifndef _RANKING_H_
+ #define _RANKING_H_
+ 
+-void RankingScore(void);
++int ScoreRanking(void);
+ void ReadScore(void);
+ void WriteScore(void);
+ 
diff --git c/debian/patches/020_score_path.diff 
i/debian/patches/020_score_path.diff
index 313a0c2..b3b2dab 100644
--- c/debian/patches/020_score_path.diff
+++ i/debian/patches/020_score_path.diff
@@ -1,8 +1,10 @@
-Index: geki3-1.0.3/src/ranking.c
-===
 geki3-1.0.3.orig/src/ranking.c 2006-05-09 20:42:06.0 +0200
-+++ geki3-1.0.3/src/ranking.c  2006-05-09 20:42:55.0 +0200
-@@ -38,7 +38,7 @@
+---
+ src/ranking.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/src/ranking.c
 b/src/ranking.c
+@@ -37,7 +37,7 @@ void ReadScore(void)
FILE *fp;
Uint16 i;
  
@@ -11,7 +13,7 @@ Index: geki3-1.0.3/src/ranking.c
  fscanf(fp, "%"SCNu32, &(Root->HiScore));
  for (i = 0; i < 5; i ++)
fscanf(fp, "%"SCNu32" %"SCNu8" %"SCNu8" %s",
-@@ -70,7 +70,7 @@
+@@ -69,7 +69,7 @@ void WriteScore(void)
FILE *fp;
Uint16 i;
  
diff --git c/debian/patches/020_shot_keys.diff 
i/debian/patches/020_shot_keys.diff
index cb35fe5..02b54f8 100644
--- c/debian/patches/020_shot_keys.diff
+++ i/debian/patches/020_shot_keys.diff
@@ -1,8 +1,12 @@
-Index: geki3-1.0.3/src/main.c
-===
 geki3-1.0.3.orig/src/main.c2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/main.c 2006-05-09 20:39:45.0 +0200
-@@ -23,6 +23,7 @@
+---
+ src/geki3.h   |2 ++
+ src/main.c|2 ++
+ src/opening.c |4 ++--
+ 3 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/src/main.c
 b/src/main.c
+@@ -23,6 +23,7 @@ void MainLoop(void)
case KXL_EVENT_KEY_PRESS: /*�

Bug#1066549: geki2: FTBFS: misc.c:127:7: error: implicit declaration of function ‘ScoreRanking’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Hi!

On Fri, 2024-05-03 at 13:06:21 +0200, Guillem Jover wrote:
> Actually, the attached debdiff should be better (properly split
> patches).

Hrmmf, sorry, please use the attached patch, which fixes some typos in
the patch description. :)

Thanks,
Guillem
diff -Nru geki2-2.0.3/debian/patches/020_headers.diff 
geki2-2.0.3/debian/patches/020_headers.diff
--- geki2-2.0.3/debian/patches/020_headers.diff 2018-05-13 16:22:49.0 
+0200
+++ geki2-2.0.3/debian/patches/020_headers.diff 2024-05-03 13:00:11.0 
+0200
@@ -4,29 +4,25 @@
 
 ===
 ---
- src/geki2.h   | 1 +
- src/ranking.c | 1 +
- 2 files changed, 2 insertions(+)
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
 
-diff --git a/src/geki2.h b/src/geki2.h
-index 938d760..b293afb 100644
 --- a/src/geki2.h
 +++ b/src/geki2.h
-@@ -9,6 +9,7 @@
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include 
-diff --git a/src/ranking.c b/src/ranking.c
-index a6683c5..4e3df6c 100644
 a/src/ranking.c
-+++ b/src/ranking.c
-@@ -1,4 +1,5 @@
- #include 
-+#include 
- #include "geki2.h"
- #include "extern.h"
  
diff -Nru geki2-2.0.3/debian/patches/020_implicit-decl.patch 
geki2-2.0.3/debian/patches/020_implicit-decl.patch
--- geki2-2.0.3/debian/patches/020_implicit-decl.patch  1970-01-01 
01:00:00.0 +0100
+++ geki2-2.0.3/debian/patches/020_implicit-decl.patch  2024-05-03 
12:59:08.0 +0200
@@ -0,0 +1,47 @@
+Description: Add and fix function declarations
+ With the compiler setting -Werror=implicit-function-declaration by default,
+ we need to properly declare all functions in the relevant headers.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+===
+---
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
+
+--- a/src/load.c
 b/src/load.c
+@@ -237,7 +237,7 @@ void LoadStageData(void)
+ /**
+   ���ơǡ��
+  **/
+-void UnLoadStageData()
++void UnLoadStageData(void)
+ {
+   Uint8 bossmax[] = {2, 3 * 2, 1 * 2, 1 * 2, 1 * 2, 1 * 2};
+   Uint8 backmax[] = {7, 16, 20, 8, 18, 15};
+--- a/src/load.h
 b/src/load.h
+@@ -9,5 +9,6 @@ void UnLoadPixmaps(PixData **my, int max
+ void CreatePixmap(void);
+ void DeletePixmap(void);
+ void LoadStageData(void);
++void UnLoadStageData(void);
+ 
+ #endif
+--- a/src/ranking.h
 b/src/ranking.h
+@@ -1,7 +1,7 @@
+ #ifndef _RANKING_H_
+ #define _RANKING_H_
+ 
+-void RankingScore(void);
++int ScoreRanking(void);
+ void ReadScore(void);
+ void WriteScore(void);
+ 
diff -Nru geki2-2.0.3/debian/patches/020_scanf.diff 
geki2-2.0.3/debian/patches/020_scanf.diff
--- geki2-2.0.3/debian/patches/020_scanf.diff   2018-05-13 16:22:49.0 
+0200
+++ geki2-2.0.3/debian/patches/020_scanf.diff   2024-05-03 13:03:10.0 
+0200
@@ -4,12 +4,10 @@
 
 ===
 ---
- src/load.c| 2 +-
- src/ranking.c | 4 ++--
+ src/load.c|2 +-
+ src/ranking.c |4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)
 
-diff --git a/src/load.c b/src/load.c
-index e771eca..284ed8f 100644
 --- a/src/load.c
 +++ b/src/load.c
 @@ -216,7 +216,7 @@ void LoadStageData(void)
@@ -21,11 +19,9 @@
 &(StageDatas[Root->StageMax]->Time),
 &(StageDatas[Root->StageMax]->CreateNo),
 &(StageDatas[Root->StageMax]->Max),
-diff --git a/src/ranking.c b/src/ranking.c
-index 4e3df6c..2ed04af 100644
 --- a/src/ranking.c
 +++ b/src/ranking.c
-@@ -39,9 +39,9 @@ void ReadScore(void)
+@@ -38,9 +38,9 @@ void ReadScore(void)
Uint16 i;
  
if ((fp = fopen(DATA_PATH "/.score", "r"))) {
diff -Nru geki2-2.0.3/debian/patches/020_score_path.diff 
geki2-2.0.3/debian/patches/020_score_path.diff
--- geki2-2.0.3/debian/patches/020_score_path.diff  2018-05-13 
16:22:49.0 +0200
+++ geki2-2.0.3/debian/patches/020_score_path.diff  2024-05-03 
13:03:13.0 +0200
@@ -4,14 +4,12 @@
 
 ===
 ---
- src/ranking.c | 4 ++--
+ src/ranking.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
-diff --git a/src/ranking.c b/src/ranking.c
-index 2ed04af..fe3f4fc 100644
 --- a/src/ranking.c
 +++ b/src/ranking.c
-@@ -38,7 +38,7 @@ void ReadScore(void)
+@@ -37,7 +37,7 @@ void ReadScore(void)
FILE *fp;
Uint16 i;
  
@@ -20,7 +18,7 @@
  fscanf(fp, "%"SCNu32, &(Root->HiScore));
  for (i = 0; i < 5; i ++)
fscanf(fp, "%"SCNu3

Bug#1066390: gravitywars: FTBFS: misc.c:6:9: error: implicit declaration of function ‘keyboard_update’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:51:07 +0100, Lucas Nussbaum wrote:
> Source: gravitywars
> Version: 1.102-35
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > cc -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > -DUSE_SDL -DUSE_JOYSTICK `pkg-config sdl --cflags` -Wdate-time 
> > -D_FORTIFY_SOURCE=2  -c -o blocks.o blocks.c
> > misc.c: In function ‘waitanykey’:
> > misc.c:6:9: error: implicit declaration of function ‘keyboard_update’ 
> > [-Werror=implicit-function-declaration]
> > 6 |   while(keyboard_update())
> >   | ^~~
> > misc.c:7:5: error: implicit declaration of function ‘vga_waitretrace’ 
> > [-Werror=implicit-function-declaration]
> > 7 | vga_waitretrace();
> >   | ^~~
> > misc.c: In function ‘doPanic’:
> > misc.c:18:3: error: implicit declaration of function ‘printf’ 
> > [-Werror=implicit-function-declaration]
> >18 |   printf("--\n"
> >   |   ^~
> > misc.c:1:1: note: include ‘’ or provide a declaration of ‘printf’
> >   +++ |+#include 
> > 1 | /* GravityWars 1.1,  (C) Sami Niemi -95 */
> > misc.c:18:3: warning: incompatible implicit declaration of built-in 
> > function ‘printf’ [-Wbuiltin-declaration-mismatch]
> >18 |   printf("--\n"
> >   |   ^~
> > misc.c:18:3: note: include ‘’ or provide a declaration of ‘printf’
> > misc.c:21:3: error: implicit declaration of function ‘keyboard_close’ 
> > [-Werror=implicit-function-declaration]
> >21 |   keyboard_close();
> >   |   ^~
> > misc.c:22:3: error: implicit declaration of function ‘mouse_close’ 
> > [-Werror=implicit-function-declaration]
> >22 |   mouse_close();
> >   |   ^~~
> > misc.c:23:3: error: implicit declaration of function ‘exit’ 
> > [-Werror=implicit-function-declaration]
> >23 |   exit(1);
> >   |   ^~~~
> > misc.c:1:1: note: include ‘’ or provide a declaration of ‘exit’
> >   +++ |+#include 
> > 1 | /* GravityWars 1.1,  (C) Sami Niemi -95 */
> > misc.c:23:3: warning: incompatible implicit declaration of built-in 
> > function ‘exit’ [-Wbuiltin-declaration-mismatch]
> >23 |   exit(1);
> >   |   ^~~~
> > misc.c:23:3: note: include ‘’ or provide a declaration of ‘exit’
> > hole.c: In function ‘OLDmakehole’:
> > hole.c:30:3: error: implicit declaration of function ‘vga_setpage’ 
> > [-Werror=implicit-function-declaration]
> >30 |   vga_setpage(page);
> >   |   ^~~
> > hole.c: In function ‘makehole’:
> > hole.c:68:3: error: implicit declaration of function ‘getbox’ 
> > [-Werror=implicit-function-declaration]
> >68 |   getbox(x,y,tmpmix);
> >   |   ^~
> > hole.c:80:3: error: implicit declaration of function ‘changeblocks’ 
> > [-Werror=implicit-function-declaration]
> >80 |   changeblocks(x,y,tmpmix);
> >   |   ^~~~
> > pixel.c: In function ‘setpixel’:
> > pixel.c:11:3: error: implicit declaration of function ‘vga_setpage’ 
> > [-Werror=implicit-function-declaration]
> >11 |   vga_setpage(adr >> 16);
> >   |   ^~~
> > bullet.c: In function ‘setbullet’:
> > bullet.c:17:3: error: implicit declaration of function ‘vga_setpage’ 
> > [-Werror=implicit-function-declaration]
> >17 |   vga_setpage(page);
> >   |   ^~~
> > cc1: some warnings being treated as errors
> > make[2]: *** [: misc.o] Error 1

The attached debdiff patch should fix this.

I pondered creating a single header and including all declarations
there to have a smaller delta, but decided to follow the existing
pattern in the project. If you'd prefer to see a single header,
instead of all new headers, I'm happy to rework the patch.

Thanks,
Guillem
diff -Nru gravitywars-1.102/debian/patches/implicit-decls.patch gravitywars-1.102/debian/patches/implicit-decls.patch
--- gravitywars-1.102/debian/patc

Bug#1066549: geki2: FTBFS: misc.c:127:7: error: implicit declaration of function ‘ScoreRanking’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Hi!

On Fri, 2024-05-03 at 12:42:19 +0200, Guillem Jover wrote:
> Control: tag -1 patch

> On Wed, 2024-03-13 at 12:50:29 +0100, Lucas Nussbaum wrote:
> > Source: geki2
> > Version: 2.0.3-10
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef
> 
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > This is most likely caused by a change in dpkg 1.22.6, that enabled
> > -Werror=implicit-function-declaration. For more information, see
> > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> > 
> > Relevant part (hopefully):
> > > gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"geki2-KXL\" 
> > > -DVERSION=\"2.0.3\" -DHAVE_LIBKXL=1 -DHAVE_LIBKXL=1 -DHAVE_SYS_TYPES_H=1 
> > > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> > > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
> > > -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 
> > > -DDATA_PATH=\"/usr/share/games/geki2/data\" 
> > > -DBMP_PATH=\"/usr/share/games/geki2/bmp\" 
> > > -DWAV_PATH=\"/usr/share/games/geki2/wav\" -DTITLE=\"geki2-KXL\ 2.0.3\"  
> > > -I. -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > > -Werror=implicit-function-declaration 
> > > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > > -c misc.c
> > > misc.c: In function ‘ClearAndGameOver’:
> > > misc.c:127:7: error: implicit declaration of function ‘ScoreRanking’ 
> > > [-Werror=implicit-function-declaration]
> > >   127 |   ScoreRanking();
> > >   |   ^~~~
> > > misc.c:132:5: error: implicit declaration of function ‘UnLoadStageData’; 
> > > did you mean ‘LoadStageData’? [-Werror=implicit-function-declaration]
> > >   132 | UnLoadStageData();
> > >   | ^~~
> > >   | LoadStageData
> > > cc1: some warnings being treated as errors
> > > make[2]: *** [Makefile:233: misc.o] Error 1
> 
> The attached debdiff patch should fix the build.

Actually, the attached debdiff should be better (properly split
patches).

Thanks,
Guillem
diff -Nru geki2-2.0.3/debian/patches/020_headers.diff 
geki2-2.0.3/debian/patches/020_headers.diff
--- geki2-2.0.3/debian/patches/020_headers.diff 2018-05-13 16:22:49.0 
+0200
+++ geki2-2.0.3/debian/patches/020_headers.diff 2024-05-03 13:00:11.0 
+0200
@@ -4,29 +4,25 @@
 
 ===
 ---
- src/geki2.h   | 1 +
- src/ranking.c | 1 +
- 2 files changed, 2 insertions(+)
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
 
-diff --git a/src/geki2.h b/src/geki2.h
-index 938d760..b293afb 100644
 --- a/src/geki2.h
 +++ b/src/geki2.h
-@@ -9,6 +9,7 @@
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include 
-diff --git a/src/ranking.c b/src/ranking.c
-index a6683c5..4e3df6c 100644
 a/src/ranking.c
-+++ b/src/ranking.c
-@@ -1,4 +1,5 @@
- #include 
-+#include 
- #include "geki2.h"
- #include "extern.h"
  
diff -Nru geki2-2.0.3/debian/patches/020_implicit-decl.patch 
geki2-2.0.3/debian/patches/020_implicit-decl.patch
--- geki2-2.0.3/debian/patches/020_implicit-decl.patch  1970-01-01 
01:00:00.0 +0100
+++ geki2-2.0.3/debian/patches/020_implicit-decl.patch  2024-05-03 
12:59:08.0 +0200
@@ -0,0 +1,47 @@
+Description: And and fix function declarations
+ With the compiler now dafeaulting to -Werror=implicit-function-declaration,
+ we need to properly declare all functions in the relevant headers.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+===
+---
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
+
+--- a/src/load.c
 b/src/load.c
+@@ -237,7 +237,7 @@ void LoadStageData(void)
+ /**
+   ���ơǡ��
+  **/
+-void UnLoadStageData()
++void UnLoadStageData(void)
+ {
+   Uint8 bossmax[] = {2, 3 * 2, 1 * 2, 1 * 2, 1 * 

Bug#1066671: geki3: FTBFS: boss.c:205:11: error: implicit declaration of function ‘CreateEnemyBomb’; did you mean ‘CreateEnemyShot’? [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:50:31 +0100, Lucas Nussbaum wrote:
> Source: geki3
> Version: 1.0.3-10
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"geki3-KXL\" 
> > -DVERSION=\"1.0.3\" -DHAVE_LIBKXL=1 -DHAVE_LIBKXL=1 -DHAVE_SYS_TYPES_H=1 
> > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
> > -DHAVE_UNISTD_H=1 -DDATA_PATH=\"/usr/share/games/geki3/data\" 
> > -DBMP_PATH=\"/usr/share/games/geki3/bmp\" 
> > -DWAV_PATH=\"/usr/share/games/geki3/wav\" -DTITLE=\"geki3-KXL\ 1.0.3\"  -I. 
> > -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection -c boss.c
> > boss.c: In function ‘MovePenguin’:
> > boss.c:205:11: error: implicit declaration of function ‘CreateEnemyBomb’; 
> > did you mean ‘CreateEnemyShot’? [-Werror=implicit-function-declaration]
> >   205 |   CreateEnemyBomb(my->X + 20,
> >   |   ^~~
> >   |   CreateEnemyShot
> > boss.c: In function ‘MoveTurtle’:
> > boss.c:302:11: error: implicit declaration of function ‘CreateMissile’; did 
> > you mean ‘CreateBoss’? [-Werror=implicit-function-declaration]
> >   302 |   CreateMissile(my, my->X - 8, my->Y);
> >   |   ^
> >   |   CreateBoss
> > cc1: some warnings being treated as errors
> > make[2]: *** [Makefile:233: boss.o] Error 1

The attached patch should fix this FTBFS

Thanks,
Guillem
diff --git c/debian/patches/020_headers.diff i/debian/patches/020_headers.diff
index 106a56b..23dfadb 100644
--- c/debian/patches/020_headers.diff
+++ i/debian/patches/020_headers.diff
@@ -1,22 +1,19 @@
-Index: geki3-1.0.3/src/ranking.c
-===
 geki3-1.0.3.orig/src/ranking.c	2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/ranking.c	2006-05-09 20:38:01.0 +0200
-@@ -1,4 +1,5 @@
- #include 
-+#include 
- #include "geki3.h"
- #include "extern.h"
- 
-Index: geki3-1.0.3/src/geki3.h
-===
 geki3-1.0.3.orig/src/geki3.h	2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/geki3.h	2006-05-09 20:38:01.0 +0200
-@@ -9,6 +9,7 @@
+---
+ src/geki3.h |3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/src/geki3.h
 b/src/geki3.h
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include "KXL.h"
+ 
diff --git c/debian/patches/020_implicit-decl.patch i/debian/patches/020_implicit-decl.patch
new file mode 100644
index 000..ba22660
--- /dev/null
+++ i/debian/patches/020_implicit-decl.patch
@@ -0,0 +1,59 @@
+Description: And and fix function declarations
+ With the compiler now dafeaulting to -Werror=implicit-function-declaration,
+ we need to properly declare all functions in the relevant headers.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+---
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.h |2 +-
+ src/your.h|2 ++
+ 4 files changed, 5 insertions(+), 2 deletions(-)
+
+--- a/src/your.h
 b/src/your.h
+@@ -6,9 +6,11 @@ void CreateItem(Sint16 x, Sint16 y, PixD
+ RcHitEnum HitEnemyToBall(CharacterData *my, CharacterData *your);
+ 
+ /** Bomb **/
++void CreateEnemyBomb(Sint16 x, Sint16 y, Uint16 direction, Uint16 speed);
+ RcHitEnum MoveBomb(CharacterData *my);
+ RcHitEnum HitEnemyToBomb(CharacterData *my, CharacterData *your);
+ RcHitEnum MoveEnemyBomb(CharacterData *my);
++void CreateMissile(CharacterData *my, Sint16 x, Sint16 y);
+ RcHitEnum MoveMissile(CharacterData *my);
+ void CreateEnemyShot(Sint16 x, Sint16 y, Uint16 direction, Uint16
+ 		 speed, Uint8 sel);
+--- a/src/load.c
 b/src/load.c
+@@ -221,7 +221,7 @@ void LoadStageData(void)

Bug#1066549: geki2: FTBFS: misc.c:127:7: error: implicit declaration of function ‘ScoreRanking’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:50:29 +0100, Lucas Nussbaum wrote:
> Source: geki2
> Version: 2.0.3-10
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"geki2-KXL\" 
> > -DVERSION=\"2.0.3\" -DHAVE_LIBKXL=1 -DHAVE_LIBKXL=1 -DHAVE_SYS_TYPES_H=1 
> > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
> > -DHAVE_UNISTD_H=1 -DDATA_PATH=\"/usr/share/games/geki2/data\" 
> > -DBMP_PATH=\"/usr/share/games/geki2/bmp\" 
> > -DWAV_PATH=\"/usr/share/games/geki2/wav\" -DTITLE=\"geki2-KXL\ 2.0.3\"  -I. 
> > -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection -c misc.c
> > misc.c: In function ‘ClearAndGameOver’:
> > misc.c:127:7: error: implicit declaration of function ‘ScoreRanking’ 
> > [-Werror=implicit-function-declaration]
> >   127 |   ScoreRanking();
> >   |   ^~~~
> > misc.c:132:5: error: implicit declaration of function ‘UnLoadStageData’; 
> > did you mean ‘LoadStageData’? [-Werror=implicit-function-declaration]
> >   132 | UnLoadStageData();
> >   | ^~~
> >   | LoadStageData
> > cc1: some warnings being treated as errors
> > make[2]: *** [Makefile:233: misc.o] Error 1

The attached debdiff patch should fix the build.

Thanks,
Guillem
diff -Nru geki2-2.0.3/debian/patches/020_headers.diff 
geki2-2.0.3/debian/patches/020_headers.diff
--- geki2-2.0.3/debian/patches/020_headers.diff 2018-05-13 16:22:49.0 
+0200
+++ geki2-2.0.3/debian/patches/020_headers.diff 2024-05-03 12:36:38.0 
+0200
@@ -4,24 +4,28 @@
 
 ===
 ---
- src/geki2.h   | 1 +
- src/ranking.c | 1 +
- 2 files changed, 2 insertions(+)
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
 
-diff --git a/src/geki2.h b/src/geki2.h
-index 938d760..b293afb 100644
 --- a/src/geki2.h
 +++ b/src/geki2.h
-@@ -9,6 +9,7 @@
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include 
-diff --git a/src/ranking.c b/src/ranking.c
-index a6683c5..4e3df6c 100644
+ 
 --- a/src/ranking.c
 +++ b/src/ranking.c
 @@ -1,4 +1,5 @@
@@ -30,3 +34,34 @@
  #include "geki2.h"
  #include "extern.h"
  
+--- a/src/load.c
 b/src/load.c
+@@ -237,7 +237,7 @@ void LoadStageData(void)
+ /**
+   ���ơǡ��
+  **/
+-void UnLoadStageData()
++void UnLoadStageData(void)
+ {
+   Uint8 bossmax[] = {2, 3 * 2, 1 * 2, 1 * 2, 1 * 2, 1 * 2};
+   Uint8 backmax[] = {7, 16, 20, 8, 18, 15};
+--- a/src/load.h
 b/src/load.h
+@@ -9,5 +9,6 @@ void UnLoadPixmaps(PixData **my, int max
+ void CreatePixmap(void);
+ void DeletePixmap(void);
+ void LoadStageData(void);
++void UnLoadStageData(void);
+ 
+ #endif
+--- a/src/ranking.h
 b/src/ranking.h
+@@ -1,7 +1,7 @@
+ #ifndef _RANKING_H_
+ #define _RANKING_H_
+ 
+-void RankingScore(void);
++int ScoreRanking(void);
+ void ReadScore(void);
+ void WriteScore(void);
+ 
diff -Nru geki2-2.0.3/debian/patches/020_score_path.diff 
geki2-2.0.3/debian/patches/020_score_path.diff
--- geki2-2.0.3/debian/patches/020_score_path.diff  2018-05-13 
16:22:49.0 +0200
+++ geki2-2.0.3/debian/patches/020_score_path.diff  2024-05-03 
12:37:05.0 +0200
@@ -4,11 +4,9 @@
 
 ===
 ---
- src/ranking.c | 4 ++--
+ src/ranking.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
-diff --git a/src/ranking.c b/src/ranking.c
-index 2ed04af..fe3f4fc 100644
 --- a/src/ranking.c
 +++ b/src/ranking.c
 @@ -38,7 +38,7 @@ void ReadScore(void)
diff -Nru geki2-2.0.3/debian/patches/020_shot_keys.diff 
geki2-2.0.3/debian/patches/020_shot_keys.diff
--- geki2-2.0.3/debian/patches/020_shot_keys.diff   2018-05-13 
16:22:49.0 +0200
+++ geki2-2.0.3/debian/patches/020_shot_keys.diff   2024-05-03 
12:37:35.0 +0200
@@ -4,16 +4,14 @@
 
 ===
 ---
- src/geki2.h   | 2 ++
- 

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Guillem Jover]

Control: severity -1 normal

Hi!

On Mon, 2024-04-29 at 00:01:02 +0200, Chris Hofstaedtler wrote:
> Control: reassign -1 dpkg
> 
> * Vincent Lefevre  [240428 22:33]:
> > Package: fdisk
> > Version: 2.40-8
> > Severity: serious
> ...
> > Setting up util-linux (2.40-8) ...
> > fstrim.service is a disabled or a static unit not running, not starting it.
> > dpkg: error: dpkg frontend lock was locked by another process with pid 58569
> > Note: removing the lock file is always wrong, can damage the locked area
> > and the entire system. See .
> > ==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) 
> > ==
> > 
> > -  Show old opportunities as well as new ones: how-can-i-help --old  
> > -
> > E: Sub-process /usr/bin/dpkg returned an error code (2)
> > Setting up bsdextrautils (2.40-8) ...
> > dpkg: dependency problems prevent configuration of fdisk:
> >  fdisk depends on libfdisk1 (= 2.40-8); however:
> >   Version of libfdisk1:amd64 on system is 2.40-6.
> > 
> > dpkg: error processing package fdisk (--configure):
> >  dependency problems - leaving unconfigured
> > Setting up eject (2.40-8) ...
> > Setting up perl-modules-5.38 (5.38.2-4) ...
> > Setting up mount (2.40-8) ...
> > Setting up libperl5.38t64:amd64 (5.38.2-4) ...
> > Setting up util-linux-extra (2.40-8) ...
> > Setting up perl (5.38.2-4) ...
> > Processing triggers for libc-bin (2.37-19) ...
> > Processing triggers for man-db (2.12.1-1) ...
> > Processing triggers for mailcap (3.70+nmu1) ...
> > Errors were encountered while processing:
> >  fdisk
> > 
> > There seem to be 2 issues: one with the dpkg lock (which may be
> > bug 1069183 in aptitude) and one

> Possible.

I don't think dpkg is at fault here, I assume something else is either
getting activated in the middle of the transaction while the package
manager frontend driving dpkg has released the lock (which it should
not), or the package manager frontend driving dpkg is performing the
locking dance incorrectly.

> > with fdisk.
> 
> I see no evidence of that in the log.

Right, it seems to me, like when dpkg fails due to the already held
lock, then the frontend is not recomputing the transaction and keeps
as if nothing had gone incorrectly, until it then notices later on.


In any case, given that dpkg is not being very helpful in diagnosing
this, I'll implement support to print the process name in addition to
the pid, as this has also hit me, and it's never clear what was the
actual culprit. So that's why I'm leaving this assigned to dpkg, but
with a lower severity. If you'd like to file this elsewhere, then
please clone and reassign that.

Thanks,
Guillem

Bug#1066507: closed by Debian FTP Masters (reply to Guillem Jover ) (Bug#1066507: fixed in kannel 1.4.5-14)

[Guillem Jover]

Hi!

On Sat, 2024-03-16 at 01:12:07 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:kannel package:
> 
> #1066507: kannel: FTBFS: configure: error: Either get a multithread-enabled 
> SSL or configure with --disable-ssl
> 
> It has been closed by Debian FTP Masters  
> (reply to Guillem Jover ).

Just sending keep-alive mail to avoid the auto-removal, as the bug is
already fixed in sid, but not migrating due to the time64 transition.

Thanks,
Guillem

Bug#1066952: Defaulting to -Werror=implicit-function-declaration might not be a good idea

[Guillem Jover]

Hi!

On Sat, 2024-03-16 at 02:18:22 +0200, Adrian Bunk wrote:
> Package: dpkg-dev
> Version: 1.22.6
> Severity: serious
> X-Debbugs-Cc: Steve Langasek 

> 3. Code that does still compile with -Werror=implicit-function-declaration
>but behaves differently, e.g. due to failing autoconf tests silently
>disabling features

> Debian has automation listing implicit-function-declaration warnings
> in all packages already running for several years:
> https://qa.debian.org/bls/bytag/W-implicit-declaration.html

> My main worry is point 3, issues like #1066394.
> 
> #1066394 was found due to causing a FTBFS in a different package,
> but the more common case is likely that a program has some
> feature/plugin disabled and this won't be spotted until much later.
> 
> "Much later" might be after the release of trixie a user upgrading
> to bookworm who uses this feature.
> 
> Or it might result in a program silently using an insecure legacy codepath,
> e.g. after a test for getentropy() failed.

Not enabling this -Werror might imply ABI breakage for the time64
transition, which seems pretty terrible too. The way I see it, and
given the timing, effort and preparation necessary for this transition,
both options (enabling or not enabling the fatal warning) are potentially
bad in their own way.

But given that these are clearly bugs, that not enabling them can imply
ABI breakage, that if things go according to plan (AFAIK) this will be
made the default anyway with gcc-14, that we can track those down, and
people have already been doing that for the Modern-C effort, see:

  https://fedoraproject.org/wiki/Changes/PortingToModernC
  https://wiki.gentoo.org/wiki/Modern_C_porting

I think we might as well just cope with this anyway right away.

> A large part of the packages in unstable might not get recompiled
> between now and the release of trixie, creating the additional
> issue that any such problem might occur only after a security update
> or point release update if this is the next rebuild of the package
> in trixie.

AFAIUI (and I'd expect) the whole distribution needs to be rebuilt
anyway as part of the time64 transition, otherwise the 32-bit ports
that are affected by it, will not benefit from it. So I don't think
this should be a concern.

So I'm inclined to close this, and consider the current state, the
less bad one. :/

Thanks,
Guillem

Bug#1065371: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1065371 pending

Hi!

Bug #1065371 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=4993fe783

---
Dpkg::Vendor::Debian: Make it possible to disable qa=-bug-implicit-func

We do not need to forcibly enable this feature if the user explicitly
specified it.

Closes: #1065371

Bug#1065486: sbd: FTBFS due to hardcoded libaio SONAME used in dlopen()

[Guillem Jover]

Source: sbd
Source-Version: 1.5.2-1
Severity: serious
Tags: patch upstream

Hi!

For the time64 transition I've done a local SONAME bump. This will
make this package FTBFS (once the mass binNMUs are triggered) due to
its test suite hardcoding the libaio SONAME for a dlopen() call.

Because the package is already explicitly linking against -laio (which
I guess also means there's a missing Build-Depends here), we are
guaranteed to have libaio.so available, so we can use that to avoid
hardcoding the SONAME. Of course dlopen()ing a shared library like
this is dangerous as the code might use the wrong ABI and that might
go unnoticed at build time, so perhaps it might also be worth
investigating in the future whether the dlopen is really necessary at
all (the test case is already being linked also against -laio).

The attached patch fixes the build for me with the new libaio.

Thanks,
Guillem
Description: Do not hardcode libaio SONAME
 The SONAME might change, and then the dlopen() fails. This just happened now
 as part of the time64 transition. The package is already linking explicitly
 against -laio, thus libaio.so will be guaranteed to be present, so instead
 of hardcoding the current SONAME at this point in time, simply use libaio.so.
Author: Guillem Jover 
Last-Update: 2024-03-05

---
 tests/sbd-testbed.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/tests/sbd-testbed.c
+++ b/tests/sbd-testbed.c
@@ -154,9 +154,9 @@ init (void)
 orig_fopen= (orig_fopen_f_type)dlsym_fatal(RTLD_NEXT,"fopen");
 orig_fclose   = (orig_fclose_f_type)dlsym_fatal(RTLD_NEXT,"fclose");
 
-handle = dlopen("libaio.so.1",  RTLD_NOW);
+handle = dlopen("libaio.so",  RTLD_NOW);
 if (!handle) {
-fprintf(stderr, "Failed opening libaio.so.1\n");
+fprintf(stderr, "Failed opening libaio.so\n");
 exit(1);
 }
 orig_io_setup = (orig_io_setup_f_type)dlsym_fatal(handle,"io_setup");

Bug#1062218: in package libaio marked as pending

[Guillem Jover]

Control: tag 1062218 pending

Hi!

Bug #1062218 that you reported in package libaio has been fixed
in the debian/pkgs/libaio.git git repository. You can see the changelog below,
and you can check the diff of the fix at:

https://git.hadrons.org/cgit/debian/pkgs/libaio.git/diff/?id=8d2d6c2

---
commit 8d2d6c2930be1e34cb357ab4f1b8d42471a16f77
Author: Guillem Jover 
Date:   Tue Mar 5 11:33:36 2024 +0100

Add time64 support

- Remove dead code for syscall handling.
- Refactor code to use an internal implementation for public functions
  that handle timespec, by switching them to always use __kernel_timespec,
  and add conversion functions to map from 'struct timespec' to
  'struct __kernel_timespec', and from 'struct __kernel_timespec' to
  'struct __kernel_old_timespec'.
- Add support for io_pgetevents_time64() Linux syscall, but disable it
  for now as it only works on 32-bit kernels, but not on the compat
  mode in 64-bit kernels running 32-bit userland, will be fixed in Linux
  in parallel, as the timeouts used are supposed to be relative anyway,
  and this does not and will not break ABI.
- Add dual time32/time64 ABI support by adding io_getevents_time64() and
  io_pgetevents_time64() library functions on 32-bit architectures, that
  get redirected from the io_getevents() and io_pgetevents() functions
  when the user sets _TIME_BITS=64.
- Perform a SONAME bump to avoid stomping on upstream SONAME. Once and if
  the new symbols are accepted by upstream then we can merge that back
  into libaio.so.1 and drop the t64 packages and temporarily provide
  a compat symlink for the t64 SONAME for a smooth transition back. This
  should also be an easier way to revert this transition when there are
  no file conflicts involved, and does not block on upstream support.
- Do not rename the udeb from libaio1-udeb, as d-i does not care, and
  that would require a pointless trip through NEW. But update the shlibs
  references for the libaio1t64 rename.
- We do not need a dependency on a newer dpkg-dev nor gcc as we are
  explicitly handling the time64 dual-ABI independently of the toolchain.

Closes: #1062218

diff --git a/debian/changelog b/debian/changelog
index 4163262..5eb83fb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,34 @@ libaio (0.3.113-6) UNRELEASED; urgency=medium
 
   * Switch from future=+lfs to abi=+lfs build flags feature, and Build-Depends
 on dpkg-dev >= 1.22.0.
+  * Add time64 support:
+- Remove dead code for syscall handling.
+- Refactor code to use an internal implementation for public functions
+  that handle timespec, by switching them to always use __kernel_timespec,
+  and add conversion functions to map from 'struct timespec' to
+  'struct __kernel_timespec', and from 'struct __kernel_timespec' to
+  'struct __kernel_old_timespec'.
+- Add support for io_pgetevents_time64() Linux syscall, but disable it
+  for now as it only works on 32-bit kernels, but not on the compat
+  mode in 64-bit kernels running 32-bit userland, will be fixed in Linux
+  in parallel, as the timeouts used are supposed to be relative anyway,
+  and this does not and will not break ABI.
+- Add dual time32/time64 ABI support by adding io_getevents_time64() and
+  io_pgetevents_time64() library functions on 32-bit architectures, that
+  get redirected from the io_getevents() and io_pgetevents() functions
+  when the user sets _TIME_BITS=64.
+- Perform a SONAME bump to avoid stomping on upstream SONAME. Once and if
+  the new symbols are accepted by upstream then we can merge that back
+  into libaio.so.1 and drop the t64 packages and temporarily provide
+  a compat symlink for the t64 SONAME for a smooth transition back. This
+  should also be an easier way to revert this transition when there are
+  no file conflicts involved, and does not block on upstream support.
+- Do not rename the udeb from libaio1-udeb, as d-i does not care, and
+  that would require a pointless trip through NEW. But update the shlibs
+  references for the libaio1t64 rename.
+- We do not need a dependency on a newer dpkg-dev nor gcc as we are
+  explicitly handling the time64 dual-ABI independently of the toolchain.
+Closes: #1062218
 
  -- Guillem Jover   Wed, 17 Jan 2024 02:57:39 +0100
 

Bug#1062218: libaio: NMU diff for 64-bit time_t transition

[Guillem Jover]

Hi!

On Mon, 2024-03-04 at 13:51:19 +0100, Guillem Jover wrote:
> I've got all the upstream changes now ready, except that there's still
> one test case failing, something wrong with the sigset_t type. I've run
> out of time trying to track this down, but I've pushed what I have on
> the pu/time64 branch, and will continue later today.

In the end this looks like Linux has a broken io_pgetevents_tiem64()
syscall on 32-bit userland running on 64-bit kernels. The syscall
works fine on 32-bit kernels though. I've disabled this for now given
that the time_t usage is for relative timeouts anyway, and because
the library ABI now will use proper types, and the underlying
implementation can be fixed after a while once I've looked into
fixing the compat syscall in Linux.

I'm preparing an upload right now with a SONAME bump.

Thanks,
Guillem

Bug#1062218: libaio: NMU diff for 64-bit time_t transition

[Guillem Jover]

Hi!

On Sun, 2024-03-03 at 23:00:00 +0100, Guillem Jover wrote:
> On Thu, 2024-02-29 at 02:35:16 +0100, Guillem Jover wrote:
> > Control: tags -1 - pending
> 
> > On Wed, 2024-01-31 at 19:36:09 +, Steve Langasek wrote:
> > > Source: libaio
> > > Version: 0.3.113-5
> > > Severity: serious
> > > Tags: patch pending
> > > Justification: library ABI skew on upgrade
> > > User: debian-...@lists.debian.org
> > > Usertags: time-t
> > 
> > > Please find the patch for this NMU attached.
> > > 
> > > If you have any concerns about this patch, please reach out ASAP.  
> > > Although
> > > this package will be uploaded to experimental immediately, there will be a
> > > period of several days before we begin uploads to unstable; so if 
> > > information
> > > becomes available that your package should not be included in the 
> > > transition,
> > > there is time for us to amend the planned uploads.
> > 
> > Unfortunately I just realized this patch is not enough. :/ This library
> > emits direct syscalls, so these are going to be broken with the time_t
> > size change, the syscalls need to be updated. I'm checking how to best
> > fix this, perhaps even via dual-ABI, to avoid the transition
> > altogether, but let's see.
> > 
> > I guess this might have been missed for other packages that that emit
> > direct syscalls and are not using the time64 variants for those
> > already.
> 
> Just as a status update, I've got most of this working, but upstream
> does not tend to be very responsive, so I think I'll do a proper
> SONAME bump with my proposed changes for the dual-ABI, to avoid any
> potential clashes with anything that gets upstream, and to make a
> revert easier, by reusing the t64 library names. And then once/if this
> gets merged upstream I can revert that and simply do the proper
> dual-ABI on the old SONAME and package names, as if nothing had
> happened (except for the required rebuilds).
> 
> Hopefully I can have something for upload today or tomorrow, hoping
> that this delay up to now, does not block too many things. :/

I've got all the upstream changes now ready, except that there's still
one test case failing, something wrong with the sigset_t type. I've run
out of time trying to track this down, but I've pushed what I have on
the pu/time64 branch, and will continue later today.

Thanks,
Guillem

Bug#1062218: libaio: NMU diff for 64-bit time_t transition

[Guillem Jover]

Hi!

On Thu, 2024-02-29 at 02:35:16 +0100, Guillem Jover wrote:
> Control: tags -1 - pending

> On Wed, 2024-01-31 at 19:36:09 +, Steve Langasek wrote:
> > Source: libaio
> > Version: 0.3.113-5
> > Severity: serious
> > Tags: patch pending
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> 
> > Please find the patch for this NMU attached.
> > 
> > If you have any concerns about this patch, please reach out ASAP.  Although
> > this package will be uploaded to experimental immediately, there will be a
> > period of several days before we begin uploads to unstable; so if 
> > information
> > becomes available that your package should not be included in the 
> > transition,
> > there is time for us to amend the planned uploads.
> 
> Unfortunately I just realized this patch is not enough. :/ This library
> emits direct syscalls, so these are going to be broken with the time_t
> size change, the syscalls need to be updated. I'm checking how to best
> fix this, perhaps even via dual-ABI, to avoid the transition
> altogether, but let's see.
> 
> I guess this might have been missed for other packages that that emit
> direct syscalls and are not using the time64 variants for those
> already.

Just as a status update, I've got most of this working, but upstream
does not tend to be very responsive, so I think I'll do a proper
SONAME bump with my proposed changes for the dual-ABI, to avoid any
potential clashes with anything that gets upstream, and to make a
revert easier, by reusing the t64 library names. And then once/if this
gets merged upstream I can revert that and simply do the proper
dual-ABI on the old SONAME and package names, as if nothing had
happened (except for the required rebuilds).

Hopefully I can have something for upload today or tomorrow, hoping
that this delay up to now, does not block too many things. :/

Thanks,
Guillem

Bug#1065371: unable to disable bug-implicit-func for time64

[Guillem Jover]

Hi!

On Sun, 2024-03-03 at 16:46:33 +0100, Guillem Jover wrote:
> On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:
> >  - please provide an opt-out option.
> 
> This is a bug, which I should fix.

The first attached patch is what I'd use to fix this.

> >  - turn it on on all architectures, so that everbody
> >can reproduce the effects.
> 
> I'd be fine with that.

The second attached patch is what I'd use to implement this, if
there's agreement. (Barring manual page updates here.)

I'll wait for Steve's input, before proceeding, otherwise I might just
upload the first patch for now, either later today or tomorrow, so that
people can opt-out of this until there's agreement on how to proceed.
(Even though I guess people could already use DEB_CFLAGS_MAINT_STRIP to
forcibly disable the -Werror=implicit-function-declaration flag.)

Thanks,
Guillem
From f747a38746cbf0fa4279e773835b7d872c0d313c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Mar 2024 18:42:34 +0100
Subject: [PATCH] Dpkg::Vendor::Debian: Make it possible to disable
 qa=-bug-implicit-func

We do not need to forcibly enable this feature if the user explicitly
specified it.

Closes: #1065371
---
 scripts/Dpkg/Vendor/Debian.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index fcf5b1e2a..ad727d2cf 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -299,8 +299,8 @@ sub set_build_features {
 $use_feature{abi}{lfs} = 1 if $libc eq 'gnu';
 
 # Require -Werror=implicit-function-declaration, to avoid linking
-# against the wrong symbol.
-$use_feature{qa}{'bug-implicit-func'} = 1;
+# against the wrong symbol, unless it has been set explicitly.
+$use_feature{qa}{'bug-implicit-func'} //= 1;
 }
 
 # XXX: Handle lfs alias from future abi feature area.
-- 
2.43.0

From 87702728876e96891d02df2d1b0419f709939190 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Mar 2024 18:53:12 +0100
Subject: [PATCH] Dpkg::Vendor::Debian: Unconditionally set qa
 bug-implicit-func

For the time64 default change, we conditionally enabled
bug-implicit-func to avoid silent ABI breakage due to implicit function
declarations that end up using the time32 symbols, but that is causing
confusion as the effects are not visible on the most commonly used
architectures. Instead enable this globally, unless the maintainer has
specified otherwise.
---
 scripts/Dpkg/Vendor/Debian.pm | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index ad727d2cf..b3be69e86 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -117,7 +117,7 @@ sub set_build_features {
 time64 => undef,
 },
 qa => {
-bug => 0,
+bug => undef,
 'bug-implicit-func' => undef,
 canary => 0,
 },
@@ -297,10 +297,6 @@ sub set_build_features {
 if ($use_feature{abi}{time64} && ! $builtin_feature{abi}{time64}) {
 # On glibc 64-bit time_t support requires LFS.
 $use_feature{abi}{lfs} = 1 if $libc eq 'gnu';
-
-# Require -Werror=implicit-function-declaration, to avoid linking
-# against the wrong symbol, unless it has been set explicitly.
-$use_feature{qa}{'bug-implicit-func'} //= 1;
 }
 
 # XXX: Handle lfs alias from future abi feature area.
@@ -311,7 +307,14 @@ sub set_build_features {
 
 ## Area: qa
 
-$use_feature{qa}{'bug-implicit-func'} //= $use_feature{qa}{bug};
+# For time64 we require -Werror=implicit-function-declaration, to avoid
+# linking against the wrong symbol. Instead of enabling this conditionally
+# on time64 being enabled, do it unconditionally so that the effects are
+# uniform and visible on all architectures. Unless it has been set
+# explicitly.
+$use_feature{qa}{'bug-implicit-func'} //= $use_feature{qa}{bug} // 1;
+
+$use_feature{qa}{bug} //= 0;
 
 ## Area: reproducible
 
-- 
2.43.0

Bug#1065371: unable to disable bug-implicit-func for time64

[Guillem Jover]

On Sun, 2024-03-03 at 16:57:28 +0100, Matthias Klose wrote:
> On 03.03.24 16:46, Guillem Jover wrote:
> > On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:
> > > I just filed another bug report for bc, together with the one for heimdal.
> > > 
> > > Please turn this off for a while, it's really harmful for the time64
> > > bootstrap.
> > 
> > This was added on request by Steve, to help with the time64 changes.
> > 
> > > When you turn it on again,
> > > 
> > >   - please provide an opt-out option.
> > 
> > This is a bug, which I should fix.
> > 
> > >   - turn it on on all architectures, so that everbody
> > > can reproduce the effects.
> > 
> > I'd be fine with that.
> > 
> > >   - before turning it on again, please do an archive wide
> > > test rebuild and file bug reports for it.
> > 
> > My impression is that this was done as part of the time64 checks? If
> > not, and the consensus is to disable the flag, I'm very unlikely to
> > drive this, and someone else will need to do those rebuilds and post
> > results.
> 
> I can do that, but we will need a stable dpkg version and a dpkg upload
> providing that setting on amd64 without time64 set. Then I'll ask Lucas for
> two test rebuilds (at this stage, that would be testing).

> Doing test rebuilds with time64 enabled on testing doesn't make sense for
> now, and unstable is too unstable.

Hmm, I'm not sure I understand what you are asking here, so let me try
to rephrase, you'd like to see:

  - a dpkg 1.22.6 upload for unstable to the Debian archive with the
bug-implicit-func unconditionally set?
  - a dpkg 1.21.x version out-of-archive with the bug-implicit-func
support  backported and also enabled by default?

For the former you should be able to do that already by setting the
flag to enable via DEB_BUILD_OPTIONS with the version already in sid,
if you don't want time64 then you can also disable that there. The
latter I don't understand, so perhaps I interpreted that incorrectly
from what you said.

> > I think making the opt-out functional might be enough to help with
> > this, and I could upload a fix later today, which would not disarm
> > this safety net for the time64 transition. But at this point I don't
> > mind either way, and if people prefer disabling the warning then I can
> > do that instead.
> 
> at least for heimdal, three people spent several hours looking for the cause
> of the failure. I'm not sure we want these kind of delays for the
> transition.

While that's unfortunate, I think that might be better than silently
letting ABI breakage through due to the missing Werror flag.

Thanks,
Guillem

Bug#1065371: unable to disable bug-implicit-func for time64

[Guillem Jover]

Hi!

On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:
> Control: severity -1 serious

> I just filed another bug report for bc, together with the one for heimdal.
> 
> Please turn this off for a while, it's really harmful for the time64
> bootstrap.

This was added on request by Steve, to help with the time64 changes.

> When you turn it on again,
> 
>  - please provide an opt-out option.

This is a bug, which I should fix.

>  - turn it on on all architectures, so that everbody
>can reproduce the effects.

I'd be fine with that.

>  - before turning it on again, please do an archive wide
>test rebuild and file bug reports for it.

My impression is that this was done as part of the time64 checks? If
not, and the consensus is to disable the flag, I'm very unlikely to
drive this, and someone else will need to do those rebuilds and post
results.


I think making the opt-out functional might be enough to help with
this, and I could upload a fix later today, which would not disarm
this safety net for the time64 transition. But at this point I don't
mind either way, and if people prefer disabling the warning then I can
do that instead.

Thanks,
Guillem

Bug#1062218: libaio: NMU diff for 64-bit time_t transition

[Guillem Jover]

Control: tags -1 - pending

Hi!

On Wed, 2024-01-31 at 19:36:09 +, Steve Langasek wrote:
> Source: libaio
> Version: 0.3.113-5
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t

> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

Unfortunately I just realized this patch is not enough. :/ This library
emits direct syscalls, so these are going to be broken with the time_t
size change, the syscalls need to be updated. I'm checking how to best
fix this, perhaps even via dual-ABI, to avoid the transition
altogether, but let's see.

I guess this might have been missed for other packages that that emit
direct syscalls and are not using the time64 variants for those
already.

Thanks,
Guillem

Bug#1064909: in package libbsd marked as pending

[Guillem Jover]

Control: tag 1064909 pending

Hi!

Bug #1064909 that you reported in package libbsd has been fixed
in the debian/pkgs/libbsd.git git repository. You can see the changelog below,
and you can check the diff of the fix at:

https://git.hadrons.org/cgit/debian/pkgs/libbsd.git/diff/?id=864f359

---
commit 864f359fe0eae118b73726c26591a0447c299359
Author: Guillem Jover 
Date:   Wed Feb 28 05:15:20 2024 +0100

New libbsd upstream release 0.12.1

- Fix missing installation of err.h. Closes: #1064909

diff --git a/debian/changelog b/debian/changelog
index 39f7b9e..0afdbbe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libbsd (0.12.1-1) UNRELEASED; urgency=medium
+
+  * New upstream release.
+- Fix missing installation of err.h. Closes: #1064909
+
+ -- Guillem Jover   Wed, 28 Feb 2024 05:13:52 +0100
+
 libbsd (0.12.0-1) unstable; urgency=medium
 
   * New upstream release.

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Guillem Jover]

Hi!

On Tue, 2024-02-27 at 17:33:16 +0100, Alejandro Colomar wrote:
> Package: libbsd-dev
> Version: 0.12.0-1
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> X-Debbugs-Cc: a...@kernel.org

> After upgrading to libbsd 0.12 today, several build systems that I use
> started reporting many failures about libbsd functions.  The functions
> seem to have disappeared.  I remember having seen that the build system
> of libbsd has been recently tweaked, so I suspect one of those changes
> might be the cause of the problem.
> 
> Here's a small reproducer:
> 
>   $ cat bsd.c 
>   #include 
> 
>   long
>   strtoi_(char *s, char **endp, int b, long min, long max, int *st)
>   {
>   return strtoi(s, endp, b, min, max, st);
>   }

> Which reports the following error:
> 
>   $ gcc -Wall -Wextra -S bsd.c 
>   bsd.c: In function ‘strtoi_’:
>   bsd.c:6:16: warning: implicit declaration of function ‘strtoi’; did you 
> mean ‘strtoi_’? [-Wimplicit-function-declaration]
>   6 | return strtoi(s, endp, b, min, max, st);
> |^~
> |strtoi_

The strtoi() function is declared in . I don't think that
has changed in libbsd.

> BTW, thanks for updating strtoi/u(3) from NetBSD!  =)

Thanks for handling the upstream interaction in NetBSD!

On Tue, 2024-02-27 at 17:42:43 +0100, Alejandro Colomar wrote:
> On Tue, Feb 27, 2024 at 05:33:16PM +0100, Alejandro Colomar wrote:
> > I've also seen errc(3bsd) disappear, and possibly many more functions.
> > If you need some help to reproduce this issue, just let me know.
> 
> In the case of , the header has disappeared:
> 
>   $ cat bsd.c 
>   #include 
>   #include 
> 
>   long
>   strtoi_(char *s, char **endp, int b, long min, long max, int *st)
>   {
>   return strtoi(s, endp, b, min, max, st);
>   }
>   alx@debian:~/tmp$ gcc -Wall -Wextra -S bsd.c
>   bsd.c:1:10: fatal error: bsd/err.h: No such file or directory
>   1 | #include 
> |  ^~~
>   compilation terminated.
> 
> This seems consistent with the recent build system changes.  The bug is
> probably there.

Ah, it indeed has disappeared. The upstream build system is missing a
conditional for the header, I'll add this later today and prepare a
new upstream release.

Another thing which I was aware, but then slipped my mind is that the
cdefs.h header needs to be placed under a multi-arch qualified
directory otherwise it will conflict with other instances of the
library now that it contains arch-specific defines. Will amend that
with the new Debian upload.

Thanks,
Guillem

Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Guillem Jover]

Hi!

On Thu, 2024-02-15 at 16:48:43 -0800, Steve Langasek wrote:
> Control: forwarded -1 seli...@vger.kernel.org
> 
> Patch now forwarded upstream for review.
> 
> https://lore.kernel.org/selinux/zc6tzkpsyzric...@homer.dodds.net/T/#t

> On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek wrote:
> > Well, "already" is not exactly correct, but the need to resolve this
> > critical showstopper bug in libselinux before making changes to the
> > toolchain behavior in unstable and breaking the world has affected the
> > timeline, yes.
> > 
> > I now have a tested patch that I've raised as an MP in salsa:
> > 
> >   https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9
> > 
> > I welcome review from the Debian libselinux maintainers prior to opening a
> > discussion with upstream.  (Which I will plan to do sometime Thursday
> > US/Pacific)

Thanks for preparing the patch. I checked it and left a comment on the
MR there.

Regards,
Guillem

Bug#1063646: tix: missing required debian/rules targets build-arch and/or build-indep

[Guillem Jover]

Source: tix
Version: 8.4.3-11
Severity: serious
Justification: Debian Policy section 4.9
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: missing-build-arch-indep

Dear maintainer,

Your package does not include build-arch and/or build-indep targets in
debian/rules. This is required by Debian Policy section 4.9, since 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please note that this is also a sign that the packaging of this software
could benefit from a refresh. For example, packages using 'dh' cannot be
affected by this issue.

This mass bug filing was discussed on debian-devel@ in
.
(The severity of this bug at the time of the mass bug filing was set to
'important', and bumped to 'serious' after a month, but given that quite
some time has passed, I'm just setting it directly to 'serious' now, as
I'm planning to remove the fallback workaround for these targets in the
next dpkg upload.)

Thanks,
Guillem

Bug#1063647: sysconfig: missing required debian/rules targets build-arch and/or build-indep

[Guillem Jover]

Source: sysconfig
Version: 0.0.14
Severity: serious
Justification: Debian Policy section 4.9
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: missing-build-arch-indep

Dear maintainer,

Your package does not include build-arch and/or build-indep targets in
debian/rules. This is required by Debian Policy section 4.9, since 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please note that this is also a sign that the packaging of this software
could benefit from a refresh. For example, packages using 'dh' cannot be
affected by this issue.

This mass bug filing was discussed on debian-devel@ in
.
(The severity of this bug at the time of the mass bug filing was set to
'important', and bumped to 'serious' after a month, but given that quite
some time has passed, I'm just setting it directly to 'serious' now, as
I'm planning to remove the fallback workaround for these targets in the
next dpkg upload.)

Thanks,
Guillem

Bug#1063644: atitvout: missing required debian/rules targets build-arch and/or build-indep

[Guillem Jover]

Source: atitvout
Version: 0.4-13.2
Severity: serious
Justification: Debian Policy section 4.9
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: missing-build-arch-indep

Dear maintainer,

Your package does not include build-arch and/or build-indep targets in
debian/rules. This is required by Debian Policy section 4.9, since 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please note that this is also a sign that the packaging of this software
could benefit from a refresh. For example, packages using 'dh' cannot be
affected by this issue.

This mass bug filing was discussed on debian-devel@ in
.
(The severity of this bug at the time of the mass bug filing was set to
'important', and bumped to 'serious' after a month, but given that quite
some time has passed, I'm just setting it directly to 'serious' now, as
I'm planning to remove the fallback workaround for these targets in the
next dpkg upload.)

Thanks,
Guillem

Bug#1063645: markdown: missing required debian/rules targets build-arch and/or build-indep

[Guillem Jover]

Source: markdown
Version: 1.0.1-12
Severity: serious
Justification: Debian Policy section 4.9
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: missing-build-arch-indep

Dear maintainer,

Your package does not include build-arch and/or build-indep targets in
debian/rules. This is required by Debian Policy section 4.9, since 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please note that this is also a sign that the packaging of this software
could benefit from a refresh. For example, packages using 'dh' cannot be
affected by this issue.

This mass bug filing was discussed on debian-devel@ in
.
(The severity of this bug at the time of the mass bug filing was set to
'important', and bumped to 'serious' after a month, but given that quite
some time has passed, I'm just setting it directly to 'serious' now, as
I'm planning to remove the fallback workaround for these targets in the
next dpkg upload.)

Thanks,
Guillem

Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Guillem Jover]

Hi!

On Tue, 2024-02-06 at 15:42:33 +0100, Helmut Grohne wrote:
> On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote:
> > Providing two APIs makes me quite uneasy due to having core components
> > that would behave differently from the rest of the distribution. It
> > sounds like something that will come back to bite for a long time.
> 
> Can you elaborate?

Yes, I'm not sure I understand either. This is what symbol versioning
makes possible, even providing different variants for the same symbol,
see for example glibc or libbsd.

In any case, if going the bi-ABI path, I think upstream should get
involved, and the shape of this decided with them. In addition
the library should also be built with LFS by the upstream build
system, which it does not currently, to control its ABI.

> Keep in mind that for all the 64bit architectures, there is no abi
> difference as the symbol is only added for those architectures, that
> currently use a 32bit ino_t.

> > I checked on codesearch.d.n and there are very few users on this API;
> > actually, none I think. Per
> > https://codesearch.debian.net/search?q=matchpathcon_filespec_add&literal=1&perpkg=1
> > - box64 mentions that API but the "code" is commented-out,
> > - busybox uses it in the "setfiles" applet which isn't built,
> > - android-platform-external-libselinux has it in headers but also has
> >   its own implementation
> > 
> > That should hopefully give more freedom although I'm not sure what would
> > be the preferred route.
> 
> And here you are arguing that there are no practical users of the added
> symbol, so with luck, we'd be adding an unused symbol on armhf. With bad
> luck, we'd have some users and for those users we'd be ABI-incompatible
> with the rest of the world on armhf.

I think there are only three ways to go about this, excluding the t64
attempt:

 1) Build the library with LFS unconditionally (except on i386). As there
are no users in Debian, this would not break there, but would
break for any external packages and locally unpackaged users of
the library.

 2) Bump the SONAME, ideally coordinate with upstream or alternatively
with a Debian specific one. This does not break locally built
packages nor locally unpackaged code linking against the library.

 3) Build the library with LFS support (everywhere including i386),
and on systems w/o built-in LFS, make the old symbol use 32-bit ino_t,
and add a new symbol that uses 64-bit ino_t. This preserves the
ABI, for external packages and locally unpackaged code linking
against the library.

I think the three options would cause no upgrade issues, as they
include either no SONAME bump (option 1 and 3), or an actual SONAME
bump (option 2) with no file conflicts involved.

Personally I'd like to be able to cleanly and safely build dpkg with
time64 everywhere (including i386, otherwise the port will not be even
installable), so my preference is for options that make that possible
(2 and 3), and from those the one with best backwards compatibility with
was the main concern for excluding i386 from the time64 transition would
be option 3. So I think that would be the preferred option here.

If you'd like assistance with trying to get a proposal for 3 to
present upstream I could look into that. But I think they should be
involved early on to see what they'd like to see and what they might
outright reject.

Thanks,
Guillem

Bug#1059266: in package dupload marked as pending

[Guillem Jover]

Control: tag 1059266 pending

Hi!

Bug #1059266 in package dupload reported by you has been fixed in
the dpkg/dupload.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dupload.git/diff/?id=62a1cb0

---
Revert "hooks: Rewrite openpgp-check in perl for Dpkg::OpenPGP multi-backend 
support"

This reverts commit 2f2e0e528d4435fd529971250786b08475a105c0.

This broke current usage, as users might not have the vendor keyring
package installed, the vendor might not have keyring support in dpkg,
or the host might not even be using one of the vendor keyrings or
the certificates might not be located in the gpgv trustedkeys.gpg.

We should make the keyrings to use per host configurable, and both
the backend, its commands and whether to use its certificate store
configurable by the user too. Until this is done, let's revert for
now to avoid the regressions.

Closes: #1059266

Bug#1059266: error: cannot verify inline signature

[Guillem Jover]

Hi!

On Fri, 2023-12-22 at 19:37:16 +0100, Aurelien Jarno wrote:
> On 2023-12-22 19:23, Aurelien Jarno wrote:
> > This also causes issues on the riscv64 build daemons running sid:
> > 
> > | dupload exit status 9/0
> > | Removed  to reupload later.
> > | 
> > | Complete output from dupload:
> > | 
> > | dupload note: no announcement will be sent.
> > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 
> > 22 18:06:16 2023 UTC
> > | gpgv:using RSA key 
> > 670D3AC041E218107D0DE6F9339F749981589F2F
> > | gpgv: Can't check signature: No public key
> > | openpgp-check: error: cannot verify inline signature for 
> > emmax_0~beta.20100307-4_riscv64-buildd.changes: no acceptable signature 
> > found
> > | 
> > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed 
> > for emmax_0~beta.20100307-4_riscv64-buildd.changes

Ouch, ok.

> > On 2023-12-22 12:16, Guillem Jover wrote:
> > > Just to understand what is going wrong, I assume you don't have the
> > > debian-keyring package installed (where the signing certificate could
> > > be found in the debian-keyring.gpg keyring), nor the certificate for
> > > A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?
> > 
> > For debian build daemons, it is not expected to have the keys in the
> > debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not
> > exist.
> > 
> > > But gpg has it in its certificate store?
> > 
> > Yes:
> > 
> > buildd@rv-manda-01:~/.gnupg$ gpg -K
> > /home/buildd/.gnupg/pubring.kbx
> > ---
> > sec   rsa4096 2023-12-08 [SC] [expire : 2024-12-07]
> >   670D3AC041E218107D0DE6F9339F749981589F2F
> > uid  [  ultime ] buildd autosigning key rv-manda-01 
> > 
> 
> It seems the decision to trust the key comes from ~/.gnupg/trustdb.gpg,
> not from ~/.gnupg/trustedkeys.gpg.

The trustedkeys.gpg is a keyring used mainly by gpgv (gpg does not use
it by default, except that the dpkg code will feed it as an additional
keyring if it is found.

I'll prepare an upload right away and force the code to use gpg for
now (as it was used before the recent upload, instead of trying gpgv,
sqop, pgpainless-cli, or sq), until I've devised a better migration
plan, or implemented enough configuration options for people to switch
or use other OpenPGP backends when desired.

Thanks,
Guillem

Bug#1059266: error: cannot verify inline signature

[Guillem Jover]

Hi!

On Fri, 2023-12-22 at 10:53:18 +0100, Christian Marillat wrote:
> Package: dupload
> Version: 2.10.4
> Severity: grave

> This version fail to check a signature. Work fine with 2.10.3
> 
> ,
> | $ debrelease 
> | dupload note: no announcement will be sent.
> | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 
> 10:50:05 2023 CET
> | gpgv:using RSA key A401FF99368FA1F98152DE755C808C2B65558117
> | gpgv:issuer "maril...@deb-multimedia.org"
> | gpgv: Can't check signature: No public key
> | openpgp-check: error: cannot verify inline signature for 
> ../gerbera-dmo_1.12.1-dmo5_amd64.changes: no acceptable signature found
> | 
> | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for 
> ../gerbera-dmo_1.12.1-dmo5_amd64.changes
> `

Just to understand what is going wrong, I assume you don't have the
debian-keyring package installed (where the signing certificate could
be found in the debian-keyring.gpg keyring), nor the certificate for
A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?

But gpg has it in its certificate store?

(Also wondering whether dpkg-source can verify the source for that,
as it is using the same logic as the rewritten hook is using now?)

Thanks,
Guillem

Bug#1055580: dlt-daemon: Runs daemon as user nobody with owned files on fsys

[Guillem Jover]

Package: dlt-daemon
Version: 2.18.0-1
Severity: serious
Tags: security

Hi!

This daemon runs as user nobody, while creating multiple files on the
filesystem owned by the same user, which are used as part of its
security protection. This is a security issue, given that other
daemons on the system might be running as the same user, and worse
when dlt-daemon is writing and parsing files from hardcoded paths
under /tmp.

From base-passwd/users-and-groups.txt.gz:

  ,---
nobody, nogroup
  Daemons that need not own any files sometimes run as
  user nobody and group nogroup, although using a
  dedicated user is far preferable. Thus, no files on a
  system should be owned by this user or group.

  (Technically speaking, it does no harm for a file to be
  owned by group nogroup as long as the ownership confers
  no additional privileges, that is if the group and other
  permission bits are equal. However, this is sloppy
  practice and should be avoided.)

  If root-squashing is in use over NFS, root access from
  the client is performed as user nobody on the server.
  `---

If you are going to fix this by using a dedicated user/group, please
make sure to namespace them with «_» to distinguish them as system
users and avoid unnecessary collisions with non-system, users. (Such
as _dlt or similar.)

[ The version I used is the earliest I found with the same issue from
  the tracker.d.o page, earlier version might be affected too, dunno. ]

Thanks,
Guillem

Bug#1054999: dlt-daemon: FTBFS: 5: /bin/sh: 1: killall: not found

[Guillem Jover]

Control: tag -1 patch

Hi!

On Sun, 2023-10-29 at 06:55:23 +0100, Lucas Nussbaum wrote:
> Source: dlt-daemon
> Version: 2.18.10-5
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231028 ftbfs-trixie

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > 89% tests passed, 1 tests failed out of 9
> > 
> > Total Test time (real) =   6.07 sec
> > 
> > The following tests FAILED:
> >   8 - gtest_dlt_daemon_multiple_files_logging (SIGTRAP)
> > Errors while running CTest
> > make[1]: *** [Makefile:74: test] Error 8
> > make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j8 test 
> > ARGS\+=--verbose ARGS\+=-j8 returned exit code 2

So the problem is that the test suite is no parallel safe, as various
test cases use the same files under /tmp (!) and incur into race
conditions. The missing killall is not a cause of failure (!), but for
me is what helped me trigger this issue locally. (I'm filing another
report for the /tmp stuff.)

Attached a series of patches that "fix" this (and some of other
cleanups. The only ones needed to workaround this problem are patch 2
and 3. Although ideally the test suite would be made parallel safe by
using different files for each test case.

Thanks,
Guillem
From 509a491ddbb36d8312a0c4db3eb5b0778aa9c7f7 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 7 Nov 2023 18:47:45 +0100
Subject: [PATCH 1/5] Run wrap-and-sort -sat

This makes changes when diffing sources minimal. As a side effect it
also removes a duplicate dependency on libsystemd-dev.
---
 debian/control | 44 ++
 debian/dlt-daemon.install  |  1 +
 debian/dlt-tools.install   |  8 +++
 debian/libdlt-dev.dirs |  2 +-
 debian/libdlt-dev.install  |  2 +-
 debian/libdlt-examples.install |  8 +++
 6 files changed, 45 insertions(+), 20 deletions(-)

diff --git a/debian/control b/debian/control
index 7cf89c9..e9e47b4 100644
--- a/debian/control
+++ b/debian/control
@@ -1,8 +1,19 @@
 Source: dlt-daemon
 Priority: optional
 Maintainer: Aigars Mahinovs 
-Uploaders: Gianfranco Costamagna 
-Build-Depends: debhelper-compat (= 13), cmake, zlib1g-dev, libdbus-1-dev, doxygen, libgtest-dev, libsystemd-dev, pandoc, systemd, libsystemd-dev, libjson-c-dev
+Uploaders:
+ Gianfranco Costamagna ,
+Build-Depends:
+ cmake,
+ debhelper-compat (= 13),
+ doxygen,
+ libdbus-1-dev,
+ libgtest-dev,
+ libjson-c-dev,
+ libsystemd-dev,
+ pandoc,
+ systemd,
+ zlib1g-dev,
 Standards-Version: 4.6.2
 Section: libs
 Rules-Requires-Root: no
@@ -12,7 +23,9 @@ Package: libdlt-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libdlt2 (= ${binary:Version}), ${misc:Depends}
+Depends:
+ libdlt2 (= ${binary:Version}),
+ ${misc:Depends},
 Description: Diagnostic Log and Trace (DLT) library (development)
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -25,7 +38,9 @@ Description: Diagnostic Log and Trace (DLT) library (development)
 Package: libdlt2
 Architecture: any
 Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: Diagnostic Log and Trace (DLT) library
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -37,8 +52,11 @@ Description: Diagnostic Log and Trace (DLT) library
 Package: dlt-daemon
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: dlt-tools
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Suggests:
+ dlt-tools,
 Description: Diagnostic Log and Trace logging daemon
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -55,8 +73,11 @@ Description: Diagnostic Log and Trace logging daemon
 Package: dlt-tools
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: dlt-daemon
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Suggests:
+ dlt-daemon,
 Description: Diagnostic Log and Trace (DLT) (documentation)
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -70,8 +91,11 @@ Description: Diagnostic Log and Trace (DLT) (documentation)
 Package: libdlt-examples
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: dlt-daemon
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Suggests:
+ dlt-daemon,
 

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Guillem Jover]

Hi!

[ CCed Russ for the pod2man side of this. ]

On Mon, 2023-08-14 at 14:18:51 +0200, Samuel Thibault wrote:
> I'm marking this important, and am tempted to raise it to serious...
> 
> The problem at stake is that we have already a hard time making
> newcomers read manpages. If they can't even trust copying/pasting lines
> from them, they will just definitely turn away, and we'll aggravate the
> schism between us olders and newcomers. Trust me from 20-year teaching
> experience...

This is not just copy&pasting, searching in formatted man pages from
within a pager or with grep for example does not work any more (well
you can always use «.» but that's rather unintuitive).

> Yes, we'd ideally want to fix all manpages to have everything set
> alright. But we have to do that before the release. And if that's not
> complete, release with the
> 
> .char - \-
> 
> workaround.

Whenever I've maintained man pages in roff I tend to be precise in
the usage of - and \-, but TBH this has seemed like a lost battle,
more so since at least lintian stopped emitting tags for it. And
another problem which I think it's going to be very hard to fix is
with man page generators from other formats, such as pod2man, where
it currently has heuristics to determine when to use - or \-, but it
does not currently has a way to accurately do this always.

> As in: maybe we can leave the symptom open until the freeze period, so
> that developers notice the issue and fix their bugs, and on the freeze
> period, introduce the workaround so that end users of the eventual
> released distribution don't get affected while we are still fixing the
> bugs.

While in an ideal world that might be good, I'm not sure this is worth
the pain, and fixing this (if deemed necessary) out of linting tags
seems like a better plan?

Thanks,
Guillem

Bug#1051189: intel-opencl-icd: Uninstallable since intel-graphics-compiler 1.0.14896.8-1 upload

[Guillem Jover]

Package: intel-opencl-icd
Version: 22.43.24595.41-1
Severity: serious

Hi!

This package has become uninstallable since the upload of the source
package intel-graphics-compiler 1.0.14896.8-1:

  ,---
  $ apt install intel-opencl-icd
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   intel-opencl-icd : Depends: libigc1 (< 1.0.12504.6+~) but 1.0.14896.8-1 is 
to be installed
  Depends: libigdfcl1 (< 1.0.12504.6+~) but 1.0.14896.8-1 
is to be installed
  E: Unable to correct problems, you have held broken packages.
  `---

Thanks,
Guillem

Bug#1043118: victoriametrics: FTBFS: test failure

[Guillem Jover]

Hi!

On Tue, 2023-08-08 at 14:59:45 +0300, Denys Holius wrote:
> The latest version of VictoriaMetrics v1.92.0
>  should be marked as
> LTS but it has some backwards-incompatible changes. Meanwhile v1.87.6
>  was marked as LTS
> and maybe this version contains bugfix.

I have pending updating to a new release, but when I looked at that
before the bookworm release, that involved packaging a ton of
dependencies (and transitive dependencies), I need to allocate some
time to do that now, but that has not seemed urgent.

> 1. Could you please point me to a documentation which I can use to
>reproduce this bug?

I've covered this (somewhat) in an reply to Denys off-BTS.

> 2. Maybe we can make a bugfix or patch and send a PR to
>https://salsa.debian.org/go-team/packages/victoriametrics ?

Sure, if you do that, I'd do an upload with such fix. Although…

> On 06.08.23 12:16, Sebastian Ramacher wrote:
> > === RUN   TestMergeForciblyStop
> > 2023-08-05T22:21:13.980Zpanic   
> > VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows 
> > must accept at least one row
> > --- FAIL: TestMergeForciblyStop (0.00s)
> > panic: BUG: Inmemory.InitFromRows must accept at least one row [recovered]
> > panic: BUG: Inmemory.InitFromRows must accept at least one row
> > 
> > goroutine 31839 [running]:
> > testing.tRunner.func1.2({0x6f7a60, 0xc003b2e4b0})
> > /usr/lib/go-1.20/src/testing/testing.go:1526 +0x24e
> > testing.tRunner.func1()
> > /usr/lib/go-1.20/src/testing/testing.go:1529 +0x39f
> > panic({0x6f7a60, 0xc003b2e4b0})
> > /usr/lib/go-1.20/src/runtime/panic.go:884 +0x213
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logMessage({0x742b44, 
> > 0x5}, {0xc00507f300, 0x37}, 0x0?)
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:269
> >  +0x965
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevelSkipframes(0x1,
> >  {0x742b44, 0x5}, {0x75c548?, 0xc00503fcc8?}, {0x0?, 0x90?, 0x72aba0?})
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:137
> >  +0x1a5
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevel(...)
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:129
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.Panicf(...)
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:125
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.(*inmemoryPart).InitFromRows(0xc7ccf0,
> >  {0x0, 0x0, 0x0})
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/inmemory_part.go:37
> >  +0x5e
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.newTestBlockStreamReader(0xca6150?,
> >  {0x0, 0x0, 0x0})
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/block_stream_reader_test.go:151
> >  +0x48
> > github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.TestMergeForciblyStop(0xc004101380)
> > 
> > /<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/merge_test.go:358
> >  +0xce
> > testing.tRunner(0xc004101380, 0x7e12e8)
> > /usr/lib/go-1.20/src/testing/testing.go:1576 +0x10b
> > created by testing.(*T).Run
> > /usr/lib/go-1.20/src/testing/testing.go:1629 +0x3ea
> > FAILgithub.com/VictoriaMetrics/VictoriaMetrics/lib/storage  10.215s

I cannot reproduce this one on my sid chroot, but another error
completely different in TestMarshalUnmarshalInt64Array.

Thanks,
Guillem

Bug#1033671: MD5File() goes into an unconditional infinite loop on bullseye

[Guillem Jover]

Hi!

On Fri, 2023-03-31 at 13:43:03 +0200, Guillem Jover wrote:
> Control: fixed -1 0.11.4-1
> Control: severity -1 serious
> 
> On Wed, 2023-03-29 at 20:51:07 +0200, Guillaume Morin wrote:
> > Package: libbsd0
> > Version: 0.11.3-1
> > Tags: patch,upstream,fixed-upstream,bullseye
> 
> > MD5File in bullseye is essentially an infinite loop. It just calls
> > itself.
> > 
> > The simplest fix is
> > 
> > --- a/src/md5.c
> > +++ b/src/md5.c
> > @@ -105,7 +105,7 @@
> >  MD5File(const char *filename, char *buf)
> >  {
> > libmd_wrapper(MD5File);
> > -   return MD5File(filename, buf);
> > +   return libmd_MD5File(filename, buf);
> >  }
> >  
> >  char *
> > 
> > This was fixed upstream by 
> > https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888
> 
> Ah, nice catch! I think I missed that during the switch. I'll be
> preparing a stable update later today to propose to the release team.

This was filed at the time as <https://bugs.debian.org/1035683>.
Adding for reference as I wondered now whether I had done so. :)

Thanks,
Guillem

Bug#1039621: libngs-jni: Installs shared object in wrong directory

[Guillem Jover]

Package: libngs-jni
Version: 3.0.3+dfsg-5
Severity: serious

Hi

This package installs the shared object in the following _literal_
pathname:

  /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so

Where the variable has not been expanded and appears as is. So the
shared object will not be found.

Thanks,
Guillem

Bug#1034120: sensible-utils: Broken shell invocation handling

[Guillem Jover]

Package: sensible-utils
Version: 0.0.18
Severity: serious

Hi!

I installed this some time ago, and started seeing issues, but was
still wondering why no one had reported this already and whether this
was a local issue of mine, until I realized now this is an experimental
only upload. In any case, when calling «dch» I'm getting stuff like:

  ,---
  $ dch
  debian/changelog.dch": 1: Syntax error: Unterminated quoted string
  dch: fatal error at line 1742:
  Error editing debian/changelog
  `---

Regards,
Guillem

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Guillem Jover]

Hi!

On Wed, 2023-03-08 at 14:26:13 +0100, Guilhem Moulin wrote:
> On Wed, 08 Mar 2023 at 14:11:05 +0100, Christoph Anton Mitterer wrote:
> > On Wed, 2023-03-08 at 14:04 +0100, Guilhem Moulin wrote:
> >> No please don't, #-1 is RC so that would block transitioning into
> >> Bookworm which only supports merged-usr…  Will fix that later during
> >> the
> >> freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
> >> further delay the transition.
> >
> > Well but at least right now people without merged /usr will still end
> > up in a broken system?
> 
> Yes.  Been the case for a week (since the argon2=0~20190702-0.1 upload).
> However the TC has ruled that these systems are no longer supported, so
> the issue isn't RC.  Not saying we should shove it under the carpet,
> only that it shouldn't delay transition.

That's not what the TC ruled though, see:

  https://lists.debian.org/debian-devel/2021/10/msg00190.html

Where this is covered explicitly:

,---
- Because Debian 11 installations with the non-merged-/usr layout
  already exist, all packages in Debian 12 should be installable onto a
  non-merged-/usr system along with their dependencies, and work
  correctly on the resulting system.

+ The key reason for this is that apt is not required to perform the
  upgrade between stable releases in any particular order, so long
  as package dependency relationships are respected; therefore the
  upgrade can happen in whatever order apt chooses, which can vary
  between machines. Debian has not traditionally required use of a
  special upgrade tool similar to Ubuntu's do-release-upgrade(8) and
  we believe the upgrade to Debian 12 should be no different (see
  below for more details on this topic).

+ Another reason for this is that during the development of Debian
  12, testing/unstable systems undergo a series of partial upgrades,
  which similarly will happen in an undefined order.

+ We do not require that the resulting system remains
  non-merged-/usr: if the packages involved in this installation
  transaction are part of the implementation of a transition to
  merged-/usr, then installing them might result in the system
  becoming merged-/usr.

- The same expectations apply to packages uploaded to testing/unstable
  during the development cycle that will lead to Debian 12.
`---

> > And there is no guarantee that /usr has already been merged at that
> > point... I mean it should, when the upgrade to bookwork completes...
> > but can it happen that it's interrupted? Or that people do it in
> > several steps? Then they could upgrade argon2, reboot and have the
> > missing libgcc.
> 
> Correct, but AFAICT that's would be a FrankenDebian so not something
> supported either.  Either way that's not something src:cryptsetup can
> fix.  One could upload src:argon2 again adding “Break: cryptsetup-initramfs
> (<< 2:2.6.1-2)” to libargon2-1, though I'm not sure it's worth doing
> given the freeze and the fact that covered that supported systems are
> covered.

Partial upgrades is the expected state you get when upgrading from
Debian N to Debian N+1.

Thanks,
Guillem

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Guillem Jover]

On Sun, 2023-03-05 at 17:18:00 +0100, Marc Haber wrote:
> On Sun, Mar 05, 2023 at 04:00:26PM +0100, Guillem Jover wrote:
> > Package: aide
> > Version: 0.18-2
> > Severity: serious
> 
> Justification?

After upgrade, something that used to work stopped working, which
seemed appropriate to me, but if you disagree I don't feel like
arguing over this.

> > This specific system is using sysvinit. Checking the postinst I notice
> > it is conditionally using systemd-sysusers if available, but then
> > unconditionally tries to chown files and does not fail if it cannot
> > perform the operation.
> 
> Yes, that is expected, please see
> /usr/share/doc/aide-common/README.Debian.gz and consider sending a
> tested patch.

Ah, ok thanks. I'm attaching the patch that I've prepared, I'll be
testing it later today. Let me know if you see any issue with its
direction, and I'm happy to amend stuff.

> > So ideally this would get adduser support, and depend on either that
> > or systemd-standalone-sysusers.
> 
> It is my intention to have aide degrade gracefully to using root on
> non-systemd systems,

I did have libcap2-bin installed so I guess that's why it broke these
expectations.

> since non-systemd users obviously dont care much about security.

(This seems like a gratuitous comment, but it does not seem productive
to get into this.)

Thanks,
Guillem
From 2f394a8b1e24b1bd0cef22cb2891c69f07820643 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 5 Mar 2023 18:16:17 +0100
Subject: [PATCH] Fix _aide user handling

Add dependencies on adduser | systemd-sysusers to guarantee either of
the commands are around and the user can be created.

Add libcap2-bin to aide-common Recommends so that it is obvious it will
be optionally used.

Call adduser to create the user, by using the old options to guarantee
smooth partial upgrades, as a versioned dependency would not guarantee
the options are around given the alternative dependency.

We also need to fix the ownership of the aideinit.* log files, and update
the version where all ownership and permissions get applied to the
current version, otherwise with a previous version where the user was
not created these will remain with the wrong metadata.

Closes: #1032381
---
 debian/aide-common.postinst | 11 +--
 debian/control  |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/debian/aide-common.postinst b/debian/aide-common.postinst
index 6cf4be6..05f7eed 100755
--- a/debian/aide-common.postinst
+++ b/debian/aide-common.postinst
@@ -42,16 +42,23 @@ esac
 SRCDIR="/usr/share/$PKGNAME/config"
 TRGDIR="/etc"
 
-if command -v systemd-sysusers >/dev/null; then
+if command -v adduser >/dev/null; then
+# XXX: Use deprecated options to handle a smooth partial upgrade,
+# switch the the new options after bookworm's release.
+adduser --system --group --force-badname --quiet \
+--no-create-home --home /var/lib/aide --shell /usr/sbin/nologin \
+---gecos 'Advanced Intrusion Detection Environment' _aide
+elif command -v systemd-sysusers >/dev/null; then
 systemd-sysusers
 fi
 
 # added updating to 0.18-1
 rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
 
-if dpkg --compare-versions "$2" lt 0.17.5-1; then
+if dpkg --compare-versions "$2" lt "0.18-2"; then
 # we're updating from a version earlier than 0.17.5, chown logs and databases
 chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log /var/log/aide/aide.log.* || true
+chown --quiet _aide:adm /var/log/aide/aideinit.log /var/log/aide/aideinit.errors || true
 chmod --quiet 2755 /var/log/aide || true
 chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new || true
 fi
diff --git a/debian/control b/debian/control
index 4730c43..c7a8438 100644
--- a/debian/control
+++ b/debian/control
@@ -49,8 +49,10 @@ Architecture: all
 Depends: aide (>= 0.17),
  liblockfile1,
  ucf (>= 2.0020),
+ adduser | systemd-sysusers,
  ${misc:Depends}
 Recommends: cron,
+ libcap2-bin,
  bsd-mailx | mailx | s-nail
 Description: Advanced Intrusion Detection Environment - Common files
  AIDE is an intrusion detection system that detects changes to files on
-- 
2.39.2

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Guillem Jover]

Package: aide
Version: 0.18-2
Severity: serious

Hi!

Just upgraded a server to Debian bookworm, and noticed that aideinit
was not working anymore, giving the following error:

  ,---
  # aideinit --yes --force
  Running aide --init...
  User [_aide] not known
  AIDE --init return code 1
  `---

This specific system is using sysvinit. Checking the postinst I notice
it is conditionally using systemd-sysusers if available, but then
unconditionally tries to chown files and does not fail if it cannot
perform the operation.

So ideally this would get adduser support, and depend on either that
or systemd-standalone-sysusers.

After having manually created the user with adduser, then aideinit
still failed with:

  ,---
  # aideinit --force --yes
  Running aide --init...
  /bin/bash: line 1: /var/log/aide/aideinit.log: Permission denied
  AIDE --init return code 1
  `---

Checking «/var/log/aide/» I saw that at least aideinit.log and
aideinit.errors were indeed still owned by root:adm, fixing the
ownership for those files made aideinit work again. So I guess this is
also missing in the postinst handling.

Thanks,
Guillem

Bug#1013876: Please close this bug report for keepassxc-browser to migrate to testing

[Guillem Jover]

Hi!

On Mon, 2023-02-06 at 19:57:02 +0100, Bruno Kleinert wrote:
> neither revision gets properly loaded by Chromium as of today.
> 
> As the freeze approaches, I will remove the Chromium package relation
> and the symbolic link to the Web Extension
> /usr/share/chromium/extensions/keepassxc-browser in order "solve" this
> RC bug.

That means that users that had this package installed will stop having
the extension at all, so I'm not sure that's much of a practical
difference compared to having the extension but it failing to load. :/

> Unless someone understands what is wrong for Chromium to load the
> extension and provides a patch.

Ok, I looked into this, and the problem seems to be the browser
variable polyfill, which is not required on Firefox, as that uses
browser, but crhomium-based ones use chrome for the namespace.

Copying the keepassxc-browser/common/browser-polyfill.min.js from
the upstream's release/1.8.x branch into
/usr/share/webext/keepassxc-browser/common/browser-polyfill.js, makes
the extension work again.

It appears as if the Build-Depends used is unrelated to that code,
where a comment at the bottom of the minimized version points at
version 0.8.0 from https://github.com/mozilla/webextension-polyfill,
but the package is trying to use node-cross-fetch, which seems
unrelated?

Thanks,
Guillem

Bug#1013876: Please close this bug report for keepassxc-browser to migrate to testing

[Guillem Jover]

Control: found -1 1.8.4+repack1-1
Control: found -1 1.8.4+repack1-2

Hi!

On Mon, 2023-02-06 at 14:34:36 +0200, Adrian Bunk wrote:
> On Fri, Nov 18, 2022 at 07:43:48PM +0100, Bruno Kleinert wrote:
> > I do not have time to investigate and fix the issue in the mid-term.
> > I'd appreciate if someone could jump in and provide a patch against the
> > package, I'd be glad to merge and upload!
> > 
> > From a past attempt to track it down, I *think* to remember there was
> > an issue with a variable 'browser' expected by Chromium not being
> > defined.
> 
> The first error in the original bug report is:
> 
> >   (E) Uncaught TypeError: Bootstrap's JavaScript requires jQuery. jQuery 
> > must be included before$
> >   Context: popups/popup.html
> >   Stack Trace: bootstrap/bootstrap.js:221 (anonymous function)
> 
> This sounds very close to what 1.8.4+repack1-2 you just uploaded to 
> experimental touches.
> 
> Could anyone confirm whether either the version in unstable or the 
> version in experimental fixes the issue?
> Having a non-RC-buggy version in unstable now is the last chance for 
> having the package in bookworm.

I retested both the -1 in unstable and -2 from experimental, and both
seem to still be broken, and fail hard due to the browser
variable/object being undefined, so unfortunately this still seems to
be a problem.

Thanks,
Guillem

Bug#1028961: dpkg: reverts to using insecure cryptographic algorithms by default

[Guillem Jover]

On Wed, 2023-01-25 at 21:44:27 +, James Addison wrote:
> Package: dpkg
> Version: 1.21.18
> Followup-For: Bug #1028961
> 
> Are SHA224 and SHA384 used widely by dpkg and/or Debian?

I'd expect all (?) signatures for packaging artifacts in Debian to be
SHA512. This change sets an explicit preference list, so that in case
more secure digest algorithms are unavailable for whatever reason, we
do not end up falling back directly into worse ones.

Thanks,
Guillem

Bug#1028961: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1028961 pending

Hi!

Bug #1028961 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=3c42b0ed7

---
Dpkg::OpenPGP::Backend::GnuPG: Set secure signing preferred algorithms

The current GnuPG defaults with --openpgp cater for heavy backwards
compatibility at the cost of being insecure but potentially being
compatible with very old programs.

We care more about secure defaults than backwards compatibility with
ancient programs, so we pass our preferences to gpg when signing. This
should also cover the case for users that have created old keys with
insecure key preferences which might end up producing insecure
signatures.

Fixes: commit b83114daa69c50d368199d00fbb67e190068b273
Closes: #1028961

Bug#1028961: dpkg: reverts to using insecure cryptographic algorithms by default

[Guillem Jover]

On Sun, 2023-01-15 at 11:45:20 +0100, Ansgar wrote:
> Package: dpkg
> Version: 1.21.13
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team 

> dpkg 1.21.13 introduced passing "--openpgp" to GnuPG by default […]. This
> causes GnuPG to use insecure cryptographic algorithms like the SHA-1
> digest algorithm by default.

> I do not think that cryptographic default from over 15 years ago are
> a good default choice today; rather they are a security issue (just
> like, for example, reverting to using SSL3 instead of TLS1.3).

Downgrading secure defaults was certainly not the intention… At the
time I checked the gnupg code, and (AFAIR) tested whether the option was
producing secure signatures, and even brought this up on the #sequoia
IRC channel. At the same time I also created a patch to restore secure
digest defaults:

  
https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=next/gnupg-secure-algos

but I cannot recall whether my testing was botched somewhere and
deemed the change unnecessary, or I lost track of that commit while
preparing those changes/release.

(Should probably also report to gnupg that it does then not seem to
respect the key preferences.)

In any case, I've reworked that a bit and will include it for 1.21.19.

Guillem

Bug#1027476: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1027476: fixed in cron 3.0pl1-155)

[Guillem Jover]

Control: reopen -1

Hi!

Although I've not tested nor checked the affected code, the fix done
to close this cannot possibly be correct, see below. :)

On Mon, 2023-01-09 at 21:27:06 +, Debian Bug Tracking System wrote:
> Date: Sun, 01 Jan 2023 07:12:58 -0500
> From: "Kevin P. Fleming" 
> To: Debian Bug Tracking System 
> Subject: cron: postrm script fails because expected dpkg-statoverride is
>  not present

> The postrm script in the current version of the cron package assumes the
> presence of a dpkg-statoverride for /usr/bin/crontab, but no such statoverride
> is present on my systems. As a result when I try to 'purge' the cron package
> the process fails.

I think the description might be read incorrectly. The error is not
that the dpkg-statoverride program is missing, as that's not possible
(w/o force) being part of dpkg which is an Essential package. But that
a statoverride entry setup by some package is missing.

> This results in the following output:
> 
> Reading package lists... Done
> Building dependency tree... Done
> The following packages will be REMOVED:
>   cron*
> 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] y
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "en_US.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such 
> device)
> (Reading database ... 11054 files and directories currently installed.)
> Purging configuration files for cron (3.0pl1-154) ...
> dpkg-statoverride: warning: no override present

As can be seen here, the tool is executed and it runs, but it warns that
it cannot find the statoverride entry.

> dpkg: error processing package cron (--purge):
>  installed cron package post-removal script subprocess returned error exit
> status 2
> Errors were encountered while processing:
>  cron
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Editing /var/lib/dpkg/info/cron.postrm to remove the first section resolves 
> the
> issue.

Adding a dependency on dpkg cannot have solved anything here.

Thanks,
Guillem

Bug#1027966: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1027966 pending

Hi!

Bug #1027966 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=4c03965ef

---
dpkg-genbuildinfo: Do not fail if the cross-compiler cannot compile

When bootstrapping a cross-compiler, it might not have some of the
required parts available, such as a libc. Catch the error, emit it as a
warning and return undef, like with the other conditions where we skip
the test. Because in the end this is just a tainting flag, and it is not
worth it failing the entire build due to that.

Closes: #1027966

Bug#1027759: pylint: Missing dependency on python3-tomli for python3 < 3.11

[Guillem Jover]

Control: reopen -1
Control: reassign -1 devscripts
Control: retitle -1 devscripts: Wrong usage of pylint as a module breaks

Hi!

On Thu, 2023-01-05 at 00:18:13 -0500, Sandro Tosi wrote:
> > Package: pylint
> > Version: 2.15.9-1
> > Severity: serious

> > It looks like the recent release is missing a dependency on
> > python3-tomli when the python used is not at least 3.11. Seen on
> > test suite failures locally and on the devscripts CI pipelines:
> >
> >   https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2644
> 
> this bug is invalid; pylint is a cli tool, not a module, so running it as
> 
>   /usr/bin/python3.10 -m pylint 
> 
> (https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2619) in 
> incorrect.
> 
> call /usr/bin/pylint

In that case, this should be fixed in devscripts (as that MR did not
introduce this usage, it just triggered the failure). Reassigning.

Thanks,
Guillem

Bug#1027966: building of cross-toolchain-base broken, wrong assumption of dpkg-buildinfo

[Guillem Jover]

Control: found -1 1.21.10

On Thu, 2023-01-05 at 11:23:30 +0100, Matthias Klose wrote:
> Package: dpkg-dev
> Version: 1.21.16
> Severity: serious
> Tags: sid bookworm

> see 
> https://buildd.debian.org/status/fetch.php?pkg=cross-toolchain-base-ports&arch=all&ver=60&stamp=1672912429&raw=0
> 
> touch /<>/glibc-2.36/stamp-dir/binaryinst_libc6.1-udeb
> make[1]: Leaving directory '/<>/glibc-2.36'
>  dpkg-genbuildinfo --build=any -O../glibc_2.36-7_alpha.buildinfo
> In file included from /usr/include/features.h:392,
>  from /usr/include/unistd.h:25,
>  from :1:
> /usr/include/features-time64.h:20:10: fatal error: bits/wordsize.h: No such
> file or directory
>20 | #include 
>   |  ^
> compilation terminated.
> dpkg-genbuildinfo: error: alpha-linux-gnu-gcc -w -x c - subprocess returned
> exit status 1
> dpkg-buildpackage: error: dpkg-genbuildinfo --build=any
> -O../glibc_2.36-7_alpha.buildinfo subprocess returned exit status 25
> make: *** [debian/rules:366: stamp-dir/build-glibc2.alpha] Error 2
> 
> 
> there is a bad assumption that the existence of a cross compiler means that
> you can successfully run the cross compiler.  Here we just built the
> "missing" glibc headers, so you cannot yet use the cross compiler.

Hmm, ok. And we cannot use -ffreestanding either. I guess I'll just
make the code ignore the condition when the compiler fails. I suppose
this might be blocking you for the toolchain freeze, so I'll upload a
fix right away.

Thanks,
Guillem

Bug#1027759: pylint: Missing dependency on python3-tomli for python3 < 3.11

[Guillem Jover]

Package: pylint
Version: 2.15.9-1
Severity: serious

Hi!

It looks like the recent release is missing a dependency on
python3-tomli when the python used is not at least 3.11. Seen on
test suite failures locally and on the devscripts CI pipelines:

  https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2644

Thanks,
Guillem

Bug#1026227: vagrant: Uninstallable in sid with VirtualBox 7.0.x

[Guillem Jover]

Hi!

On Sun, 2022-12-18 at 18:10:16 -0300, Antonio Terceiro wrote:
> On Fri, Dec 16, 2022 at 06:31:41PM +0100, Guillem Jover wrote:
> > Package: vagrant
> > Version: 2.2.19+dfsg-2
> > Severity: serious

> > Since virtualbox 7.0.4 got uploaded, vagrant is no longer installable
> > in Debian sid. I assume this will require packaging a new upstream
> > release to support the new virtualbox version 7.0.x series.
> 
> I cherry picked a patch from upstream that should solve the issue. The
> Breaks: restriction will now make the package installable with
> virtualbox 7.0, but I don't use virtualbox so I can't really test that
> it actually works.
> 
> Can you please try the package from git master?

I built it from git HEAD, installed and it seems to work fine now with
virtualbox 7.0.4, thanks! Even though I saw the following from the test
suite output:

  ,---
  # 
terminated with exception (report_on_exception is true):
  /tmp/vagrant/lib/vagrant/machine.rb:208:in `block in action': Vagrant 
attempted to call the action 'destroy' on the provider 
(Vagrant::Errors::UnimplementedProviderAction)
  '#', but this provider 
doesn't support this action. This
  is probably a bug in either the provider or the plugin calling this
  action, and should be reported.
  from /tmp/vagrant/lib/vagrant/environment.rb:614:in `lock'
  from /tmp/vagrant/lib/vagrant/machine.rb:201:in `call'
  from /tmp/vagrant/lib/vagrant/machine.rb:201:in `action'
  from /tmp/vagrant/lib/vagrant/batch_action.rb:86:in `block (2 levels) 
in run'
  `---

it didn't affect the test suite results nor the apparent operation with
the virtualbox plugin, so I guess this is completely unrelated.

Thanks,
Guillem

Bug#1026227: vagrant: Uninstallable in sid with VirtualBox 7.0.x

[Guillem Jover]

Package: vagrant
Version: 2.2.19+dfsg-2
Severity: serious

Hi!

Since virtualbox 7.0.4 got uploaded, vagrant is no longer installable
in Debian sid. I assume this will require packaging a new upstream
release to support the new virtualbox version 7.0.x series.

Thanks,
Guillem

Bug#1025261: vagrant: Broken with ruby3.1

[Guillem Jover]

Package: vagrant
Version: 2.2.19+dfsg-1
Severity: serious

Hi!

After the upgrade of ruby to the 3.1 version vagrant has stopped
working completely, I'm getting the following errors repeated multiple
times:

,---
/usr/lib/ruby/vendor_ruby/rubygems/resolver/conflict.rb:47:in 
`conflicting_dependencies': undefined method `request' for nil:NilClass 
(NoMethodError)

[@failed_dep.dependency, @activated.request.dependency]
   
from /usr/lib/ruby/vendor_ruby/rubygems/exceptions.rb:61:in 
`conflicting_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/exceptions.rb:55:in `initialize'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `exception'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `raise'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:193:in `rescue in 
resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:191:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:411:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:423:in 
`resolve_current'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:230:in `finish_resolve'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:287:in `block in 
activate_bin_path'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `activate_bin_path'
from /usr/bin/vagrant:25:in `'
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:317:in
 `raise_error_unless_state': Unable to satisfy the following requirements: 
(Gem::Resolver::Molinillo::VersionConflict)

- `vagrant (= 2.2.19)` required by `user-specified dependency`
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:299:in
 `block in unwind_for_conflict'
from :90:in `tap'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:297:in
 `unwind_for_conflict'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:682:in
 `attempt_to_activate'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:254:in
 `process_topmost_state'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:182:in
 `resolve'
from 
/usr/lib/ruby/vendor_ruby/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:43:in
 `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/resolver.rb:190:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:411:in `resolve'
from /usr/lib/ruby/vendor_ruby/rubygems/request_set.rb:423:in 
`resolve_current'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:230:in `finish_resolve'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:287:in `block in 
activate_bin_path'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems.rb:285:in `activate_bin_path'
from /usr/bin/vagrant:25:in `'
`---

Installing ruby3.0 and forcing the «/usr/bin/ruby» symlink back to
ruby3.0 make vagrant work again.

Thanks,
Guillem

Bug#1013876: Please close this bug report for keepassxc-browser to migrate to testing

[Guillem Jover]

On Thu, 2022-11-17 at 13:52:38 +, Amr Ibrahim wrote:
> On Sat, 24 Sep 2022 21:37:45 +0200 Guillem Jover  wrote:
> > I've kept the package on hold since, but try to upgrade from time to
> > time to see whether its fixed. Last time I did with the latest version
> > currently in sid, it seemed to be still broken.
> 
> Is this still broken in Chromium?

Well, nothing has changed in webext-keepassxc-browser since my last
reply, so I'd assume yes. In any case I just upgraded again to check
and, yes it's still broken.

> There is no problem in Firefox, and this bug report is preventing
> the package to migrate to testing

Sure, but that makes it unusable with Chromium which would be a
disservice to those users, so not migrating seems entirely the right
outcome.

Thanks,
Guillem

Bug#1023654: in package liburing marked as pending

[Guillem Jover]

Control: tag 1023654 pending

Hi!

Bug #1023654 that you reported in package liburing has been fixed
in the debian/pkgs/liburing.git git repository. You can see the changelog below,
and you can check the diff of the fix at:

https://git.hadrons.org/cgit/debian/pkgs/liburing.git/diff/?id=b80de0d

---
commit b80de0dca45a2c0006d0cc2c4059d56f56898f57
Author: Guillem Jover 
Date:   Mon Nov 14 00:13:19 2022 +0100

Artificially bump some symbol versions to 2.3

Do this for functions involved in a forward compatibility ABI break,
for objects built against the new library and run-time linked against
the old one, until upstream decides how to fix/improve this.

Forwarded: https://github.com/axboe/liburing/issues/724
Closes: #1023654

diff --git a/debian/changelog b/debian/changelog
index 3855e86..d3b6c23 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+liburing (2.3-2) UNRELEASED; urgency=medium
+
+  * Artificially bump symbol versions to 2.3 for functions involved in a
+forward compatibility ABI break, for objects built against the new
+library and run-time linked against the old one, until upstream decides
+how to fix/improve this. Closes: #1023654
+
+ -- Guillem Jover   Mon, 14 Nov 2022 00:09:51 +0100
+
 liburing (2.3-1) unstable; urgency=medium
 
   * New upstream release.

Bug#1023654: liburing 2.3 breaks binary compatibility

[Guillem Jover]

Hi!

I've forwarded this upstream now.

On Tue, 2022-11-08 at 14:44:25 +0100, Guillem Jover wrote:
> On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
> > On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:
> > > In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
> > > their sizes. Both of these structures are parts of io_uring structure
> > > which the main part of the API.  Here's the difference:
> > > 
> > > @@ -43,7 +79,9 @@
> > > @@ -56,13 +94,18 @@
> > > size_t ring_sz;
> > > void *ring_ptr;
> > > -   unsigned pad[4];
> > > +   unsigned ring_mask;
> > > +   unsigned ring_entries;
> > > +
> > > +   unsigned pad[2];
> > 
> > This does not look like it is changing the size actually, - I haven't
> > noticed it adjusts pad[] accordingly. So this is not the issue here.
> > 
> > But the end result is the same: samba compiled with liburing 2.2 does
> > not work with runtime liburing 2.3, and samba compiled with liburing
> > 2.3 does not work with runtime liburing 2.2.

I've checked the code and this is weird, the new code is taking care of
initializing all members with the new shared library. So I'd expect
samba built against the old liburing to work with the new one. But the
problem seems to be that code built against the new liburing will not
work with the old liburing, as that one does not initialize the new
members being used from the inline functions.

If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.

Thanks,
Guillem

Bug#1023654: liburing 2.3 breaks binary compatibility

[Guillem Jover]

Hi!

On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
> On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev  wrote:
> > Source: liburing
> > Version: 2.3-1
> > Severity: grave
> > 
> > liburing 2.3 broke binary compatibility without bumping the soname.

Indeed. :/ Should make a habit of checking the header diffs, as this
is not the first time this has happened.

> > In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
> > their sizes. Both of these structures are parts of io_uring structure
> > which the main part of the API.  Here's the difference:
> > 
> > @@ -43,7 +79,9 @@
> > @@ -56,13 +94,18 @@
> > size_t ring_sz;
> > void *ring_ptr;
> > -   unsigned pad[4];
> > +   unsigned ring_mask;
> > +   unsigned ring_entries;
> > +
> > +   unsigned pad[2];
> 
> This does not look like it is changing the size actually, - I haven't
> noticed it adjusts pad[] accordingly. So this is not the issue here.
> 
> But the end result is the same: samba compiled with liburing 2.2 does
> not work with runtime liburing 2.3, and samba compiled with liburing
> 2.3 does not work with runtime liburing 2.2.
> 
> I'm just too tired now to dig further.

The problem is that this release has deprecated the kring_mask and
kring_entries, and does not have fallback code to use them if they are
being used by the callers.

I'll report this upstream to see how they want to fix this, either
with a SOVERSION bump or trying to add dynamic fallback code or
similar.

For sid, I guess I could bump the affected functions required minimal
versions in the symbols file, and then add breaks on the old packages
using the old ABI, but meh. :/

Thanks,
Guillem

Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6

[Guillem Jover]

Package: perl6-readline,raku-file-which,raku-librarycheck,raku-readline
Severity: serious

Hi!

[ Filing against all affected packages because it's not clear to me which
  one needs to be fixed. ]

These packages all contain (at least) these same filenames:

  ,---
  perl6-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  perl6-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  raku-file-which: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  raku-file-which: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  raku-librarycheck: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  raku-librarycheck: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  raku-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6
  raku-readline: 
/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id
  `---

which cause the installation to fail:

  ,---
  Preparing to unpack .../raku-file-which_1.0.1-3+b1_amd64.deb ...
  Unpacking raku-file-which (1.0.1-3+b1) over (1.0.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/raku-file-which_1.0.1-3+b1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6',
 which is also in package raku-readline:amd64 0.1.6-2+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../raku-librarycheck_0.0.10-3_amd64.deb ...
  Unpacking raku-librarycheck (0.0.10-3) over (0.0.10-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/raku-librarycheck_0.0.10-3_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A37F26876B58371B70EDD889AD69F064C90AC2C6',
 which is also in package raku-readline:amd64 0.1.6-2+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/raku-file-which_1.0.1-3+b1_amd64.deb
   /var/cache/apt/archives/raku-librarycheck_0.0.10-3_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  `---

while perl6-readline and raku-readline can be installed to replace one
another, they cannot be installed alongside the others AFAICS.

Thanks,
Guillem

Bug#1013876: Please close if fixed to migrate to testing

[Guillem Jover]

Hi!

On Fri, 2022-09-23 at 13:27:31 +, Amr Ibrahim wrote:
> On Mon, 27 Jun 2022 07:21:33 +0200 Bruno Kleinert 
> wrote:
> > thanks for the report. Something else in 1.8.0 is bugging me that may
> > be related to upstream's jQuery removal. I'm expecting upstream may
> > release 1.8.1 soonish.

> Please close this bug if fixed in unstable to migrate the package to
> testing.

I've kept the package on hold since, but try to upgrade from time to
time to see whether its fixed. Last time I did with the latest version
currently in sid, it seemed to be still broken.

Thanks,
Guillem

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Guillem Jover]

On Wed, 2022-09-14 at 17:31:16 +0200, Santiago Ruano Rincón wrote:
> Yeah, sorry. I lately realised not all the packages would autoreconf
> during building time.
> 
> So silencing these warnings would make sense.

Please consider implementing a way to be able to conditionally re-enable
locally these warnings so that we can try to hunt down and fix those,
otherwise we might end up hitting these once we revert the silencing,
for example for code paths that are not commonly exercised.

I've mentioned this on the upstream bug report, but it would be nicer
if you could coordinate a way upstream might be happy with, say using
a specific environment variable or similar.

Thanks,
Guillem

Bug#995387: in package dpkg marked as pending

[Guillem Jover]

Control: tag 995387 pending

Hi!

Bug #995387 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=741d474aa

---
dpkg: Fix conffile removal-on-upgrade handling

We need to check for file conflicts during conffile removal, otherwise
we might end up removing files from any other packages that has started
owning them since we targeted the pathname for removal.

We remove the conffiles during upgrade, as configure is a local
action that does not load all file lists files, so we cannot check for
file conflicts.

Closes: #995387
Stable-Candidate: 1.20.x
(cherry picked from commit 20e181fc2030385488e3db2d4cc3ce4114f0a498)

Bug#1008478: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008478 pending

Hi!

Bug #1008478 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=699c417f5

---
dpkg-fsys-usrunmess: Explicitly set user/group and mode for created dirs

We should explicitly set the user/group and mode for the newly created
directories, to make sure they end up with the expected values, instead
of assuming a good environment (umask and user/group). We will still be
setting a known umask in a subsequent commit as a defensive measure.

Closes: #1008478
(cherry picked from commit 77756084e9e50d7a8578259ee56e64dcf4f6f9a0)

Bug#1008316: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008316 pending

Hi!

Bug #1008316 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=7086b1b62

---
dpkg-fsys-usrunmess: Special case untracked kernel module files

Kernel module files are required as part of the system boot, so we need
to make sure any such files gets moved or the system might end up not
being able to boot, once the initramfs images get regenerated.

In particular, kernel module files are easily found on systems as
untracked pathnames in the filesystem, either from custom built kernels,
or as part of modules built via machinery such as DKMS.

One complication is that there appears to be some documentation
referencing /usr/lib/modules/ pathnames for at least apache, python and
ruby module locations. Which we do not want to be moving.

To limit these unknowns, and as we are dealing with untracked pathnames,
we will restrict moving subdirectories that start with a digit, which
matches Linux and kFreeBSD module locations, in addition to the
modprobe.conf filename.

Closes: #1008316
(cherry picked from commit 48e33c40691596b3bf91b86b50a8aa164b585639)
(cherry picked from commit b1898b812b71f64082107d4e2f98ccf020d18b70)

Bug#1000421: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1000421 pending

Hi!

Bug #1000421 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=5a9f336dc

---
Dpkg::Shlibs::Objdump: Fix apply_relocations to work with versioned symbols

Since binutils 2.26 (commit bb4d2ac2cc637c61232624d9d359b8d3f031e3e9)
versioned symbols in copy relocations are output as «symbol@@version»
when they are in an undefined section (otherwise they use «@»). We were
not taking this into account which meant these did not match and did not
get marked as undefined, and got ignored for symbol dependency
calculation.

Try both the version qualified symbol and the bare symbol name to cope
with old and new formats.

Known to be affected are at least any-amd64, hppa and m68k architectures.

Closes: #1000421
(cherry picked from commit ecbd9f1b1f248fb5be182b3a78bc613591dba865)

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Control: reassign -1 arcanist

Hi!

On Fri, 2022-09-02 at 07:46:43 +0200, Sylvestre Ledru wrote:
> Le 02/09/2022 à 01:10, Guillem Jover a écrit :
> > So we have reached the point at which arc is getting autoremoved from
> > testing as the RC is still filed against it too. :(
> > 
> > Could some arcanist maintainer please check this, and ideally agree to
> > reassign this bug to arcanist? If necessary I'm willing to prepare a
> > patch for arcanist to stop installing as bin/arc, as described above,
> > if this would expedite things.

> However, as:
> * phabricator is dying
> * Richard, Christoph and myself didn't show a strong interest to keep
> it alive (it is currently broken in unstable).
> 
> Please do what you want. ;)

Thanks! Much appreciated, I've reassigned it now with this mail!

On Fri, 2022-09-02 at 12:12:06 +0200, Christoph Biedl wrote:
> Sylvestre Ledru wrote...
> > I don't think renaming is the right approach against an MS-DOS
> > software (and I still think that Debian's policy is too binary for
> > this).
> 
> As there is a very small chance users would want to install *both*
> packages, can't we just resolve this with a Breaks: on both sides, or
> anything else that prevents co-installation from happening?

See Adrian's reply.

> Else I think for the various reasons it's indeed the arcanist package
> that should move. Although I have concerns here since (arcanist's) arc
> program is a command line tool and therefore users will have created
> scripts around it.

> About the policy - I think the idea behind it is right, and colliding
> file names are a problem. Can you think of a better way to handle this?

See my proposal on the previous mail, quoted here for convenience:

> > On Wed, 2022-08-10 at 01:29:27 +0200, Guillem Jover wrote:
> > > Could you please rename the archanist /usr/bin/arc into
> > > /usr/bin/arcanist? Or if that's not feasible, then stop installing the
> > > symlink in PATH, and document that users might want to add the /usr/share
> > > /arcanist/bin/ into their own PATH? Or do both?

I think this would make the program match the package name, and at the
same time make it possible for willing users to simply modify their
pathname or add a symlink say under ~/bin/arc pointing to the actual
program.

I can take a stab at this (as gratitude :), and propose a patch during
the weekend or something, if you want.

Thanks,
Guillem

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Hi!

On Wed, 2022-08-10 at 01:29:27 +0200, Guillem Jover wrote:
> [ The bug has been (correctly) bumped back to serious. Sorry that I
>   have not engaged about this bug in the past, but the reply to simply
>   ignore policy looked rather off-putting, I just noticed the reply
>   below, which seemed encouraging! :) ]
> 
> On Sat, 2019-01-26 at 11:20:13 +0100, Sylvestre Ledru wrote:
> > As we shipped the previous release with this bug, we are close to
> > the freeze and there is not easy fix,
> > I propose that we fix this issue for the next stable release.
> 
> Could you please rename the archanist /usr/bin/arc into
> /usr/bin/arcanist? Or if that's not feasible, then stop installing the
> symlink in PATH, and document that users might want to add the /usr/share
> /arcanist/bin/ into their own PATH? Or do both?
> 
> Renaming the binary from the arc package, which matches the package
> name itself, seems unfair, as it has existed upstream and has been in
> the Debian archive for way way longer, and in addition the idea of
> potentially having a binary package arc with a non-arc program, and
> arcanist providing an arc program seems rather confusing and just
> wrong. :)
> 
> Otherwise, all these package will get removed in the coming days. So I'd
> also appreciate if you could reassign these bugs to arcanist.

So we have reached the point at which arc is getting autoremoved from
testing as the RC is still filed against it too. :(

Could some arcanist maintainer please check this, and ideally agree to
reassign this bug to arcanist? If necessary I'm willing to prepare a
patch for arcanist to stop installing as bin/arc, as described above,
if this would expedite things.

Thanks,
Guillem

Bug#1017440: pahole: Several tools just segfault

[Guillem Jover]

Package: pahole
Version: 1.23-2
Severity: serious

Hi!

Many of the tools simply segfault when executed. On a shared library
with debugging symbols:

  $ codiff libsysfs.so.2.0.1 libsysfs.so.2.0.1
  Segmentation fault (core dumped)
  $ dtagnames libsysfs.so.2.0.1
  Segmentation fault (core dumped)
  $ prefcnt libsysfs.so.2.0.1
  Segmentation fault (core dumped)
  $ scncopy -s data -o output libsysfs.so.2.0.1
  Segmentation fault (core dumped)
  $ syscse libsysfs.so.2.0.1
  Segmentation fault (core dumped)

On a stripped library:

  $ codiff /usr/lib/x86_64-linux-gnu/libbsd.so.0 \
   /usr/lib/x86_64-linux-gnu/libbsd.so.0
  Segmentation fault (core dumped)
  $ dtagnames /usr/lib/x86_64-linux-gnu/libbsd.so.0
  Segmentation fault (core dumped)
  $ prefcnt /usr/lib/x86_64-linux-gnu/libbsd.so.0
  Segmentation fault (core dumped)
  $ scncopy -s data -o output /usr/lib/x86_64-linux-gnu/libbsd.so.0
  Segmentation fault (core dumped)
  $ syscse /usr/lib/x86_64-linux-gnu/libbsd.so.0
  Segmentation fault (core dumped)

Some even with no arguments:

  $ dtagnames
  Segmentation fault (core dumped)
  $ prefcnt
  Segmentation fault (core dumped)

Thanks,
Guillem

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Hi!

[ The bug has been (correctly) bumped back to serious. Sorry that I
  have not engaged about this bug in the past, but the reply to simply
  ignore policy looked rather off-putting, I just noticed the reply
  below, which seemed encouraging! :) ]

On Sat, 2019-01-26 at 11:20:13 +0100, Sylvestre Ledru wrote:
> As we shipped the previous release with this bug, we are close to
> the freeze and there is not easy fix,
> I propose that we fix this issue for the next stable release.

Could you please rename the archanist /usr/bin/arc into
/usr/bin/arcanist? Or if that's not feasible, then stop installing the
symlink in PATH, and document that users might want to add the /usr/share
/arcanist/bin/ into their own PATH? Or do both?

Renaming the binary from the arc package, which matches the package
name itself, seems unfair, as it has existed upstream and has been in
the Debian archive for way way longer, and in addition the idea of
potentially having a binary package arc with a non-arc program, and
arcanist providing an arc program seems rather confusing and just
wrong. :)

Otherwise, all these package will get removed in the coming days. So I'd
also appreciate if you could reassign these bugs to arcanist.

Thanks,
Guillem

Bug#1013876: webext-keepassxc-browser: Version 1.8.0+repack1-2 fail to load in chromium

[Guillem Jover]

Package: webext-keepassxc-browser
Version: 1.8.0+repack1-2
Severity: serious

Hi!

This version seems to fail load on chromium 103.0.5060.53-1, with the
following warnings and errors shown on the extensions settings page:

  (W) Unrecognized manifest key 'applications'.
  (W) Manifest version 2 is deprecated, and support will be removed in 2023.
  See https://developer.chrome.com/blog/mv2-transition/ for more details.
  (E) Uncaught TypeError: Bootstrap's JavaScript requires jQuery. jQuery must 
be included before Bootstrap's JavaScript.
  Context: popups/popup.html
  Stack Trace: bootstrap/bootstrap.js:221 (anonymous function)
  (E) Uncaught (in promise) ReferenceError: browser is not defined
  Context: popups/popup.html
  Stack Trace: popups/popup_functions.js:74 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: popups/popup.html
  Stack Trace: common/translate.js:11 (anonymous function)
  (E) Uncaught (in promise) ReferenceError: browser is not defined
  Context: popups/popup.html
  Stack Trace: popups/popup_functions.js:40 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: _generated_background_page.html
  Stack Trace: common/global.js:161 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: _generated_background_page.html
  Stack Trace: background/keepass.js:39 (anonymous function)
  (E) Uncaught ReferenceError: browser is not defined
  Context: _generated_background_page.html
  Stack Trace: background/init.js:23 (anonymous function)

Thanks,
Guillem

Bug#1012544: libworkflow1: Broken shared library packaging

[Guillem Jover]

Package: libworkflow1
Version: 0.9.10-1
Severity: serious

Hi!

This package has several problems:

 - It contains a shared library without a SOVERSION

   ,---
   $ objdump -p /usr/lib/x86_64-linux-gnu/libworkflow.so | grep SONAME
   SONAME   libworkflow.so
   `---

   This means any binary package linked against this shared library
   misses relevant ABI information and can break on any ABI change.
   The SONAME should contain the SOVERSION, in this case I'd assume
   that to be 1, from the binary package name, but given the version
   used in the fully versioned shared library filename, perhaps that
   should have been libworkflow0, and then SONAME should be
   libworkflow.so.0.

 - The shared library object should be the one with the full version,
   say libworkflow.so.0.9.10, the SONAME should be the symlink, so
   say libworkflow.so.0 → libworkflow.so.0.9.10, and the unversioned
   .so symlink for build-time linking should also be a symlink (or in
   some cases a linker script), libworkflow.so → libworkflow.so.0.9.10.

 - The versioned shared library filenames should go into the versioned
   shared library package.

 - The unversioned shared and static library filenames should go into
   the -dev package.

Please refer to debian-policy section §8 for further information. I
think in this case lintian would have flagged these as errors.

Thanks,
Guillem

Bug#1008443: golang-github-smartystreets-assertions: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/smartystreets/assertions github.com/smartystreets/assert

[Guillem Jover]

Hi!

On Sat, 2022-04-16 at 23:06:39 +0200, Drew Parsons wrote:
> I don't understand the version scheme for this package.
> 
> The Debian version is 1.10.1, which was released 1 Apr 2019.
> 
> After that, many more versions were released, but with "older" version
> numbers.  The most recent was v1.2.1, released on 29 Sep 2021.

It seems like upstream changed the versioning scheme. I've filed a
report there asking if they can prepare a release with a greater
version:

  

Otherwise, the options would be to use something like 1.10.1+really1.2.1,
until upstream catches up with the current version in Debian; or using
an epoch, after consultation with d-d, which would be unfortunate.

Thanks,
Guillem

Bug#1008764: dpkg: [dpkg-fsys-usrunmess] fails to copy /lib/modules directories, breaks

[Guillem Jover]

Control: severity -1 normal

Hi!

On Fri, 2022-04-01 at 07:27:26 +0900, Norbert Preining wrote:
> Package: dpkg
> Version: 1.21.6
> Severity: critical
> Justification: breaks the whole system

The script does not break the whole system, it fails quite early
during preparations before doing any migration.

> my system was installed *after* buster and now is in the unfortunate
> messed up state.
> 
> I tried to fix it as suggested by dpkg using dpkg-fsys-usrunmess, but
> it fails reproducibly:
> $ dpkg-fsys-usrunmess
> ...
> D: creating shadow file = /.usrunmess/lib/modprobe.d/aliases.conf
> D: creating shadow file = /.usrunmess/lib/modprobe.d/fbdev-blacklist.conf
> D: creating shadow file = /.usrunmess/lib/modprobe.d/systemd.conf
> D: creating shadow dir = 
> /.usrunmess/lib/modules/5.15.15+futex+zstd+intel+wine+
> error: cannot mkdir /.usrunmess/lib/modules/5.15.15+futex+zstd+intel+wine+: 
> No such file or directory
> $
> 
> I have my own compiled kernels.
> 
> The problem is that it seems to be a missing mkdir -p  or similar.

Sorry, it looks like I previously only fixed the cases of mixed tracked
and untracked kernel module files there. I've now fixed this locally,
which will be included in 1.21.7.

You'll need to remove the shadow hierarchy before being able to run
this again with a fixed script though.

Thanks,
Guillem

Bug#1008316: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008316 pending

Hi!

Bug #1008316 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=48e33c406

---
dpkg-fsys-usrunmess: Special case untracked kernel module files

Kernel module files are required as part of the system boot, so we need
to make sure any such files gets moved or the system might end up not
being able to boot, once the initramfs images get regenerated.

In particular, kernel module files are easily found on systems as
untracked pathnames in the filesystem, either from custom built kernels,
or as part of modules built via machinery such as DKMS.

One complication is that there appears to be some documentation
referencing /usr/lib/modules/ pathnames for at least apache, python and
ruby module locations. Which we do not want to be moving.

To limit these unknowns, and as we are dealing with untracked pathnames,
we will restrict moving subdirectories that start with a digit, which
matches Linux and kFreeBSD module locations, in addition to the
modprobe.conf filename.

Closes: #1008316

Bug#1008316: dpkg-fsys-usrunmess breaks system boot

[Guillem Jover]

On Mon, 2022-03-28 at 09:34:35 +, Éric Valette wrote:
> On 3/28/22 01:29, Guillem Jover wrote: 
> >> Invoquing the dkms postinstall script fails because it does not find 
> >> /lib/modules/x.y.z 
> >>
> >> directories and rebooting without graphic drivers and other stff does not 
> >> work. 

> > Just to understand, did dpkg-fsys-usrunmess fail (exited non-zero) while 
> >  
> > configuring packages (with dkms)? And then you rebooted? 

> There was no printed error beside the arror from dkms postinst (virtualbox 
> assumed it was running virtualized, and nvidia just failling): just a 
> congratulation message. Diid not check the return value of the script  via 
> echo $? 

Ok, so if the script did not finish with something like:

  ,---
  error: cannot reconfigure packages: ...
  `---

Then I suppose it exited normally with something like:

  ,---
  Done, hierarchy unmessed, congrats!
  Rebooting now is very strongly advised.

  (Note: you might need to run 'hash -r' in your shell.)
  `---

?

If the latter, I guess the maintainer script(s) running dkms, didn't exit
non-zero. Hmm. Where those from external third-party packages?

> >> So you probably should copy /usr/lib/modules to /lib/modules before the 
> >> calling the 
> >> postinstall. 

> > Hmm, right, because these were not tracked, they got missed in the 
> > migration. I've checked the Debian archive and at least there, it does 
> > not look like anything else besides kernel modules are being current 
> > shipped in those directories (via apt-file), but the problem is that 
> > I've seen references in source code (via codesearch.d.o) to 
> > /usr/lib/modules, for at least apache and python modules, so I don't 
> > think an unconditional move for untracked files would be safe there. 
> > I'm thinking the following special-case options (in order of decreasing 
> > preference): 
> >  
> >    * move only untracked «/usr/lib/modules/[0-9]*» expecting/assuming 
> >  those to be kernel modules, 
>  
> You could move only the current running kernel modules using uname 
> to find the version. It will not hurt and they will be rebuild anyway at 
> least for the dkms ones. 

I guess that would be another option yes, thanks.

> The real problem being that dkms generated file does not appear in any file 

Sure.

I'll try to prepare something later today.

Thanks,
Guillem