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

[Guillem Jover]

Hi!

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

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

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

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

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

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

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

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

Thanks,
Guillem

Bug#1065371: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1065371 pending

Hi!

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

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

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

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

Closes: #1065371

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

[Guillem Jover]

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

Hi!

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

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

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

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

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

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

Bug#1062218: in package libaio marked as pending

[Guillem Jover]

Control: tag 1062218 pending

Hi!

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

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

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

Add time64 support

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

Closes: #1062218

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

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

[Guillem Jover]

Hi!

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

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

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

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

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

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

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

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

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

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

[Guillem Jover]

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

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

This is a bug, which I should fix.

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

I'd be fine with that.

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

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


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

Thanks,
Guillem

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

[Guillem Jover]

Control: tags -1 - pending

Hi!

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

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

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

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

Thanks,
Guillem

Bug#1064909: in package libbsd marked as pending

[Guillem Jover]

Control: tag 1064909 pending

Hi!

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

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

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

New libbsd upstream release 0.12.1

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

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

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

[Guillem Jover]

Hi!

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

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

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

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

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

Thanks for handling the upstream interaction in NetBSD!

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

Regards,
Guillem

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

[Guillem Jover]

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

Dear maintainer,

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Dear maintainer,

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Dear maintainer,

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Dear maintainer,

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

> > I checked on codesearch.d.n and there are very few users on this API;
> > actually, none I think. Per
> > https://codesearch.debian.net/search?q=matchpathcon_filespec_add=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#1059266: in package dupload marked as pending

[Guillem Jover]

Control: tag 1059266 pending

Hi!

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

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

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

This reverts commit 2f2e0e528d4435fd529971250786b08475a105c0.

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

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

Closes: #1059266

Bug#1059266: error: cannot verify inline signature

[Guillem Jover]

Hi!

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

Ouch, ok.

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

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

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

Thanks,
Guillem

Bug#1059266: error: cannot verify inline signature

[Guillem Jover]

Hi!

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

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

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

But gpg has it in its certificate store?

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

Thanks,
Guillem

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

[Guillem Jover]

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

Hi!

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

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Control: tag -1 patch

Hi!

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

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

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

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

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

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

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

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

[Guillem Jover]

Hi!

[ CCed Russ for the pod2man side of this. ]

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Hi!

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

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

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

Thanks,
Guillem

Bug#1043118: victoriametrics: FTBFS: test failure

[Guillem Jover]

Hi!

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

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

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Hi

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Package: sensible-utils
Version: 0.0.18
Severity: serious

Hi!

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

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

Regards,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

Where this is covered explicitly:

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

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Guillem Jover]

Package: aide
Version: 0.18-2
Severity: serious

Hi!

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

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Hi!

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

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

Thanks,
Guillem

Bug#1028961: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1028961 pending

Hi!

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

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

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

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

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

Fixes: commit b83114daa69c50d368199d00fbb67e190068b273
Closes: #1028961

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

[Guillem Jover]

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

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

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

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

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

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

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

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

Guillem

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

[Guillem Jover]

Control: reopen -1

Hi!

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

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

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

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

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

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

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

Adding a dependency on dpkg cannot have solved anything here.

Thanks,
Guillem

Bug#1027966: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1027966 pending

Hi!

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

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

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

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

Closes: #1027966

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

[Guillem Jover]

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

Hi!

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Control: found -1 1.21.10

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Package: pylint
Version: 2.15.9-1
Severity: serious

Hi!

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Hi!

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

Thanks,
Guillem

Bug#1025261: vagrant: Broken with ruby3.1

[Guillem Jover]

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

Hi!

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

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

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

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

Thanks,
Guillem

Bug#1023654: in package liburing marked as pending

[Guillem Jover]

Control: tag 1023654 pending

Hi!

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

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

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

Artificially bump some symbol versions to 2.3

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

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

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

Bug#1023654: liburing 2.3 breaks binary compatibility

[Guillem Jover]

Hi!

I've forwarded this upstream now.

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

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

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

Thanks,
Guillem

Bug#1023654: liburing 2.3 breaks binary compatibility

[Guillem Jover]

Hi!

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

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

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

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

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

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

Thanks,
Guillem

Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6

[Guillem Jover]

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

Hi!

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

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

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

which cause the installation to fail:

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

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

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

Thanks,
Guillem

Bug#995387: in package dpkg marked as pending

[Guillem Jover]

Control: tag 995387 pending

Hi!

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

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

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

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

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

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

Bug#1008478: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008478 pending

Hi!

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

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

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

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

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

Bug#1008316: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008316 pending

Hi!

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

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

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

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

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

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

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

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

Bug#1000421: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1000421 pending

Hi!

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

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

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

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

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

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

Closes: #1000421
(cherry picked from commit ecbd9f1b1f248fb5be182b3a78bc613591dba865)

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Control: reassign -1 arcanist

Hi!

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

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

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

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

See Adrian's reply.

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

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

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

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

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

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

Thanks,
Guillem

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Hi!

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

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

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

Thanks,
Guillem

Bug#1017440: pahole: Several tools just segfault

[Guillem Jover]

Package: pahole
Version: 1.23-2
Severity: serious

Hi!

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

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

On a stripped library:

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

Some even with no arguments:

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

Thanks,
Guillem

Bug#919697: arcanist: file conflict with arc

[Guillem Jover]

Hi!

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

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

Hi!

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

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

Thanks,
Guillem

Bug#1012544: libworkflow1: Broken shared library packaging

[Guillem Jover]

Package: libworkflow1
Version: 0.9.10-1
Severity: serious

Hi!

This package has several problems:

 - It contains a shared library without a SOVERSION

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

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

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

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

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

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

Thanks,
Guillem

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

[Guillem Jover]

Hi!

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

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

  

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

Thanks,
Guillem

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

[Guillem Jover]

Control: severity -1 normal

Hi!

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

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

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

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

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

Thanks,
Guillem

Bug#1008316: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008316 pending

Hi!

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

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

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

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

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

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

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

Closes: #1008316

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

[Guillem Jover]

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

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

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

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

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

Then I suppose it exited normally with something like:

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

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

?

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

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

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

I guess that would be another option yes, thanks.

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

Sure.

I'll try to prepare something later today.

Thanks,
Guillem

Bug#1008478: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1008478 pending

Hi!

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

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

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

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

Closes: #1008478

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

[Guillem Jover]

Control: retitle -1 dpkg-fsys-usrunmess: Does not deal with untracked kernel 
modules

Hi!

On Sat, 2022-03-26 at 19:21:44 +0100, Eric Valette wrote:
> Package: dpkg
> Version: 1.21.4
> Severity: critical
> Justification: breaks the whole system

> Gobally the scripts does a very good job but it missed to copy 
> /usr/lib/modules to
> /lib/modules on a self generated kernel that has modules build via dkms and a
> few native kernel modules.

I assume the custom built kernel was installed w/o a .deb package?

> Invoquing the dkms postinstall script fails because it does not find 
> /lib/modules/x.y.z
> directories and rebooting without graphic drivers and other stff does not 
> work.

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

If so, I guess the error message should be more clear that the system
has many chances of not being in a bootable state. And perhaps add
some instructions on how to proceed or similar. And it should ideally
be restartable (as already requested in another report), which I guess
I'll be working on next.

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

