Bug#1071429: dpkg: `dpkg-db-backup.timer` starts `dpkg-db-backup.service` in hot path of boot

[Guillem Jover]

Hi!

On Sun, 2024-05-19 at 07:09:24 +0200, Paul Menzel wrote:
> Package: dpkg
> Version: 1.22.6
> Severity: normal

> Trying to decrease the boot time of a desktop system (pressing the power
> button to GDM login screen), I noticed `dpkg-db-backup.service` in the
> hotpath:

[…]

> It’d be great if this could be moved out the hot path, for example, by
> running it at least ten(?) minutes after the system has been started.

I'm not sure systemd provides something to implement the requested
behavior though. The closest I see is RandomizedDelaySec, but that
will not guarantee the delay. If you can suggest a specific change
then we can discuss that, otherwise, I'm afraid this might need to
be closed?

Thanks,
Guillem

Bug#1071124: dpkg: post-invoke hook does not run after failure due to non-superuser (but pre-invoke hook does)

[Guillem Jover]

Hi!

On Tue, 2024-05-14 at 18:19:18 +, Ben Ferreri wrote:
> Package: dpkg
> Version: 1.22.6
> Severity: normal
> X-Debbugs-Cc: bferr...@intwineconnect.com

> When attempting to install a package as a non-superuser, the configured
> pre-invoke hook runs, but the post-invoke hook does not. I believe that
> either both hooks should run in this case or neither should.
> 
> For example:
> 
> I have configured both a pre-invoke and post-invoke hook in
> /etc/dpkg/dpkg.cfg.
> I attempt to install a package as a non-root user with `dpkg -i
> mypackage.deb`. The command fails, as expected. However, I observe 
> that the pre-invoke hook has run, but the post-invoke hook has not run.
> 
> I would have expected that if the pre-invoke hook ran, the post-invoke
> hook should also have run.

Ah, indeed. Thanks for the report. I've got this fixed locally, but
I'll ponder a bit more about the correct semantics, when combined with
--force-not-root. For --no-act/--dry-run I think it's clear they
should not be executed though.

Thanks,
Guillem

Bug#1071078: Skip creation of start-stop-daemon compat symlink if /sbin does not exist

[Guillem Jover]

Hi!

On Mon, 2024-05-13 at 22:36:12 +0200, Johannes Schauer Marin Rodrigues wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: wishlist
> Tags: patch

> dpkg postinst fails to create the start-stop-daemon compatibility
> symlink if /usr does not exist:
> 
> ln: failed to create symbolic link '/sbin/start-stop-daemon': No such 
> file or directory
> 
> Getting into this situation requires some creativity. Here is an example:
> 
> $ mmdebstrap --variant=custom 
> --include=dpkg,dash,diffutils,coreutils,libc-bin,sed unstable /dev/null

> Here are two patches that fix this problem by just not creating the
> compatibility symlink in this situation:

Yes, thanks, as we discussed on IRC I think this is better than the
initially proposed change to create the directory, which would break
on usr-merged systems that ship /sbin as a symlink in base-files.

> --- a/debian/dpkg.postinst
> +++ b/debian/dpkg.postinst
> @@ -59,7 +59,8 @@ setup_aliases()
>  
># Add a backward compatibility symlink alias for s-s-d, which is now
># installed in its canonical location.
> -  if [ ! -f "$DPKG_ROOT/sbin/$prog" ]; then
> +  # Skip creation of the compat symlink if /sbin is not an existing directory
> +  if [ ! -f "$DPKG_ROOT/sbin/$prog" ] && [ -d "$DPKG_ROOT/sbin" ]; then
>  ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog"
>fi
>  }
> 
> --- a/debian/dpkg.postinst
> +++ b/debian/dpkg.postinst
> @@ -59,8 +59,10 @@ setup_aliases()
>  
># Add a backward compatibility symlink alias for s-s-d, which is now
># installed in its canonical location.
> +  # Failure to create the compat symlink (for example if /usr does not
> +  # exist) is non-fatal.
>if [ ! -f "$DPKG_ROOT/sbin/$prog" ]; then
> -ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog"
> +ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog" || true
>fi
>  }
>  
> 
> The second patch has the advantage, that the user will receive the error
> message from ln about its inability to create the symlink together with the
> reason for the failure.

When I proposed suppressing the creation of the symlink I had in mind
and had locally the first approach, because it's less noisy, and I
assume users on those kind of systems will have logic somewhere to
handle that case anyway.

But I've been thinking that this still seems wrong from a conceptual
PoV, in that I think base-files should be unpacked as one of, if not
the first package as part of the bootstrapping protocol, as it encodes
the structure and metadata for the base filesystem. I think next would
be base-passwd as that also defines the metadata for the filesystem.

For example the symlink to dir and dir to symlink avoidance behavior
in dpkg would be one reason for this, another is that directory
metadata does not get updated if the directory exists, so the first
unpack wins.

I realize that we have continuously talked about wanting to avoid
encoding this kind of ordering in external tools, and this information
should be part of the packages themselves (which I still think is the
right approach). But I think we still could extend the packaging
and/or possibly the bootstrap protocol to cover this case.

One option would be to add dependencies within the bootstrap set on
both of these packages, but that goes counter to the no-depends on
essential packages, and would not be safe against other external
packages that might conflict with metadata definitions in base-files,
but it would work for the specific dpkg issue, and perhaps that would
be the better immediate fix. Another could be to mark these two base-*
packages somehow so that the bootstrap tools know in a generic way
that they need to unpack them first. I guess a field could be used,
something like the following comes to mind:

  base-files
Bootstrap: fsys-tree

  base-passwd
Bootstrap: fsys-meta

(or Bootstrap-Phase or Bootstrap-Order, or …).

Where I think the order should be:

  fsys-tree → fsys-meta → rest of essential + dependencies

This does not solve the other bootstrap problem we've had in the past
with base-files requiring passwd information from base-passwd before
that has been unpacked, but I guess that might partially go away once
we can declare optional paths and template-based initialization
through fsys metadata so that the base-files maintscript can disappear
completely. Although an external dpkg will still have a similar problem
as base-files currently does, and will need to either assume some name
to id mappings or use the ones from outside the chroot, but meh.

(But perhaps the solution to that last bit is for base-files to declare
the user/groups it requires as dpkg sysusers out of previously agreed
definitions from base-passwd, then that would make it all self-contained.)

> I'm working around this issue in the mmdebstrap test suite by creating /sbin
> manually in a hook. I'm filing this bug to not loose track of the situation
> and to be able to add a bugnumber to the hook.

Thanks. I'm happy to apply the ln 

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], ,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_H=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]

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/patches/implic

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#1070197: debsign: Ensure future GnuPG interop by forcing OpenPGP compliant behavior

[Guillem Jover]

Package: devscripts
Version: 2.23.7
Severity: wishlist
Tags: patch
X-Debbugs-Cc: Daniel Kahn Gillmor 

Hi!

GnuPG upstream has decided to get out of the standardizing process for
OpenPGP, and instead is trying to push its own proprietary fork based on
an old draft that did not have consensus within the IETF working group.

This is going to be a source of interoperability problems, but we can
mitigate them somewhat when creating signatures by requiring compliance
with the OpenPGP RFC, even if it's going to be locked into an old version,
as later ones are not planned to get implemented. More so, given that the
latest releases of GnuPG have been switched to default to the proprietary
draft.

We need to set secure signing preferred algorithms as 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.

Equivalent changes were made to dpkg-buildpackage.

Attached the patch implementing this.

(Ideally debsign would also grow additional OpenPGP backends, like
dpkg did, or perhaps it could be replaced entirely with the upcoming
dpkg-sign program.)

Thanks,
Guillem
From 14fd5d300f4cf9188d09aed356cc348d3d5c49fa Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 27 Apr 2024 20:33:05 +0200
Subject: [PATCH] debsign: Ensure future GnuPG interop by forcing OpenPGP
 compliant behavior

GnuPG upstream has decided to get out of the standardizing process for
OpenPGP, and instead is trying to push its own proprietary fork based on
an old draft that did not have consensus within the IETF working group.

This is going to be a source of interoperability problems, but we can
mitigate them somewhat when creating signatures by requiring compliance
with the OpenPGP RFC, even if it's going to be locked into an old version,
as later ones are not planned to get implemented. More so, given that the
latest releases of GnuPG have been switched to default to the proprietary
draft.

We need to set secure signing preferred algorithms as 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.

Equivalent changes were made to dpkg-buildpackage.
---
 scripts/debsign.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/debsign.sh b/scripts/debsign.sh
index 15b0dfc2..bc894b18 100755
--- a/scripts/debsign.sh
+++ b/scripts/debsign.sh
@@ -178,6 +178,8 @@ signfile() {
 then
 	$signcommand --no-auto-check-trustdb \
 		--local-user "$signas" --clearsign \
+		--openpgp \
+		--personal-digest-preferences 'SHA512 SHA384 SHA256 SHA224' \
 		--list-options no-show-policy-urls \
 		--armor --textmode --output "$ASCII_SIGNED_FILE"\
 		"$UNSIGNED_FILE" || \
@@ -188,6 +190,8 @@ signfile() {
 	}
 else
 	$signcommand --local-user "$signas" --clearsign \
+		--openpgp \
+		--personal-digest-preferences 'SHA512 SHA384 SHA256 SHA224' \
 		--no-show-policy-url \
 		--armor --textmode --output "$ASCII_SIGNED_FILE" \
 		"$UNSIGNED_FILE" || \
-- 
2.43.0

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#1066875: devscripts: debsign tries to parse gpg version from human-readable output, should use machine-readable output

[Guillem Jover]

Hi!

On Thu, 2024-03-14 at 14:55:36 -0400, Daniel Kahn Gillmor wrote:
> Package: devscripts
> Version: 2.23.7
> Tags: patch

> debsign currently tries to determine the version of gpg by parsing the
> human-readable output of `gpg --version`.

[…]

> The attached patch converts debsign to use the machine-parseable format,
> rather than the human-readable format.

I was just modifying this code for another report I'm about to file,
and instead wondered why have it at all! I'm proposing simply removing
the backwards compat code given that even in oldstable gnugp1 is
already at verison 1.4.23. See attached patch.

Thanks,
Guillem
From a9601103ca8deb4aeaaca04b8f42272ced6fde27 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 27 Apr 2024 23:06:39 +0200
Subject: [PATCH] debsign: Remove compatibility code for ancient GnuPG

The code is trying to handle GnuPG versions older than 1.4, where
the oldest GnuPG version available in Debian via the gnupg1 package
is 1.4.23 since oldstable. So there is no much point in trying to
support even older versions.

Remove the code to simplify things.
---
 scripts/debsign.sh | 37 ++---
 1 file changed, 10 insertions(+), 27 deletions(-)

diff --git a/scripts/debsign.sh b/scripts/debsign.sh
index 15b0dfc2..2ddb8b11 100755
--- a/scripts/debsign.sh
+++ b/scripts/debsign.sh
@@ -170,33 +170,16 @@ signfile() {
 ASCII_SIGNED_FILE="${UNSIGNED_FILE}.asc"
 (cat "$file" ; echo "") > "$UNSIGNED_FILE"
 
-gpgversion=$($signcommand --version | head -n 1 | cut -d' ' -f3)
-gpgmajorversion=$(echo $gpgversion | cut -d. -f1)
-gpgminorversion=$(echo $gpgversion | cut -d. -f2)
-
-if [ $gpgmajorversion -gt 1 -o $gpgminorversion -ge 4 ]
-then
-	$signcommand --no-auto-check-trustdb \
-		--local-user "$signas" --clearsign \
-		--list-options no-show-policy-urls \
-		--armor --textmode --output "$ASCII_SIGNED_FILE"\
-		"$UNSIGNED_FILE" || \
-	{ SAVESTAT=$?
-	  echo "$PROGNAME: $signcommand error occurred!  Aborting" >&2
-	  stty $savestty 2>/dev/null || true
-	  exit $SAVESTAT
-	}
-else
-	$signcommand --local-user "$signas" --clearsign \
-		--no-show-policy-url \
-		--armor --textmode --output "$ASCII_SIGNED_FILE" \
-		"$UNSIGNED_FILE" || \
-	{ SAVESTAT=$?
-	  echo "$PROGNAME: $signcommand error occurred!  Aborting" >&2
-	  stty $savestty 2>/dev/null || true
-	  exit $SAVESTAT
-	}
-fi
+$signcommand --no-auto-check-trustdb \
+	--local-user "$signas" --clearsign \
+	--list-options no-show-policy-urls \
+	--armor --textmode --output "$ASCII_SIGNED_FILE"\
+	"$UNSIGNED_FILE" || \
+{ SAVESTAT=$?
+  echo "$PROGNAME: $signcommand error occurred!  Aborting" >&2
+  stty $savestty 2>/dev/null || true
+  exit $SAVESTAT
+}
 stty $savestty 2>/dev/null || true
 echo
 PRECIOUS_FILES=$(($PRECIOUS_FILES + 1))
-- 
2.43.0

Bug#1069846: dpkg: dpkg-deb fails to build package w/ incomplete changelog entry

[Guillem Jover]

Hi!

On Thu, 2024-04-25 at 18:42:50 +0100, Rainer Weikusat wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: minor
> Tags: patch
> X-Debbugs-Cc: rweiku...@cyberadapt.com

> The /usr/share/dpkg/pkg-info.mk file invokes dpkg-parsechangelog to
> set the SOURCE_DATE_EPOCH environment variable to the date of the
> last changelog entry for the package being built. If this changelog
> entry hasn't yet been finalized with a date, eg, if it looks like this
> (actual example):
> 
> apache2 (2.4.59-ca001-1-deb12u2) unstable; urgency=medium
> 
>   * updated to Debian 12 sources
> 
>  --
> 
> SOURCE_DATE_EPOCH is set to an empty string. This causes the
> parse_timestamp routine in build.c to fail and print the (rather
> confusing) error message:
> 
> unable to parse timestamp '': Success
> 
> (Success being printed because errno isn't set). Package generation then
> fails because dpkg-deb afterwards terminates with an exit code of 2.
> 
> Building such packages may not be a supported feature but I've been
> using it for dev builds of packages for about 20 years (and plan to
> continue doing so). The included patch avoids the issue by ignoring the
> value of SOURCE_DATA_EPOCH when it's empty.

Thanks for the report and the patch! I've queued the attached patch,
in addition to another one improving the error messages to avoid the
above confusing output, and I'll also add yet another one refactoring
the functions (which I had pending on doing).

Thanks,
Guillem
From 93e7b2268fabc35d754ffe6389b5172b5917eb8c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 25 Apr 2024 22:44:19 +0200
Subject: [PATCH] src: Check whether SOURCE_DATE_EPOCH is set before parsing it

The dpkg-deb and dpkg-split program try to parse this environment
variable to use it for their timestamps inside files to generate
reproducible artifacts. But when the environment variable is set
but empty then the parsing function fails with a confusing error
message.

This is an issue when building a package directly via debian/rules
that uses the pkg-info.mk fragment file, because that one tries to
set the SOURCE_DATE_EPOCH and can end up setting it to an empty value
if the changelog contains an unfinished trailer. This is not an issue
when using dpkg-buildpackage, though because the code there will
fallback to use the current time if it there is no value from the
changelog.

Closes: #1069846
Based-on-patch-by: Rainer Weikusat 
---
 src/deb/build.c   | 2 +-
 src/split/split.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/deb/build.c b/src/deb/build.c
index 1f0c050ee..16f2bafdf 100644
--- a/src/deb/build.c
+++ b/src/deb/build.c
@@ -597,7 +597,7 @@ do_build(const char *const *argv)
   m_output(stdout, _(""));
 
   timestamp_str = getenv("SOURCE_DATE_EPOCH");
-  if (timestamp_str)
+  if (str_is_set(timestamp_str))
 timestamp = parse_timestamp(timestamp_str);
   else
 timestamp = time(NULL);
diff --git a/src/split/split.c b/src/split/split.c
index 771de626c..04d41b281 100644
--- a/src/split/split.c
+++ b/src/split/split.c
@@ -162,7 +162,7 @@ mksplit(const char *file_src, const char *prefix, off_t maxpartsize,
 	version = versiondescribe(>available.version, vdew_nonambig);
 
 	timestamp_str = getenv("SOURCE_DATE_EPOCH");
-	if (timestamp_str)
+	if (str_is_set(timestamp_str))
 		timestamp = parse_timestamp(timestamp_str);
 	else
 		timestamp = time(NULL);
-- 
2.43.0

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Guillem Jover]

Hi!

On Thu, 2024-03-28 at 09:58:29 +0800, Sean Whitton wrote:
> On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index 4307e89..2fb05cd 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -685,7 +685,7 @@ variables are also available.
> >
> >  The ``debian/substvars`` file is usually generated and modified
> >  dynamically by ``debian/rules`` targets, in which case it must be
> > -removed by the ``clean`` target.
> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
> > clean``).
> >
> >  See :manpage:`deb-substvars(5)` for full details about source variable
> >  substitutions, including the format of ``debian/substvars``.
> > @@ -725,8 +725,9 @@ building packages to record which files are being 
> > generated.
> >
> >  It should not exist in a shipped source package, and so it (and any
> >  backup files or temporary files such as ``files.new``)  [#]_ should be
> > -removed by the ``clean`` target. It may also be wise to ensure a fresh
> > -start by emptying or removing it at the start of the ``binary`` target.
> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
> > clean``).
> > +It may also be wise to ensure a fresh start by emptying or removing it at 
> > the
> > +start of the ``binary`` target.
> >
> >  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
> >  to ``debian/files`` for the ``.deb`` file that will be created when
> 
> Instead of "It may also be wise ..." can you use one of the sets of
> magic words from Policy 1.1, please?

This text was already part of policy and the proposed patch did not
really touch it, except for wrapping it into a new line. I think
modifying it feels a bit out-of-scope for this request? But if you
think it's relevant, and the sentence should be improved as part of
this, then I'll try to provide some wording. :)

Thanks,
Guillem

Bug#868095: base-files: clean up legacy conffiles

[Guillem Jover]

Hi!

On Mon, 2024-04-15 at 13:15:13 +0200, Santiago Vila wrote:
> Hi. I'm scared about removing /etc/profile by accident.
> 
> Guillem: I see that dpkg contains some helper programs to remove
> "obsolete conffiles".
> 
> Are they meant to be used for conffiles which should no longer exist,
> or also for conffiles which are no longer conffiles but should
> continue to exist?

I'm afraid they are for the former.

> The end goal is to make "dpkg -s base-files" not to show /etc/profile anymore
> on systems which were upgraded from an old Debian release (where the file
> was still a conffile). Is there a tested and fool-proof way to do that?

I don't think there is one. I guess at least right now it would require
devising, testing and adding a new action to dpkg-maintscript-helper.
But perhaps I should just focus on the conffile handling rework, with
dynamic conffile support. I've at least added an explicit entry for
this specific case to my dpkg TODO list (even though I think this was
already implicit in that planned rework).

Thanks,
Guillem

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Guillem Jover]

Hi!

On Wed, 2024-04-17 at 04:24:16 +0200, Vincent Lefevre wrote:
> Package: developers-reference
> Version: 13.5
> Severity: normal

> Now that the deborphan package has been removed from unstable,
> the section "Make transition packages deborphan compliant" in
> "Best Packaging Practices" is out of date and should be updated.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312
> where "apt-mark auto ..." (for autoremove) is suggested as a
> replacement. But with it, putting transition packages to oldlibs
> is even more necessary.

While I fully support properly marking obsolete packages by putting
them in the (unfortunately misnamed :) oldlibs section (well excluding
library-like depended on packages that get dropped as a mater of course).
I wanted to note that I've received some pushback from the archive
maintainers about this being considered unnecessary churn (paraphrasing
from what ISTR). So it would be nice to clarify this with them before
creating and proposing a procedure that might end up generating social
friction.

Thanks,
Guillem

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Guillem Jover]

Hi!

On Thu, 2024-04-18 at 23:29:11 +0300, Maytham Alsudany wrote:
> Package: debian-policy
> Version: 4.7.0.0
> Severity: normal
> X-Debbugs-Cc: debian-de...@lists.debian.org

> In early 2022, Guillem added support for a new Static-Built-Using field to
> dpkg, encouraging packagers to use it over Built-Using to specify
> statically-linked dependencies [2]. The commit message states the following:
> 
>   This field mimics the previous Built-Using field semantics, but is
>   specifically intended for shadow dependencies stemming from static builds.
>   
>   In Debian, the Rust and Go teams agreed to use this language agnostic field,
>   instead of one for each of the languages. This means it can be easily
>   supported by dpkg, and can be used by other languages and run-times.
> 
> This was also added to the deb-control(5) manpage, specifically 
> differentiating
> it from Built-Using as a field to be used "for static building purposes (for
> example linking against static libraries, builds for source-centered languages
> such as Go or Rust[...])".

I think this (and the policy proposal) is omitting several important
parts for the intended use for the field, as it was considered on its
addition. Quoting from deb-control(5) for context, which I think
covers the concerns from the mails from Simon and Chris:

   Built-Using: 
   This dependency field lists extra source packages that were used
   during the build of this binary package, for license compliance
   purposes.  This is an indication to the archive maintenance
   software that these extra source packages must be kept whilst this
   binary package is maintained.  This field must be a comma-separated
   list of source package names with strict ‘=’ version relationships
   enclosed within parenthesis.  Note that the archive maintenance
   software is likely to refuse to accept an upload which declares a
   Built-Using relationship which cannot be satisfied within the
   archive.

   Static-Built-Using: 
   This dependency field lists extra source packages that were used
   during the build of this binary package, for static building
   purposes (for example linking against static libraries, builds for
   source-centered languages such as Go or Rust, usage of header-only
   C/C++ libraries, injecting data blobs into code, etc.).  This is
   useful to track whether this package might need to be rebuilt when
   source packages listed here have been updated, for example due to
   security updates.  This field must be a comma-separated list of
   source package names with strict ‘=’ version relationships enclosed
   within parenthesis.

   Supported since dpkg 1.21.3.

> The proposed change is to clarify and formally mandate the requirement to
> declare statically-linked libraries used to build packages containing binaries
> in Static-Built-Using. Attached is a draft patch of the proposed change.

Thanks for starting this!

As mentioned before I think the currently proposed description is too
restrictive and specific to Go and Rust, and it should be expanded. The
example usage seems also too specific, and might lead people to think
this is the only valid use, and their placement feels a bit odd, perhaps
these should be given as a footnote? (But this is really for the Policy
editors to decide.)

Thanks,
Guillem

Bug#1020533: Bug#825385: Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Guillem Jover]

Hi!

On Fri, 2023-06-16 at 16:29:17 +0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Guillem Jover (2022-10-10 12:23:58)
> > On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues 
> > wrote:
> > As mentioned on IRC, the problem here (and on #825385) is indeed that dpkg
> > considers its own arch the native one, and when operating on a cross-arch
> > chroot, that goes wrong, both in dependency resolution and when outputting
> > arch-qualified package names for example.
> > 
> > Fixing this properly is tricky though, because there are multiple
> > requirements in tension here:
> > 
> >   * The external dpkg should be able to tell what's the arch for the
> > internal one w/o having to execute anything (that it might not be
> > able to run anyway).
> >   * Setting a file on the database means either requiring a dpkg
> > maintscript (for the bootstrap phase) which we are trying to get
> > rid of, or offloading this to the bootstrappers (even worse), it
> > also means it could be modified w/o dpkg noticing, which can break
> > dependency resolution from an existing system.
> >   * Shipping a file with the arch would seem like the best option (as
> > that is checksummed) and not in the db, but that means then, that
> > pathname under /usr needs to be selectable too at run-time, as
> > that encodes configure-time vendor-specific fsys layout.
> >   * Setting that directory from the config file is currently
> > problematic as dpkg does not have a way to specify a different
> > config directory.
> >   * Perhaps just adding a new --foodir option to dpkg could be enough
> > for now, if the inner dpkg uses a different pathname, in the
> > same way if it uses a different database pathname.
> >   * But then only specifying the db pathname would no longer be
> > enough, and dependency resolution and arch-qualifying would still
> > be wrong. :/
> >   * But then if the file does not exist (or cannot be found in the
> > «right» place) it could still fallback to the currently running
> > native arch, but that looks flaky (not worse than now, though,
> > but not ideal). :/
> > 
> > I guess I can prototype something with the --foodir idea though, but that's
> > still rather meh.
> 
> once you have a prototype (even if it's not release-ready) feel free to share
> it, because our CI setup is able to apply patches to source packages. So if 
> you
> have something that we can test, just send it over and we'll build a patched
> dpkg to run this with our scripts.

I provided a prototype patch some time ago which got integrated in
Helmut's dpkg-root-demo CI system. But I've not been entirely happy
with it though. I've been rethinking about it from a clean slate and
I went with a file in the db instead which seems way cleaner after all.
My current reasoning is:

  * Shipping a file under /usr/share means:
- The chroot has no defined native arch until dpkg is unpacked, which
  again imposes an installation ordering, which we'd rather avoid I
  think.
- It also requires to install a dpkg in the chroot! (Which is generally
  desirable but might not be in cases such as for testing purposes.)
- It requires hardcoding a filesystem pathname (worse) in addition to
  the database pathname.
- It creates a public interface.
  * It creates a potential out-of-sync situation between the admindir
and the root directory, as these can be specified separately.
  * It would require adding a new --foodir option for this new
directory.
  * If we need to pre-create the file in the chroot, I think doing
that inside the db is always preferable than creating one in the
filesystem part, because the latter is a filesystem policy
governed by the chroot distributor, and is part of the packaged
data while the location of the latter is still a policy issue,
it is something already handled by the tooling and more
independent than the packaged bits.
  * In the future pre-creating the file could be done by extending
dpkg to provide a new dpkg action to initialize a chroot db for
example, that could hide any such detail, while doing the same for
the chroot filesystem seems just wrong.

The annoying part is that this information is already present in the
Architecture field for the dpkg package, but that is also a downstream
policy decision and I'd consider it a regression to try to infer the
package name dpkg itself is being packaged as inside the chroot, not
to mention that still does not cover some of the points above anyway.

I've queued the changes and I'm planning to push them during the
weekend.

Thanks,
Guillem

Bug#1068483: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo

[Guillem Jover]

Hi!

On Wed, 2024-04-10 at 15:22:45 -0700, Vagrant Cascadian wrote:
> On 2024-04-09, Guillem Jover wrote:
> > I've now finished the change I had in that branch, which implements
> > support so that dpkg-buildpackage can be passed a .dsc or a source-dir,
> > and in the former will first extract it, and for both then it will
> > change directory to the source tree. If it got passed a .dsc then it
> > will instruct dpkg-genbuildinfo to include a ref to it.
> >
> > Which I think accomplishes the requested behavior in a safe way? I've
> > attached what I've got, which I'm planning on merging for 1.22.7. I'll
> > probably split that into two commits though before merging.
> 
> Had a chance to take this for a test run, and it appears to work, though
> with a few surprises...

Ah, thanks for the testing, that was very helpful! :)

>   dpkg-buildpackage -- hello_2.10-3.dsc
> 
> Ends up regenerating the .dsc, as --build=any,all,source by default
> ... which may end up with a different .dsc checksum in the .buildinfo
> than .dsc that was passed on the commandline. Which makes some sense,
> but maybe would be better to error out? I would not expect to regenerate
> the .dsc if you're passing dpkg-buildpackage a .dsc!

Hmm, right I think I had documented that locally in the manual page,
but I can see how this can be surprising. I've for now switched the
code to not regenerate the .dsc when that is being passed, but the
problem is that I think the three options are potentially correct:

  * regen: If you built the source on a stable/unstable system, then
you'd want to regenerate it on the target one (for unstable or a
backport or stable update), otherwise we might get compatibility
issues or missed updates. It is also what is being requested when
calling dpkg-buildpackage (as in "please build source and
binaries" :).
  * no-regen: If we rebuild then we might end up with inconsistent
sources if these are tracked in different places, and if you pass
it the sources then it seems logical to expect them not to be
regenerated.
  * error: This is the safe option of "both options are correct, let's
do none :D", of deferring the interface behavior.

Even though I changed it to no-regen for now, I'm thinking, though,
that the regen behavior is the more correct one.

>   dpkg-buildpackage --build=any,all -- /path/to/hello_2.10-3.dsc
> 
> Fails to find the .dsc file, as it appears to extract the sources to
> hello-2.10 and then expects to find ../hello_2.10-3.dsc

Ah, right, this is expected to be a filename not a pathname. (Placing
the source elsewhere is not currently feasible, see #657401; I mean I
guess dpkg-buildpackage could copy the source but…).

I've now added a check, although I'll be reworking it a bit before
merging, because it will emit confusing output if you specify
«./filename.dsc» as not being in the current directory. :)

> All that said ... this seemed to work for me:
> 
>   dpkg-buildpackage --build=any,all -- hello_2.10-3.dsc
> 
> So yay, progress! Thanks!

Great, thanks!

> All of the above cases do not clean up the hello-2.10 extracted from the
> .dsc file, so re-running any of the above need to manually clean that or
> run from a clean directory or experience various failure modes with the
> existing hellp-2.10 directory.

I've also added an explicit check, and dpkg-buildpackage now will error
out if the directory already exists. I don't think removing a
pre-existing directory would be safe (at least w/o an explicit option
to do so). But perhaps, as you hinted, removing the source tree (for a
successful build) after finishing would indeed be an option, hmm.

> So a few little glitches, but overall this seems close to something we
> have really wanted for reproducible builds! And just for good measure,
> thanks!

I force-pushed the reworked code into:

  
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/dpkg-buildpackage-dsc

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#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Guillem Jover]

Hi!

On Mon, 2024-03-11 at 01:44:30 +0100, Nicolas Boulenguez wrote:
> Package: dpkg-dev
> Followup-For: Bug #872381

> Please consider this new patch queue instead of the old or untested
> ones.  With this one applied on 279c6ccb, the package builds and
> passes all tests.

Thanks!

> * scripts/mk: only use ASCII characters
>   Cosmetic independent suggestion.

I'll skip this one, these are in comments are UTF-8 should be safe to
use.

> * scripts/mk: protect files against double inclusion
>   The variables are renamed as you have recommended.
>   The test is fixed (ifdef fails on a defined but empty variable).

Merged, although I've renamed the variables to avoid the slashes and
«.», as even though permitted by make, can be rather surprising and
have unintended consequences if they need to be passed to a shell
(unlikely here but…). And they hardcode a pathname that might not
match the actual destination of these files in the system (which can
be rather confusing).

> * scripts/mk: stop hard-coding dpkg_datadir
>   Already discussed.

I've still skipped this for now, while I think I like it, see my
previous reply, as there's still the possibility we might need to
replace other stuff, such as SED anyway.

> * scripts/mk/buildopts.mk: search once for parallel= in DEB_BUILD_OPTIONS
> 
> > > [...DEB_BUILD_OPTION_PARALLEL empty instead of undefined
> > > when parallel= is missing...]
> > [kind of an API change].
> 
> I have changed my patch and updated the comment.

Merged.

> However..
> The policy only describes 'parallel=N' when N is a positive integer.
> I think we should assume that the option is either missing or valid.
> For me, 'parallel=' is as incorrect as 'parallel=foo'.

Right, but I'm not sure whether there's anything now relying on this,
which could break. :/

> > I think it might perhaps make more sense to fallback to setting it
> > to 1 if it's missing, but I need to ponder about possible
> > consequences/fallout, etc.
> 
> I doubt any sensible default exist.
> * 1 is safe/produces readable logs and $max_available_processors is fast.
> * the policy/debhelper/... have found no one-size-fits-all solution.

Sure, let's leave this for now, it can always be revisited later on.

> * scripts/buildflags.mk: add missing GCJFLAGS
>   Fixes a bug.

This was removed with commit 19dccf2b43d07ee0cb62ac002658768dce0b33aa,
due to the gcj project being dead since 2018.

> * scripts/buildflags.mk: generate the _FOR_BUILD variant of each variable

Merged.

> * scripts/buildflags.mk: sort the flag list
>   These changes hopefully prevent new missing flags in the future (the
>   output of dpkg-buildflags is sorted).

While in general I also prefer sorted lists, these currently try to
match the order in the toolchain stack, which also matches the order
in the manual page and other perl modules. I'll skip this for now.