Hmm, right, because these were not tracked, they got missed in the
migration. I've checked the Debian archive and at least there, it does
not look like anything else besides kernel modules are being current
shipped in those directories (via apt-file), but the problem is that
I've seen references in source code (via codesearch.d.o) to
/usr/lib/modules, for at least apache and python modules, so I don't
think an unconditional move for untracked files would be safe there.
I'm thinking the following special-case options (in order of decreasing
preference):

  * move only untracked «/usr/lib/modules/[0-9]*» expecting/assuming
those to be kernel modules,
  * copy (not move) all untracked files from «/usr/lib/modules/*» to
«/lib/modules», and print a message at the end, but that will leave
cruft behind if not cleaned up,
  * record them, and print a list at the end of the execution for the
user to deal with, but that can be rather unfriendly, and that can
include usual dkms built modules too,

> To fix i did:
>1) boot in recovery mode,
>2) copy /usr/lib/modules to /lib/modules
>3) dkms autoinstall
>4) update-grub
> 
> and it wworked.

I guess depending on whether the program failed or not that might
change what the better approach might be.

Thanks,
Guillem

Bug#1005141: linux-perf: Removes diversions on upgrade breaking it

[Guillem Jover]

Package: linux-perf
Version: 5.16.3-1~exp1
Severity: serious

Hi!

This package has code in its postrm maintscript, which unconditionally
removes the diversion, which breaks as the rename cannot be performed
due to linux-base owning the file, and dpkg-divert refusing to
overwrite it. This is the error shown:

  ,---
  # dpkg -i linux-perf_5.16.7-1_amd64.deb
  (Reading database ... 280997 files and directories currently installed.)
  Preparing to unpack linux-perf_5.16.7-1_amd64.deb ...
  Leaving 'diversion of /usr/bin/perf to /usr/bin/perf.wrapper by linux-perf'
  Leaving 'diversion of /usr/share/bash-completion/completions/perf to 
/usr/share/bash-completion/completions/perf.wrapper by linux-perf'
  Leaving 'diversion of /usr/share/man/man1/perf.1.gz to 
/usr/share/man/man1/perf.wrapper.1.gz by linux-perf'
  Unpacking linux-perf (5.16.7-1) over (5.16.7-1) ...
  Removing 'diversion of /usr/bin/perf to /usr/bin/perf.wrapper by linux-perf'
  dpkg-divert: error: rename involves overwriting '/usr/bin/perf' with
different file '/usr/bin/perf.wrapper', not allowed
  dpkg: warning: old linux-perf package post-removal script subprocess returned 
error exit status 2
  dpkg: trying script from the new package instead ...
  Removing 'diversion of /usr/bin/perf to /usr/bin/perf.wrapper by linux-perf'
  dpkg-divert: error: rename involves overwriting '/usr/bin/perf' with
different file '/usr/bin/perf.wrapper', not allowed
  dpkg: error processing archive linux-perf_5.16.7-1_amd64.deb (--install):
   new linux-perf package post-removal script subprocess returned error exit 
status 2
  Leaving 'diversion of /usr/bin/perf to /usr/bin/perf.wrapper by linux-perf'
  Leaving 'diversion of /usr/share/bash-completion/completions/perf to 
/usr/share/bash-completion/completions/perf.wrapper by linux-perf'
  Leaving 'diversion of /usr/share/man/man1/perf.1.gz to 
/usr/share/man/man1/perf.wrapper.1.gz by linux-perf'
  Removing 'diversion of /usr/bin/perf to /usr/bin/perf.wrapper by linux-perf'
  dpkg-divert: error: rename involves overwriting '/usr/bin/perf' with
different file '/usr/bin/perf.wrapper', not allowed
  dpkg: error while cleaning up:
   new linux-perf package post-removal script subprocess returned error exit 
status 2
  Processing triggers for man-db (2.10.0-2) ...
  [main a8458e04] Commit dpkg db updates
   1 file changed, 2 insertions(+), 1 deletion(-)
  Errors were encountered while processing:
   linux-perf_5.16.7-1_amd64.deb
  `---

The dpkg-divert calls should be protected to run only on the relevant
actions on all maintscripts.

Thanks,
Guillem

Bug#1003814: in package dpkg-repack marked as pending

[Guillem Jover]

Control: tag 1003814 pending

Hi!

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

https://git.dpkg.org/cgit/dpkg/dpkg-repack.git/diff/?id=55a6cc7

---
debian: Replace experimental usage of «/» in build profile

This was done to check whether it was currently feasible to use such
characters, even though currently not permitted by the spec, but do
fix a design flaw, given that package names can contain «.» which is
the current designated namespace separator.

It looks like some infrastructure will need to be fixed before this can
be reconsidered.

Closes: #1003814

Bug#1003664: fwupd: Too loose dependency on libfwupdN

[Guillem Jover]

Package: fwupd
Version: 1.5.7-5
Severity: serious

Hi!

This package seems to use a too loose dependency on at least
libfwupdN, but I suspect the same applies to libfwupdpluginM (or even
libfwupdN from libfwupdpluginM).

These are encoded as >=, which causes them to be upgradable on new
upstream releases, and do break partial upgrades. Right now I've got
fwupd held due to the signed version not being yet available, and
libfwupdplugin1 is not upgraded as that bumped its SONAME, but libfwupd2
did, and now the daemon is segfaulting. This is not the first time
this has happened, but I guess I forgot to file the other time, which
means this seems to be consistent behavior as with requiring exact
versions of the library:

  fwupd[108906]: 21:12:16:0092 GLib-GIO g_file_new_for_path: 
assertion 'path != NULL' failed
  fwupd[108906]: 21:12:16:0092 GLib-GIO g_file_query_file_type: 
assertion 'G_IS_FILE(file)' failed
  fwupd[108906]: 21:12:16:0092 GLib-GIO g_file_monitor_file: 
assertion 'G_IS_FILE (file)' failed
  kernel: fwupd[108906]: segfault at 8 ip 559242c78109 sp 7ffe4df24910 
error 4 in fwupd[559242c73000+26000]
  kernel: Code: ff 85 c0 0f 85 97 02 00 00 48 8b 7c 24 30 e8 5e d5 ff ff e9 67 
01 00 00 48 8b 44 24 28 48 8d 3d dc 14 02 00 41 be 01 00 00 00 <48> 8b 70 08 31 
c0 e8 4c f4 ff ff 4d 85 e4 74 08 4c 89 e7 e8 5f db

So it looks like all the intra library dependencies should be changed
to «libfwup.* (= )».

Thanks,
Guillem

Bug#1002258: marked as pending in golang-github-go-openapi-analysis

[Guillem Jover]

Control: tag -1 pending

Hello,

Bug #1002258 in golang-github-go-openapi-analysis reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-go-openapi-analysis/-/commit/a3a8f1c282ff31def08b6da0b861cedb2805665c


Disable test case requiring network access

Closes: #1002258


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1002258

Bug#995387: in package dpkg marked as pending

[Guillem Jover]

Control: tag 995387 pending

Hi!

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

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

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

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

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

Closes: #995387
Stable-Candidate: 1.20.x

Bug#1000421: Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32

[Guillem Jover]

Hi!

On Sat, 2021-12-04 at 23:09:19 +, Ian Jackson wrote:
> Joachim:
> > I'm aware of that. And "shortly" definitely means "before the
> > autoremoval" (which is currently scheduled for 2022-01-01).
> 
> The real deadline is when I ought to take action myself, as someone
> adversely affected by an RC bug.

Sorry for not having updated the report before, but I didn't see the
urgency either, and was planning on dealing with it before this had
any further effect. I'd have appreciated more a request for a status
update, instead of wielding the NMU around though…

> The timeline for fixing this is:
> 
>   NMU DELAYED-10 upload of fixed dpkg
>   wait 10 days
>   wait ?? days for dpkg to migrate, say 5 (I think there are tests)
>   NMU DELAYED-10 upload of no-change cppcheck
>   wait 10 dayhs
>   wait 10 days for cppcheck to migrate
> 
> Total waiting time here is 35 days plus time I spend doing the work.

There's another RC in dpkg, which I have a fix for, but had pending
reviewing it again and checking whether some of the cases from the
report are handled right. And then there are also autopkgtest failures
which I've also got fixed locally. My intention is to get this
uploaded this weekend.

> If I want to fix this without having to manually restart the
> autoremoval clock and/or ask for help from the release team, I should
> have NMU'd dpkg at least a week ago.

(Where either of these first options, if they would be required at all,
seem like way less effort and way less disruptive anyway…)

Regards,
Guillem

Bug#1000776: marked as pending in golang-github-go-openapi-validate

[Guillem Jover]

Control: tag -1 pending

Hello,

Bug #1000776 in golang-github-go-openapi-validate reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-go-openapi-validate/-/commit/7d0f66c3a4c8d722931cad15960b8f62b3fac9d2


Version dependency on golang-github-go-openapi-errors-dev (>= 0.19.5~)

The minimum version required is 0.19.5.

Closes: #1000775, #1000776


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1000776

Bug#1000775: marked as pending in golang-github-go-openapi-validate

[Guillem Jover]

Control: tag -1 pending

Hello,

Bug #1000775 in golang-github-go-openapi-validate reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-go-openapi-validate/-/commit/7d0f66c3a4c8d722931cad15960b8f62b3fac9d2


Version dependency on golang-github-go-openapi-errors-dev (>= 0.19.5~)

The minimum version required is 0.19.5.

Closes: #1000775, #1000776


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1000775

Bug#1000421: in package dpkg marked as pending

[Guillem Jover]

Control: tag 1000421 pending

Hi!

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

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

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

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

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

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

Closes: #1000421

Bug#1000421: dpkg-shlibdeps: Wrong minimum version requirement on libc6

[Guillem Jover]

Hi!

On Mon, 2021-11-22 at 22:49:43 +0100, Joachim Reichel wrote:
> Package: dpkg-dev
> Version: 1.20.9
> Severity: serious
> Control: affects -1 cppcheck

> dpkg-shlibdeps calculates too low minimum version requirements for cppcheck 
> on libc6 (see bug 1000146).
> 
> To reproduce, build cppcheck 2.6-1 in unstable chroot without cleaning up, 
> e.g., "dpkg-buildpackage -rfakeroot -us -uc".
> 
> $ grep Depends debian/cppcheck/DEBIAN/control
> Depends: libc6 (>= 2.29), [...]
> 
> But running the binary with libc6 2.31 fails with
> 
> cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by cppcheck)
> cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
> cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
> /lib/x86_64-linux-gnu/libpthread.so.0)
> 
> I believe that is the case because a certain symbol in the .bss section is 
> ignored (this is the only symbol with 2.32 suffix):
> 
> $ objdump -w -T ./debian/cppcheck/usr/bin/cppcheck | grep 
> __libc_single_threaded
> 004670e0 gDO .bss   0001  GLIBC_2.32  
> __libc_single_threaded
> 
> $ nm -D ./debian/cppcheck/usr/bin/cppcheck | grep __libc_single_threaded
> 004670e0 B __libc_single_threaded@@GLIBC_2.32
> 
> $ dpkg-shlibdeps ./debian/cppcheck/usr/bin/cppcheck; cat debian/substvars
> shlibs:Depends=libc6 (>= 2.29), [...]
> 
> After hacking /usr/share/perl5/Dpkg/Shlibs/Objdump.pm:462 to read
> "defined => ($sect ne '*UND*') && ($sect ne '.bss')"
> (maybe not the right solution, just for demonstration):

Thanks for the investigation! But, I'm afraid that would mean
dpkg-gensymbols missing symbols on the generated .symbols file. Also
marking all such symbols from «.bss» would start emitting tons of
warnings for non-imported symbols, more so in cppcheck case as it is
built with -rdynamic (which exports those).

After some further checking, it seems newer binutils have started
qualifying symbols in copy relocation with the version string, which
the code was not matching (but i386 was not affected f.ex. as it does
not use copy relocations for those). The attached patch seems to work
on amd64, but I'll check tomorrow whether the same applies to other
arches and if they use the same symbol format. But at least it should
improve things and not cause regressions as it will try both formats.

Thanks,
Guillem
From a9c4f1806f1927a2da42712658f4cfdd37f73e50 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 23 Nov 2021 02:26:50 +0100
Subject: [PATCH] Dpkg::Shlibs::Objdump: Fix apply_relocations to work with
 versioned symbols
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since at least binutils 2.28 copy relocations for versioned symbols have
the version appended after «@@». We were not taking this into account
which meant these did not match and did not get marked as undefined.

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

Closes: #1000421
---
 scripts/Dpkg/Shlibs/Objdump.pm | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm
index 93319d1eb..43d786edd 100644
--- a/scripts/Dpkg/Shlibs/Objdump.pm
+++ b/scripts/Dpkg/Shlibs/Objdump.pm
@@ -488,9 +488,20 @@ sub apply_relocations {
 	# We want to mark as undefined symbols those which are currently
 	# defined but that depend on a copy relocation
 	next if not $sym->{defined};
-	next if not exists $self->{dynrelocs}{$sym->{name}};
-	if ($self->{dynrelocs}{$sym->{name}} =~ /^R_.*_COPY$/) {
+
+my @relocs;
+push @relocs, $sym->{name} . '@@' . $sym->{version} if $sym->{version};
+
+# Symbols that are not versioned, or versioned but linked with old
+# binutils do not have a version appended.
+push @relocs, $sym->{name};
+
+foreach my $reloc (@relocs) {
+next if not exists $self->{dynrelocs}{$reloc};
+next if not $self->{dynrelocs}{$reloc} =~ /^R_.*_COPY$/;
+
 	$sym->{defined} = 0;
+last;
 	}
 }
 }
-- 
2.34.0

Bug#999768: lintian: false report: adopted-extended-field XS-Autobuild

[Guillem Jover]

On Tue, 2021-11-16 at 13:11:26 +0100, Andreas Beckmann wrote:
> Package: lintian
> Version: 2.112.0
> Severity: serious
> 
> Lintian now reports
> 
> I: nvidia-graphics-drivers source: adopted-extended-field XS-Autobuild (in 
> section for source) [debian/control:26]
> 
> but that field is not usable as Autobuild, dpkg/sid does not accept it:
> 
> dpkg-gencontrol: warning: unknown information field 'Autobuild' in input data 
> in general section of control info file
> dpkg-genchanges: warning: unknown information field 'Autobuild' in input data 
> in general section of control info file
> dpkg-source: warning: unknown information field 'Autobuild' in input data in 
> general section of control info file

The same with XS-Go-Import-Path, and I guess a bunch of other fields
that are unknown to dpkg-dev.

Regards,
Guillem

Bug#997566: marked as pending in golang-github-prometheus-exporter-toolkit

[Guillem Jover]

Control: tag -1 pending

Hello,

Bug #997566 in golang-github-prometheus-exporter-toolkit reported by you has 
been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-prometheus-exporter-toolkit/-/commit/72776a7afd1ff89d24010cc6759bc63b07fb


Fix test failures with new golang 1.17

Closes: #997566


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/997566

Bug#995999: marked as pending in prometheus

[Guillem Jover]

Control: tag -1 pending

Hello,

Bug #995999 in prometheus reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/prometheus/-/commit/28288181ca2b02383c51f8d8592636e8668f147a


Fix build failure in test suite with Go 1.16

Patch taken from upstream commit 8bf7bc68f1d678ea82c392f80486a62e7973720b.

Closes: #995999


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/995999

Bug#995387: dpkg: remove-on-upgrade deletes symlink targets owned by another package

[Guillem Jover]

Hi!

On Thu, 2021-09-30 at 16:21:21 +0200, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.20.6
> Severity: grave
> Justification: breaks unrelated packages by removing their conffiles
> 
> attached is a small package demonstrating the misbehavior of
> remove-on-upgrade which may delete symlink targets. It builds foo.deb
> (which has 'remove-on-upgrade /etc/old-conffile') and bar.deb (which
> has /etc/old-conffile -> /etc/new-conffile).

Thanks for the reproducer. I'm looking how to best fix this, ideally
with a minimal amount of code that might be sensible to add into a
stable release.

> The actual bug where I encountered this misbehavior is
>   #994971: OpenCL not working with latest Nvidia driver
> and it was an error of debhelper converting rm_conffile to remove-on-upgrade
> but dpkg played its part by deleting the symlink target instead of the
> symlink itself, but it should rather do nothing (or print a diagnostic) if
> the to-be-removed file is not a plain file.

Actually I think there's just a problem here with remove-on-upgrade not
taking into account ownership from other packages. But the conffile
dereferencing is an "expected" behavior (although I think is more of a
misfeature than anything else TBH, and I'm not sure it even behaves
sanely in all cases, which might require additional tests and fixes),
which does the same as with normal purging and unpacking. If there's a
symlink then what it points to will be used instead for its contents and
for removals etc.

> Simplified, the nvidia use case the following:
> 
> Long ago, /etc/conffile was a conffile
> That was later removed with rm_conffile
> and since then the different co-installable drivers ship 
> /etc/conffile-$driver_version instead
> and a slave alternative exists as /etc/conffile pointing to the corresponding 
> file of
> the activated driver variant.
> (The different drivers may require slightly different conffile content.)

So given the above, the ownership fix is needed to protect the user, but I
don't think it would have helped you anyway, as the alternative is not
owned in a way that dpkg knows. So it would consider it a local
symlink that can be overwritten. :/

I guess the remove-on-upgrade directive needs a possibly optional
version restriction like dpkg-maintscript-helper. :/

Thanks,
Guillem

Bug#995492: lintian: Broken --fails-on=none as default never got reverted

[Guillem Jover]

Package: lintian
Version: 2.77.0
Severity: serious

Sigh,

So the problematic --fail-on default change never got actually reverted
as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e
omitted the relevant part that would make it work. :(

None of the previous arguments against the default change brought up
in #962158 have stopped being relevant (also contrary to the commit
message…). Worse, this sneaked in what has shipped now in a stable
Debian release. :( So any errors found in CI systems and through other
tooling has been silently ignored since then. :/

Only noticed now due to #994414, a great excuse to now keep the broken
behavior I guess. (Where the --help output still does not match…)

Unamused,
Guillem

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

[Guillem Jover]

Control: reassign -1 glx-diversions 1.2.0

On Tue, 2021-09-14 at 11:19:43 +0200, Sébastien Villemot wrote:
> Control: reassign -1 dpkg 1.20.9

> Le dimanche 12 septembre 2021 à 15:24 +, Witold Baryluk a écrit :
> > Package: octave
> > Version: 6.2.0-1
> > Followup-For: Bug #993338
> > X-Debbugs-Cc: witold.bary...@gmail.com
> > 
> > After a lof of trial and error and minimizing my package list from ~7000
> > to just few, I got it easily reproducible using live-build. It is somehow
> > related to multiarch.
> > 
> > Here and attached below is a script that should reproduce the issue. It
> > uses /tmp-live-build as a scratch space, so be sure to clean it after.
> > (I cannot use /tmp as it often has nodev / nosuid set).
> > 
> > I am also attaching compressed output log from the script and live-build,
> > as well the apt / dpkg logs from inside the target chroot.
> 
> Thanks for sending a way of reproducing the problem.

Yeah, that was helpful, although some part of the script were inert.
I'm attaching a simplified one which still reproduces it.

> I have no idea what’s going on. But it seems clear to me that the bug
> is not in octave. I’m reassign to dpkg, for lack of a better idea, in
> the hope that its maintainer can give some guidance.

I'm not sure doing this in general scales though. In any case I took a
look, and it seems like glx-diversions is the culprit, as hinted by
the «Removing.*libGL\.so.*» lines in the logs provided by Witold.

I reproduced the problem and replaced the postinst maintscript, and
got the output in «glx-diversions.postinst.log», and after that
there's no more libGL.so*. And these only get regenerated during the
triggers processing.

Looking at the postinst, besides the symlink removal and regeneration
being bust, it also seems like the trigger logic is based on wrong
assumptions? In this specific case the packages that it tries to
trigger on their behalf, are in unpacked state so they never end up
awaiting the triggers, and their reverse dependencies can be
configured once these are configured too, with the reported error,
given that the libGL.so* symlinks have not been reinstated yet.

Thanks,
Guillem


repro-glx-diversions.sh
Description: Bourne shell script
+ TRIPLETS=/ /i386-linux-gnu/ /x86_64-linux-gnu/ /arm-linux-gnueabihf/ 
/aarch64-linux-gnu/ /powerpc64le-linux-gnu/
+ DIVERT_QUIET=--quiet
+ [ configure = configure ]
+ add_multiarch_diversion libGL.so /usr/lib /usr/lib/mesa-diverted
+ local file source_dir diversion_dir triplet
+ file=libGL.so
+ source_dir=/usr/lib
+ diversion_dir=/usr/lib/mesa-diverted
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/libGL.so /usr/lib/libGL.so
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so /usr/lib/i386-linux-gnu/libGL.so
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so 
/usr/lib/x86_64-linux-gnu/libGL.so
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so 
/usr/lib/arm-linux-gnueabihf/libGL.so
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so 
/usr/lib/aarch64-linux-gnu/libGL.so
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGL.so 
/usr/lib/powerpc64le-linux-gnu/libGL.so
+ add_multiarch_diversion libGL.so.1 /usr/lib /usr/lib/mesa-diverted
+ local file source_dir diversion_dir triplet
+ file=libGL.so.1
+ source_dir=/usr/lib
+ diversion_dir=/usr/lib/mesa-diverted
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/libGL.so.1 /usr/lib/libGL.so.1
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 
/usr/lib/i386-linux-gnu/libGL.so.1
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 
/usr/lib/x86_64-linux-gnu/libGL.so.1
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 
/usr/lib/arm-linux-gnueabihf/libGL.so.1
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1 
/usr/lib/aarch64-linux-gnu/libGL.so.1
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGL.so.1 
/usr/lib/powerpc64le-linux-gnu/libGL.so.1
+ add_multiarch_diversion libGL.so.1.0.0 /usr/lib /usr/lib/mesa-diverted
+ local file source_dir diversion_dir triplet
+ file=libGL.so.1.0.0
+ source_dir=/usr/lib
+ diversion_dir=/usr/lib/mesa-diverted
+ dpkg-divert --quiet --add --rename --package glx-diversions --divert 
/usr/lib/mesa-diverted/libGL.so.1.0.0 /usr/lib/libGL.so.1.0.0
+ dpkg-divert 

Bug#993135: in package inetutils marked as pending

[Guillem Jover]

Control: tag 993135 pending

Hi!

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

https://git.hadrons.org/cgit/debian/pkgs/inetutils.git/diff/?id=a7fcfbf

---
commit a7fcfbf633594801e2c3d1c1ac1b9e994bb8bf7b
Author: Guillem Jover 
Date:   Sat Aug 28 01:15:04 2021 +0200

Stop using obsolete autoconf macros

This will make the build stop emitting warnings that break the
autopkgtest.

Closes: #993135

diff --git a/debian/changelog b/debian/changelog
index 43eca12..9b3b3ec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 inetutils (2:2.1-1) UNRELEASED; urgency=medium
 
   * New upstream release. Closes: #993144
+  * Stop using obsolete autoconf macros, to stop emitting warnings that
+break the autopkgtest. Closes: #993135
 
  -- Guillem Jover   Sat, 28 Aug 2021 00:34:25 +0200
 

Bug#992602: libtinyxml2-9: Bogus Provides/Conflicts on libtinyxml2-8

[Guillem Jover]

Package: libtinyxml2-9
Version: 9.0.0+dfsg-2
Severity: serious

Hi!

This package contains bogus Provides/Conflicts against libtinyxml2-8
from when the package was named libtinyxml2-8a. These need to be
removed as they are leftovers, incorrect (as they might make package
depending on libtinyxml2-8 fail to run when being installed alongside
libtinyxml2-9) and make upgrades more difficult than necessary.

Thanks,
Guillem

Bug#991399: mariadb: Daemon hangs on stop with replication and parallel slaves

[Guillem Jover]

Source: mariadb-10.5
Source-Version: 1:10.5.10-2
Severity: serious
Forwarded: https://jira.mariadb.org/browse/MDEV-20821
Control: fixed -1 1:10.5.11-1~exp1

Hi!

When replication is enabled with the slave running in parallel mode,
the daemon completely hangs and will not terminate, which means daemon
shutdowns need to timeout and a SIGKILL sent to take effect, as such
daemon restarts will fail.

This is fixed in upstream 10.5.11, the relevant upstream bugs are:

  https://jira.mariadb.org/browse/MDEV-20821
  https://jira.mariadb.org/browse/MDEV-22370

I've set this as serious, as ending up with no mariadb running on a
system can be pretty fatal, and because upstream had it as "critical",
but feel free to lower if you think it would not deserve it. Given that
there appears to be a version that fixes this issue in experimental, it
seems this would not be too cumbersome, and it would be nice if that
could be targeted for bullseye.

Thanks,
Guillem

Bug#991334: monit: Race condition on reboot timestamp checks

[Guillem Jover]

Package: monit
Version: 1:5.27.2-1
Severity: serious
Forwarded: 
https://bitbucket.org/tildeslash/monit/pull-requests/110/use-an-epsilon-when-doing-the-reboot-boot

Hi!

On Linux the current method to retrieve the boot timestamp is racy,
which means that the reboot checks (the daemon start delay), and the
state machinery can be affected. The former is an annoyance as monit
will not respond to commands during the set amount of time. But the
latter means that services set to «onreboot nostart» and managed f.ex.
by a HA system will lose their state on «monit restart», which can be
rather bad.

I notice that Hurd patch modifies the Linux _getStartTime()
implementation making it need way more syscalls, which can exacerbate
this problem, and IMO should be either reverted for bullseye, or
modified so that the Hurd has its own sysdep file with that change.

I'm attaching the patch I've submitted upstream, which fixes the
problem for us.

To reproduce I added a Log_debug() entry to see the exact timestamps,
but this can be easily seen anyway by adding a start delay and
checking whether the delay gets skipped or taken into account after
each «service monit restart».

Thanks,
Guillem
From dc50d6cca9a69922f75f98fe73d95bb2f1067cfa Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 20 Jul 2021 20:40:54 +0200
Subject: [PATCH] Use an epsilon when doing the reboot boot timestamp
 comparisons

At least on Linux, the current method to retrieve the boot timestamp is
racy, as we first fetch the system uptime (seconds since the epoch),
then subtract that from the current time. But if between these two
syscalls a new or more seconds elapse, then the result can change
depending on the invocation compared to the stored state. This is
trivial to trigger at least on a VirtualBox machine.

To avoid this problem we refactor the reboot checks to use
State_reboot(), and change it to use a small epsilon value, either
positive or negative, to account for a possible mismatch in the
current timestamp or the state one.
---
 src/state.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/state.c b/src/state.c
index 05c3b64e..986202b7 100644
--- a/src/state.c
+++ b/src/state.c
@@ -243,7 +243,7 @@ static void _updateStart(Service_T S, int nstart, int ncycle) {
 
 
 static void _updateMonitor(Service_T S, Monitor_State monitor) {
-if (systeminfo.booted == booted || S->onreboot == Onreboot_Laststate) {
+if (!State_reboot() || S->onreboot == Onreboot_Laststate) {
 // Monit reload or restart within the same boot session OR persistent state => restore the monitoring state
 if (monitor == Monitor_Not)
 S->monitor = Monitor_Not;
@@ -664,6 +664,9 @@ void State_restore() {
 
 
 bool State_reboot() {
-return systeminfo.booted == booted ? false : true;
+/* We need to use a small epsilon when comparing the boot timestamps,
+ * as at least on Linux its gathering is racy and can diverge from the
+ * real boot timestamp. */
+return abs(systeminfo.booted - booted) < 2 ? false : true;
 }
 
-- 
2.32.0

Bug#947086: spamassassin doesn't start at boot under sysvinit-core after update

[Guillem Jover]

On Mon, 2021-05-17 at 10:41:28 -0700, Noah Meyerhans wrote:
> -if [ $code -eq 104 ] && \
> -! command -v systemctl > /dev/null ; then
> -# We're not using systemd and thus may have some sysvinit cleanup
> -# to do in order to comply with policy 9.3.3.1
> -
> -if [ -z "$ENABLED" -o "$ENABLED" = 0 ]; then
> -# The rc?d symlinks are inconsistent with the value set in
> -# /etc/default/spamassassin. Update the symlinks to
> -# reflect the actual state.
> -update-rc.d -f spamassassin remove
> -update-rc.d -f spamassassin defaults-disabled
> -deb-systemd-helper disable spamassassin.service
> -fi
> -elif [ $code -eq 101 ] && \
> - command -v systemctl > /dev/null && \
> - [ $ENABLED -eq 1 ]; then
> -# We're running on a systemd system, and the service is not
> -# configured to start (the default), but the admin has
> -# previously enabled it via
> -# /etc/default/spamassassin. Preserve that configuration.
> -deb-systemd-helper enable spamassassin.service
> -fi
> 
> Won't this introduce a similar bug for systemd users who have ENABLED=1
> in /etc/default/spamassassin?  The expectation is that this setting is 
> preserved by enabling the systemd service if ENABLED=1 is set.