> * scripts/*.mk: reduce the number of subprocesses

I've skipped this for now, see previous discussion about sed usage.

> * scripts/t: use loops instead of repetitions, check exports and overrides

Could you split this into one commit for the loop switch, and another
for the new tests? Also I think the later commit to handle spaces
should be folded into the loop splitting and new tests additions.

>   * all four combinations of existing/new scripts/mk/*.mk pass the
> existing/new tests in scripts/t/mk/*.mk.
>   * comparing the time taken by tests gives a rough idea of the speed
> gain
> architecture.mk 30 times faster (probably no gain under dpkg-buildpackage)
> buildflags.mk   20 times faster
> pkg-info.mk  4 times faster
> buildtools.mk20% faster
> 
> Guillem Jover
> > I've left this one out for now. I'm not entirely satisfied with the
> > sed usage here. If we keep using sed, then I think it needs to be
> > set via a SED variable, substituted from the value found at
> 
> In which context do you expect GNU Make but a non recent sed?
> Should I rewrite the regular expressions without -r/-E?

BSD systems come to mind, where GNU sed might be called gsed for
example, or not present at all. And where GNU make might be called
gmake. But the proper name is detected at configure time, so if we are
using sed then we should use the detected one.

> > configure time. But then, I've been pondering whether we can have
> > better export formats, that might make the sed usage not
> > necessary. I started with a make-eval export mode for buildflags,
> > but perhaps it would be better a more generic formatting mode where
> > the caller can specify how the output should look like, akin
> > «dpkg-query --showformat». Will ponder about this.
> 
> A generic format would be more maintainable in the long term.
> Something like that would be con

Bug#1068483: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo

[Guillem Jover]

Control: forcemerge 882511 1068483

Hi!

After replying to Adrian's report, I recalled there being a previous one
that was similar, and then recalled that I had an even older branch that
implemented a potential solution for this. See below.

On Thu, 2017-11-23 at 16:23:29 +0100, Ximin Luo wrote:
> Package: dpkg-dev
> Version: 1.19.0.4
> Severity: wishlist
> Tags: patch

> dpkg-buildpackage currently does not automatically list the source .dsc nor
> its hash in the call to dpkg-genbuildinfo when doing a binary-only build. This
> is understandable because in a binary-only build, dpkg-buildpackage does not
> have any concept of a source package and therefore does not know (and cannot
> verify) if the working tree was actually generated from any .dsc or not.
> 
> However, the caller knows this information, and it is useful for reproducible
> builds to track exactly which (i.e. hash-wise) source code generates which
> binary packages. So it should be possible for the caller to tell
> dpkg-buildpackage, "yes please do include the .dsc hash in the buildinfo, I am
> telling you it is correct, you can assume this safely".
> 
> Tools like sbuild/pbuilder could then do this, as well as users or rebuilders.
> 
> The attached patch implements this in the simplest way possible. It allows the
> caller to run something like:
> 
>   $ dpkg-buildpackage --no-sign -b --buildinfo-option=--build=full
> 
> The resulting $pkg_$ver_$arch.buildinfo then contains the .dsc and its hash.
> 
> However this requires the caller to know which option to pass, which would 
> either be
> 
>   --buildinfo-option=--build=full
>   --buildinfo-option=--build=any,source
>   --buildinfo-option=--build=all,source
> 
> depending on whether the original build request (to dpkg-buildpackage) was a 
> -b, -B, or -A.
> 
> For this reason, it may be better (more usable) to add a 
> --force-source-in-buildinfo
> flag (or similar name) and when this is switched on, do this instead:
> 
> -push @buildinfo_opts, "--build=$build_types" if 
> build_has_none(BUILD_DEFAULT);
> +push @buildinfo_opts, "--build=$build_types,source" if 
> build_has_none(BUILD_DEFAULT);
> 
> Let me know if you like this idea and I'll be happy to implement that instead 
> of
> the attached patch.

The problem with this solution is that it is prone do accidental use,
as it is very easy for a user to unknowingly have recreated the sources
from a locally extracted tree (be that modified or not).

On Sat, 2024-04-06 at 02:57:40 +0200, Guillem Jover wrote:
> On Sat, 2024-04-06 at 02:56:02 +0300, Adrian Bunk wrote:
> > Package: dpkg-dev
> > Version: 1.22.6
> > Severity: normal
> > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> > A thought I already wrote in a recent debian-devel discussion:
> > 
> > In theory source package filenames should be eternally and globally
> > unique, but in practice there are cornercases where this assumption
> > might break like for example:
> > - *stable-security does not currently have a copy of the sources
> >   in the main archive, one always have to upload the source archive
> >   there and this might accidentally be a different orig.tar
> > - dak does not keep an eternal history of everything it ever knew,
> >   e.g. RM and later re-NEW of a source version might have a different
> >   source .orig.tar or even different sources for a Debian revision
> > - Debian and Ubuntu might have different orig.tar for the same version,
> >   if Ubuntu updated a package before Debian did, or with packages
> >   were development is completely independent in Debian and Ubuntu
> >   (e.g. OpenStack, KDE)
> > 
> > The reason for different files might be as trivial as "git archive"
> > not always producing the same output when running in different
> > environments, e.g. the autogenerated tarball for a git tag on Github
> > might have different checksums depending on whether it is downloaded
> > today or next year despite identical contents due to slightly
> > different gzip compression.
> > 
> > Should buildinfo files contain the hashes of the source package,
> > to clearly define what sources have been used?
> 
> Ideally? Yes, and I think we considered that at the time when we
> introduced the .buildinfo files. Although a ref to the .dsc does get
> included if the build is also creating the source package.
> 
> The problem is that when dpkg-buildpackage is not building the source
> package, there is no guarantee the source package is going to be
> present, or that if it is present it matches what is currently being
> built from the working directory.

I've now finished the c

Bug#1068483: dpkg-genbuildinfo: Should buildinfo files copy the hash of the source package?

[Guillem Jover]

Hi!

On Sat, 2024-04-06 at 02:56:02 +0300, Adrian Bunk wrote:
> Package: dpkg-dev
> Version: 1.22.6
> Severity: normal
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

> A thought I already wrote in a recent debian-devel discussion:
> 
> In theory source package filenames should be eternally and globally
> unique, but in practice there are cornercases where this assumption
> might break like for example:
> - *stable-security does not currently have a copy of the sources
>   in the main archive, one always have to upload the source archive
>   there and this might accidentally be a different orig.tar
> - dak does not keep an eternal history of everything it ever knew,
>   e.g. RM and later re-NEW of a source version might have a different
>   source .orig.tar or even different sources for a Debian revision
> - Debian and Ubuntu might have different orig.tar for the same version,
>   if Ubuntu updated a package before Debian did, or with packages
>   were development is completely independent in Debian and Ubuntu
>   (e.g. OpenStack, KDE)
> 
> The reason for different files might be as trivial as "git archive"
> not always producing the same output when running in different
> environments, e.g. the autogenerated tarball for a git tag on Github
> might have different checksums depending on whether it is downloaded
> today or next year despite identical contents due to slightly
> different gzip compression.
> 
> Should buildinfo files contain the hashes of the source package,
> to clearly define what sources have been used?

Ideally? Yes, and I think we considered that at the time when we
introduced the .buildinfo files. Although a ref to the .dsc does get
included if the build is also creating the source package.

The problem is that when dpkg-buildpackage is not building the source
package, there is no guarantee the source package is going to be
present, or that if it is present it matches what is currently being
built from the working directory.

Thanks,
Guillem

Bug#1067087: dpkg-buildflags: Enable frame pointers by default

[Guillem Jover]

Control: tags -1 moreinfo
Control: retitle -1 dpkg-buildflags: Enable frame pointers by default

Hi!

On Mon, 2024-03-18 at 09:56:38 +0100, Kurt Roeckx wrote:
> Source: gcc-14
> Severity: wishlist

> Please consider enabling frame pointers on 64 bit arches.
> See: 
> https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html

On Sat, 2024-03-30 at 11:59:24 +0100, Matthias Klose wrote:
> Make sure, that you contact porters on which architectures that should be
> enabled, and e.g. don't do that on 32bit architectures at all.

Please see this entry in the dpkg FAQ:

  
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F

and if you are interested in pursuing this, then start the process,
while I don't see any issue with enabling this, I'm not going to drive
this myself.

Thanks,
Guillem

Bug#1068342: RFP: valkey -- Persistent key-value database with network interface (Redis fork)

[Guillem Jover]

Hi!

On Wed, 2024-04-03 at 12:29:44 -0400, Antoine Beaupre wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: Guillem Jover , "Chris Lamb" 
> 
> 
> * Package name: valkey
>   Version : 7.2.4
>   Upstream Contact: https://github.com/valkey-io
> * URL : https://github.com/valkey-io/valkey
> * License : BSD-3
>   Programming Lang: C
>   Description : Persistent key-value database with network interface 
> (Redis fork)
> 
> Valkey is a high-performance data structure server that primarily
> serves key/value workloads. It supports a wide range of native
> structures and an extensible plugin system for adding new data
> structures and access patterns.
> 
> 
> 
> "This project was forked from the open source Redis project right
> before the transition to their new source available licenses."
> 
> Valkey is one of many Redis forks out there, but it seems to me to be
> the most promising one, at least after reading this LWN article:
> 
> https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/

Yes, I initially had doubts about it because at the time it did not
even have a name, and thought that Redict might be the only viable
direct option. But before the article came up, and after checking a
bit more the context, my impression swapped, and I agree that this
feels more like the spiritual successor for Redis.

> For me, the plus sides:
> 
>  1. unchanged licence (while redict changed to LGPL)

I agree that license continuity is a plus for a project with an
established user base and ecosystem, and that the LGPL change could
be rather disruptive here.

>  2. has the backing of the Linux foundation

  2.1 apparently including Snapchat, so KeyDB might perhaps
  eventually be abandoned for this one (?)

>  3. exact same feature set as Redis before the fork (while KeyDB is
> lagging behind)

Although I'd qualify this, as it does not seem so clear cut, KeyDB has
a different set of features currently missing in Redis/Valkey, such
as active-active replication support (which we require at work), and
multi-threading (for a nice performance boost). It has indeed not
integrated the changes from Redis 7 (which we have not missed).

   4. has many of the old contributors, including previous core team
  members

> We use Redis at the Tor Project internnally, and we're looking for a
> smooth transition, drop-in replacement.

For a smooth migration from Redis 7, Valkey seems like the obvious
candidate indeed.

Thanks,
Guillem

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Guillem Jover]

On Fri, 2024-04-05 at 09:22:04 +0200, Raphael Hertzog wrote:
> On mer., 27 mars 2024, Guillem Jover wrote:
> > A binNMU would fix that, but given that no one has apparently asked
> > for that yet, I think instead I'll just add (later today) a compat
> > symlink only for the udeb for the old SONAME, because the new SONAME is
> > ABI compatible, but done to avoid stomping on the upstream SONAME in
> > case they end up merging something else or rejecting the patches, but
> > in d-i we do not care about backwards compatibility as long as it is
> > ABI compatible, then no binNMU will be needed anymore.
> 
> Would it be problematic to add the same compat symlink in the main
> library package?

I think so yes, because if the intention is to reverse the SONAME
bump (while adding the t64 symlinks also on the reintroduced libaio1
package), then I'd need to add Replaces in both directions which would
then depend on the installation order. :/

> Since the SONAME is changed, the presence of the compat symlink would
> not change anything on your decision: new software compiled against the
> library would link against the new SONAME, but software compiled against
> the old SONAME would continue to work (since ABI is compatible).
> 
> There are (proprietary) software out there that link against it and we
> happen to ship some in Kali's non-free (oracle-instantclient-*).
> 
> https://pkg.kali.org/pkg/oracle-instantclient-basic
> https://pkg.kali.org/pkg/oracle-instantclient-devel
> 
> It would be nice if we could continue to keep compabitility with binaries
> compiled against upstream's SONAME.

I'll try to fix the Linux issue so that I can send the patches
upstream, although perhaps I could send these right away and leave
the 64-bit syscall part for later, so that I can potentially revert
this as soon as possible in Debian. Will check during the weekend.

Thanks,
Guillem

Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs

[Guillem Jover]

Hi!

On Thu, 2024-04-04 at 23:13:03 +0200, Sebastian Andrzej Siewior wrote:
> On 2024-04-04 00:14:27 [+0200], Guillem Jover wrote:
> > I initially was thinking that a conditionally triggered activation
> > when upgrading from the affected versions would be sufficient, but if
> > people have already upgraded, then that will still leave them with the
> > malicious stuff in their initramfs.
> 
> Do you think about a one-time trigger to ensure the 5.6 release is gone
> or to keep it?

Given that we do not have a release barrier to assume people have
upgraded to a known state, and are dealing with the rolling testing
and sid releases, I'd say probably at least until the release of
trixie to be extra safe, or if you don't want to have it included in
the stable release, then to be removed immediately before or during
the freeze?

(As in, if you include it for say 5.6.1+really5.4.5-2 and remove it
in 5.6.1+really5.4.5-3, if someone does not upgrade until -3 or later
then they will still miss it.)

> I can't tell what happend exactly but the 5.6 release is
> gone from my _current_ initramfs so something triggered it already. Only
> the older "previous" kernel has it.

If you have since installed any other package that might also trigger its
regeneration such as grub, a linux kernel, udev, etc, then that would be
expected. But if users have not, they might still have the backdoor.

I think the price for an excess initramfs regeneration is worth the
hassle of the time it takes to perform that action (better safe than
sorry etc).

Thanks,
Guillem

Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs

[Guillem Jover]

Source: xz-utils
Source-Version: 5.6.1+really5.4.5-1
Severity: important

(Maybe this even deserves to be serious, dunno.)

Hi!

The last upload by the Security Team reverted the version, but that
does not necessarily include regenerating the system initramfs, as
brought up from a comment in LWN but directed to RedHat/Fedora systems.
And detectable in Debian and derivatives with something like:

  ,---
  for i in /boot/initrd.img*; do
echo $i:
lsinitramfs $i | grep liblzma\.so\.5\.6
  done
  `---

I suggested this to the Security Team some days ago, but I guess they
have their hands full. And a bug report here seems probably more
appropriate.

I initially was thinking that a conditionally triggered activation
when upgrading from the affected versions would be sufficient, but if
people have already upgraded, then that will still leave them with the
malicious stuff in their initramfs.

So I guess adding an unconditional:

  ,--- liblzma5.triggers ---
  activate-noawait update-initramfs
  `---

should do, but have not tested the integration.

Thanks,
Guillem

Bug#1068024: revert to version that does not contain changes by bad actor

[Guillem Jover]

Hi!

On Sat, 2024-03-30 at 14:16:52 -0400, Joey Hess wrote:
> My git repository is here (note all my commits are gpg signed):
> https://git.joeyh.name/index.cgi/xz-unscathed/

> My build of dpkg ended up not being linked to a lzma library at all,
> because liblzmaunscathed is too old to support concurrent decompression,
> which the configure script detects. So dpkg-deb instead uses xz-utils
> to decompress debs. I replaced xz-utils.deb with the one built from my
> fork, and dpkg seems to work fine using it.

dpkg should be able to use an old liblzma w/o multi-threaded compressor
or decompressor support (both are intended to be optionally used if
available). I think the problem might be that you seem to have missed
renaming the .pc.in file, and that does not get included in the -dev
package perhaps, or not picked up then by dpkg with your attached
patch to it? I only checked the renaming commit, didn't check the
packaging nor tried to build it.

(Please do not take this mail as endorsing any specific action, just
wanted to clarify/correct the above.)

Thanks,
Guillem

Bug#1068024: Or remove xz altogether?

[Guillem Jover]

On Sat, 2024-03-30 at 00:48:34 +, Stephan Verbücheln wrote:
> Maybe the people who criticized xz back in the day for being an amateur
> project implementing a defective file format were right all along?
> 
> https://www.nongnu.org/lzip/xz_inadequate.html

*Sigh*, the current situation is bad enough, and has nothing to do
with the xz format or design, or the FUD and propaganda from that
link. Please drop it…

Thanks,
Guillem

Bug#1067876: dpkg allows installation of malformed .deb packages resulting in corrupt .list file

[Guillem Jover]

Hi!

On Thu, 2024-03-28 at 09:54:36 +, Grueninger, Tobias wrote:
> Package: dpkg
> Version: 1.20.12
> Severity: wishlist

> In our case we did install a package from a 3rd party which apparently
> uses a non-conforming .deb package building tool (unknown to us)
> resulting in a malformed data.tar.gz

> dpkg did allow this package to be completely installed but generated a
> malformed .list file.

Ah, not good, indeed.

> This as consequence did prevent later installation of any other package
> as dpkg's .list file database was broken resulting in the following
> error message
> 
>   Selecting previously unselected package .
>   (Reading database ...
>   dpkg: unrecoverable fatal error, aborting:
>files list file for package 'xxx-config--xxx' contains empty filename
> 
> Analysis of the .deb package showed
> 
>   dpkg -c xxx-config-xxx.deb 
> 1 drwxrwxr-x root/root 0 2023-09-07 08:36 ./
> 2 drwxrwxr-x root/root 0 2023-09-07 08:36 .//
> 3 drwxrwxr-x root/root 0 2023-09-07 08:36 .//ddd/
> 4 drwxrwxr-x root/root 0 2023-09-07 08:36 .//ddd/fff/
>   ...
> 
> * The offending malform is the second line containing './/' which is not
>   conform to standard, resulting in the following .list file
> 
>   cat -v -t -e ./lib/dpkg/info/xxx-config-xxx.list
> 1 /.$
> 2 /$
> 3 /ddd$
> 4 /ddd/fff$
>   ...
> 
> * the '/$' does break the .list file parsing when later installing other
>   .deb packages
> 
> Clearly the root cause is the use of 3rd party malformed .deb package
> tooling nevertheless my wish to improve would be following:
> 
> 1. As dpkg does parse all existing .list files during installation of
>a .deb package and understand if one of them is malformed it shall
>do this also for the newly generated .deb package .list file.
> 2. If the newly generated .deb package .list file does fail the check
>installation shall be aborted and rolled back.

Thank you for the detailed and very helpful report!

I've prepare a couple of changes to catch these conditions, will check
whether there are more things that should be verified, and add some
test cases for these. Will queue these file git main and probably mark
them as stable candidates.

Thanks,
Guillem

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Guillem Jover]

Hi!

On Wed, 2024-03-27 at 17:56:25 +0700, Arnaud Rebillout wrote:
> Source: libaio
> Version: 0.3.113-7
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali

> I noticed that the t64 variant of the package libaio is already in
> testing. I did a quick check, and it seems that it's the only t64 package
> in testing at the moment, I suppose it wasn't intentional?

In theory, compared to the other packages involved in the transition,
it should not matter whether it transitioned as it is using a new
actual bumped SONAME (instead of only modifying the package name and
reusing the old SONAME). But because the udeb did not get renamed that
is indeed a problem for d-i. See also the thread at:

  https://lists.debian.org/debian-boot/2024/03/msg00125.html

> $ chdist apt-file trixie search -x '/lib/.*lib[^/]+t64$'
> libaio1t64: /usr/lib/x86_64-linux-gnu/libaio.so.1t64
> 
> The libaio1-udeb package is now also using the t64 lib, and it breaks
> the installer ISO that is built from testing. When trying to partition
> the disk using LVM, it fails, and we can see this error in the logs:
> 
> partman: pvscan: error while loading shared libraries: libaio.so.1:
>   cannot open shared object file: No such file or directory
> partman: vgscan: error while loading shared libraries: libaio.so.1:
>   cannot open shared object file: No such file or directory
> partman-lvm: vgchange: error while loading shared libraries: libaio.so.1:
>   cannot open shared object file: No such file or directory
> 
> I must say that this issue was reported in the Kali Linux bugtracker
> [1], as Kali is built on top of Debian testing, so our weekly images are
> now broken for users who try to use LVM partitioning.
> 
> I didn't check if it _really_ affects the weekly Debian installer ISOs,
> but I suppose so.
> 
> I don't know if anything can/should be done at this point, apart from
> waiting for the t64 transition to complete? Or should there be a binNMU
> for the d-i packages partman-*, would that fix the issue?

A binNMU would fix that, but given that no one has apparently asked
for that yet, I think instead I'll just add (later today) a compat
symlink only for the udeb for the old SONAME, because the new SONAME is
ABI compatible, but done to avoid stomping on the upstream SONAME in
case they end up merging something else or rejecting the patches, but
in d-i we do not care about backwards compatibility as long as it is
ABI compatible, then no binNMU will be needed anymore.

Thanks,
Guillem

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

[Guillem Jover]

Hi!

On Fri, 2024-03-22 at 12:35:47 +, Chris Lamb wrote:
> > I'm CCing Chris, who might perhaps be interested in replacing Redis with
> > KeyDB as its spiritual successor and taking this on? Or if not, at least
> > to perhaps potentially coordinate some kind of transition, even though
> > we've had issues migrating persistent DBs from newer Redis to KeyDB, so
> > that might be tricky or not feasible at all.
> 
> Thanks for including me here. I had not yet looked into potential
> Redis replacements nor the exact and precise details of the new
> license etc. and this activity around KeyDB feels like a good start.
> I thought I'd let the dust settle for a bit before making any
> decisions — perhaps the change even gets reversed (!), and no doubt
> there might be new alternatives that will fork the code immediately
> prior to the license change.

Yeah, fair enough.

> My personal and professional usage of Redis has dropped off in the
> past few years, so it would make more sense for me to help out in a
> team maintainership role, at least with respect to KeyDB.

Ack.

> However, I'd be interested in coordinating around some kind of
> Redis→KeyDB/something transition if need be.

For KeyDB, that would also depend on whether KeyDB adds Redis 7 support
or not I guess.

  https://github.com/Snapchat/KeyDB/issues/420

and if that does not materialize, a potential migration path via:

  https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311

In our, case we migrated from Redis 6 to KeyDB, so the above did not
really affect us.

> (Incidentally, why did your work switch to KeyDB?)

We did this several years ago, AFAIR mainly for its active-active
replication mode for our HA setup. The multi-threading was a nice
improvement too. And I cannot recall exactly, but I think at that
time Redis Inc was already going into a weird licensing path with
its other adjacent projects, so we might have taken that too as a
nice side effect to get away from.

Thanks,
Guillem

Bug#1059150: No longer works with signing subkeys

[Guillem Jover]

Hi!

On Wed, 2024-03-20 at 19:05:59 +, Steve McIntyre wrote:
> On Wed, Dec 20, 2023 at 11:59:31PM +0100, Guillem Jover wrote:
> >On Wed, 2023-12-20 at 15:30:24 +, Steve McIntyre wrote:
> >> Package: debsig-verify
> >> Version: 0.23+b2
> >> Severity: important
> >> Tags: patch

> >Ouch, I've been increasingly unhappy with the whole policy thing,
> >because it was not functioning as documented, fixing it to do so has
> >broken multiple use cases, it seems like unnecessary complexity and in
> >a way trying to reimplement some of the checks that should be done by
> >the OpenPGP implementation, and it is getting in the way of adding
> >other OpenPGP backends due to the insistence of tying the signature
> >issuer fingerprint with the policy to apply, which means the primary
> >certificate fingerprint cannot be used as would perhaps be usually
> >expected.
> 
> Nod. To make everything work reliably here for all cases, we're now
> making 4 copies of the policy directory for every key we might use,
> using both the long keyid and the full fingerprint for each of the
> master key and the signing subkey. Then we're including a keyring with
> all of the keys in each of those policy directories. It's not
> wonderful... :-/

Ugh. :/ I'd expect that if the keys are new-ish (and they have a
fingerprint packet), and the package providing the policy does not
need to cater to old debsig-verify packages then just using the
fingerprint path would be enough though? In any case yeah, this is
all very nasty.

> >I recorded part of this in the TODO, and I had in mind asking you
> >about how you use this as part of the redesign work, but I'll leave
> >that for a later point. :)
> 
> ACK. :-)
> 
> So, I'm curious...
> 
> Debsig-verify does seem to be really quite over-complicated, at least
> for our use case. Wouldn't it be much simpler to just have a keyring
> per origin, and then (maybe) a system config file to state which
> origin(s) are needed. The policy definition files don't seem to add
> any value here. IMHO.

I don't know what was the thinking in the original design and
implementation choices TBH, the only thing I can go by is the
specification and design documents from that time. AFAIR this was
designed before (or at a similar time) as the repo signing, so there
was probably not much experience in this area. And perhaps also to
be flexible for unexpected ways people could end up using this.

Also when pondering about how to redesign and simply this, my other
fear is that I've had zero visibility over how people are using this
(if at all) except four your invaluable input!

Currently my thinking is that multiple origins and the role-based
signing ideas are not bad, and that some kind of stacking would be
interesting to support, as you might want to sign .debs taken from
somewhere else, or to record the provenance steps where the packages
have gone through (but perhaps no one is using that for example, or
would ever do, dunno :).

As part of this redesign my main motivation would be to be able to
integrate this directly into dpkg-deb (so no new external libraries,
where in the past I even played with switching from XML to JSON, but
that's still unnecessary complexity and dependencies), and being able
to use SOP as the primary OpenPGP interface (probably also gpgv in
addition).

So from the TODO (slightly edited now):

* Redesign policies:
  - Do not require XML.
  - Do not require fetching the fingerprint for signatures and keys.
  - Use the origin name as entry point, and role names to refer to keyrings.
  - Use filesystem as policy declaration? For example:
/keyrings//origin.pgp
/keyrings//role-maint.pgp
/keyrings//role-uploader.pgp
/keyrings//role-builder.pgp
  - Use a deb822 file for a policy file to denote optional/required/reject?

I'm not even sure we might need a deb822 file, perhaps if that part is
needed/wanted at all it could even be a few text files with just one
line each containing a fingerprint. Say:

  /keyrings//policy/optional
  /keyrings//policy/reject
  /keyrings//policy/required

or similar. And then the match would be based on the vendor, not the
fingerprint, which then should make key rotation, and the OpenPGP
verification (even using SOP) easier to implement, to deploy and to
reason about, I think.

> It would also be lovely if the design was less restricted by
> GnuPG. (Yes, I know!) A real problem for me is that debsig-verify
> wants to see *every* signature accounted for when verifying a
> package. This is opposite to the behaviour of gpgv, which is more like
> what we were inititally expecting / hoping for. We're signing packages
> with a rolling range of N keys for our releases, similar to Debian's
> Release.gpg setup, and now we have to include 4*N policy directories
> for debsig

Bug#1059150: No longer works with signing subkeys

[Guillem Jover]

Hi!

On Wed, 2024-03-20 at 18:00:30 +, Steve McIntyre wrote:
> On Wed, Mar 20, 2024 at 05:18:08PM +, Steve McIntyre wrote:
> >Sorry, I've been swamped with other stuff then ill for the last week
> >or so. Looking now...

No worries, hope you are doing well now! :)

> And I can confirm that your changes work here for our system too.

Perfect, thank you! I'll be rechecking the change and merging and
uploading during the weekend. Then will prepare a stable update.

Thanks,
Guillem

Bug#1067490: tracker.debian.org: Display release-team blocks more prominently

[Guillem Jover]

Package: tracker.debian.org
Severity: wishlist

Hi!

Currently when a package is blocked by a release-team block hint, that
appears at the end of the "Issues preventing migration" list, which
can easily be missed if there are also lots of autopkgtest issues,
(see the current dpkg tracker page).

,---
Migration status for dpkg (1.22.4 to 1.22.6): BLOCKED: Rejected/violates 
migration policy/introduces a regression
Issues preventing migration:
∙ ∙ Updating dpkg would introduce bugs in testing: #1067427
∙ ∙ autopkgtest for ceilometer/blocked-on-ci-infra: i386: Ignored failure
∙ ∙ autopkgtest for chrony/4.5-1: amd64: Pass, arm64: Pass, armel: Regression 
or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), 
i386: Pass, ppc64el: Pass, s390x: Pass
∙ ∙ autopkgtest for dash/0.5.12-6: amd64: Pass, arm64: Pass, armel: Regression 
or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), 
i386: Pass, ppc64el: Pass, s390x: Pass
∙ ∙ autopkgtest for dpkg/1.22.6: amd64: Pass, arm64: Pass, armel: Pass, armhf: 
Pass, i386: Pass, ppc64el: Pass, s390x: Pass
∙ ∙ autopkgtest for gsocket/1.4.41-1: amd64: Pass, arm64: Pass, armel: 
Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ 
(reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass
∙ ∙ autopkgtest for lintian/2.117.0: amd64: Regression or new test ♻ (reference 
♻), arm64: Regression or new test ♻ (reference ♻), armel: Regression or new 
test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: 
Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ 
(reference ♻), s390x: Regression or new test ♻ (reference ♻)
∙ ∙ Not touching package due to block request by sramacher (please contact 
debian-release if update is needed)
Additional info:
∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/d/dpkg.html
∙ ∙ Reproducible on amd64 - info ♻
∙ ∙ Reproducible on arm64 - info ♻
∙ ∙ Waiting for reproducibility test results on armhf - info ♻
∙ ∙ Reproducible on i386 - info ♻
∙ ∙ 11 days old (needed 5 days)
Not considered
`---

The block seems like the most important information there, because
even if everything else gets solved that still requires active action
by the release-team. So I think it would be better to place it as the
first item, also so that it does not get drown by autopkgtest entries
that can be many. Also perhaps the autopkgtest entries should be
nested? As in:

,---
∙ ∙ Status for autopkgtest:
∙ ∙ ∙ ceilometer/blocked-on-ci-infra: i386: Ignored failure
∙ ∙ ∙ chrony/4.5-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ 
(reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
ppc64el: Pass, s390x: Pass
∙ ∙ ∙ dash/0.5.12-6: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ 
(reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
ppc64el: Pass, s390x: Pass
∙ ∙ ∙ dpkg/1.22.6: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: 
Pass, ppc64el: Pass, s390x: Pass
∙ ∙ ∙ gsocket/1.4.41-1: amd64: Pass, arm64: Pass, armel: Regression or new test 
♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
ppc64el: Pass, s390x: Pass
∙ ∙ ∙ lintian/2.117.0: amd64: Regression or new test ♻ (reference ♻), arm64: 
Regression or new test ♻ (reference ♻), armel: Regression or new test ♻ 
(reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression 
or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ (reference ♻), 
s390x: Regression or new test ♻ (reference ♻)
`---

Which would remove repetition and make it visually easier to see?

(This has come up recently, I think multiple times, as I've got multiple
private queries, and some public ones, where it looks like people missed
the main reason for why dpkg is not migrating.)

(Also as an aside, perhaps autopkgtest entries that are all-pass,
should appear in the “Additional info” part instead?)

Thanks,
Guillem

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

[Guillem Jover]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Chris Lamb , Sascha Steinbiss 

* Package name: keydb
  Version : 6.3.4
  Upstream Contact: https://github.com/Snapchat/KeyDB
* URL : https://keydb.dev/
* License : BSD-3-clause
  Programming Lang: C, C++
  Description : persistent key-value database with network interface

 keydb is a key-value database in a similar vein to memcache but the dataset
 is non-volatile. keydb additionally provides native support for atomically
 manipulating and querying data structures such as lists and sets.
 .
 The dataset is stored entirely in memory and periodically flushed to disk.



This project started as a fork from redis, for improved performance and
multi-threading support. We switched at work to it some time ago, and
had pending sending an RFP/ITP, but given the just announced license
change for redis to make it non-free [L], this seems more relevant now.
We've got the packaging bits around, which I'll try to send to this bug
report, but there's still some work that might be needed before an
upload, at least:

  - Unvendor more stuff (we have at least unvendored jemalloc and
rocksdb, but most of the rest need to go too).
  - Switch to use _keydb:_keydb as user and group (instead of
keydb:keydb).
  - Review and improve the maintscripts (as I think we initially based
our packaging on the upstream provided templates).

I'll try to do this during this week or next one, but if someone would
like to package this right ahead, I can speed this up.

I'm CCing Chris, who might perhaps be interested in replacing Redis with
KeyDB as its spiritual successor and taking this on? Or if not, at least
to perhaps potentially coordinate some kind of transition, even though
we've had issues migrating persistent DBs from newer Redis to KeyDB, so
that might be tricky or not feasible at all. I'm also CCing Sascha who
might be interested (given the keydb packaging repo in salsa). (I'm not
sure we are up for sole maintainership if no one takes this on, but
we'd be happy to give a hand in a team maintainership setting and that
might be an option for us if someone else is interested in driving this.)

[L] https://lwn.net/Articles/966133/

Thanks,
Guillem

Bug#1065429: dpkg -s: spurious error "dpkg-query: error: --status needs a valid package name"

[Guillem Jover]

Hi!

On Thu, 2024-03-07 at 04:25:03 +0100, Vincent Lefevre wrote:
> On 2024-03-07 03:34:08 +0100, Guillem Jover wrote:
> > > "apt-cache show libc6-dev" also lists this package.
> > 
> > apt behaves differently, this has been also a known discrepancy, but
> > then they operate in general differently when it comes to their CLI
> > arguments anyway.
> 
> The difference is bad for the user, making simple copy-paste
> impossible, and usage more difficult: the user doesn't know
> in advance whether the package name given by apt needs to be
> completed for dpkg (systematically adding the main architecture
> does not work for "Architecture: all" packages).

That's why dpkg is and has always been internally consistent, and
always arch-qualifies Multi-Arch:any packages (and more recently also
foreign arch:any packages), so that its output can always be used as
its input, even during a cross-upgrade of dpkg itself. As mentioned
above, it's unfortunate that apt implemented a different interface.

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

JFYI, I released dupload 2.11.0 with support for the mentioned
transitions check hook. Have not received any complaints (yet? :).

On Sun, 2024-01-14 at 22:06:46 +0100, Guillem Jover wrote:
> On Sun, 2024-01-14 at 19:35:40 +0100, Guillem Jover wrote:
> > Perfect, thanks. I've force pushed the new changes to the previous
> > branch. How about then the following output?
> > 
> > ,---
> > Warning: Source package barnowl is part of ongoing transitions:
> > 
> >   auto-perl perl-5.38
> > 
> 
> Was wondering now whether it would be better to linkify the list of
> transitions, such as:
> 
> ,---
> Warning: Source package barnowl is part of ongoing transitions:
> 
>   <https://release.debian.org/transitions/html/auto-perl>
>   <https://release.debian.org/transitions/html/perl-5.38>
> 
> […]
> `---
> 
> Although that seems a bit more noisy, but provides more context. I'm
> not sure though how stable those URLs should be considered to be.

In the end went with full URLs, like above.

> > If the upload does not solve issues caused by these transitions, then it
> > might disrupt them by adding delays or entangling them. For more 
> > information,
> > please read:
> > 
> >   <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook>
> > 
> > Note: If you are aware of this and do not want to be warned, you can disable
> > this hook from the config file, set the one-off environment variable
> > DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
> > following prompt.
> 
> (I think I'll be adding some generic way to skip specific hooks,
> because this is a common pattern among them, something like
> --skip-hooks=a,b and DUPLOAD_SKIP_HOOKS=a,b.)

I implemented this too.

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#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Guillem Jover]

Package: debian-policy
Version: 4.6.2.1
Severity: wishlist

Hi!

Currently the Debian policy lists several files that are generated by
dpkg tools, but because there was no matching dpkg tool to clean them
up, it delegates that responsibility to packagers. With dpkg 1.22.3 a
new dpkg-buildtree tool was introduced that supports a «clean» action
precisely to take care of removing all these files. In the future I'd
like to change the location of some of these files, but that requires
for packages that do not use a helper to be updated to match the dpkg
behavior. While I expect this to be controlled via dpkg-build-api, it
would be best if such packages switched to use dpkg-buildtree to have
automatic handling when that time comes.

I've worded the changes as an example, because I don't want to impose
that packages should be using this if they are using a helper or that
helpers necessarily have to call it. If you'd prefer me to spell that
out more explicitly I'm happy to try to come up with some wording. It
intends to be more informational than a requirement, as I am going to
be filing wishlist bugs with patches as time permits, anyway.

I'm attaching a patch to add references to that new tool.

Thanks,
Guillem
From afac52fa956087eb737c123682f634fc739c7e20 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 27 Feb 2024 23:37:06 +0100
Subject: [PATCH] =?UTF-8?q?Add=20references=20to=20=C2=ABdpkg-buildtree=20?=
 =?UTF-8?q?clean=C2=BB=20for=20debian/{substvars,files}?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

These files are generated by dpkg tools (and in some cases by helpers),
but the maintainer was responsible for cleaning them up. There is now
a new command that will take care of cleaning these (and any other
future) files that the dpkg suite might end up generating, making their
introduction easier as the responsibility to remove them shifts back
where it belongs.
---
 policy/ch-source.rst | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 4307e89..2fb05cd 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -685,7 +685,7 @@ variables are also available.
 
 The ``debian/substvars`` file is usually generated and modified
 dynamically by ``debian/rules`` targets, in which case it must be
-removed by the ``clean`` target.
+removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
 
 See :manpage:`deb-substvars(5)` for full details about source variable
 substitutions, including the format of ``debian/substvars``.
@@ -725,8 +725,9 @@ building packages to record which files are being generated.
 
 It should not exist in a shipped source package, and so it (and any
 backup files or temporary files such as ``files.new``)  [#]_ should be
-removed by the ``clean`` target. It may also be wise to ensure a fresh
-start by emptying or removing it at the start of the ``binary`` target.
+removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
+It may also be wise to ensure a fresh start by emptying or removing it at the
+start of the ``binary`` target.
 
 When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
 to ``debian/files`` for the ``.deb`` file that will be created when
-- 
2.43.0

Bug#1032623: marked as done (vcswatch: should not raise error on repos > 1GiB in size)

[Guillem Jover]

Hi!

On Thu, 2024-03-07 at 14:34:39 +0100, Christoph Berg wrote:
> > It looks like this broke for remotes that do not support filtering
> > (yet?). The attached completely untested patch might make this work
> > again. Affecting at least git.hadrons.org and git.dpkg.org, but there
> > might be others too.
> 
> Thanks for spotting that, the patch seems to work.

Great! :)

> Re-running the scan on the dpkg repo still takes around 3 minutes -
> not sure what the client or the server are doing during that time, it
> doesn't re-fetch the repo.

I've now done a «git gc --aggressive» on the repo on the server,
hoping that might help with that.

> On acl and attr the scan is done in 2 or 3s.

These only contain the debian/ directory, so I'd expect them to be
fast no matter what.

Thanks,
Guillem

Bug#1032623: marked as done (vcswatch: should not raise error on repos > 1GiB in size)

[Guillem Jover]

Hi!

On Wed, 2024-03-06 at 14:15:03 +, Debian Bug Tracking System wrote:
> 
> vcswatch: Use --filter blob:none
> 
> Required blobs (changelog, control, upstream metadata) are fetched by
> git on demand. Thanks to Gábor Németh for the suggestion!
> 
> Closes: #1032623
> 

It looks like this broke for remotes that do not support filtering
(yet?). The attached completely untested patch might make this work
again. Affecting at least git.hadrons.org and git.dpkg.org, but there
might be others too.

Thanks,
Guillem
From d78a41fad53de64eb50f72692bf057c82d41fc85 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 7 Mar 2024 13:30:41 +0100
Subject: [PATCH] vcswatch: Ignore warning when the server does not know about
 filtering

The command succeeded, but emitted a warning. Instead of failing the
fetching, ignore the warning.
---
 data/vcswatch/vcswatch | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/data/vcswatch/vcswatch b/data/vcswatch/vcswatch
index be72cc35..611d5372 100755
--- a/data/vcswatch/vcswatch
+++ b/data/vcswatch/vcswatch
@@ -243,6 +243,8 @@ sub process_package ($) {
 	# try a full clone instead
 	runcmd ('git', 'clone', '--quiet', '--bare', '--mirror', '--template', '', $url, $pkgdir);
 	$dbh->do("UPDATE vcs SET dumb_http = true WHERE package = ?", undef, $pkg->{package});
+} elsif ($err =~ /warning: filtering not recognized by server, ignoring/) {
+	# ignore the warning
 } else {
 	error ($err);
 }
-- 
2.43.0

Bug#1059150: No longer works with signing subkeys

[Guillem Jover]

Hi!

On Wed, 2023-12-20 at 23:59:31 +0100, Guillem Jover wrote:
> On Wed, 2023-12-20 at 15:30:24 +, Steve McIntyre wrote:
> > diff --git a/src/openpgp-gpg.c b/src/openpgp-gpg.c
> > index 4c29b7f..97ec3a4 100644
> > --- a/src/openpgp-gpg.c
> > +++ b/src/openpgp-gpg.c
> > @@ -241,6 +242,7 @@ gpg_getKeyID(const char *keyring, const char *match_id)
> > continue;
> >  if (strcmp(uid, match_id) != 0) {
> >  free(uid);
> > +   state = KEYID_SUB;
> > continue;
> > }
> >  free(uid);
> 
> I think the problem with this is that if the first uid does not match,
> then it will then switch to looking for a new fingerprint line, which
> might then omit some valid uids.
> 
> I've prepared a change based on this at:
> 
>   
> https://git.hadrons.org/cgit/debian/dpkg/debsig-verify.git/log/?h=pu/openpgp-subkey
> 
> With the assumption that one would define the policy and keyrings
> paths based on the subkey fingerprint and not the primary public
> certificate fingerprint, because otherwise some of the other matches
> cannot easily match, such as uid-based ones. But wanted to check with
> you whether that's the case before merging. Otherwise I can try to see
> how to support all the various cases.

I assume you have had no time to look into this, but I'd like to make
sure the above branch fixes your issue before merging, and potentially
preparing a backport for stable. :)

Thanks,
Guillem

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Guillem Jover]

Hi!

On Mon, 2024-01-29 at 11:21:32 +0700, Arnaud Rebillout wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali

> Kali Linux is a rolling distro based on Debian testing. We go with a
> merged-usr layout for a while now, and therefore with patch away the
> warning message regarding merged-usr-via-aliased-dirs. We also don't
> install dpkg-fsys-usrunmess anymore, since dpkg 1.22.4.
> 
> Please find attached a patch that adds Kali to the list of distros with
> a usr-merged layout, along Debian and Ubuntu.

Thanks for the patch! Sorry, it seems this has fallen through the
cracks. At the time I received this I looked into adding support for
some new field in the origins file so that then downstreams would not
need to patch dpkg at all, but got stuck with how to name it, and
whether to make it a boolean or contain a set of values for things to
not warn or similar to not make it so specific, contrast something
like:

  Vendor: Kali
  ...
  Show-Usrmerge-Warnings: no

versus something like:

  Vendor: Kali
  ...
  Dpkg-Suppress-Warnings: usrmerge

or similar. But other ideas welcome, although now that I tried to
name the suppress field, it's starting to grow on me. In any case it
seemed preferable to try to come up with a generic solution, and
assumed that as you probably had already made this change in your
distribution source, this was not urgent. But if this is the only
delta you have I'd be fine merging something like the patch that you
provided for now until a more generic solution is implemented.

Thanks,
Guillem

Bug#1065439: dpkg-buildflags: add HIPFLAGS to supported flags

[Guillem Jover]

Hi!

On Mon, 2024-03-04 at 10:59:36 -0700, Cordell Bloor wrote:
> Package: dpkg-dev
> Version: 1.22.5
> Severity: wishlist
> X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

> When packaging the AMD ROCm GPU libraries for Debian, we are currently
> using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if
> they were written in C++.

I guess we should also add HIPCXX (defaulting to -hipcc
and HIPCXX_FOR_BUILD (defaulting to -hipcc when cross
compiling, otherwise to hipcc) like with the other toolchains? An
apt-file query seems to indicate thee hipcc package provides no
triplet-qualified toolchains? Which means automatic cross-compiling
is going to be painful given our current infrastructure.

If support for this is really missing from the looks of it, we can
always postpone adding the compiler tool variables for now until this
is implemented (we can still add the HIPFLAGS variables though). I'm
CCing the debian-cross list for further insight.

> This necessitates filtering out flags that are not supported when
> building HIP language code. For example, the rocsparse d/rules include:
> 
> export CXX=hipcc
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify optimize=-lto
> 
> # filter incompatible options from affecting device code
> CXXFLAGS := $(subst -fstack-protector-strong,-Xarch_host 
> -fstack-protector-strong,$(CXXFLAGS))
> CXXFLAGS := $(subst -fcf-protection,-Xarch_host 
> -fcf-protection,$(CXXFLAGS))
> 
> In the lines above, we are prepending `-Xarch_host` to prevent certain
> flags from being applied to device code (i.e., GPU code) while still
> ensuring that they are applied to host code (i.e., CPU code).
> 
> However, there is HIP language support in CMake. We should use it!
> dpkg-buildflags should set HIPFLAGS [1]. The CXXFLAGS make a good
> starting place for the HIPFLAGS values, but `-Xarch_host` should be
> added to `-fstack-protector-strong` and `-fcf-protection`, like in the
> example above.

> [1]: https://cmake.org/cmake/help/v3.28/envvar/HIPFLAGS.html

It would be helpful if you could verify whether all flags currently
added to CXXFLAGS would work for HIPFLAGS. You can check for all such
instances by searching for either default_flags, @compiler_flags and
CXXFLAGS from:

  $ perldoc -m Dpkg::Vendor::Debian

Once we have the complete list, I'm happy to add the handling for
these flags in the code.

Thanks,
Guillem

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: 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: 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#1064856: dpkg: New xz-utils print warnings on stderr

[Guillem Jover]

On Mon, 2024-02-26 at 20:10:20 +0100, Sebastian Andrzej Siewior wrote:
> On 2024-02-26 19:23:58 [+0100], Guillem Jover wrote:
> > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> > > memory usage limit of 1400 MiB
> > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> > > memory usage limit of 1400 MiB
> > > | 89s 4. deb-format.at:511:  FAILED (deb-format.at:518)
> > > 
> > > Allowing output on stderr would be a possible tix.
> > 
> > Hmm, that's warning is unfortunate, and a quick check at the xz code
> > didn't reveal a way to only suppress it. :/
> > 
> > For dpkg, I'd like to either not get the warning or being able to tell xz
> > that even if the threads are reduced, that's ok and it should not warn
> > about that (but that would then require depending on a new enough
> > version supporting that, perhaps that could be suppresses instead via
> > an envvar) so that?
> 
> Could poke upstream.

Thanks!

> > Ignoring stderr could be a workaround, but I'd need to do something as
> > well for the libdpkg code and the perl code calling xz, which will get
> > very annoying.
> > 
> > This is also going to get in the way of migrating both xz and dpkg
> > (which seems like would need to be uploaded today for the time64
> > transition).
> > 
> > Or perhaps that warning could be disabled for now in Debian until things
> > are sorted out with upstream?
> 
> Falling back to -T1 in order to keep the previous is not an option?

I'm not sure I understand what you are saying. Do you mean dpkg would
fallback to pass -T1 (maybe you mean -T+1, otherwise we might get
unreproducible output due to switching to single-threaded)? And
fallback on what condition?

Ah, I think you mean to pass -T+1 to the xz invocations for the test
suite, right, that could workaround the issue there indeed. Thanks, I
think I'll do that for now.

> Let me try to sell this "we move this warning to verbose" to upstream in
> the meantime…

That would actually be great!

> > (Had not seen this test suite failure yet, as I've got xz on hold due
> > to the breaks on pristine-tar, but would probably stumble over it
> > during the release process anyway I guess, so thanks for the heads up!)
> 
> This poped up on xz debci only armel and armhf.

Perhaps I'll not see it in my local tree then, but I think the dpkg
failure will at least block xz migration, but thinking about it now,
probably not dpkg's migration. So this might not be blocking for dpkg.
(Sorry if this sounded alarming, but didn't want to add new roadblocks
to the time64 transition from the dpkg side! :D)

Thanks,
Guillem

Bug#1064856: dpkg: New xz-utils print warnings on stderr

[Guillem Jover]

Hi!

On Mon, 2024-02-26 at 18:57:32 +0100, Sebastian Andrzej Siewior wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: important

> xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of
> `xz' is now that mutlti threaded compress/ decompression is now enabled
> by default. This in turn leads to warnings if the requested amount of
> memory exceeds the available amount. A snippet from
> 
> https://ci.debian.net/data/autopkgtest/testing/armel/d/dpkg/43341232/log.gz
> 
> | 88s 
> /tmp/autopkgtest-lxc.dumkcbm0/downtmp/build.4CO/src/src/at/deb-format.at:518:
> | 88s # Extract the base members
> | 88s xz -c control.tar >control.tar.xz
> | 88s xz -c data.tar >data.tar.xz
> | 88s
> | 89s --- /dev/null   2024-02-26 09:29:33.669234548 +
> | 89s +++ 
> /tmp/autopkgtest-lxc.dumkcbm0/downtmp/autopkgtest_tmp/src/at/testsuite.dir/at-groups/4/stderr
>2024-02-26 09:30:58.601386838 +
> | 89s @@ -0,0 +1,2 @@
> | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> memory usage limit of 1400 MiB
> | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> memory usage limit of 1400 MiB
> | 89s 4. deb-format.at:511:  FAILED (deb-format.at:518)
> 
> Allowing output on stderr would be a possible tix.

Hmm, that's warning is unfortunate, and a quick check at the xz code
didn't reveal a way to only suppress it. :/

For dpkg, I'd like to either not get the warning or being able to tell xz
that even if the threads are reduced, that's ok and it should not warn
about that (but that would then require depending on a new enough
version supporting that, perhaps that could be suppresses instead via
an envvar) so that?

Ignoring stderr could be a workaround, but I'd need to do something as
well for the libdpkg code and the perl code calling xz, which will get
very annoying.

This is also going to get in the way of migrating both xz and dpkg
(which seems like would need to be uploaded today for the time64
transition).

Or perhaps that warning could be disabled for now in Debian until things
are sorted out with upstream?

(Had not seen this test suite failure yet, as I've got xz on hold due
to the breaks on pristine-tar, but would probably stumble over it
during the release process anyway I guess, so thanks for the heads up!)

Thanks,
Guillem

Bug#960434: Bug#1026463: kanshi: Please ship kanshictl command and man page

[Guillem Jover]

Hi!

On Sat, 2024-01-13 at 15:36:09 +0100, Guillem Jover wrote:
> On Tue, 2020-05-12 at 09:43:04 -0400, Jason Francis wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Jason Francis 
> > 
> > * Package name: varlink
> >   Version : 19
> >   Upstream Author : Kay Sievers 
> > * URL : https://www.varlink.org/
> > * License : Apache-2.0
> >   Programming Lang: C
> >   Description : point-to-point IPC protocol and interface description
> > format
> > 
> > Varlink is an interface description format and protocol that aims to make
> > services accessible to both humans and machines in the simplest feasible 
> > way.
> > 
> > A varlink interface combines the classic UNIX command line options,
> > STDIN/OUT/ERROR text formats, man pages, service metadata and provides the
> > equivalent over a single file descriptor, a.k.a. “FD3”.
> > 
> > Varlink is plain-text, type-safe, discoverable, self-documenting, remotable,
> > testable, easy to debug. Varlink is accessible from any programming
> > environment.
> 
> > ---
> > 
> > Submission Notes:
> > Varlink is a small IPC protocol intended to be a very simple peer-to-peer
> > alternative to D-Bus. A minimal implementation has already been adopted by 
> > the
> > systemd project and integrated into their codebase; however I am submitting
> > this ITP in order to package the official C reference implementation that
> > includes a shared library and command line utility. Another package named
> > "kanshi" that I contribute to upstream is looking at using this library, 
> > and it
> > would be nice to have it ready in Debian for when a new version is 
> > published.
> > I'm not sure what package team this would fall under, but I've been testing
> > some Debian packaging already which is up on my github:
> > https://github.com/cyclopsian/libvarlink/tree/debian-19/debian
> 
> It looks like the upstream varlink project is dead or close to that.
> 
> The last commit on the libvarlink project is from 2 years ago, and
> I think there's been no apparent interaction in MRs and issues for a
> long time. The Linux kernel module for longer. And that looks similar
> for the other bindings, except for the Rust ones which have seen a
> few commits 6 months ago.
> 
> My memory was spotty about its popularity, so did some checking. It
> looks like podman gained varlink support but they then dropped it when
> varlink upstream told them they'd stop maintaining the project:
> 
>   https://podman.io/blogs/2020/12/11/remove-varlink-libpod-conf-notice
>   https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice
> 
> It looks like the main user, as noted above, is systemd, which imported
> or implemented minimal varlink code into their tree and do not use the
> external reference implementation at all.
> 
> Then also checked dependencies in Debian:
> 
>   - python3-varlink: 0 reverse depends
>   - golang-github-varlink-go-dev: 0 build-depends
> 
> A search for varlink.h across all Debian sources:
> 
>   https://codesearch.debian.net/search?q=varlink.h=1
> 
> shows only a handful of potential users. Searching instead of varlink
> gives way more hits, but I think the majority are unrelated, and instead
> are related to Java SWIG.
> 
> 
> The state of this upstream does not look very healthy, and from here
> it does not look like adding this to Debian might be entirely wise.
> For kanshi perhaps upstream should be looking into using something
> else, maybe Cap'n Proto <https://capnproto.org/>?

I ended up submitting a request upstream [I] to switch away from varlink,
which from my analysis above looks like a pretty dead project
upstream, but kanshi upstream mentioned not being interested and did
not give further insights about the varlink status or the effects of
depending on it.

  [I] <https://todo.sr.ht/~emersion/kanshi/104>

I don't think it would be wise to include varlink (as it is right now)
into Debian, and thus enabling support for it in kanshi does not seem
wise either to me, so I'll retract my request for this bug, thus
closing it now.

Thanks,
Guillem

Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

[Guillem Jover]

Hi!

On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Loren M. Lang 

> * Package name: golang-github-cheggaaa-pb
>   Version : 3.1.5-1
>   Upstream Author : Sergey Cherepanov
> * URL : https://github.com/cheggaaa/pb
> * License : BSD-3-clause
>   Programming Lang: Go
>   Description : Console progress bar for Golang

> This is a dependency for pwru which is in RFP and I plan to complete packaging
> shortly. pwru is an eBPF-based Linux kernel networking debugger.

This is already packaged as:

  golang-github-cheggaaa-pb.v3-dev
  golang-gopkg-cheggaaa-pb.v2-dev
  golang-gopkg-cheggaaa-pb.v1-dev

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#1064036: dpkg: wrong dpkg-query exit status on syntax error?

[Guillem Jover]

Hi!

On Fri, 2024-02-16 at 04:37:47 +0100, Christoph Anton Mitterer wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: normal

> dpkg-query manpage says:
> EXIT STATUS
>0   The requested query was successfully performed.
> 
>1   The  requested  query  failed  either fully or partially, due to no
>file  or  package   being   found   (except   for   --control-path,
>--control-list and --control-show were such errors are fatal).
> 
>2   Fatal  or unrecoverable error due to invalid command-line usage, or
>interactions with the system, such as  accesses  to  the  database,
>memory allocations, etc.

> E.g.:
>  $ dpkg-query --showformat='${db:Status-Status}' --show --list 2>/dev/null ; 
> echo $?
>  2
> looks good, as does
>  $ dpkg-query --showformat='${db:Status-Status}' --show not-existing-package 
> 2>/dev/null ; echo $?
>  1
> 
> But e.g.
>  $ dpkg-query --showformat='${db:Status-Statu' --show  2>/dev/null ; echo $?
>  1
> causes also 1, though it fails because of the syntax error in the format 
> string.
> 
> Shouldn't that be a 2?

Yeah, I think so. I've looked into this now, and there are several
problems in the dpkg-query code, one is that several of the action
functions only ever return 1 for any direct failure they handle, the
other is that even if they returned something else, the main()
function coerces that return code into a boolean, so it always ends
up being 0 or 1. I'll have a pass over the entire code, and correct
all instances and queue this for the next upload. Thanks!

> At least it seems to make it impossible to definitely find out whether a 
> package
> is not installed (respectively not existant).

Exactly.

> btw. it will also not fail at all in cases like:
>  $ dpkg-query --showformat='${db:Status-Statu}' --show  2>/dev/null ; echo $?
>  0
> where the field doesn't exist. Not sure whether that’s desired or not

This is used for field names, be them real or virtual, so erroring out
on fields that do not exist would seem bad. But there's the
distinction between the real fields and virtual ones, where the latter
always contain a colon. So I guess I could make the latter, at least
warn if they do not exist. My main concern with making them errors, is
that this would break backwards and/or forwards compatibility, where
you could not use a new or renamed field with old or new releases.

Thanks,
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#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#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#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=1=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#1061665: sq: Broken bash completion

[Guillem Jover]

Package: sq
Version: 0.33.0-2
Severity: normal

Hi!

It looks like the bash completion is broken, the file only contains
now:

  ,---
  $ cat /usr/share/bash-completion/completions/sq
  target/sq.bash sq
  `---

Thanks,
Guillem

Bug#1061450: /usr/bin/dpkg-buildpackage: dpkg-buildpackage does not have tab completion

[Guillem Jover]

Hi!

On Wed, 2024-01-24 at 19:18:15 +, Aidan Gallagher wrote:
> Package: dpkg-dev
> Version: 1.20.12
> Severity: wishlist
> File: /usr/bin/dpkg-buildpackage
> Tags: newcomer
> X-Debbugs-Cc: aidg...@gmail.com

> I'm creating a wrapper around dpkg-buildpackage that allows package
> builds to run in a docker container
> (https://github.com/aidan-gallagher/debpic).
> 
> My package has tab completion for everything however when I added
> the option to specify dpkg-buildpackage options I realised
> dpkg-buildpackage doesn't have tab completion.
> 
> I assume this is an easy task that is free for picking up?

I've been working on trying to first integrate the current bash
completion support from the bash-completion upstream, but there are
some compatibility issues that need to be fixed first:

  https://github.com/scop/bash-completion/issues/694
  https://github.com/guillemj/bash-completion/tree/pu/upstream-dpkg

and here's the integration in dpkg itself:

  
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/merge-bash-completions

But then I don't think that would affect dpkg-buildpackage. So if you
want to tackle that one, that would be great. I can probably split the
build system support and merge that and leave the tricky parts of the
hand over for later.

If you are talking about zsh, that also works though! :)

Thanks,
Guillem

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

[Guillem Jover]

Hi!

On Tue, 2024-01-23 at 16:47:34 -0800, Joshua Hudson wrote:
> On Tue, Jan 23, 2024 at 3:16 PM Guillem Jover  wrote:
> > On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote:
> > > Package: dpkg
> > > Version: 1.21.22
> > > Severity: important

> > > Source for long link record length does not include trailing null:
> > >
> > > https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294
> > >
> > > I've stashed the offending .deb package but I'm not sure if I can
> > > get clearance to release it.
> >
> > Ack. I did not try to reproduce this yet because it was not obvious
> > exactly how to do that from the report, instead just inspected the
> > code for potential brokenness related to this, and I think I've fixed
> > this now, but as I've not tested it, could you instead try applying
> > the attached patch against dpkg and test with your package whether
> > this fixes the problem you've found?
> 
> That patch fixed the bug. Knowing where the bug is, I can see how
> the bug works and explain why. I'm wondering if this was just a
> pending disaster for everybody or if there's some actual reason it
> doesn't trip on official packages.

Thanks for testing! Much appreciated.

It looks like the code in libdpkg has been like that since long GNU
names and links were implemented (around Oct 1999, in dpkg commit
<https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=3252594427f5285ab4091a6beca2adaa5082a883>).

Checking now the libdpkg test suite and the GNU tar implementation
which is what gets used to generate .debs by dpkg-deb, I see it always
includes the NUL byte as part of the size, which explains why this has
never been a problem when using the dpkg-deb tooling combined with GNU
tar.

  <https://git.savannah.gnu.org/cgit/tar.git/tree/src/create.c#n542>

I assume, given the libtar link you provided initially, that your custom
.deb package is being generated by something using that library? If so
that would also explain things. I think libtar should probably get a
bug report to mimic the GNU behavior.

But regardless of libtar getting fixed or not, I'm still going to be
committing the change, to make the parser robust against such input.

Thanks,
Guillem

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

[Guillem Jover]

Hi!

On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: important

> On unpacking a custom .dpkg file with long symbolic links, I found a
> bunch of symbolic links ending in right, and one with copyright. The
> overrun made all the links exactly the same length; suggesting reuse
> of some kind of static buffer, but it's not clear if that's really
> the case.
> 
> Making long link records an extra byte longer for the trailing null
> fixed the overrun and allowed the package to unpack correctly.

Where those long name lengths exactly multiples of 512?

> Source for long link record length does not include trailing null:
> 
> https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294
> 
> I've stashed the offending .deb package but I'm not sure if I can
> get clearance to release it.

Ack. I did not try to reproduce this yet because it was not obvious
exactly how to do that from the report, instead just inspected the
code for potential brokenness related to this, and I think I've fixed
this now, but as I've not tested it, could you instead try applying
the attached patch against dpkg and test with your package whether
this fixes the problem you've found?

> This is a potential security vulnerability due to the bug class,
> but I can'd find a plausible exploit pathway.

I don't think this is a security issue, because dpkg-deb (which is the
only component that's expected to be used with untrusted .debs, in
contrast to dpkg which expects only trusted data) never uses the libdpkg
tar extracting implementation, and instead it uses the external GNU tar
implementation.

See 
and 
for recently added blurbs on the security expectations. :)

Thanks,
Guillem
diff --git i/lib/dpkg/tarfn.c w/lib/dpkg/tarfn.c
index bc39acd7d..d999db68e 100644
--- i/lib/dpkg/tarfn.c
+++ w/lib/dpkg/tarfn.c
@@ -362,7 +362,7 @@ tar_gnu_long(struct tar_archive *tar, struct tar_entry *te, char **longp)
 	int long_read;
 
 	free(*longp);
-	*longp = bp = m_malloc(te->size);
+	*longp = bp = m_malloc(te->size + 1);
 
 	for (long_read = te->size; long_read > 0; long_read -= TARBLKSZ) {
 		int copysize;
@@ -386,6 +386,7 @@ tar_gnu_long(struct tar_archive *tar, struct tar_entry *te, char **longp)
 		memcpy(bp, buf, copysize);
 		bp += copysize;
 	}
+	*bp = '\0';
 
 	return status;
 }

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Guillem Jover]

Hi!

On Fri, 2024-01-19 at 14:13:07 +, Aidan wrote:
> On Fri, 19 Jan 2024, 00:08 Guillem Jover,  wrote:
> > …regardless of whether this is or not the last blocking issue, I'd
> > still very much appreciate if you could rename the project and tool
> > upstream. :)

> I shall rename the tool to remove "dpkg". Unless there are any objections
> I'm going to rename it to:
> "debpic: DEbian Build Package In Container"

That looks better, yes, and thank you for considering doing that!

(Also the pic part also evokes into my mind "image" which seems apt in
this context. :)

Thanks,
Guillem

Bug#1060320: dpkg-buildpackage: PERL_UNICODE variable causes bad encoding in output

[Guillem Jover]

Hi!

On Tue, 2024-01-09 at 15:39:33 +0100, Peter Krefting wrote:
> Package: dpkg-dev
> Version: 1.21.22
> Severity: wishlist
> Tags: l10n

> With PERL5OPTS=-Mutf8 and PERL_UNICODE=SDL set in environment [1], output from
> dpkg-buildpackage (and others) is garbled ("double" UTF-8 encoding):
> 
>   $ dpkg-buildpackage --version
>   Debian dpkg-buildpackage version 1.21.22.
> 
>   Detta program är fri programvara. Se GNU General Public License version 2
>   eller senare för kopieringsvillkor. Det finns INGEN garanti.
> 
> Unsetting PERL5OPTS fixes it:
> 
>   $ bash -c "unset PERL_UNICODE; dpkg-buildpackage --version"
>   Debian dpkg-buildpackage version 1.21.22.
> 
>   Detta program är fri programvara. Se GNU General Public License version 2
>   eller senare för kopieringsvillkor. Det finns INGEN garanti.

Right, dpkg does not currently set its streams to be UTF-8. But I
agree it probably should.

> [1] As per https://stackoverflow.com/a/6163129

Ah, yes, that page is great, I've had it in my bookmarks for a long
time. :D

In any case I started looking into this the other day, and the first
blocker is that adding «use open qw(:encoding(UTF-8) :std);» is not
enough as the gettext code needs to be switched to its Object Oriented
methods which handle encoding according to the locale automatically,
otherwise we also get doubly encoded output. I've got some of this in
a branch but…

…my concern is whether just with those two things will be enough, or
if we'll get botched input/output, like we did in around 2008, when a
similar change in spirit was done for dpkg-genchanges, dpkg-gencontrol
and dpkg-source. So I'll need to check all this thoroughly, and add
new test cases, etc.

Thanks,
Guillem

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Guillem Jover]

Hi!

On Thu, 2024-01-18 at 23:14:49 +, Aidan wrote:
> On Thu, Jan 18, 2024 at 6:30 PM David Kalnischkies wrote:
> > On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote:
> > > I am looking for a sponsor for my package "dpkg-buildenv":
> >
> > Similar to my recent "veto" of apt-verify in #1059267, which was
> > subsequently ignored and pushed into the archive anyhow, I would
> > like to call into question the naming of the package/application…
> >
> > There are various "dpkg-build*" tools already that grabbing 'env' feels
> > wrong (I would confuse it probably with 'flag' on a bad day), especially
> > if that isn't at least discussed with dpkg maintainers (I at least see
> > no mention of it on the list) and given that this is something that
> > "just" works with Docker.

Just by chance I had seen the mail on the mentors list, but thanks for
the heads-up, because I tend to look there very sporadically!

My reaction was pretty similar TBH. There's enough confusion with
things like dpkg-reconfigure and dpkg-preconfigure and other packages
that have also grabbed from the dpkg-* namespace, which I'd like to
reduce. In this case, it would remove the possibility to use such name
in the future, creates confusion, and it looks like a layer violation,
because it's setting up apt, containers and stuff which should be
sitting on top and not below dpkg.

> > As explained in the other bug, there is no veto and as you can see its
> > easy to completely ignore me (and anyone else) but I wanted to say it
> > anyhow, so that nobody is surprised later on.

> Thanks for taking a look David.
> For the name I choose "dpkg'' because it stands for "debian package" and
> dpkg-buildenv is intrinsically related to debian packaging.
> However I understand the usage of dpkg may imply the package has been
> officially created and maintained by the dpkg developers.

Yes, see above. I also appreciate naming is hard, :) but all other
similar implementations could have claimed the same about using dpkg-*,
and I think josch questions are also relevant, even though I also
understand that even among all other options, none might seem
completely suitable to you. But…

> If the package's name was the last blocking issue preventing adoption in
> Debian then I would spend the time to rename it.

…regardless of whether this is or not the last blocking issue, I'd
still very much appreciate if you could rename the project and tool
upstream. :)

Thanks,
Guillem

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Guillem Jover]

Hi!

On Wed, 2024-01-03 at 15:04:01 -0700, Sam Hartman wrote:
> >>>>> "Guillem" == Guillem Jover  writes:
> Guillem> At least the dpkg behavior seems entirely
> Guillem> correct to me and required for safe upgrades (
> 
> Can you help me understand the sentence above?
> Where is the case where this behavior is needed for safe upgrades?
> (I am asking out of curiosity; I'm guessing it's some corner case with
> essential packages, but I would like to understand.)

I should probably have qualified that statement, where safe upgrades
is restricted to the specific scenarios at hand. In any case, I don't
think this is specific to essential packages, this seems more general.
But of course the effects of not supporting such safe upgrades for
essential packages would be potentially more severe (although an
essential package can never be a conflictor as dpkg would refuse to
remove it).

In essence this involves a cyclic restriction where a set of packages
are stating they cannot be unpacked at the same time, but later
versions might be. There are several subcases for this depending on
the strength of the dependencies from each side, whether these are
versioned, and also whether the package manager front-end or the user
decides whether to fully evict a conflictor or wants to upgrade to a
latest version that can co-exist.

What the current behavior permits is to safely intertwine an unpack,
a conflictors files transfer and its removal in the same step, so that
the front-end or the user does not need to apply --force-* options to
forcibly remove the conflictor while breaking the dependency system
for an undetermined amount of time, to be able to proceed with such
upgrade.

I don't see any other way around this kind of upgrade that does not
break the dependency system besides the current behavior (if someone
does, I'm happy to hear it). Of course there's always the option to
prohibit those kinds of relationships, which means the behavior never
is brought up, and there's no need either to be concerned about whether
it needs to be supported or not. But that seems overly restrictive,
because once or if you need to express that kind of relationship, then
that path would be closed.


All this being said, when Helmut brought this up, I noticed that dpkg
is expecting to be hand held by giving to it the proper order for these
operations (as front-ends do), or it will either fail to upgrade
depending on the scenario, or unnecessarily use the conflictor eviction
behavior, which are not ideal (but do not break the dependency system).
I've got some test cases (Conflicts vs Breaks, Conflicts vs Conflicts),
which I should expand to add addition restrictions in the form of
Depends and Pre-Depends, unversioned relationships and similar, after
which I'll look into improving the way dpkg schedules its processing
queue in these cases so that it is a bit smarter about them and does
not fail so easily or uses this behavior unnecessarily when there's a
path forward at hand. But this seems besides the point of the conflictor
eviction behavior.

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 19:35:40 +0100, Guillem Jover wrote:
> Perfect, thanks. I've force pushed the new changes to the previous
> branch. How about then the following output?
> 
> ,---
> Warning: Source package barnowl is part of ongoing transitions:
> 
>   auto-perl perl-5.38
> 

Was wondering now whether it would be better to linkify the list of
transitions, such as:

,---
Warning: Source package barnowl is part of ongoing transitions:

  <https://release.debian.org/transitions/html/auto-perl>
  <https://release.debian.org/transitions/html/perl-5.38>

[…]
`---

Although that seems a bit more noisy, but provides more context. I'm
not sure though how stable those URLs should be considered to be.

> If the upload does not solve issues caused by these transitions, then it
> might disrupt them by adding delays or entangling them. For more information,
> please read:
> 
>   <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook>
> 
> Note: If you are aware of this and do not want to be warned, you can disable
> this hook from the config file, set the one-off environment variable
> DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
> following prompt.
> 

(I think I'll be adding some generic way to skip specific hooks,
because this is a common pattern among them, something like
--skip-hooks=a,b and DUPLOAD_SKIP_HOOKS=a,b.)

> Continue anyway? (yes/NO) 
> Ok, aborting the upload.
> 
> `---

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 19:12:03 +0100, Paul Gevers wrote:
> On 14-01-2024 18:46, Guillem Jover wrote:
> > I think that would be great, I guess the message from the hook could
> > give some very basic and generic guidance, and point to this page for
> > more in-depth explanation of what to do, what else to check etc. But in
> > any case an initial version sounds good, as that can always be tuned,
> > or extended/improved later on. :)
> 
> Initial version. Please consider the name too, moving now is easier than
> later:
> https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook

Perfect, thanks. I've force pushed the new changes to the previous
branch. How about then the following output?

,---
Warning: Source package barnowl is part of ongoing transitions:

  auto-perl perl-5.38

If the upload does not solve issues caused by these transitions, then it
might disrupt them by adding delays or entangling them. For more information,
please read:

  <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook>

Note: If you are aware of this and do not want to be warned, you can disable
this hook from the config file, set the one-off environment variable
DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
following prompt.

Continue anyway? (yes/NO) 
Ok, aborting the upload.

`---

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 18:22:16 +0100, Paul Gevers wrote:
> On 14-01-2024 17:43, Guillem Jover wrote:
> >https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> > 
> > but it looks like that one is targeted more to maintainers that start
> > or drive the transitions instead of someone that might upload a
> > package which is part or affected by that transition?
> 
> Indeed. I had the same idea when I replied earlier, but I think we'd need a
> new (wiki) page for this. If we happen to agree here, I'm fine with creating
> an initial version.

I think that would be great, I guess the message from the hook could
give some very basic and generic guidance, and point to this page for
more in-depth explanation of what to do, what else to check etc. But in
any case an initial version sounds good, as that can always be tuned,
or extended/improved later on. :)

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 10:22:21 +0100, Paul Gevers wrote:
> On 10-01-2024 02:23, Guillem Jover wrote:
> > I've had for a while a new hook for dupload that adds a transitions
> > check for Debian hosts, for sourceful uploads targeting unstable (to
> > avoid disrupting buildd or porter uploads, or uninteresting suites).
> > I've just finished polishing it, and the main lingering question I've
> > had all along has been whether you think this would actually be useful
> > and/or desired at all, see below.
> > 
> > The hook is currently using
> > https://release.debian.org/transitions/export/packages.yaml, and
> > prompting in case that source package is part of any ongoing
> > transition.
> 
> Cool.
> 
> > I wondered also whether checking
> > https://ftp-master.debian.org/transitions.yaml would be useful,
> > but I'm not sure whether that is or has ever been used?
> 
> It still works, but it's hardly used. I do have some vague ideas to use it
> again in the future, but that's not going to happen soon I guess.

Ok, then, I might leave this as a comment reference as a potential
future source in case this ever gets used.

> > So I guess my questions would be whether you think this is helpful or
> > useful at all?
> 
> Yes, I do.

Ok, great! :)

> > If so, whether the criteria is adequate or it needs to
> > be changed? Whether this should be a prompt, or maybe only an info or
> > warning? And any other comment or suggestion you might have!
> 
> I'm mostly wondering if the information shown is enough to help people. I'm
> actually surprised how many people don't know how transitions work. What is
> your opinion on the length of the text you could provide? Maybe a link to a
> wiki page with more info particularly for this case?

Ah, right, having a longer description and an external reference would
actually be in line with other similar notices such as:

  https://git.dpkg.org/cgit/dpkg/dupload.git/tree/hooks/debian-source-only#n73
  https://git.dpkg.org/cgit/dpkg/dupload.git/tree/hooks/debian-security-auth#n23

If you have some proposed wording, I'll gladly incorporate that,
otherwise I'll try to come up with something and post it here for
review, with a reference to at least:

  https://release.debian.org/transitions/

and perhaps to:

  https://wiki.debian.org/Teams/ReleaseTeam/Transitions

but it looks like that one is targeted more to maintainers that start
or drive the transitions instead of someone that might upload a
package which is part or affected by that transition?

> Maybe Sebastian can comment on how often he sees interfering uploads to
> judge if it should be a warning or a prompt. If you make this only a
> warning, what are the options of the uploader, canceling?

Hmm, right, just a warning would probably not be very helpful, and if
it gets a pause (with no prompt) then in effect that's kind of a prompt
anyway as you can always Ctrl-C or similar. So probably a prompt might
be the best option, but it's not clear whether that will end up being
very annoying. Probably it would need some easy way to disarm it, say
an env var or similar, instead of requiring to change the config.

> PS: if you're happy with this, should we file wish list bugs against dput
> and dput-ng too?

I think that would be nice, once the above details are more clear. :)

Thanks,
Guillem

Bug#1026463: Bug#960434: ITP: varlink -- point-to-point IPC protocol and interface description format

[Guillem Jover]

Hi!

[ I was asked to mentor someone to complete this ITP, which prompted
  me to look into its current state. ]

It seems Jason's mail bounces, so this ITP should at least be turned
into an RFP most probably, and even perhaps be closed, see below.

On Tue, 2020-05-12 at 09:43:04 -0400, Jason Francis wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jason Francis 
> 
> * Package name: varlink
>   Version : 19
>   Upstream Author : Kay Sievers 
> * URL : https://www.varlink.org/
> * License : Apache-2.0
>   Programming Lang: C
>   Description : point-to-point IPC protocol and interface description
> format
> 
> Varlink is an interface description format and protocol that aims to make
> services accessible to both humans and machines in the simplest feasible way.
> 
> A varlink interface combines the classic UNIX command line options,
> STDIN/OUT/ERROR text formats, man pages, service metadata and provides the
> equivalent over a single file descriptor, a.k.a. “FD3”.
> 
> Varlink is plain-text, type-safe, discoverable, self-documenting, remotable,
> testable, easy to debug. Varlink is accessible from any programming
> environment.

> ---
> 
> Submission Notes:
> Varlink is a small IPC protocol intended to be a very simple peer-to-peer
> alternative to D-Bus. A minimal implementation has already been adopted by the
> systemd project and integrated into their codebase; however I am submitting
> this ITP in order to package the official C reference implementation that
> includes a shared library and command line utility. Another package named
> "kanshi" that I contribute to upstream is looking at using this library, and 
> it
> would be nice to have it ready in Debian for when a new version is published.
> I'm not sure what package team this would fall under, but I've been testing
> some Debian packaging already which is up on my github:
> https://github.com/cyclopsian/libvarlink/tree/debian-19/debian

It looks like the upstream varlink project is dead or close to that.

The last commit on the libvarlink project is from 2 years ago, and
I think there's been no apparent interaction in MRs and issues for a
long time. The Linux kernel module for longer. And that looks similar
for the other bindings, except for the Rust ones which have seen a
few commits 6 months ago.

My memory was spotty about its popularity, so did some checking. It
looks like podman gained varlink support but they then dropped it when
varlink upstream told them they'd stop maintaining the project:

  https://podman.io/blogs/2020/12/11/remove-varlink-libpod-conf-notice
  https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice

It looks like the main user, as noted above, is systemd, which imported
or implemented minimal varlink code into their tree and do not use the
external reference implementation at all.

Then also checked dependencies in Debian:

  - python3-varlink: 0 reverse depends
  - golang-github-varlink-go-dev: 0 build-depends

A search for varlink.h across all Debian sources:

  https://codesearch.debian.net/search?q=varlink.h=1

shows only a handful of potential users. Searching instead of varlink
gives way more hits, but I think the majority are unrelated, and instead
are related to Java SWIG.


The state of this upstream does not look very healthy, and from here
it does not look like adding this to Debian might be entirely wise.
For kanshi perhaps upstream should be looking into using something
else, maybe Cap'n Proto ?

Thanks,
Guillem

Bug#1059982: dpkg: move start-stop-daemon to /usr for DEP17

[Guillem Jover]

Hi!

On Thu, 2024-01-04 at 12:05:00 +0100, Helmut Grohne wrote:
> Package: dpkg
> Version: 1.22.2
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2

> please move /sbin/start-stop-daemon to /usr for the /usr-move aka DEP17.
> It's the last file in dpkg that needs moving and since it is essential,
> it's a prerequisite for doing the bootstrap work. Thanks in advance.

Thanks for the patch! As mentioned on IRC at the time, I'll be going
with an alternative solution, which I think I'll be uploading to
experimental alongside another potentially disruptive refactoring change
during the weekend.

Thanks,
Guillem

Bug#1060420: less: Fix build failure on GNU/Hurd

[Guillem Jover]

Source: less
Source-Version: 590-2
Severity: important
Tags: patch
Forwarded: https://github.com/gwsw/less/pull/469
X-Debbugs-Cc: debian-h...@lists.debian.org

Hi!

This package has been failing to build for a while on GNU/Hurd, due to
the assumption that PATH_MAX is defined on all systems, which is not
the case on GNU/Hurd as it tries to impose no arbitrary limits
gratuitously.

I've prepared a patch fixing this and submitted that upstream, and
adapted that for the current version in Debian, which I'm attaching.

Thanks,
Guillem
From d29a630e1a112613e20bff4917fee879951a6112 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 11 Jan 2024 02:18:07 +0100
Subject: [PATCH] Do not assume PATH_MAX is defined
Origin: vendor
Forwarded: https://github.com/gwsw/less/pull/469

On systems such as GNU/Hurd, PATH_MAX is not defined, because the system
intends to impose no arbitrary limits. In other systems though it might
be defined but to a very large value.

We can use realpath() with its POSIX.1-2008 semantics, where passing a
NULL argument will make it allocate the destination buffer, but not all
systems support these semantics yet.

For now, instead of complicating the code to cope with realpath()
limitations on some systems, we simply handle the case where PATH_MAX
is not defined, where realpath() should always support these semantics.
---
 filename.c |   15 +++
 1 file changed, 15 insertions(+)

--- a/filename.c
+++ b/filename.c
@@ -800,10 +800,25 @@ lrealpath(path)
 	char *path;
 {
 #if HAVE_REALPATH
+	/*
+	 * Not all systems support the POSIX.1-2008 realpath() behavior of
+	 * allocating when passing a NULL argument. And PATH_MAX is not
+	 * required to be defined, or might contain an exceedinly big value.
+	 * We assume that if it is not defined (such as on GNU/Hurd), then
+	 * realpath() accepts NULL.
+	 */
+#ifndef PATH_MAX
+		char *rpath;
+
+		rpath = realpath(path, NULL);
+		if (rpath != NULL)
+			return rpath;
+#else
 	char rpath[PATH_MAX];
 	if (realpath(path, rpath) != NULL)
 		return (save(rpath));
 #endif