Given that /etc/default/spamassassin does not set ENABLED anymore, by
default on systemd systems that code block would no longer run. If the
admin had not updated the conffile (due to local changes) to remove the
variable (and thus the block would still run now), the code block would
have already taken effect in the previous stable release to set the
desired outcome (and preserve the state). So it seemed safe to me to
remove both as part of the ENABLED variable deprecation process.

Thanks,
Guillem

Bug#988056: shim-signed: Fails to install due to missing update-secureboot-policy

[Guillem Jover]

Package: shim-signed
Version: 1.34+15.4-2
Severity: serious

Hi!

Just upgraded shim packages today and then shim-signed was unable to
configure:

  ,---
  Setting up shim-signed:amd64 (1.34+15.4-2) ...
  Installing for x86_64-efi platform.
  Installation finished. No error reported.
  /var/lib/dpkg/info/shim-signed:amd64.postinst: 80: update-secureboot-policy: 
not found
  dpkg: error processing package shim-signed:amd64 (--configure):
   installed shim-signed:amd64 package post-installation script subprocess 
returned error exit status 127
  Errors were encountered while processing:
   shim-signed:amd64
  `---

The dependency on shim-signed-common got dropped so the required program
stopped being available:

  ,---
  ii  shim-helpers-amd64-signed 1+15.4+2 amd64
  iF  shim-signed:amd64 1.34+15.4-2  amd64
  ic  shim-signed-common1.33+15+1533136590.3beb971-7 all
  ii  shim-unsigned 15.4-3   amd64
  `---