+#endif
 	return (save(path));
 }
 

Bug#1060272: libsysfs2: ""trying to overwrite shared changelog.Debian.gz', which is different"

[Guillem Jover]

Hi!

On Mon, 2024-01-08 at 15:45:41 +0100, Sven-Haegar Koch wrote:
> Package: libsysfs2
> Version: 2.1.1-5+b1
> Severity: normal

> Trying to upgrade libsysfs2 from 2.1.1-5 to 2.1.1-5+b1 seems to have
> problems with Multi-Arch installs:
> 
> Preparing to unpack .../117-libsysfs2_2.1.1-5+b1_amd64.deb ...
> De-configuring libsysfs2:i386 (2.1.1-5), to allow configuration of 
> libsysfs2:amd64 (2.1.1-5+b1) ...
> Unpacking libsysfs2:amd64 (2.1.1-5+b1) over (2.1.1-5) ...
> Preparing to unpack .../118-libsysfs2_2.1.1-5+b1_i386.deb ...
> Unpacking libsysfs2:i386 (2.1.1-5+b1) over (2.1.1-5) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-9SDLmy/118-libsysfs2_2.1.1-5+b1_i386.deb (--unpack):
>  trying to overwrite shared '/usr/share/doc/libsysfs2/changelog.Debian.gz', 
> which is different from other instances of package libsysfs2:i386
> Preparing to unpack .../119-sysfsutils_2.1.1-5+b1_amd64.deb ...
> Unpacking sysfsutils (2.1.1-5+b1) over (2.1.1-5) ...
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-9SDLmy/118-libsysfs2_2.1.1-5+b1_i386.deb
> 
> Perhaps the binary only rebuild needs to be replaced with a new source
> upload only updating changelog.

This would be due to #1059395. I'll probably try to upload a new
sysfsutils revision as a temporary workaround for that.

Thanks,
Guillem

Bug#1060156: acl: move files to /usr for DEP17

[Guillem Jover]

Hi!

On Sun, 2024-01-07 at 13:33:04 +, ca...@allfreemail.net wrote:
> I'm wondering why you decided to keep the acl.postinst and
> acl.postrm files, their contents appear to be of no use on
> a usrmerged system (to the best of my knowledge). Is that
> intentional? Trixie only supports usrmerged layouts.

Yes, it was intentional, for the benefit of any downstream that does
not use aliased directories.

I'll remove them in the future, once I've gone over any other package
that hardcodes absolute pathnames to these programs, and get them to
be switched to use relative ones instead via PATH which is the better
and more portable and future-proof solution to this. When I last
checked there were only a handful of them, AFAIR.

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Package: release.debian.org
Severity: wishlist

Hi!

I've had for a while a new hook for dupload that adds a transitions
check for Debian hosts, for sourceful uploads targeting unstable (to
avoid disrupting buildd or porter uploads, or uninteresting suites).
I've just finished polishing it, and the main lingering question I've
had all along has been whether you think this would actually be useful
and/or desired at all, see below.

The hook is currently using
https://release.debian.org/transitions/export/packages.yaml, and
prompting in case that source package is part of any ongoing
transition. I wondered also whether checking
https://ftp-master.debian.org/transitions.yaml would be useful,
but I'm not sure whether that is or has ever been used?