Installing the package again by hand, makes it able to proceed.

Thanks,
Guillem

Bug#987131: dpkg: libreoffice upgrade failure

[Guillem Jover]

Hi!

[ I'm assuming this is from Andreas Beckman? :) CCed explicitly. ]

On Wed, 2021-03-17 at 12:04:32 +0100, piupar...@zam127.zam.kfa-juelich.de wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: block 985297 with -1
> 
>   Preparing to unpack .../0-ure_1%3a7.0.4-3_amd64.deb ...
>   Unpacking ure (1:7.0.4-3) over (6.1.5-3+deb10u7) ...
>   Preparing to unpack .../1-libreoffice-style-colibre_1%3a7.0.4-3_all.deb ...
>   Unpacking libreoffice-style-colibre (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering deconfiguration of libreoffice-writer, which would be 
> broken by installation of libreoffice-core ...
>   dpkg: yes, will deconfigure libreoffice-writer (broken by libreoffice-core)
>   Preparing to unpack .../2-libreoffice-core_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-writer (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering removing libreoffice-writer in favour of 
> libreoffice-common ...
> * dpkg: libreoffice-writer is not properly installed; ignoring any 
> dependencies on it ***
> * dpkg: yes, will remove libreoffice-writer in favour of libreoffice-common   
> ***
>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> libreoffice-common:all, cannot switch to symlink
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
> (--unpack):
>new libreoffice-common package pre-installation script subprocess returned 
> error exit status 1
>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
> directory
>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
>   Selecting previously unselected package libreoffice-writer.
>   dpkg: considering deconfiguration of libreoffice-common, which would be 
> broken by installation of libreoffice-writer ...
>   dpkg: yes, will deconfigure libreoffice-common (broken by 
> libreoffice-writer)
>   Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ...
>   Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ...
>   Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ...
>   Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb
> 
> So is dpkg going to remove libreoffice-writer or not? It says both and does
> not remove it, causing dpkg-maintscript-helper to fail since
> /usr/lib/libreoffice/share/registry is not empty before dir_to_symlink
> is run. There should be enough Conflicts to ensure all packages previously
> shipping files there are removed or upgraded.
> 
> Andreas
> 
> (full log in #985297)
> 
> PS: could we please have a dpkg with fixed dpkg-realpath uploaded soon?
> Before people trying to fix the "missing symlink_to_dir" bugs I filed
> recently start to run into that issue?

From the Received headers, can I assume this was a mail that got stuck
in some mail server and delivered just now? Otherwise I'd be a bit
confused, as the dpkg-realpath issue is supposed to have been fixed
already and this report looks like a duplicate of #985401, which was
also analyzed, and deemed a non-bug in dpkg-maintscript-helper?

Otherwise, I'll just be closing this one in a bit.

Thanks,
Guillem

Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

[Guillem Jover]

Control: retitle -1 dpkg: Print package removal due to Conflicts
Control: severity -1 normal

[ Changing title and lowering severity as I take this bug is now
  about the printing. ]

Hi!

On Fri, 2021-04-09 at 10:35:56 +0200, Andreas Beckmann wrote:
> Control: reopen -1
> 
> On 08/04/2021 19.22, Guillem Jover wrote:
> > > Otherwise, I don't see a bug in dpkg for this here. And I'd be
> > > inclined to close this.
> 
> I've managed to solve most of the upgrade paths by propagating some
> Conflicts from libreoffice-common to libreoffice-core, s.t. the packages
> get removed right away and are not deconfigured first (which causes the
> Conflicts encountered later to be ignored).

Ok, great!

> What I see left for dpkg is the missing verboseness when it is actually
> removing the conflicting package:
> 
>   Preparing to unpack .../0-ure_7.0.4-4~deb11anbe2_amd64.deb ...
>   Unpacking ure (1:7.0.4-4~deb11anbe2) over (6.1.5-3+deb10u7) ...
>   Preparing to unpack 
> .../1-libreoffice-style-colibre_7.0.4-4~deb11anbe2_all.deb ...
>   Unpacking libreoffice-style-colibre (1:7.0.4-4~deb11anbe2) over 
> (1:6.1.5-3+deb10u7) ...
>   dpkg: considering removing libreoffice-draw in favour of libreoffice-core 
> ...
>   dpkg: yes, will remove libreoffice-draw in favour of libreoffice-core
>   Preparing to unpack .../2-libreoffice-core_7.0.4-4~deb11anbe2_amd64.deb ...
>   Unpacking libreoffice-core (1:7.0.4-4~deb11anbe2) over (1:6.1.5-3+deb10u7) 
> ...
>   Preparing to unpack .../3-libreoffice-common_7.0.4-4~deb11anbe2_all.deb ...
>   Unpacking libreoffice-common (1:7.0.4-4~deb11anbe2) over 
> (1:6.1.5-3+deb10u7) ...
>   Selecting previously unselected package libreoffice-draw.
>   Preparing to unpack .../4-libreoffice-draw_7.0.4-4~deb11anbe2_amd64.deb ...
>   Unpacking libreoffice-draw (1:7.0.4-4~deb11anbe2) ...
>
> which makes it hard to understand the last failing case:

Right, I'll add these in 1.21.x.

>   Removing libreoffice-style-tango (1:6.1.5-3+deb10u7) ...

New run starts here. First package being processed.

>   dpkg: considering removing libreoffice-core in favour of libreoffice-common 
> ...
>   dpkg: yes, will remove libreoffice-core in favour of libreoffice-common
>   dpkg: considering removing libreoffice-draw in favour of libreoffice-common 
> ...
>   dpkg: yes, will remove libreoffice-draw in favour of libreoffice-common
>   dpkg: considering removing libreoffice-impress in favour of 
> libreoffice-common ...
>   dpkg: yes, will remove libreoffice-impress in favour of libreoffice-common
>   (Reading database ...
>   Preparing to unpack .../0-libreoffice-common_7.0.4-4~deb11anbe2_all.deb ...
>   De-configuring libreoffice-draw (1:6.1.5-3+deb10u7), to allow removal of 
> libreoffice-core (1:6.1.5-3+deb10u7) ...
>   De-configuring libreoffice-impress (1:6.1.5-3+deb10u7), to allow removal of 
> libreoffice-core (1:6.1.5-3+deb10u7) ...
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/ogltrans.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/impress.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/graphicfilter.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/draw.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> libreoffice-common:all, cannot switch to symlink
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-1xO0pR/0-libreoffice-common_7.0.4-4~deb11anbe2_all.deb 
> (--unpack):
>new libreoffice-common package pre-installation script subprocess returned 
> error exit status 1

The maintscript failed here so the queued removals didn't happen.

>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
> directory
>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory

Next package being processed.

>   Selecting previously unselected package libreoffice-draw.
>   dpkg: considering deconfiguration of libreoffice-common, which would be 
> broken by installation of libreoffice-draw ...
>   dpkg: yes, will deconfigure libreoffice-common (broken by libreoffice-draw)
>   dpkg: considering deconfiguration of libreoffice-core, which would be 
> broken by installation of libreoffice-draw ...
>   dpkg: yes, will deconfigure libreoffice-core (broken by libreoffice-draw)
>   Preparing to unpack .../1-libreoffice-draw_7.0.4-4~deb11anbe2_amd64.deb ...
>   De-configuring libreoffice-core (1:6.1.5-3+deb10u7)

Bug#983855: in package dpkg marked as pending

[Guillem Jover]

Control: tag 983855 pending

Hi!

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

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

---
dpkg-realpath: Fix resolution for absolute symlinks on «/»

We should not reset the resulting pathname to be the root directory when
the root directory is empty, as that will happen to always match.

Closes: #983855

Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

[Guillem Jover]

Hi!

On Thu, 2021-03-18 at 18:25:17 +0100, Rene Engelhard wrote:
> Am 18.03.21 um 06:53 schrieb Rene Engelhard:
> > It would be helpful if you actually did your homework. There already was
> > 985297 so you now caused a bogus addditional RC bug.
> > 
> > That bug even was marked as blocked by the dpkg bug so being careful
> > when reassigning RC bugs would actually be of help.
> > 
> > Now I have two of them. (Yes, I know about merge but still it is wrong
> > to reassign llike this at all.)
> 
> Sorry for my tone this morning, but waking up with a RC bug more for
> this wasn't actually making me happy in any way.

Thanks, much appreciated.

> >>>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
> >>>   dpkg-maintscript-helper: error: file 
> >>> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> >>> 'libreoffice-common:all'
> >>>   dpkg-maintscript-helper: error: directory 
> >>> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> >>> libreoffice-common:all, cannot switch to symlink
> >>>   dpkg: error processing archive 
> >>> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
> >>> (--unpack):
> >>>new libreoffice-common package pre-installation script subprocess 
> >>> returned error exit status 1
> >>>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file 
> >>> or directory
> >>>   rmdir: failed to remove '/var/lib/libreoffice': No such file or 
> >>> directory
> >> The libreoffice-common preinst maintainer script fails, so I'd expect
> >> the installation for the package gets aborted and the conflictor does
> >> not get removed after this, and before processing the next archive.
> > 
> > It fails because of
> > 
> >   dpkg-maintscript-helper: error: file 
> > '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> > 'libreoffice-common:all'
> >   dpkg-maintscript-helper: error: directory 
> > '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> > libreoffice-common:all, cannot switch to symlink
> > 
> > which is dpkg-maintscript-helpers domain.

Sure, because that file on buster is owned by another package, while
the failing package also owns files there. This still looks like a
usage issue in the caller, as this behavior has not changed nor is
a regression.

> Actually I pondered filing a bug back then (wishlist) when I first saw
> this because I think dpkg should trust maintainers to do the right thing
> if they used dir_to_symlink and the ownership of the file  changes.
> (That would also have saved the Conflicts)

I guess something could be added as a new feature, but taking into
account that the dpkg-maintscript-helper is a tool that tries to
cover feature deficiencies in dpkg, that should eventually be
supported natively, I'd rather not add anything that might make such
future integration not possible. But even then, this seems out of
scope at this time of the freeze.

> Is there a way to do  that? Or some way to force it?

I don't see how what the packages want to do can be done as is with
debhelper's dpkg-maintscript-helpers support, it seems to break unpacking
assumptions.

If you really need the symlink, then perhaps you could try to do the
switch on the postinst of all the packages that have shipped files
there, conditional on the directory being empty, so that the last one
moving its files out of the directory would switch it (specifying
manually the package that's supposed to own the symlink).

> Then I didn't actually do it and "just" added the Conflicts:
> 
> (The symlink is only needed because of LO not honouring their own
> configuration so otherwise the config is not found - see #972043 and
> #969653)

Ok, then if this is needed, see above.

Otherwise, I don't see a bug in dpkg for this here. And I'd be
inclined to close this.

Thanks,
Guillem

Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

[Guillem Jover]

Control: reassign -1 libreoffice-common 1:7.0.4-3

[ Leaving all context for the reassign. ]

Hi!

On Wed, 2021-03-17 at 12:13:52 +0100, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: block 985297 with -1
> 
>   Preparing to unpack .../0-ure_1%3a7.0.4-3_amd64.deb ...
>   Unpacking ure (1:7.0.4-3) over (6.1.5-3+deb10u7) ...
>   Preparing to unpack .../1-libreoffice-style-colibre_1%3a7.0.4-3_all.deb ...
>   Unpacking libreoffice-style-colibre (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering deconfiguration of libreoffice-writer, which would be 
> broken by installation of libreoffice-core ...
>   dpkg: yes, will deconfigure libreoffice-writer (broken by libreoffice-core)
>   Preparing to unpack .../2-libreoffice-core_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-writer (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...

The libreoffice-core package has finished unpacking. Next, dpkg starts
with libreoffice-common.

>   dpkg: considering removing libreoffice-writer in favour of 
> libreoffice-common ...
> * dpkg: libreoffice-writer is not properly installed; ignoring any 
> dependencies on it ***
> * dpkg: yes, will remove libreoffice-writer in favour of libreoffice-common   
> ***

dpkg detects there's a Conflicts involved during the unpack and queues
it for later removal. (Although that removal is then silent anyway, which
seems confusing, so ideally dpkg should probably print something like we
do with the de-configuring.)

>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> libreoffice-common:all, cannot switch to symlink
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
> (--unpack):
>new libreoffice-common package pre-installation script subprocess returned 
> error exit status 1
>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
> directory
>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory

The libreoffice-common preinst maintainer script fails, so I'd expect
the installation for the package gets aborted and the conflictor does
not get removed after this, and before processing the next archive.

>   Selecting previously unselected package libreoffice-writer.
>   dpkg: considering deconfiguration of libreoffice-common, which would be 
> broken by installation of libreoffice-writer ...
>   dpkg: yes, will deconfigure libreoffice-common (broken by 
> libreoffice-writer)
>   Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ...
>   Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ...
>   Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ...
>   Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb
> 
> So is dpkg going to remove libreoffice-writer or not?

It would if the maintscript would not have failed.

> It says both and does 
> not remove it, causing dpkg-maintscript-helper to fail since
> /usr/lib/libreoffice/share/registry is not empty before dir_to_symlink
> is run. There should be enough Conflicts to ensure all packages previously
> shipping files there are removed or upgraded.

This would be an incorrect assumption from the package, policy
describes how Conflicts interact during upgrades in §6.6. Notice
there the conflictors are only removed in step 13, the last one.

Thanks,
Guillem

Bug#985066: mono-gac: messes with the unpacking of another package

[Guillem Jover]

Control: reassign -1 mono-gac 6.8.0.105+dfsg-3
Control: retitle -1 mono-gac: messes with the unpacking of another package

[ Leaving context for the reassign. ]

Hi!

On Fri, 2021-03-12 at 12:54:31 +0100, Andreas Beckmann wrote:
> Package: mono-runtime-common,dpkg
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: found -1 6.8.0.105+dfsg-3
> Control: found -1 1.20.7.1

> during a test with piuparts I noticed your package modifies conffiles.
> Or rather, it appears so.
> 
> piuparts reports:
> 
> 0m48.5s ERROR: FAIL: debsums reports modifications inside the chroot:
>   /etc/mono/config
> 
> I don't see something obviously wrong in the package:
> 
> mono-runtime-common 5.18.0.240+dfsg-3 (buster) ships
> 
> # ls -la /etc/mono/config
> -rw-r--r-- 1 root root 2890 Apr 16  2019 /etc/mono/config
> # md5sum /etc/mono/config
> dc9d7e7fbd83e76c7c7956f392a6ee6f  /etc/mono/config
> # dpkg -s mono-runtime-common | grep /etc/mono/config
>  /etc/mono/config dc9d7e7fbd83e76c7c7956f392a6ee6f
> 
> mono-runtime-common 6.8.0.105+dfsg-3 (bullseye/sid) ships
> 
> # ls -la /etc/mono/config
> -rw-r--r-- 1 root root 3093 Apr  8  2020 /etc/mono/config
> # md5sum /etc/mono/config
> 267499e20c8acc00b7e01596bec6adba  /etc/mono/config
> # dpkg -s mono-runtime-common | grep /etc/mono/config
>  /etc/mono/config newconffile
> 
> That's a weird entry in dpkg's status file
> 
> There is no report about updating the conffile during the upgrade:
> 
> [...]
>   Preparing to unpack .../18-mono-runtime-common_6.8.0.105+dfsg-3_amd64.deb 
> ...
>   Unpacking mono-runtime-common (6.8.0.105+dfsg-3) over (5.18.0.240+dfsg-3) 
> ...
> [...]
>   Setting up mono-runtime-common (6.8.0.105+dfsg-3) ...
>   Processing triggers for libc-bin (2.31-9) ...
> [...]
> 
> and in the chroot I find this after the upgrade:
> 
> # ls -la /etc/mono/config*
> -rw-r--r-- 1 root root 3093 Apr  8  2020 /etc/mono/config
> # md5sum /etc/mono/config
> 267499e20c8acc00b7e01596bec6adba  /etc/mono/config
> # dpkg -s mono-runtime-common | grep /etc/mono/config
>  /etc/mono/config dc9d7e7fbd83e76c7c7956f392a6ee6f
> 
> So the new file is there, but dpkg still remembers the old md5sum.

I reproduced the upgrade, and then grepped for anything in the dpkg
database touching that file. And found that this is because mono-gac
is messing around with the conffile unpacking of another package, and
then obviously dpkg gets very confused:

  ,---
  $ dpkg-query --control-show mono-gac postinst | head
  #!/bin/sh -e

  # Work around for gacutil needing /etc/mono/config >= 5.20
  if [ -e /etc/mono/config.dpkg-new ]; then
  mv /etc/mono/config.dpkg-new /etc/mono/config
  fi

  # On upgrades we need to repopulate the GAC and framework paths
  # to accomodate any changes in layout
  #
  `---

The "work around" there is completely wrong. :)

Thanks,
Guillem

Bug#983855: golang-github-coreos-bbolt-dev: fails to upgrade from 'buster': unable to install new version of '/usr/share/gocode/src/go.etcd.io/bbolt/allocate_test.go': No such file or directory

[Guillem Jover]

Hi!

On Tue, 2021-03-02 at 22:26:55 +0100, Andreas Beckmann wrote:
> Control: reassign -1 dpkg 1.20.7.1
> Control: retitle -1 dpkg: dpkg-realpath is broken
> Control: severity -1 grave
> Control: affects -1 + golang-github-coreos-bbolt-dev 
> golang-github-xordataexchange-crypt-dev
> Control: tag -1 - help

> The good thing is that it is easily reproducible ...
> 
> # readlink /usr/share/gocode/src/go.etcd.io/bbolt
> ../github.com/coreos/bbolt
> # readlink -f /usr/share/gocode/src/go.etcd.io/bbolt
> /usr/share/gocode/src/github.com/coreos/bbolt
> # dpkg-realpath /usr/share/gocode/src/go.etcd.io/bbolt
> /github.com/coreos/bbolt
> 
> The output from dpkg-realpath is wrong, causing
> dpkg-maintscript-helper to skip its job.
> 
> Severity grave since I'm afraid that bug prepares for future upgrade
> errors since several dpkg-maintscript-helper actions may have been
> silently skipped without causing immediate trouble.

Ah! Ok good thing I had not done the unblock request. :) Attached a
patch that I think fixes this issue, and also fixes a problem with
the symlink loop detection.

Thanks,
Guillem
diff --git i/scripts/dpkg-realpath.sh w/scripts/dpkg-realpath.sh
index 5636ab3c7..bb7861038 100755
--- i/scripts/dpkg-realpath.sh
+++ w/scripts/dpkg-realpath.sh
@@ -69,10 +69,6 @@ canonicalize() {
  src=${src#/}
   done
   while [ -n "$src" ]; do
-loop=$((loop + 1))
-if [ "$loop" -gt 25 ]; then
-  error "too many levels of symbolic links"
-fi
 # Get the first directory component.
 prefix=${src%%/*}
 # Remove the first directory component from src.
@@ -88,10 +84,14 @@ canonicalize() {
 elif [ "$prefix" = .. ]; then
   # Go up one directory.
   result=${result%/*}
-  if [ "${result#"$root"}" = "$result" ]; then
+  if [ -n "$root" ] && [ "${result#"$root"}" = "$result" ]; then
 result="$root"
   fi
 elif [ -h "$result/$prefix" ]; then
+  loop=$((loop + 1))
+  if [ "$loop" -gt 25 ]; then
+error "too many levels of symbolic links"
+  fi
   # Resolve the symlink within $result.
   dst=$(readlink "$result/$prefix")
   case "$dst" in

Bug#982273: libbsd0-udeb: depends on libmd0

[Guillem Jover]

On Mon, 2021-02-08 at 14:54:28 +0100, Guillem Jover wrote:
> On Mon, 2021-02-08 at 14:07:08 +0100, Cyril Brulebois wrote:
> > Feel free to let us know about a source package/git repository so that
> > we have a chance of experimenting with it before or while it's being
> > reviewed/processed by ftp-masters.
> 
> Ok, thanks, then I'll upload in 1h at most, and provide repo + src +
> bin packages.

I've uploaded it now, once it hits NEW I'll poke ftp-masters. The git
and source+binary packages at:

  <https://git.hadrons.org/cgit/debian/pkgs/libmd.git/>
  <https://people.debian.org/~guillem/libmd-udeb/>

Thanks,
Guillem