You can see the commit at
.

For a package currently under transitions such as dart, the hook
output and interaction could be right now:

,---
Source dart is part of ongoing transitions:
  auto-tinyxml2 boost1.83
Continue anyway? (yes/NO)
Ok, aborting upload.
`---

So I guess my questions would be whether you think this is helpful or
useful at all? If so, whether the criteria is adequate or it needs to
be changed? Whether this should be a prompt, or maybe only an info or
warning? And any other comment or suggestion you might have!

Thanks,
Guillem

Bug#1059919: DEP17: move ifupdown files to /usr

[Guillem Jover]

Hi!

On Wed, 2024-01-03 at 16:56:36 +0100, Helmut Grohne wrote:
> Source: ifupdown
> Version: 0.8.41
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2

> ifupdown still is part of the debootstrap package set. I know you want
> to change this, but since it still is, it should be converted for the
> /usr-move (DEP17) sooner rather than later. I'm attaching a patch and
> note that it wasn't entirely trivial. I expect that dumat will not moan
> about it in any way, but giving it some project exposure in experimental
> for volunteers to test might not be the worst of ideas. As with similar
> patches, this should not be uploaded to bookworm-backports, so you may
> want to use dh_movetousr instead.

The provided patch seems to be missing canonicalization for the lib/
scripts from `inet6.defn` which will break downstreams of this project
that are not aliasing directories, and in Debian would fail to be located
if a user reading the code passed them to «dpkg -S» for example.

I had a patch locally (yet untested, but I'm happy to do that) to make
the program accesses relative, which should increase portability and
make these more independent of the system filesystem layout. For the
programs and lib/ scripts owned by this project though this seems
unnecessary as the destination is controlled by the build system
machinery, so those could perhaps be replaced at build/install time to
make them coherent, but that seemed like more work. :) But I'm happy to
switch to that approach if you'd prefer. Alternatively they could simply
be hardcoded to the new locations.

The original patch in this bug report could then perhaps be adapted on
top of the one I'm attaching here (or a variation of it). Otherwise I
can provide parts of it independently on top of the original patch, as
a MR or similar.

Thanks,
Guillem
From 6044af67053f8aa9ebf4e8aa3d6b9ce1c640212e Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Dec 2023 02:51:43 +0100
Subject: [PATCH] Use relative names when executing programs

This switches program invocations to use relative names, so that we are
then not concerned about the filesystem layout of the system we are
installing into.

While for programs we ship and install we will know the end destination
and could simply replace that at build or install time, that seemed more
effort than simply making all usage relative.
---
 Makefile| 8 +---
 debian/ifupdown-hotplug | 2 +-
 examples/network-interfaces | 5 +++--
 examples/pcmcia-compat.sh   | 4 +++-
 execute.c   | 2 +-
 inet6.defn  | 6 +++---
 6 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index 0ce2fa3..85c887e 100644
--- a/Makefile
+++ b/Makefile
@@ -3,9 +3,11 @@ CFLAGS ?= -Wall -W -Wno-unused-parameter -g -O2
 ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 
 BASEDIR ?= $(DESTDIR)
+PKGLIBDIR ?= /lib/ifupdown
 
 CFLAGS += -std=c99 -D_DEFAULT_SOURCE
 CFLAGS += -D'IFUPDOWN_VERSION="$(VERSION)"'
+CFLAGS += -D'PKGLIBDIR="$(PKGLIBDIR)"'
 
 DEFNFILES := inet.defn ipx.defn inet6.defn can.defn
 
@@ -26,9 +28,9 @@ install :
 	install -m 0755 ifup   ${BASEDIR}/sbin
 	ln -s /sbin/ifup ${BASEDIR}/sbin/ifdown
 	ln -s /sbin/ifup ${BASEDIR}/sbin/ifquery
-	install -D -m 0755 settle-dad.sh $(BASEDIR)/lib/ifupdown/settle-dad.sh
-	install -D -m 0755 wait-for-ll6.sh $(BASEDIR)/lib/ifupdown/wait-for-ll6.sh
-	install -D -m 0755 wait-online.sh $(BASEDIR)/lib/ifupdown/wait-online.sh
+	install -D -m 0755 settle-dad.sh $(BASEDIR)$(PKGLIBDIR)/settle-dad.sh
+	install -D -m 0755 wait-for-ll6.sh $(BASEDIR)$(PKGLIBDIR)/wait-for-ll6.sh
+	install -D -m 0755 wait-online.sh $(BASEDIR)$(PKGLIBDIR)/wait-online.sh
 
 clean :
 	rm -f *.o $(patsubst %.defn,%.c,$(DEFNFILES)) *~
diff --git a/debian/ifupdown-hotplug b/debian/ifupdown-hotplug
index 6e5f6c5..f53b87b 100755
--- a/debian/ifupdown-hotplug
+++ b/debian/ifupdown-hotplug
@@ -1,6 +1,6 @@
 #!/bin/sh -e
 #
-# run /sbin/{ifup,ifdown} with the --allow=hotplug option.
+# run {ifup,ifdown} with the --allow=hotplug option.
 #
 
 PATH='/sbin:/bin:/usr/sbin:/usr/bin'
diff --git a/examples/network-interfaces b/examples/network-interfaces
index d8bba2b..3dd1d7e 100644
--- a/examples/network-interfaces
+++ b/examples/network-interfaces
@@ -119,14 +119,15 @@
 # Note, this won't work unless you specifically change the file
 # /etc/pcmcia/network to look more like:
 #
+# PATH="$PATH:/sbin:/usr/sbin"
 # if [ -r ./shared ] ; then . ./shared ; else . /etc/pcmcia/shared ; fi
 # get_info $DEVICE
 # case "$ACTION" in
 # 'start')
-# /sbin/ifup $DEVICE
+# ifup $DEVICE
 # ;;
 # 'stop')
-# /sbin/ifdown $DEVICE
+# ifdown $DEVICE
 # ;;
 # esac
 # exit 0
diff --git a/examples/pcmcia-compat.sh b/examples/pcmcia-compat.sh
index 4b31fdb..a45a236 100644
--- a/examp

Bug#1060022: acl FTBFS with newer hardening flags

[Guillem Jover]

Hi!

On Thu, 2024-01-04 at 14:04:50 -0800, Steve Langasek wrote:
> Package: acl
> Version: 2.3.1-4
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu noble ubuntu-patch

> This traces back to a use of a 0-length array in a struct as a flexible
> variable-length array, which confuses the compiler's + glibc's string
> hardening and results in a false-positive detection of a buffer overflow.
> 
> While this false-positive could be avoided by downgrading from
> _FORTIFY_SOURCE=3 back to _FORTIFY_SOURCE=2, that would also weaken our
> ability to detect actual bugs, so instead I've prepared the attached patch
> to make the flexible array implementation compatible with the gcc hardening
> implementation, as described at
> .

Thanks for the analysis and patch, I can confirm the issue and the
fix. I've queued this for my next upload to unstable, which I'll be
doing after a quick one into experimental.

Regards,
Guillem

Bug#1060156: acl: move files to /usr for DEP17

[Guillem Jover]

Hi!

On Sat, 2024-01-06 at 15:04:47 +, ca...@allfreemail.net wrote:
> Source: acl
> Followup-For: Bug #1060156
> 
> better patch attached

Ah, thanks for the patch. I had already prepared a patch for this the
other day, but forgot to push to git, as I was meaning to upload right
away, but ended getting pulled in by something else.

(I'm going to be using instead
https://git.hadrons.org/cgit/debian/pkgs/acl.git/log/?h=pu/canonical-paths)

Thanks,
Guillem

Bug#1060111: libmd0:i386: Fail to upgrade with an overwrite error

[Guillem Jover]

Control: reassign -1 debhelper
Control: forcemerge 1059395 -1

Hi!

On Sat, 2024-01-06 at 01:25:34 +0100, Christian Marillat wrote:
> Package: libmd0
> Version: 1.1.0-1
> Severity: normal

> Strange error. 'sudo apt-get -f install' is unable to solve this issue.
> 
> ,
> | Preparing to unpack .../libmd0_1.1.0-1+b2_i386.deb ...
> | Unpacking libmd0:i386 (1.1.0-1+b2) over (1.1.0-1) ...
> | dpkg: error processing archive 
> /var/cache/apt/archives/libmd0_1.1.0-1+b2_i386.deb (--unpack):
> |  trying to overwrite shared '/usr/share/doc/libmd0/changelog.Debian.gz', 
> which is different from other instances of package libmd0:i386
> | Errors were encountered while processing:
> |  /var/cache/apt/archives/libmd0_1.1.0-1+b2_i386.deb
> `
> 
> ,
> | $ dpkg -l|grep libmd0 
> | iU  libmd0:amd64 1.1.0-1+b2 amd64 message digest functions from BSD systems 
> - shared library
> | ii  libmd0:i386 1.1.0-1 i386 message digest functions from BSD systems - 
> shared library
> `

I've uploaded a new libmd package to resync the versions across arches
as a workaround, but this is a bug in debhelper. Reassigned and merged.

Thanks,
Guillem

Bug#1059837: opencolorio： Please help fix circle dependence in Loongarch between openimageio and opencolorio

[Guillem Jover]

Hi!

On Fri, 2024-01-05 at 11:37:30 +0800, xiao sheng wen wrote:
> 在 2024/1/5 11:09, Guillem Jover 写道:
> > > So, my question is:
> > > 
> > > Can dpkg-checkbuilddeps  read
> > > 
> > > ||BuildProfileSpec "Registered profile names"pkg.$sourcepackage.$anything 
> > > in debian/control |Build-Depends section?|
> > > 
> > > Perhaps, it's a bug of dpkg-checkbuilddeps.
> > It can obviously parse the build profile, otherwise it would not have
> > succeeded when you passed the build profile to it. So, I don't understand
> > why this was cloned against dpkg-dev. So I'm closing this now.

> If build profile already exist in env variable like DEB_BUILD_PROFILES,
> 
> dpkg-checkbuilddeps can parse the build profile succeeded, that is right.
> 
> But if there is nobuild profile env variable exist before, can
> dpkg-checkbuilddeps  parse the debian/control Build-Depends section to
> getDEB_BUILD_PROFILES env variable? At present, Is dpkg-checkbuilddeps
> parse pkg.$sourcepackage.$anything in debian/control ?

I think there's some confusion on how build profiles work, I'd
recommend rereading the wiki pages, if there's something not clear
I guess the debian-cross list could clarify further. In any case
here follows a simplified view of how this works.

We mark dependencies (bust mostly build-dependencies) with specific
build-profiles. These dependencies will be in effect if the restriction
formula evaluates to true, which depends on whether specific build
profiles are active, and how the formula looks like. By default there
are no active build profile.

There's no such thing as a literal «pkg.$sourcepackage.$anything» being
parsed, the dpkg code simply parses the dependencies and the formulas,
matches the build profiles found in the formulas against active
profiles, that are specified via the environment or options such as -P,
and evaluates those formulas based on that.

> If dpkg-checkbuilddeps parse it, dpkg-checkbuilddeps  will pass, then the
> buildd will begin build these packages.

dpkg-checkbuilddeps always parses the formulas, they just evaluate
differently depending on whether the profiles are active or not. Which
means, if you want to make the specific profiles active you need to
tell the buildd to build that specific package like so, or build it
locally (just to bootstrap it), upload then retrigger a rebuild to
get a clean build.

Regards,
Guillem

Bug#1059837: opencolorio： Please help fix circle dependence in Loongarch between openimageio and opencolorio

[Guillem Jover]

Hi!

On Fri, 2024-01-05 at 09:27:29 +0800, xiao sheng wen wrote:
>     IMHO, it's not a bug of opencolorio, even is not a bug of Loongarch.

Well, the circular dependency is problematic for bootstrapping,
ideally opencolorio and openimageio would not depend on each other,
but that can be handled by the build profiles already present, which
is something the porters need to do. This is not something for the
maintainers to do.

> In opencolorio debian/control, |Build-Depends|[1] already used:
> 
> |libopenimageio-dev (>= 2.3.9.0) ,|
> 
> 
> | is a |BuildProfileSpec "Registered profile 
> names"pkg.$sourcepackage.$anything[2]
> 
> After I installed other |Build-Depends packages of |opencolorio, then run:
> 
> dpkg-checkbuilddeps
> dpkg-checkbuilddeps: error: Unmet build dependencies: libopenimageio-dev (>=
> 2.3.9.0)
> 
> But after I export DEB_BUILD_PROFILES, dpkg-checkbuilddeps run success:
> 
> export
> DEB_BUILD_PROFILES="pkg.opencolorio.noopenimageio";dpkg-checkbuilddeps
> atzlinux@nlx:~/opencolorio$ echo $?
> 0
> 
> So, my question is:
> 
> Can dpkg-checkbuilddeps  read
> 
> ||BuildProfileSpec "Registered profile names"pkg.$sourcepackage.$anything in 
> debian/control |Build-Depends section?|
> 
> Perhaps, it's a bug of dpkg-checkbuilddeps.

It can obviously parse the build profile, otherwise it would not have
succeeded when you passed the build profile to it. So, I don't understand
why this was cloned against dpkg-dev. So I'm closing this now.

The report against opencolorio should be closed too IMO, and the
loong64 porters need to deal with the circular dependency as any other
bootstrapping scenario.

Regards,
Guillem

Bug#1059986: dpkg: Please add hurd-arm64 case

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Thu, 2024-01-04 at 12:35:58 +0100, Samuel Thibault wrote:
> Package: dpkg
> Version: 1.22.2
> Severity: normal
> User: debian-h...@lists.debian.org
> Usertags: hurd

> aarch64-gnu support is coming too :)

Yes, I noticed! :)

> Could you add a hurd-amd64 case in dpkg?

I've added hurd-arm64 support into the following branch:

https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/arch-hurd-arm64

but even though I've seen already some toolchain patches flying by,
AFAIUI there's still no GNU Mach support, so I think I'd prefer to
wait until that materializes, as per the FAQ entry on new ports. I
don't think this would block anything right now anyway, no?

BTW, I've assumed that port would also enable PIE by default in the
toolchain, if not, let me know and I can fix that up in the branch.

Thanks,
Guillem

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Guillem Jover]

Hi!

On Fri, 2023-12-15 at 16:40:09 +, Sean Whitton wrote:
> On Fri 01 Dec 2023 at 02:11pm +01, Helmut Grohne wrote:
> > §7.4 currently starts with:
> >
> > When one binary package declares a conflict with another using a
> > Conflicts field, dpkg will refuse to allow them to be unpacked on
> > the system at the same time.
> >
> > I believe this is technically wrong. There are situations where dpkg
> > will allow such unpacks to temporarily co-exist. §6.6 goes into further
> > detail and is accurate.
> 
> Thank you for the detailed report.
> 
> Do the dpkg and apt people think that the bug here is just in Policy, or
> are there any code changes under consideration in response to this work?

I think it is just a documentation issue in the Debian Policy, yes. At
least the dpkg behavior seems entirely correct to me and required for safe
upgrades (and definitely not something like an accidental regression as it
has behaved that way since pretty much the beginning of its git history).

In addition I think the paragraph in §7.4 that states:

,---
A package will not cause a conflict merely because its configuration
files are still installed; it must be at least “Half-Installed”.
`---

could also be clarified that what is stated here does not apply either
to conflicting packages that are being removed, as those will be in
half-installed state. Perhaps as part of this, also make this state
change explicit in §6.6.2.3.

Thanks,
Guillem

Bug#1059644: inetutils: provide rsh-client & rsh-server?

[Guillem Jover]

Hi!

On Sat, 2023-12-30 at 02:33:22 +0100, Simon Josefsson wrote:
> Ah, I had forgotten about this (if I ever knew about it).  But looking
> at src/rsh*.c in inetutils there is plenty of Kerberos stuff in it. 
> Doesn't it work?  We build inetutils against MIT Kerberos V5 in GitLab
> CI/CD: https://gitlab.com/jas/inetutils/-/jobs/5836939514

AFAIR the Kerberos V5 support is not complete for those commands, at
least according to the configure.ac file:

,---
krb5)
[…]
  # We have limited support for krcmd() with Kerberos5.
  # Encryption must be sorted out as a first step.
  IU_DISABLE_TARGET(rcp)
  IU_DISABLE_TARGET(rlogin)
  IU_DISABLE_TARGET(rsh)
  # Likewise, we need to migrate away from KRB4 and des_*()
  IU_DISABLE_TARGET(rlogind)
  IU_DISABLE_TARGET(rshd)
`---

And forcibly commenting those out, resulted in compilation failures
(and just checked now to confirm this).

> I think there is value in having a plaintext-able rsh and rshd
> available for interacting with ancient systems.
> 
> The current netkit-rsh package does not support Kerberos.  I feel it
> may be more appropriate to replace netkit-rsh with a inetutils-rsh of
> the same feature-set rather than with a Kerberos-enabled variant. 

There's also the src:rsh-redone packages, but that also seems
orphaned. In any case I understand how rsh/rexec/rlogin might be
useful for compatibility, but as I've said I'd feel rather
uncomfortable adding this anew (even if to replace the equivalent
netkit or rsh-redone ones), with no encryption available whatsover
on this day and age. In general I think using ssh should always be the
better option in any case.

> Offering both would be even better.  But simply enabling Kerberos V5
> for rsh/rsh in inetutils and ship that is probably sufficient and
> resolves all concerns.

If we can get the Kerberos V5 support then that would indeed
ameliorate my concerns, even though the program will still be usable
in their default insecure modes. :)

Thanks,
Guillem

Bug#1059644: inetutils: provide rsh-client & rsh-server?

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Fri, 2023-12-29 at 20:03:33 +0100, Simon Josefsson wrote:
> Package: inetutils
> Severity: wishlist

> I noticed that netkit-rsh is orphaned and there are even requests to
> remove it:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041864
> 
> That is stalled because there are two reverse dependencies that
> allegedly uses: pdsh and pvm.
> 
> I was thinking that the inetutils package could provide the rsh-client
> and rsh-server packages, allowing netkit-rsh to be removed from Debian.
> Currently the Debian packaging of inetutils doesn't build rsh/rshd
> though.
> 
> What do you think?

This crosses my mind some time ago, and started preparing the changes,
but then stopped when I realized these clients and daemons would end
up with no Kerberos 5 support (they seem to have Shishi support but the
packaging was switched away from that, and rexec* has no Kerberos support
whatsoever), which made me rather uncomfortable. See the following
old branches which I've just rebased and pushed:

  https://git.hadrons.org/cgit/debian/pkgs/inetutils.git/commit/?h=pu/rsh
  https://git.hadrons.org/cgit/debian/pkgs/inetutils.git/log/?h=pu/rexec

I realize that would be no worse than the current netkit implementations
(AFAICT), but I'd rather not maintain these clients/servers if they do
not even have an option for secure connections.

> Some experiment would be needed to make sure pdsh/pvm (and their reverse
> dependencies) still build and work.
> 
> It would help to analyze any differences between netkit and inetutils
> rsh and rshd too.

Once the above is covered, then this would need to be done too, yes. :)

Thanks,
Guillem

Bug#1059395: libacl1, debhelper: changelog handling with --no-trim seems to be not binNMU-safe

[Guillem Jover]

Control: reassign -1 debhelper
Control: found -1 debhelper/13.11.4

On Sun, 2023-12-24 at 14:27:22 +, Simon McVittie wrote:
> Package: libacl1,debhelper
> Control: found -1 libacl1/2.3.1-3
> Control: found -1 debhelper/13.11.9
> Severity: important
> X-Debbugs-Cc: debian-rele...@lists.debian.org

> I notice that libacl1 uses dh_installchangelogs --no-trim in its
> debian/rules to suppress the default exclusion of older changelog
> entries. It appears that using that option also suppresses the separation
> of binNMU changelog entries into a separate file? I think it probably
> should not, because the trimming of old changelog entries is merely
> a nice-to-have to save some disk space, but the separation of binNMU
> changelog entries is functionally necessary if we want packages to remain
> multiarch co-installable across binNMUs.

Yes, I don't see why the old behavior, when requested explicitly,
would no longer behave as previously. This would seem like a regression
in debhelper due to the trimming handling.

> A sourceful upload of libacl1 would temporarily address this (until the
> next binNMU) by not being a binNMU, but would not be a long-term solution,
> unless we stop using binNMUs entirely and replace them with "no-changes"
> machine-assisted sourceful uploads like Ubuntu has done.

I've uploaded acl now with some minor pending changes I had queued as
a temporary workaround. But the obvious and correct way forward to me
is to fix debhelper (instead of having to change all affected packages,
or having to stop using binNMUs due to this…).

And I've just tested this and it also affects the current debhelper
version in Debian (stable) bookworm. :/

Thanks,
Guillem

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