Bug#1071749: bidentd: Cannot work with current kernels - remove?

[Chris Hofstaedtler]

Source: bidentd
Version: 1.1.4-1.2
Severity: serious

Inspection of the source reveals bidentd uses /proc/net/ip_conntrack
and/or /proc/net_ip_masquerade to identify connections.
These files have long been removed from Linux.

I believe bidentd thus cannot work at all and propose its removal.

I'm filing with sev: serious, because it's been a really really long
time already since when bidentd could have become useful, and IMO we
should not have it in trixie.

Chris

Bug#1070965: rtorrent: does not start due to soname update

[Chris Lamb]

Liam Stitt wrote:

> libxmlrpc-core-c3t64 has bumped that soname to .4, so presumably a rebuild 
> will
> fix this.

A rebuild will indeed fix this, or at least rebuilding rtorrent
locally fixes this for me.

Can the maintainer therefore please request a binNMU?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1071063: screenkey: malformed debian/changelog

[Chris Lamb]

Package: screenkey
Version: 1:1.5-4
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org


Hi,

This might not *strictly* be an RC bug, but the latest upload of
screenkey has the following entry in debian/changelog:

<<<
screenkey (1:1.5-4) unstable; urgency=medium

  * fixed d/watch
  * bumped Standards-Version: 4.7.0
  * removed the stance X-Python-Version

 --
>>>

Note in particular the missing date. This doesn't break dak, otherwise
it would not have been accepted by the archive, but it breaks many
other tools (eg. gbp-buildpackage, etc.) as well as other things. For
example, the package is not reproducible because SOURCE_DATE_EPOCH
cannot be extracted from the debian/changelog.

When building the package you should have seen warnings by, for
instance, dh_installchangelogs, dpkg-gencontrol, dpkg-genchanges,
etc. :)

Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1070416: src:diffoscope: unsatisfied build dependency in testing: aapt

[Chris Lamb]

Paul Gevers wrote:

> Dose [1] is reporting a build issue with your package, it's missing a
> build dependency. Obviously your build dependencies shouldn't be
> removed from testing, but unfortunately there are multiple scenarios
> where that can happen nevertheless.

Looks like this happened due to these RC bugs:

  https://bugs.debian.org/1062206
  https://bugs.debian.org/1062110
  https://bugs.debian.org/1062209

i.e. it wasn't that aapt was removed or barred from testing for some
reason specific to aapt's code or license, etc. It is, as I understand
it, not impossible that it might return to testing without further
intervention on our part..?

Otherwise, we can very cleanly remove this build dependency, even
keeping the .arsc file support in diffoscope itself.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1069538: zeroc-ice: FTBFS on armel: Gradle / Java heap space out-of-memory error

[Chris Knadle]

retitle 1069538 zeroc-ice: FTBFS on armel: Gradle / Java heap space 
out-of-memory-error


tags 1069538 - moreinfo

thanks

I've done additional test builds of zeroc-ice-3.7.10-2.2 on armel on 
porter boxes amdahl and abel and the build fails with the same error 
which seems to be during a Java memory check. It is still unclear as to 
why this error is happening now but not previously.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1070019: [Pkg-utopia-maintainers] Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev

[Chris Hofstaedtler]

* Chris Hofstaedtler  [240429 15:24]:
> > udisks2's autopkgtest fails when tried together with util-linux 2.40. An
> > example can be seen here:
> > https://ci.debian.net/packages/u/udisks2/testing/amd64/46012968/
> > 
> > 537s ==
> > 537s FAIL: test_ext4 (__main__.FS.test_ext4)
> > 537s fs: ext4
> > 537s --
> > 537s Traceback (most recent call last):
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 1107, in _do_udisks_check
> > 537s cd_fs.call_mount_sync(ro_options, None)
> > 537s gi.repository.GLib.GError: udisks-error-quark: 
> > GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 
> > at /media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call 
> > failed: /dev/sr1: Can't open blockdev (0)
> > 537s
> > 537s During handling of the above exception, another exception occurred:
> > 537s
> > 537s Traceback (most recent call last):
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 725, in test_ext4
> > 537s self._do_fs_check('ext4')
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 894, in _do_fs_check
> > 537s self._do_udisks_check(fs_type)
> > 537s   File 
> > "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> > 1112, in _do_udisks_check
> > 537s self.fail('Mounting read-only device with \'rw\' option failed'
> > 537s AssertionError: Mounting read-only device with 'rw' option failedwith 
> > an unexpected error.
> > 537s Got: udisks-error-quark: 
> > GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 
> > at /media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call 
> > failed: /dev/sr1: Can't open blockdev (0)
> > 537s Expected: 'is write-protected but explicit read-write mode requested' 
> > or 'is write-protected but `rw' option given'
 

> I won't get to it this week (also re: stable v2.40.1), but maybe
> someone else has seen this failure already?

Having said that, it seems likely the test was broken by this
change in util-linux:
  libmount: report kernel message from new API
  
https://github.com/util-linux/util-linux/commit/9da5644e414cdc318f0311260dabc6035c85b58e

I don't know if the error messages are supposed to be stable or not,
but it looks like a very intentional change :-)

Orthogonally, "/dev/sr1: Can't open blockdev" seems not very
informative if it's supposed to mean "write-protected but `rw'
option given".

Chris

Bug#1070019: [Pkg-utopia-maintainers] Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev

[Chris Hofstaedtler]

Dear util-linux@,

in Debian, udisks2 2.10.1-6 (autopkg-)tests fail with util-linux
2.40, but passed with 2.39. We are not yet sure if this is directly
caused by util-linux, but it seems somewhat likely.

I won't get to it this week (also re: stable v2.40.1), but maybe
someone else has seen this failure already?

> udisks2's autopkgtest fails when tried together with util-linux 2.40. An
> example can be seen here:
> https://ci.debian.net/packages/u/udisks2/testing/amd64/46012968/
> 
> 537s ==
> 537s FAIL: test_ext4 (__main__.FS.test_ext4)
> 537s fs: ext4
> 537s --
> 537s Traceback (most recent call last):
> 537s   File 
> "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> 1107, in _do_udisks_check
> 537s cd_fs.call_mount_sync(ro_options, None)
> 537s gi.repository.GLib.GError: udisks-error-quark: 
> GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 at 
> /media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call 
> failed: /dev/sr1: Can't open blockdev (0)
> 537s
> 537s During handling of the above exception, another exception occurred:
> 537s
> 537s Traceback (most recent call last):
> 537s   File 
> "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 725, 
> in test_ext4
> 537s self._do_fs_check('ext4')
> 537s   File 
> "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 894, 
> in _do_fs_check
> 537s self._do_udisks_check(fs_type)
> 537s   File 
> "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", line 
> 1112, in _do_udisks_check
> 537s self.fail('Mounting read-only device with \'rw\' option failed'
> 537s AssertionError: Mounting read-only device with 'rw' option failedwith an 
> unexpected error.
> 537s Got: udisks-error-quark: 
> GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 at 
> /media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call 
> failed: /dev/sr1: Can't open blockdev (0)
> 537s Expected: 'is write-protected but explicit read-write mode requested' or 
> 'is write-protected but `rw' option given'
> 
> I do not understand what this error means, or what the underlying problem is.
> Please investigate.

For context, Debian's util-linux 2.40-7 should have everything from
2.40 stable up to a8aa0b5f154a44557f5bae5a4027bdbfe42b0323.

Chris

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

[Chris Hofstaedtler]

Control: reassign -1 dpkg

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

> with fdisk.

I see no evidence of that in the log.

C

Bug#1070020: autopkgtest: (unrelated) packages not found

[Chris Hofstaedtler]

Source: mmdebstrap
Version: 1.4.3-6
Severity: serious
X-Debbugs-Cc: debian-rele...@lists.debian.org

Hi,

the autopkgtests for mmdebstrap as part of migration tests for
testing/amd64 fail with apt reporting 'Not found' errors.

As an example, for this scenario:
mmdebstrap 1.4.3-6
util-linux/2.40-8 gdm3/46.0-2 sssd/2
src:util-linux from unstable
src:gdm3 from unstable
src:sssd from unstable
https://ci.debian.net/packages/m/mmdebstrap/testing/amd64/46033215/

1085s Err:22 http://127.0.0.1/debian unstable/main amd64 libssl3 amd64 3.1.5-1
1085s   404  File not found [IP: 127.0.0.1 80]
...
1085s Err:41 http://127.0.0.1/debian unstable/main amd64 libdb5.3 amd64 
5.3.28+dfsg2-4+b1
1085s   404  File not found [IP: 127.0.0.1 80]
...
1085s Err:73 http://127.0.0.1/debian unstable/main amd64 libgdbm6 amd64 
1.23-5+b1
1085s   404  File not found [IP: 127.0.0.1 80]
1085s Err:74 http://127.0.0.1/debian unstable/main amd64 libgdbm-compat4 amd64 
1.23-5+b1
1085s   404  File not found [IP: 127.0.0.1 80]

This looks like a pinning problem or some other issue. Given libssl3 is
a problem here, which is NOT a package considered for migration in this
test, I don't see how the test failure is actually related to the
involved packages.
If this is a transient situation, please detect it and exit with status
77.

Chris

Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev

[Chris Hofstaedtler]

Source: udisks2
Version: 2.10.1-6
Severity: serious

Hi,

udisks2's autopkgtest fails when tried together with util-linux 2.40. An
example can be seen here:
https://ci.debian.net/packages/u/udisks2/testing/amd64/46012968/

537s ==
537s FAIL: test_ext4 (__main__.FS.test_ext4)
537s fs: ext4
537s --
537s Traceback (most recent call last):
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 1107, in _do_udisks_check
537s cd_fs.call_mount_sync(ro_options, None)
537s gi.repository.GLib.GError: udisks-error-quark: 
GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 at 
/media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call failed: 
/dev/sr1: Can't open blockdev (0)
537s 
537s During handling of the above exception, another exception occurred:
537s 
537s Traceback (most recent call last):
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 725, in test_ext4
537s self._do_fs_check('ext4')
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 894, in _do_fs_check
537s self._do_udisks_check(fs_type)
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 1112, in _do_udisks_check
537s self.fail('Mounting read-only device with \'rw\' option failed'
537s AssertionError: Mounting read-only device with 'rw' option failedwith an 
unexpected error.
537s Got: udisks-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: 
Error mounting /dev/sr1 at /media/root/41b1acb1-744c-422a-9071-2dba5368a683: 
fsconfig system call failed: /dev/sr1: Can't open blockdev (0)
537s Expected: 'is write-protected but explicit read-write mode requested' or 
'is write-protected but `rw' option given'

I do not understand what this error means, or what the underlying problem is.
Please investigate.

Chris

Bug#1069923: marked as pending in util-linux

[Chris Hofstaedtler]

Control: tag -1 pending

Hello,

Bug #1069923 in util-linux 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/debian/util-linux/-/commit/c75d35c930036610bc82b92152daa6975e8c2a98


Also cover ctrlaltdel in /usr-move mitigation

Closes: #1069923


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069923

Bug#1069064: marked as pending in util-linux

[Chris Hofstaedtler]

Control: tag -1 pending

Hello,

Bug #1069064 in util-linux 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/debian/util-linux/-/commit/e7b4b439820d215cc81e1b37d1950216378a2289


Fix /usr-move mitigation

Closes: #1069064


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069064

Bug#1069762: pdns-recursor: CVE-2024-25583 - 4.8.8 for stable

[Chris Hofstaedtler]

* Moritz Muehlenhoff  [240425 08:44]:
> On Thu, Apr 25, 2024 at 08:37:14AM +0200, Chris Hofstaedtler wrote:
> > Hi Moritz,
> > 
> > could we once again use the upstream release for stable?
> > debdiff 4.8.7-1 -> 4.8.8-1 is attached.
> 
> Ack. Following the 4.8 releases has served us well. debdiff looks fine,
> please build with -sa and upload to security-master.

Done.

Thanks,
Chris

Bug#1064311: rdkit: NMU diff for 64-bit time_t transition

[Chris Hofstaedtler]

On Wed, Apr 24, 2024 at 09:25:29AM +0300, Andrius Merkys wrote:
> Hi,
> 
> On Mon, 19 Feb 2024 21:35:16 + Steve Langasek 
> wrote:> Since turning on 64-bit time_t is being handled centrally through a
> change
> > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> > important that libraries affected by this ABI change all be uploaded close
> > together in time.  Therefore I have prepared a 0-day NMU for rdkit
> > which will initially be uploaded to experimental if possible, then to
> > unstable after packages have cleared binary NEW.
> > 
> > Please find the patch for this NMU attached.
> 
> It is most likely my fault this has not been resolved yet - by uploading
> 202309.3-3 I trashed 202309.3-2.1~exp1. Am I right that I should reupload
> rdkit with t64 binaries to experimental now?

t64 is already in unstable and making its way to testing. So you are
a bit late with getting rdkit fixed for t64.

An upload with t64 binaries is required as soon as possible. Given
the packages have to go to binary-NEW, you must upload with
binaries, and then probably follow up with a source-only upload once
they are ACCEPTed.

Chris

Bug#1065100: efingerd: Depends on libident, which is NBS

[Chris Hofstaedtler]

Control: reassign -1 release.debian.org
Control: retitle -1 nmu: efingerd_1.6.7-1
Control: severity -1 normal

On Thu, Feb 29, 2024 at 02:41:54PM -0500, Boyuan Yang wrote:
> Severity: serious
> Justification: Policy 2.2.1
> 
> Package efingerd depends on binary package libident, but this package has
> been renamed to libident0 due to time64 transition.
...
> You may need to rebuild the package.

This should just have been filed as a binNMU request to
release.debian.org. There was no need to remove the package from
testing. A local no-change rebuild shows that it picks up the new
libident0 name just fine.

Release team, please schedule binNMU for this package.


Chris

Bug#1069538: zeroc-ice: FTBFS on armel: make[3]: out of memory error

[Chris Knadle]

Hello Lucas.

The zeroc-ice 3.7.10-2.2 package built correctly on an armel buildd 
within two weeks ago:


https://buildd.debian.org/status/logs.php?pkg=zeroc-ice=3.7.10-2.2=armel

The underlying error in the build logs you sent looks like an 
out-of-memory condition:


> Failed to execute 
org.gradle.process.internal.health.memory.DefaultMemoryManager$MemoryCheck@12c1b75.

> java.lang.OutOfMemoryError: Java heap space
> An exception has occurred in the compiler (17.0.11). Please file a 
bug against the Java compiler via the Java bug reporting page 
(https://bugreport.java.com) after checking the Bug Database 
(https://bugs.java.com) for duplicates. Include your program, the 
following diagnostic, and the parameters passed to the Java compiler in 
your report. Thank you.

> java.lang.OutOfMemoryError: Java heap space
> :test:compileJava FAILED
> :test:compileJava (Thread[Task worker for ':' Thread 3,5,main]) 
completed. Took 5 mins 20.937 secs.


I suspect this isn't a bug in the zeroc-ice package.

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1069538: zeroc-ice: FTBFS on armel: appears to be out-of-memory condition

[Chris Knadle]

tags 1069538 + moreinfo

thanks

Bug#1057850: libnss-db: Uses db5.3, no replacement in sight

[Chris Hofstaedtler]

On Thu, Apr 04, 2024 at 07:16:34PM -0300, Paulo Henrique de Lima Santana wrote:
> Would be possible reintroduce libnss-db to testing?
> 
> I'm asking because I'm maintainer of the pglistener package and I know there
> aren't plans to update the sofwtare with another database solution.

Well what's your plan forward? db5.3 is supposed to be removed.

Chris

Bug#1067318: autorm ping

[Chris Hofstaedtler]

ping to prevent autoremoval from testing, while time_t-64bit
migration is unfinished.

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

[Chris Hofstaedtler]

Hi Helmut,

On Mon, Apr 15, 2024 at 08:58:42PM +0200, Helmut Grohne wrote:
> I think I mentioned this on IRC already and you intended to revert, but
> nothing happened, so lets turn this into a bug for tracking purposes at
> least.

Indeed, I forgot to follow up afterwards. Thanks for keeping track!

> util-linux-extra gained the utils ctrlaltdel, [..] In
> util-linux-extra, these now reside below /usr/sbin [..]

> I think we have three ways to address this:

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

I think half of 2) exists now, but Conflicts: util-linux will
probably end badly as you note. I'd welcome a patch implementing 3).

Initially I favored 1), but then u-l will never make progress on
moving the non-essential files.

Thanks!

Chris

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Chris Hofstaedtler]

On Fri, Apr 12, 2024 at 09:11:51AM +0200, Jan Katins wrote:
> Package: cryptsetup
> Version: 2:2.7.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After a recent apt upgrade on a debian sid system (installed about 3
> years ago with an installer, choosing to encrypt the filesystem, no
> idea what actually ended up on my system as a crypt setup. Since then,
> the laptop runs debian unstable), my system failed to unlock. After a
> ctrl-alt-del, I got to the console and there it showed an error about
> libgcc_s.so.1 not available and aborting.

Can you tell us which part was wanting libgcc_s.so.1? 
cryptsetup in the initramfs doesn't seem to be the (original)
problem of that.

Chris

Bug#1065457: openzwave: diff for NMU version 1.6.1914+ds-1.2

[Chris Hofstaedtler]

Control: tags 1065457 + patch
Control: tags 1065457 + pending

Dear maintainer,

I've prepared an NMU for openzwave (versioned as 1.6.1914+ds-1.2) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru openzwave-1.6.1914+ds/debian/changelog openzwave-1.6.1914+ds/debian/changelog
--- openzwave-1.6.1914+ds/debian/changelog	2024-02-29 19:55:23.0 +0100
+++ openzwave-1.6.1914+ds/debian/changelog	2024-04-11 15:37:03.0 +0200
@@ -1,3 +1,15 @@
+openzwave (1.6.1914+ds-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload. (Closes: #1065457)
+  * Bump dpkg-dev versioned Build-Depends for t64 transition.
+  * Patch upstream Makefiles to show compiler invocations.
+  * Patch additional upstream Makefile to remove -Wno-format.
+  * Build-Depends: add pkgconf, necessary to place .pc file.
+  * Reduce CPPFLAGS updating, to avoid unknown ‘-Werror=implicit-function-declaration’
+in cc1plus aborting the build.
+
+ -- Chris Hofstaedtler   Thu, 11 Apr 2024 15:37:03 +0200
+
 openzwave (1.6.1914+ds-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru openzwave-1.6.1914+ds/debian/control openzwave-1.6.1914+ds/debian/control
--- openzwave-1.6.1914+ds/debian/control	2024-02-29 19:55:23.0 +0100
+++ openzwave-1.6.1914+ds/debian/control	2024-04-11 15:37:03.0 +0200
@@ -7,7 +7,8 @@
 	, dh-exec (>=0.2)
 	, libudev-dev
 	, libxml2-utils
-  , dpkg-dev (>= 1.20)
+	, dpkg-dev (>= 1.22.6)
+	, pkgconf
 Standards-Version: 4.6.0
 Homepage: http://www.openzwave.net/
 Vcs-Browser: https://salsa.debian.org/debian-iot-team/openzwave
diff -Nru openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch
--- openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch	1970-01-01 01:00:00.0 +0100
+++ openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch	2024-04-11 15:37:03.0 +0200
@@ -0,0 +1,146 @@
+Index: openzwave-1.6.1914+ds/cpp/build/support.mk
+===
+--- openzwave-1.6.1914+ds.orig/cpp/build/support.mk
 openzwave-1.6.1914+ds/cpp/build/support.mk
+@@ -184,24 +184,24 @@ endif
+ 
+ $(OBJDIR)/%.o : %.cpp
+ 	@echo "Building $(<:$(top_builddir)/cpp/%=%)"
+-	@$(CXX) -MM $(CFLAGS) $(CPPFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d
++	$(CXX) -MM $(CFLAGS) $(CPPFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d
+ 	@mv -f $(DEPDIR)/$*.d $(DEPDIR)/$*.d.tmp
+ 	@$(SED) -e 's|.*:|$(OBJDIR)/$*.o: $(DEPDIR)/$*.d|' < $(DEPDIR)/$*.d.tmp > $(DEPDIR)/$*.d;
+ 	@$(SED) -e 's/.*://' -e 's/\\$$//' < $(DEPDIR)/$*.d.tmp | $(FMTCMD) | \
+ 	  $(SED) -e 's/^ *//' -e 's/$$/:/' >> $(DEPDIR)/.$*.d;
+ 	@rm -f $(DEPDIR)/$*.d.tmp
+-	@$(CXX) $(CFLAGS) $(CPPFLAGS) $(TARCH) $(INCLUDES) -o $@ $<
++	$(CXX) $(CFLAGS) $(CPPFLAGS) $(TARCH) $(INCLUDES) -o $@ $<
+ 
+ 
+ $(OBJDIR)/%.o : %.c
+ 	@echo "Building $(<:$(top_builddir)/cpp/src/%=%)"
+-	@$(CC) -MM $(CFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d
++	$(CC) -MM $(CFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d
+ 	@mv -f $(DEPDIR)/$*.d $(DEPDIR)/$*.d.tmp
+ 	@$(SED) -e 's|.*:|$(OBJDIR)/$*.o: $(DEPDIR)/$*.d|' < $(DEPDIR)/$*.d.tmp > $(DEPDIR)/$*.d;
+ 	@$(SED) -e 's/.*://' -e 's/\\$$//' < $(DEPDIR)/$*.d.tmp | $(FMTCMD) | \
+ 	  $(SED) -e 's/^ *//' -e 's/$$/:/' >> $(DEPDIR)/.$*.d;
+ 	@rm -f $(DEPDIR)/$*.d.tmp
+-	@$(CC) $(CFLAGS) $(TARCH) $(INCLUDES) -o $@ $<
++	$(CC) $(CFLAGS) $(TARCH) $(INCLUDES) -o $@ $<
+ 
+ 
+ dummy := $(shell test -d $(OBJDIR) || mkdir -p $(OBJDIR))
+Index: openzwave-1.6.1914+ds/cpp/build/Makefile
+===
+--- openzwave-1.6.1914+ds.orig/cpp/build/Makefile
 openzwave-1.6.1914+ds/cpp/build/Makefile
+@@ -206,7 +206,7 @@ $(LIBDIR)/$(SHARED_LIB_NAME):	$(patsubst
+ 			$(patsubst %.cpp,$(OBJDIR)/%.o,$(indep)) \
+ 			$(OBJDIR)/vers.o
+ 	@echo "Linking Shared Library"
+-	@$(LD) $(LDFLAGS) $(TARCH) -o $@ $+ $(LIBS)
++	$(LD) $(LDFLAGS) $(TARCH) -o $@ $+ $(LIBS)
+ 	@ln -sf $(SHARED_LIB_NAME) $(LIBDIR)/$(SHARED_LIB_UNVERSIONED)
+ 
+ $(top_builddir)/libopenzwave.pc: $(top_srcdir)/cpp/build/libopenzwave.pc.in $(PKGCONFIG)
+@@ -256,35 +256,35 @@ endif
+ 
+ install: $(LIBDIR)/$(SHARED_LIB_NAME) doc $(top_builddir)/libopenzwave.pc $(top_builddir)/ozw_config
+ 	@echo "Installing Shared Library"
+-	@install -d $(DESTDIR)/$(instlibdir)/
+-	@cp  $(LIBDIR)/$(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_NAME)
+-	@ln -sf $(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_UNVERSIONED)
++	install -d $(DESTDIR)/$(instlibdir)/
++	cp  $(LIBDIR)/$(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_NAME)
++	ln -sf $(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_UNVERSIONED)
+ 	@echo "Installing Headers"
+-	@install -d $(DESTDIR)/$(includedir)
+-	@install -m 0644 $(top_srcdir)/cpp/src/*.h $(DESTDIR)/$

Bug#1067911: Diff for fix of FTBFS bug

[Chris Knadle]

Attached is the NMUdiff for fixing FTBFS Bug #1067911 which would keep 
zeroc-ice from migrating to Testing.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us
diff -Nru zeroc-ice-3.7.10/debian/changelog zeroc-ice-3.7.10/debian/changelog
--- zeroc-ice-3.7.10/debian/changelog	2024-02-29 19:14:45.0 -0500
+++ zeroc-ice-3.7.10/debian/changelog	2024-04-10 10:48:17.0 -0400
@@ -1,3 +1,13 @@
+zeroc-ice (3.7.10-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches:
+- Add remove-Werror-build-option.patch to fix FTBFS bug due to injection
+  of "inplicit-function-declaration" flag during time_t 64bit transition
+  (Closes: #1067911)
+
+ -- Christopher Knadle   Wed, 10 Apr 2024 10:48:17 -0400
+
 zeroc-ice (3.7.10-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch
--- zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch	1969-12-31 19:00:00.0 -0500
+++ zeroc-ice-3.7.10/debian/patches/remove-Werror-build-option.patch	2024-04-10 10:32:22.0 -0400
@@ -0,0 +1,18 @@
+Description: remove -Werror build option to fix FSBFS issue
+ During the time_t 64bit transition the "implicit-function-declaration" build
+ flag is injected and this breaks the build when -Werror is set
+Author: Christopher Knadle 
+Bug: https://bugs.debian.org/1067911
+Last-Update: 2024-04-10
+
+--- a/config/Make.rules.Linux
 b/config/Make.rules.Linux
+@@ -137,7 +137,7 @@
+ -pie $(if $(filter yes,$(new_dtags)),-Wl$(comma)--enable-new-dtags,-Wl$(comma)--disable-new-dtags) \
+ $$(call unique,$$(foreach d,$($4_dependencies),$$(call make-rpath-link-ldflags,$$d,$($4_dependencies)
+ 
+-cppflags= -Wall -Wextra -Wredundant-decls -Wshadow -Wdeprecated -Werror -pthread $(if $(filter yes,$(OPTIMIZE)),-DNDEBUG,-g)
++cppflags= -Wall -Wextra -Wredundant-decls -Wshadow -Wdeprecated -pthread $(if $(filter yes,$(OPTIMIZE)),-DNDEBUG,-g)
+ ldflags = -pthread
+ 
+ # -Wshadow is too strict with gcc 4
diff -Nru zeroc-ice-3.7.10/debian/patches/series zeroc-ice-3.7.10/debian/patches/series
--- zeroc-ice-3.7.10/debian/patches/series	2023-11-07 04:45:43.0 -0500
+++ zeroc-ice-3.7.10/debian/patches/series	2024-04-10 10:27:07.0 -0400
@@ -1 +1,2 @@
 java-build.patch
+remove-Werror-build-option.patch

Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]

[Chris Knadle]

On 4/10/24 10:02, Andrey Rakhmatullin wrote:

On Wed, Apr 10, 2024 at 09:52:44AM -0400, Chris Knadle wrote:

Removing -Werror looks like it would be a simple patch, it seems to be set
here:

config/Make.rules.Linux:cppflags    = -Wall -Wextra -Wredundant-decls
-Wshadow -Wdeprecated -Werror -pthread $(if $(filter
yes,$(OPTIMIZE)),-DNDEBUG,-g)

... but this also doesn't sound like the right answer.

Yes, it just turns the error into a warning, it's still better to remove
the problem that causes this warning, but it's *also* better to not use
-Werror when building Debian packages.


That's probably true.

I've made a patch to do this, I'll do a test build and then upload an NMU.

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]

[Chris Knadle]

On 4/10/24 04:32, Andrey Rakhmatullin wrote:

On Tue, Apr 09, 2024 at 09:50:37PM -0400, Chris Knadle wrote:

Apparently this new bug got introduced with the time_t 64bit transition:

Yes, but it's a valid bug in the package, not a bad thing accidentally
introduced by the transition.

That doesn't sound right.
The zeroc-ice source code does not set the 
'-Werror=implicit-function-declaration' build option.
I think these two lines in debian/rules in the package are where CFLAGS 
get set:



   DPKG_EXPORT_BUILDFLAGS = 1
   include /usr/share/dpkg/default.mk

In other words, whatever bug this is seems to be due to a change in 
reasonable default configs from Debian, not in the source.



(?) Can the CFLAGS be cleared with:

   DEB_CFLAGS_SET=""


What I don't know is what has to be done now to get zeroc-ice fixed. Does
this require an upload to disable the implict-function-declaration flag

Please don't disable it.

I see two options here: either fix the package to not use $CFLAGS to build
C++ code or fix the package to not use -Werror.
From examining the source, zeroc-ice doesn't set CFLAGS when building 
with Linux.The source of CFLAGS being set seems to be set by 
dpkg-buildflags


Removing -Werror looks like it would be a simple patch, it seems to be 
set here:


config/Make.rules.Linux:cppflags    = -Wall -Wextra 
-Wredundant-decls -Wshadow -Wdeprecated -Werror -pthread $(if $(filter 
yes,$(OPTIMIZE)),-DNDEBUG,-g)


... but this also doesn't sound like the right answer.

But clearing CFLAGS seems like it would be reasonable.


I need to fix this to allow zeroc-ice to transition to Testing, in order to
allow mumble to transition to Testing.

Note that it won't transition to testing before the time64 transition to
to testing is allowed.


--
Chris Knadle
chris.kna...@coredump.us

Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]

[Chris Knadle]

Hello Audrey.

Apparently this new bug got introduced with the time_t 64bit transition:

"abi=time64 turns on -Werror=implicit-function-declaration in 
dpkg-buildflags, which causes unrelated build failures."


See: https://wiki.debian.org/BrainDumpT64

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

What I don't know is what has to be done now to get zeroc-ice fixed. 
Does this require an upload to disable the implict-function-declaration 
flag, or does this simply require a binNMU?


I need to fix this to allow zeroc-ice to transition to Testing, in order 
to allow mumble to transition to Testing.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us


Source: zeroc-ice
Version: 3.7.10-2.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=zeroc-
ice=armhf=3.7.10-2.1=1711639887=0

arm-linux-gnueabihf-g++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-
protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -MT

modules/IcePy/build/arm-linux-gnueabihf/shared/pic/Grammar.o -MMD -MP -MF
modules/IcePy/build/arm-linux-gnueabihf/shared/pic/Grammar.Td -Wall 
-Wextra

-Wshadow -Wdeprecated -Werror -pthread -DNDEBUG -Imodules/IcePy
-I../cpp/include -I../cpp/include/generated -I../cpp/src
-I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g
-Werror=implicit-function-declaration -fstack-protector-strong 
-fstack-clash-
protection -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O2 
-Wall -Wno-

missing-field-initializers -Wno-psabi -fPIC -fvisibility=hidden
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2 -c ../cpp/src/Slice/Grammar.cpp -o 
modules/IcePy/build/arm-

linux-gnueabihf/shared/pic/Grammar.o
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]

Bug#1068572: tgt: diff for NMU version 1:1.0.85-1.2

[Chris Hofstaedtler]

Control: tags 1068572 + patch
Control: tags 1068572 + pending

Dear maintainer,

I've prepared an NMU for tgt (versioned as 1:1.0.85-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru tgt-1.0.85/debian/changelog tgt-1.0.85/debian/changelog
--- tgt-1.0.85/debian/changelog	2023-11-17 22:35:38.0 +0100
+++ tgt-1.0.85/debian/changelog	2024-04-09 09:28:44.0 +0200
@@ -1,3 +1,11 @@
+tgt (1:1.0.85-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop building tgt-rbd on 32bit archs (Closes: #1068572)
+  * Replace Build-Depends: pkg-config (deprecated) with pkgconf
+
+ -- Chris Hofstaedtler   Tue, 09 Apr 2024 09:28:44 +0200
+
 tgt (1:1.0.85-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tgt-1.0.85/debian/control tgt-1.0.85/debian/control
--- tgt-1.0.85/debian/control	2023-11-17 22:35:38.0 +0100
+++ tgt-1.0.85/debian/control	2024-04-09 09:28:44.0 +0200
@@ -3,8 +3,10 @@
 Priority: optional
 Maintainer: Apollon Oikonomopoulos 
 Build-Depends: debhelper-compat (= 13), libibverbs-dev, librdmacm-dev (>= 1.0.16),
-	   xsltproc, docbook-xsl, librbd-dev, libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64], uuid-dev,
-   bash-completion, libsystemd-dev, libaio-dev, pkg-config
+   xsltproc, docbook-xsl,
+   librbd-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64],
+   libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64],
+   uuid-dev, bash-completion, libsystemd-dev, libaio-dev, pkgconf
 Vcs-Git: https://salsa.debian.org/debian/tgt.git
 Vcs-Browser: https://salsa.debian.org/debian/tgt
 Standards-Version: 4.6.1
@@ -35,7 +37,7 @@
  This package includes the daemon and user-space tools.
 
 Package: tgt-rbd
-Architecture: linux-any
+Architecture: amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64
 Depends: tgt (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Description: Linux SCSI target user-space daemon and tools - RBD support
  The Linux target framework (tgt) allows a Linux system to provide SCSI
diff -Nru tgt-1.0.85/debian/rules tgt-1.0.85/debian/rules
--- tgt-1.0.85/debian/rules	2023-11-17 22:35:38.0 +0100
+++ tgt-1.0.85/debian/rules	2024-04-09 09:28:44.0 +0200
@@ -1,12 +1,16 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE=1
 
-FEATURES = ISCSI_RDMA=1 CEPH_RBD=1 SD_NOTIFY=1
+FEATURES = ISCSI_RDMA=1 SD_NOTIFY=1
 
 glfs_libs = $(shell pkg-config --libs glusterfs-api 2>/dev/null)
 ifneq ($(glfs_libs),)
 FEATURES += GLFS_BD=1
 endif
+rbd_lib = $(shell ls /usr/lib/${DEB_HOST_MULTIARCH}/librbd.so 2>/dev/null)
+ifneq ($(rbd_lib),)
+FEATURES += CEPH_RBD=1
+endif
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 

Bug#1066396: lftp: FTBFS: ./config.h:2540:11: fatal error: trio.h: No such file or directory

[Chris Hofstaedtler]

On Sun, Mar 24, 2024 at 03:42:18PM +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 13, 2024 at 01:03:20PM +0100, Lucas Nussbaum wrote:
> > > ./config.h:2540:11: fatal error: trio.h: No such file or directory
> > >  2540 | # include "trio.h"
> > >   |   ^~~~
> (this suggests that using trio is not actually supported but that's
> irrelevant)
> This is caused by the stdio detection failing and should be fixed by
> adding #include  to the test case code in m4/needtrio.m4 but this
> package doesn't run autoreconf so fixing d/rules to at least do that is
> also needed.

I gave the following a try, but it makes `make install` fail with an error
suggesting a variable was left empty.

Making install in po
make[3]: Entering directory '/<>/po'
/<>/debian/lftp/usr/share
make[3]: /<>/debian/lftp/usr/share: Permission denied
make[3]: *** [Makefile:304: install-data-yes] Error 127
make[3]: Leaving directory '/<>/po'
...


diff -Nru lftp-4.9.2/debian/rules lftp-4.9.2/debian/rules
--- lftp-4.9.2/debian/rules 2018-09-17 09:33:33.0 +0200
+++ lftp-4.9.2/debian/rules 2024-04-08 16:46:06.0 +0200
@@ -20,6 +20,8 @@
 #configure: configure-stamp
 configure-stamp:
dh_testdir
+   dh_update_autotools_config
+   dh_autoreconf
# Add here commands to configure the package.
CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)" ./configure \
--prefix=/usr \
@@ -56,6 +58,7 @@
[ ! -f Makefile ] || $(MAKE) distclean
rm -f doc/lftp.inf*

+   dh_autoreconf_clean
dh_clean

 install: build

Bug#1068572: tgt: ceph no longer supports 32 bit architectures

[Chris Hofstaedtler]

Control: tags -1 + patch

Hi,

On Sun, Apr 07, 2024 at 01:28:11PM +0200, Sebastian Ramacher wrote:
> Source: tgt
> Version: 1:1.0.85-1.1
> Severity: serious
> Control: block #1065470 by -1
> X-Debbugs-Cc: sramac...@debian.org
> 
> ceph no longer supports 32 bit architectures. Please stop build
> depending on librbd-dev on 32 bit architectures and please also stop
> building tgt-rbd on 32 bit architectures.

I've pushed a potential patch here: 
https://salsa.debian.org/debian/tgt/-/merge_requests/3/diffs

I also propose to NMU within the next few days. Let me know if this
is not desired.

Chris

Bug#1067849: marked as pending in util-linux

[Chris Hofstaedtler]

Control: tag -1 pending

Hello,

Bug #1067849 in util-linux 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/debian/util-linux/-/commit/95eb5918012e2db63a5808db53b1c8e6bada7fba


Add upstream patches to fix CVE-2024-28085

Closes: #1067849


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067849

Bug#1067849: marked as pending in util-linux

[Chris Hofstaedtler]

Control: tag -1 pending

Hello,

Bug #1067849 in util-linux 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/debian/util-linux/-/commit/839ff33b8002189411b679cc9ee99d1a99e099cb


Add upstream patches to fix CVE-2024-28085

Closes: #1067849


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067849

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Chris Lamb]

Alberto Bertogli wrote:

> If you know of a functional official image that I can use to try to
> reproduce the problem, or recently-tested steps I can follow to get
> a working qemu install, please let me know.

Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.

Hm, googling the actual error message a little, I think this might be
a bigger issue... or perhaps more accurately, at least one that has
potentially been also solved elsewhere:

  * Same think in lightdm: <https://bugs.debian.org/1067561>

  * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils
<https://www.spinics.net/lists/linux-media/msg230147.html>

etc.

Does this spark anything worth trying? :-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Chris Lamb]

Alberto Bertogli wrote:

> I'll try to get a debian install to boot for armhf, but it'll take me a 
> bit because it's not straightforward (to put it mildly :).

Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.

> How urgent/important is this issue?

Medium? As it is technically a regression (as in, armhf used to build
before), this was filed with a severity of "serious". What this means
in practical terms is that newer versions of libfiu we upload will not
migrate to the staging area for the next release of Debian.


Regards,

-- 
  ,''`.
     : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Chris Lamb]

Dear Alberto,

Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.


Best wishes,

Chris


- Original message -
From: Sebastian Ramacher 
To: Debian Bug Tracking System 
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: 
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM

Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0

cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. 
-I../../libfiu/ -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1

Bug#1067043: libruby: needs updating for libruby3.1t64

[Chris Hofstaedtler]

Control: tags -1 + pending

* Simon McVittie  [240317 15:57]:
> Package: libruby
> Version: 1:3.1
[..]

> Now that libruby3.1t64 has reached unstable, libruby is uninstallable on
> the architectures affected by the 64-bit time_t transition, 
[..]

> I suspect the only change needed here is to update the libruby metapackage
> so that it depends on libruby3.1t64 instead of libruby3.1. Please could
> someone who knows Ruby check this?

Indeed. I've uploaded ruby-defaults 1:3.1+nmu1 and pushed to salsa.

Chris

PS: @ruby-team: if you disagree / want to take over, please let me know.

Bug#1067043: marked as pending in ruby-defaults

[Chris Hofstaedtler]

Control: tag -1 pending

Hello,

Bug #1067043 in ruby-defaults 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/ruby-team/ruby-defaults/-/commit/0f0bd9f3bc8dde8192350491c14a02cbe058ae3e


libruby: follow libruby3.1 -> libruby3.1t64 rename

Closes: #1067043


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067043

Bug#1065431: lintian: autopkgtests fail due to implicit definition of memcpy

[Chris Hofstaedtler]

Source: lintian
Version: 2.117.0
Severity: serious

dpkg has turned on -Werror=implicit-function-declaration on some
archs (compare #1065371 and the earlier bug requesting this). This
in turn causes lintian's autopkgtests to fail on armel, armhf and
maybe others, like this:

https://ci.debian.net/packages/l/lintian/testing/armel/43531737/

gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/tmp/autopkgtest-lxc.kznc_8xn/downtmp/autopkgtest_tmp/build-and-evaluate-test-packages/packages/checks/libraries/embedded/binaries-embedded-libs/binaries-embedded-libs-1.0=.
 -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -o 
libbz2 libbz2.c
In file included from libpng.c:2:
hardening-trigger.h: In function 'e':
hardening-trigger.h:3:3: error: implicit declaration of function 'memcpy' 
[-Werror=implicit-function-declaration]

Indeed hardening-trigger.h has a call to memcpy but neglects to
include .

Please fix this.

If dpkg reverts turning on the option, this bug obviously becomes
less severe, but its still a bug.

Chris

Bug#1065242: marked as pending in util-linux

[Chris Hofstaedtler]

Control: tag -1 pending

Hello,

Bug #1065242 in util-linux 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/debian/util-linux/-/commit/e1bd9dfee696d58a942c8dbc2c11ab7c5e001e26


Break/Replace libuuid1t64 and provide it versioned

Closes: #1065242


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065242

Bug#1061744: ipyparallel: Patch to fix failing unit test

[Chris Peterson]

Package: ipyparallel
Followup-For: Bug #1061744
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: chris.peter...@canonical.com
Control: tags -1 patch

Dear Maintainer,


In Ubuntu, the attached patch was applied to achieve the following:


  * Fix tests for python3.12 (LP: #2052727)

Python3.12 added checks for mock methods prefixed with `called_` since

  assert mock.called_once()

was a common mistake.

Thanks for considering the patch.

- Chris
diff -Nru 
ipyparallel-7.1.0/debian/patches/python3-assert-called-once-with.patch 
ipyparallel-7.1.0/debian/patches/python3-assert-called-once-with.patch
--- ipyparallel-7.1.0/debian/patches/python3-assert-called-once-with.patch  
1969-12-31 16:00:00.0 -0800
+++ ipyparallel-7.1.0/debian/patches/python3-assert-called-once-with.patch  
2024-02-08 10:44:16.0 -0800
@@ -0,0 +1,24 @@
+Description: Fix bad test assert for python3.12
+ Python3.12 includes a check for the common mistake of:
+assert mocked_object.called_once_with(params)
+ and now raises an attribute error instead of erroneously passing the test.
+ The correct assertion method is `assert_called_once_with`. See:
+ https://github.com/python/cpython/issues/100690
+ for more information.
+Author: Chris Peterson 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ipyparallel/+bug/2052727
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061744
+Last-Update: 2024-02-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/ipyparallel/tests/test_util.py
 b/ipyparallel/tests/test_util.py
+@@ -14,7 +14,7 @@
+ assert util.disambiguate_ip_address('0.0.0.0', socket.gethostname()) == 
localhost()
+ wontresolve = 'this.wontresolve.dns'
+ assert util.disambiguate_ip_address('0.0.0.0', wontresolve) == wontresolve
+-assert warn_mock.called_once_with(
++warn_mock.assert_called_once_with(
+ 'IPython could not determine IPs for {}: '
+ '[Errno -2] Name or service not known'.format(wontresolve),
+ RuntimeWarning,
diff -Nru ipyparallel-7.1.0/debian/patches/series 
ipyparallel-7.1.0/debian/patches/series
--- ipyparallel-7.1.0/debian/patches/series 2023-02-10 00:19:19.0 
-0800
+++ ipyparallel-7.1.0/debian/patches/series 2024-02-08 10:42:39.0 
-0800
@@ -5,3 +5,4 @@
 fix_docs
 fix_setuptools_import.patch
 0007-generate-code-reducer-from-CodeType-signature.patch
+python3-assert-called-once-with.patch

Bug#1063434: 389-ds-base: Build flags for 32bit architectures

[Chris Peterson]

Package: 389-ds-base
Version: 2.4.4+dfsg1-1
Followup-For: Bug #1063434
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: chris.peter...@canonical.com
Control: tags -1 patch

Dear Maintainer,

I see this has been marked for autoremoval, but I have recently
introduced a patch in Ubuntu which fixed builds for armhf. Please see
the attached for a functionally similar patch that should enable builds
on your 32bit architectures (armhf, armel, and i386). I can provide
armhf autopkgtest results shortly.

Thanks,
Chris
diff -Nru 389-ds-base-2.4.4+dfsg1/debian/rules 
389-ds-base-2.4.4+dfsg1/debian/rules
--- 389-ds-base-2.4.4+dfsg1/debian/rules2024-01-08 07:40:49.0 
-0800
+++ 389-ds-base-2.4.4+dfsg1/debian/rules2024-02-08 16:26:51.0 
-0800
@@ -7,6 +7,9 @@
 ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc powerpcspe 
sh4))
   export DEB_LDFLAGS_MAINT_APPEND=-latomic
 endif
+ifneq (,$(filter $(DEB_HOST_ARCH), armhf armel i386))
+ export DEB_CFLAGS_MAINT_APPEND=-D_LARGEFILE64_SOURCE
+endif
 
 REALFILE = \
bin/ds-logpipe.py \

Bug#1059995: Re: Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

* Paul Gevers  [240126 22:25]:
> Hi zeha,
> 
> On 26-01-2024 10:21, Chris Hofstaedtler wrote:
> > I see this "works", but now the tests fail after one try on the
> > problematic worker and then are never retried. Can this please be
> > fixed?
> 
> What do you have in mind? I think you need to wait until issue 166 [1] is
> fixed, which I guess isn't going to happen soon.

166 seems like an option, or auto-retry on a different worker, if
thats possible?

Chris

Bug#1059995: Re: Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

clone 1059995 -1
reopen -1
reassign -1 systemd
found -1 systemd/254.3-1
forwarded -1 https://github.com/systemd/systemd/issues/31037
thanks

Dear systemd Packagers,

Paul Gevers noted that src:pdns's autopkgtests fail every so often
on a large amd64 debci worker and on s390x workers. Apparently a
similar problem can be seen in src:pdns-recursor's debci runs.

As there is no pdns(-recursor) code running at this point, this
seems to be a problem somewhere in the space of systemd <> lxc <>
apparmor <> kernel.

I've opened a bug with systemd upstream, unfortunately with very
little info as I don't know how to provide additional info from
within a debci run. Help with providing additional info would be
very welcome.

Thanks,
Chris

Bug#1059995: Re: Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

Hi Paul,

* Paul Gevers  [240104 18:14]:
> Can you figure out decent numbers for these? Below I printed the output of
> lsipc and AFAICT SHMMAX is already pretty big ;) (and the same on all our
> hosts, which is also true for MSGMAX).
> 
> On the other hand, $(ipcs -a) doesn't show anything on the host, not even if
> I let it run in a while-loop (1 second interval) while I schedule the test
> of pdns. So, could this be a bug in systemd (which you claim below should be
> handeling this) or is this just not really supported in lxc and do you need
> a full VM. Because it works elsewhere, I feel more like a bug, and it would
> not be the first instance where code fails to properly handle 64 cores or
> 256GB or RAM.

Likely, but it is probably in systemd or in lxc or in apparmor or
elsewhere.

> > > > I wouldn't know what to do about this, its not really under the
> > > > control of src:pdns.
> > > 
> > > Well, maybe check for it and fail gracefully?
> > 
> > But how? systemd sets up the IPC namespace.
> 
> exit with 77 when you detect problems and add the skippable restriction.

I see this "works", but now the tests fail after one try on the
problematic worker and then are never retried. Can this please be
fixed?

Thanks,
Chris

Bug#1061369: fsprotect: proposal to remove

[Chris Hofstaedtler]

Source: fsprotect
Severity: serious

fsprotect hasn't made it into bullseye or bookworm. It depends on
the broken aufs package. It hasn't seen a (non-QA) upload since
2017.

With this background I propose removal from unstable.

If you intend to keep fsprotect in Debian, please start maintaining
the package (and aufs!) _now_.

Chris

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

On Fri, Jan 12, 2024 at 08:02:53PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 12-01-2024 12:36, Chris Hofstaedtler wrote:
> > can you confirm two additional things please:
> > 
> > 1) this happens only on the large host?
> 
> https://ci.debian.net/packages/p/pdns/testing/s390x/41650331/
> 
> Seems it happens on our s390x host too (which has 10 debci workers running
> in parallel).
> 
> > 2) this does not or does happen with other packages also requesting
> > the same settings from systemd, e.g. dnsdist or pdns-recursor?
> 
> https://ci.debian.net/packages/d/dnsdist/ -> Page not found.
> 
> pdns-recursor seems to be flaky as well on amd64 and all passing tests were
> on one of the smaller hosts. pdns-recursor passes on s390x though.

For now I've added the exit 77 hack in the pdns tests, but this is
quite unsatisfying.

I've opened an issue with systemd upstream, maybe someone there has
any insight: https://github.com/systemd/systemd/issues/31037

Chris

Bug#999989: planning to NMU poco to orphan it

[Chris Knadle]

Hello Jochen.

What I want to do is orphan the Poco package as an NMU and then do an 
NMU of a new version -- in that order. It seems to be the right thing to 
do for this situation. I had a brief discussion with [debian-qa] and was 
given feedback that the plan seems reasonable:


    https://lists.debian.org/debian-qa/2024/01/msg6.html

The NMU uploads will go to a -delayed queue to allow stopping it or 
increasing delay if there is an objection.


On 1/5/24 07:30, Jochen Sprickerhof wrote:

* Chris Knadle  [2024-01-02 16:53]:
The way to orphan a package is to do an upload and setting the 
maintainer to be . Until that's done the 
package ends up in maintainership limbo. See the bottom of Policy 
3.3, and Developer's Reference section 5.9.4.


Agreed but I think that is something for the Maintainer: to do, who 
seems to be active in Debian, otherwise.


Unfortunately that's not what I see. Feel free to add additional 
information.


The last activity I've been able to find from Krzysztof was an upload of 
clamfs 2020-01-10. For Poco the last activity from him is 2009. The Git 
repository for Poco shows one commit 2009-08-30 and one package upload 
2009-09-01. I find no email in [debian-devel] from him as far back as 
2014. The Debian bug tracker last activity was January 2011 with one 
email in Bug #500134.


Looking at his website, the first thing on the main page mentions 
ClamFS. The clamfs package in Debian has him as the only listed 
maintainer and the package has dropped out of Testing because of the 
Poco library dropped and there as has been no response. Bug #679125 for 
clamfs from 2012 has had no response.


I sent email to the Debian MIA team but have not yet heard back from 
them. Assuming I can get contact with the MIA team and they start their 
process, that will take about six months.


  -- Chris

--

Chris Knadle
chris.kna...@coredump.us
Debian Developer

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

Hi,

can you confirm two additional things please:

1) this happens only on the large host?

2) this does not or does happen with other packages also requesting
the same settings from systemd, e.g. dnsdist or pdns-recursor?

Chris

Bug#1060316: redis: CVE-2023-41056

[Chris Lamb]

Package: redis
Version: 5:6.0.16-1+deb11u2
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for redis.

CVE-2023-41056[0]:
Buffer overflow in certain payloads may lead to remote code execution

Info just unembargoed, so links may time some time to update.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-41056
https://www.cve.org/CVERecord?id=CVE-2023-41056


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1060260: epics-base: FTBFS on amd64, arm64

[Chris Hofstaedtler]

Source: epics-base
Version: 7.0.7+dfsg1-5
Severity: serious
Tag: ftbfs

Your package failed to build from source in binNMUs to move systemd
files. Please see f.e. this build log:
https://buildd.debian.org/status/fetch.php?pkg=epics-base=amd64=7.0.7%2Bdfsg1-5%2Bb1=1704674513=0

Last parts:
Test Summary Report
---
testpvif.t   (Wstat: 0 Tests: 98 Failed: 0)
  TODO passed:   40
testpvalink.t(Wstat: 0 Tests: 20 Failed: 0)
  TODO passed:   9
Files=7, Tests=363,  4 wallclock secs ( 0.08 usr  0.03 sys +  0.26 cusr  0.09 
csys =  0.46 CPU)
Result: PASS
---

...

Tests failed in:
/<>/modules/pvAccess/testApp/O.linux-x86_64
/<>/modules/pvDatabase/test/O.linux-x86_64
make[2]: *** [configure/RULES_TOP:62: runtests] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:31: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Build finished at 2024-01-08T00:41:45Z

Bug#999989: poco 1.1 uses PCRE3, Mumble 1.5 depends on poco

[Chris Knadle]

On 1/5/24 07:30, Jochen Sprickerhof wrote:

* Chris Knadle  [2024-01-02 16:53]:
The way to orphan a package is to do an upload and setting the 
maintainer to be . Until that's done the 
package ends up in maintainership limbo. See the bottom of Policy 
3.3, and Developer's Reference section 5.9.4.


Agreed but I think that is something for the Maintainer: to do, who 
seems to be active in Debian, otherwise.


Normally, yes. But it also doesn't do to have a maintainer that doesn't 
communicate concerning a package; that's the #1 responsibility a package 
maintainer has.


The situation with Poco clearly fits the criteria for when "salvaging" a 
package is needed:


   https://wiki.debian.org/PackageSalvaging

The RC bug for Poco is holding back the following list of source 
packages from migrating: clickhouse, clamfs, gm-assistant, gpsshogi, mumble.



Feel free to ask if you have questions regarding maintaining a library.


The main thing I'd like to understand is how to do coordinate the 
transition (i.e. the release) with the Release Team. I found some hints 
about that here:


https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#lib-trans

--

Chris Knadle
chris.kna...@coredump.us

Bug#877016: Time to drop cpufrequtils?

[Chris Hofstaedtler]

On Sun, Sep 03, 2023 at 08:26:00PM +0200, Moritz Mühlenhoff wrote:
> severity 877016 serious
> thanks
> 
> Am Thu, Sep 28, 2017 at 06:51:30AM -0700 schrieb Mattia Dongili:
> > On Wed, Sep 27, 2017 at 03:16:52PM -0400, Phil Susi wrote:
> > > Package: cpufrequtils
> > > Version: 008-1
> > ...
> > > is the case, should cpufrequtils not be removed now?
> > 
> > Yes, indeed it should. Thanks for nagging.
> 
> Bumping the severity to RC to move forward with this for trixie.
> 

$ dak rm -nR cpufrequtils
Will remove the following packages from unstable:

cpufrequtils |  008-2 | source, amd64, arm64, armel, armhf, i386, mips64el, 
s390x
libcpufreq-dev |  008-2 | amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, s390x
libcpufreq-dev |   008-2+b1 | riscv64
libcpufreq0 |  008-2 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, 
s390x
libcpufreq0 |   008-2+b1 | riscv64

Maintainer: Seunghun Han 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Seems like it's good to go?

C

Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco

[Chris Knadle]

Hello Jochen.

On 1/4/24 02:44, Jochen Sprickerhof wrote:

Hi Chris,

* Chris Knadle  [2024-01-02 03:06]:

Can the poco library be updated? Can I help in some way?


poco is basically orphaned, as I dropped myself from Uploaders in git 
and did not hear from the other maintainers for some time. The best 
way to help is to step up as a maintainer and update it ;).


The way to orphan a package is to do an upload and setting the 
maintainer to be . Until that's done the package 
ends up in maintainership limbo. See the bottom of Policy 3.3, and 
Developer's Reference section 5.9.4.


https://www.debian.org/doc/debian-policy/ch-binary.html#the-maintainer-of-a-package

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package

    https://wiki.debian.org/Orphaning

I may be able to prepare an updated version to upload as an NMU (i.e. it 
would be Debian version 1.13.0-0.1), but I can't take over maintaining 
this package long-term because I don't use it and am not familiar with 
it -- I only maintain a package that has it as a required build 
dependency. I also haven't maintained a library yet, but I've been in 
this situation of needing to upload a newer version of a library before 
so I might be able to figure out what's required to prepare an upload. 
It would be interesting to upload a new version as an NMU with the 
maintainer marked as  but strangely that seems 
to be what's called for here.


Unless the Poco library can be updated the only way to save Mumble 
will be to introduce an epoch in the package version to upload the 
now well outdated mumble 1.3.4 again which upstream cannot support 
anymore.


Nit: please don't use epochs for that, also see Policy 5.6.12.1.


Hah ... okay so if absolutely required I could upload mumble 
"1.5.517+really1.3.4-2". As crazy a version scheme as that is it beats 
having to introduce an epoch that I'd have to live with forever, so I'm 
glad to know that trick. Thanks.


--
Chris Knadle
chris.kna...@coredump.us

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

On Thu, Jan 04, 2024 at 03:37:21PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 04-01-2024 15:08, Chris Hofstaedtler wrote:
> > It would seem that the host runs out of IPC space?
> 
> What is IPC space?

https://manpages.debian.org/bookworm/manpages/sysvipc.7.en.html
https://manpages.debian.org/bookworm/manpages/ipc_namespaces.7.en.html

> And when does a host run out of it? As I said, this is
> one of our most powerful hosts, so I would expect it to run out of things
> last.
> 
> > Does it run more tests in parallel than other workers, or so?
> 
> Yes, this host (like most of our host, but a bit more) runs multiple lxc
> based debci workers.

My guess: the default limits are static, and if LXC doesn't do
anything special, the limits are probably shared with the whole
host.
kernel.shmmax, kernel.msgmax are I think the limits (but I'm not
entirely sure).

> > I wouldn't know what to do about this, its not really under the
> > control of src:pdns.
> 
> Well, maybe check for it and fail gracefully?

But how? systemd sets up the IPC namespace.

> Or, since a couple of days, if
> qemu VM don't run out of IPC space, we could run them in qemu always.

I imagine a fully separated VM would not run out of IPC space,
indeed.

Chris

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Chris Hofstaedtler]

On Thu, Jan 04, 2024 at 02:42:59PM +0100, Paul Gevers wrote:
> 269s Dec 25 16:13:20 ci-359-77591125 (s_server)[3766]: pdns.service: Failed
> to set up IPC namespacing: Resource temporarily unavailable
> 269s Dec 25 16:13:20 ci-359-77591125 (s_server)[3766]: pdns.service: Failed
> at step NAMESPACE spawning /usr/sbin/pdns_server: Resource temporarily
> unavailable

It would seem that the host runs out of IPC space?
Does it run more tests in parallel than other workers, or so?

I wouldn't know what to do about this, its not really under the
control of src:pdns.

Chris

Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco

[Chris Knadle]

All recent versions of Mumble now require Poco to build and will not 
build without it.


Unless the Poco library can be updated the only way to save Mumble will 
be to introduce an epoch in the package version to upload the now well 
outdated mumble 1.3.4 again which upstream cannot support anymore.


Can the poco library be updated? Can I help in some way?

--
Chris Knadle
chris.kna...@coredump.us

Bug#1058828: thunderbolt-tools: diff for NMU version 0.9.3-6.1

[Chris Hofstaedtler]

Control: tags 1058828 + pending


Dear maintainer,

I've prepared an NMU for thunderbolt-tools (versioned as 0.9.3-6.1) and
uploaded it to DELAYED/7. Please feel free to upload yourself in the
meantime.

Chris
diff -Nru thunderbolt-tools-0.9.3/debian/changelog thunderbolt-tools-0.9.3/debian/changelog
--- thunderbolt-tools-0.9.3/debian/changelog	2022-12-14 13:42:55.0 +0100
+++ thunderbolt-tools-0.9.3/debian/changelog	2023-12-24 14:13:22.0 +0100
@@ -1,3 +1,10 @@
+thunderbolt-tools (0.9.3-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Skip duplicate installation of tbtacl-write. (Closes: #1058828)
+
+ -- Chris Hofstaedtler   Sun, 24 Dec 2023 14:13:22 +0100
+
 thunderbolt-tools (0.9.3-6) unstable; urgency=medium
 
   * Roll in all fixes since 0.9.3, project is now in maintainence
diff -Nru thunderbolt-tools-0.9.3/debian/install thunderbolt-tools-0.9.3/debian/install
--- thunderbolt-tools-0.9.3/debian/install	2018-04-08 16:43:12.0 +0200
+++ thunderbolt-tools-0.9.3/debian/install	2023-12-24 14:13:14.0 +0100
@@ -1,2 +1 @@
-build_userspace/tbtacl/tbtacl-write lib/udev/
 build_userspace/tbtadm/tbtadm usr/bin

Bug#1057240: alsa-utils: diff for NMU version 1.2.10-1.1

[Chris Hofstaedtler]

Control: tags 1057240 + patch
Control: tags 1057240 + pending


Dear maintainer,

I've prepared an NMU for alsa-utils (versioned as 1.2.10-1.1) and
uploaded it to DELAYED/7.
The NMU/patch also fixes the install path for systemd units and
moves the d-i script.

Chris

diff -Nru alsa-utils-1.2.10/debian/alsa-utils-udeb.install alsa-utils-1.2.10/debian/alsa-utils-udeb.install
--- alsa-utils-1.2.10/debian/alsa-utils-udeb.install	2019-10-30 11:35:09.0 +0100
+++ alsa-utils-1.2.10/debian/alsa-utils-udeb.install	2023-12-24 12:42:40.0 +0100
@@ -1,4 +1,4 @@
-debian/S37alsa-utils-udeb lib/debian-installer-startup.d
+debian/S37alsa-utils-udeb usr/lib/debian-installer-startup.d
 debian/utils.sh /usr/share/alsa
 usr/bin/amixer
 usr/sbin/alsactl
diff -Nru alsa-utils-1.2.10/debian/changelog alsa-utils-1.2.10/debian/changelog
--- alsa-utils-1.2.10/debian/changelog	2023-09-13 15:45:59.0 +0200
+++ alsa-utils-1.2.10/debian/changelog	2023-12-24 12:42:40.0 +0100
@@ -1,3 +1,14 @@
+alsa-utils (1.2.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use udevdir from udev.pc to determine udev rules install path.
+(Closes: #1057240)
+  * Use systemdsystemunitdir from systemd.pc to determine systemd unit install
+path.
+  * udeb: move debian-installer-startup.d/S37alsa-utils-udeb into /usr/lib.
+
+ -- Chris Hofstaedtler   Sun, 24 Dec 2023 12:42:40 +0100
+
 alsa-utils (1.2.10-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru alsa-utils-1.2.10/debian/control alsa-utils-1.2.10/debian/control
--- alsa-utils-1.2.10/debian/control	2023-06-13 13:42:46.0 +0200
+++ alsa-utils-1.2.10/debian/control	2023-12-24 12:40:58.0 +0100
@@ -14,6 +14,7 @@
pkg-config,
python3-docutils,
systemd,
+   systemd-dev,
xmlto
 Standards-Version: 4.6.2
 Homepage: https://www.alsa-project.org/
diff -Nru alsa-utils-1.2.10/debian/install alsa-utils-1.2.10/debian/install
--- alsa-utils-1.2.10/debian/install	2022-07-06 03:17:35.0 +0200
+++ alsa-utils-1.2.10/debian/install	2023-12-24 12:42:40.0 +0100
@@ -1,6 +1,6 @@
 debian/utils.sh /usr/share/alsa
-lib/systemd
-lib/udev
+${env:deb_systemdsystemunitdir}
+${env:deb_udevdir}/rules.d
 usr/bin
 usr/lib/*/alsa-topology/*.so
 usr/sbin
diff -Nru alsa-utils-1.2.10/debian/links alsa-utils-1.2.10/debian/links
--- alsa-utils-1.2.10/debian/links	2019-10-30 11:35:09.0 +0100
+++ alsa-utils-1.2.10/debian/links	2023-12-24 12:42:40.0 +0100
@@ -1,3 +1,3 @@
-dev/null			lib/systemd/system/alsa-utils.service
+dev/null			${env:deb_systemdsystemunitdir}/alsa-utils.service
 usr/bin/aplay			usr/bin/arecord
 usr/share/man/man1/aplay.1.gz	usr/share/man/man1/arecord.1.gz
diff -Nru alsa-utils-1.2.10/debian/rules alsa-utils-1.2.10/debian/rules
--- alsa-utils-1.2.10/debian/rules	2023-09-13 15:45:07.0 +0200
+++ alsa-utils-1.2.10/debian/rules	2023-12-24 12:41:31.0 +0100
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+export deb_systemdsystemunitdir = $(shell pkg-config --variable=systemdsystemunitdir systemd | sed s,^/,,)
 
 %:
 	dh $@
@@ -10,7 +12,7 @@
 			--with-asound-state-dir=/var/lib/alsa \
 			--with-alsactl-home-dir=/run/alsa \
 			--with-alsactl-runtime-dir=/run/alsa/runtime \
-			--with-systemdsystemunitdir=/lib/systemd/system \
+			--with-systemdsystemunitdir=/$(deb_systemdsystemunitdir) \
 			--disable-alsaconf
 
 override_dh_auto_test:

Bug#1057231: udev.pc was changed

[Chris Hofstaedtler]

severity 1057231 serious
severity 1057240 serious
severity 1057245 serious
severity 1058828 serious
thanks

udev.pc was changed today. Your package will now either FTBFS or
introduce a policy violation on a rebuild.

Chris

Bug#1058787: closed by Debian FTP Masters (reply to bott...@debian.org (A. Maitland Bottoms)) (Bug#1058787: fixed in libmirisdr 2.0.0-3)

[Chris Hofstaedtler]

On Sat, Dec 16, 2023 at 02:51:03PM +, Debian Bug Tracking System wrote:
>* upload to experimental for dumat tool
>* Move udev files from /lib to /usr/lib, including protective diversion
>  against Multi-Arch: same file loss scenario (DEP17 P7 M10).
>  (Closes: #1058787)

Please go ahead with an upload to unstable.

Chris

Bug#1058767: netplug: unmaintained

[Chris Hofstaedtler]

Hi,

* Pali Rohár  [231216 11:35]:
> On Friday 15 December 2023 21:56:01 Chris Hofstaedtler wrote:
> Hello, I talked with the author of the netplug (Bryan O'Sullivan) and I
> got permission to continue working on this project. I can continue
> maintaining this package on Debian, so please let me know what is needed
> to fix for preventing its removal. Thanks.

Well, the immediate thing to do is: close this bug.

But the more important thing: actually maintain the package,
including ongoing quality work in the packaging, responding
to/fixing bugs, etc.

If I were in your shoes, I'd make sure to know if/where the users of
this package are. If all users are using vyos, then maybe its better
maintained as part of vyos, and removed from Debian.
Debian has a number of other things that can react to network
events, some of those have active upstreams ...

Best,
Chris

Bug#1054485: postfix: diff for NMU version 3.8.2-1.1

[Chris Hofstaedtler]

Control: tags 1054485 + patch
Control: tags 1054485 + pending

Dear maintainer,

I've prepared an NMU for postfix (versioned as 3.8.2-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer. Better, upload yourself in the meantime.

Best,
Chris

diff -Nru postfix-3.8.2/debian/changelog postfix-3.8.2/debian/changelog
--- postfix-3.8.2/debian/changelog	2023-09-14 20:08:10.0 +0200
+++ postfix-3.8.2/debian/changelog	2023-12-19 01:24:10.0 +0100
@@ -1,3 +1,13 @@
+postfix (3.8.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [Helmut Grohne]
+
+  * Install units using dh_installsystemd only. (Closes: #1054485)
+
+ -- Chris Hofstaedtler   Tue, 19 Dec 2023 01:24:10 +0100
+
 postfix (3.8.2-1) unstable; urgency=medium
 
   [Scott Kitterman]
diff -Nru postfix-3.8.2/debian/postfix.dirs postfix-3.8.2/debian/postfix.dirs
--- postfix-3.8.2/debian/postfix.dirs	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/postfix.dirs	2023-12-19 01:23:16.0 +0100
@@ -34,5 +34,4 @@
 var/spool/postfix/usr/lib/sasl2
 var/log
 var/lib/postfix
-lib/systemd/system
 lib/systemd/system-generators
diff -Nru postfix-3.8.2/debian/postfix.postfix-resolvconf.path postfix-3.8.2/debian/postfix.postfix-resolvconf.path
--- postfix-3.8.2/debian/postfix.postfix-resolvconf.path	1970-01-01 01:00:00.0 +0100
+++ postfix-3.8.2/debian/postfix.postfix-resolvconf.path	2023-12-19 01:23:16.0 +0100
@@ -0,0 +1,11 @@
+[Unit]
+Description=Watch for resolv.conf updates and restart postfix
+ConditionPathExists=/etc/resolv.conf
+
+[Path]
+PathChanged=/etc/resolv.conf
+Unit=postfix-resolvconf.service
+
+[Install]
+WantedBy=multi-user.target
+
diff -Nru postfix-3.8.2/debian/postfix.postfix-resolvconf.service postfix-3.8.2/debian/postfix.postfix-resolvconf.service
--- postfix-3.8.2/debian/postfix.postfix-resolvconf.service	1970-01-01 01:00:00.0 +0100
+++ postfix-3.8.2/debian/postfix.postfix-resolvconf.service	2023-12-19 01:23:16.0 +0100
@@ -0,0 +1,9 @@
+[Unit]
+Description=Copies updated resolv.conf to postfix chroot and restarts postfix.
+
+[Service]
+Type=simple
+ExecStart=/etc/resolvconf/update-libc.d/postfix
+
+[Install]
+WantedBy=multi-user.target
diff -Nru postfix-3.8.2/debian/postfix-resolvconf.path postfix-3.8.2/debian/postfix-resolvconf.path
--- postfix-3.8.2/debian/postfix-resolvconf.path	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/postfix-resolvconf.path	1970-01-01 01:00:00.0 +0100
@@ -1,11 +0,0 @@
-[Unit]
-Description=Watch for resolv.conf updates and restart postfix
-ConditionPathExists=/etc/resolv.conf
-
-[Path]
-PathChanged=/etc/resolv.conf
-Unit=postfix-resolvconf.service
-
-[Install]
-WantedBy=multi-user.target
-
diff -Nru postfix-3.8.2/debian/postfix-resolvconf.service postfix-3.8.2/debian/postfix-resolvconf.service
--- postfix-3.8.2/debian/postfix-resolvconf.service	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/postfix-resolvconf.service	1970-01-01 01:00:00.0 +0100
@@ -1,9 +0,0 @@
-[Unit]
-Description=Copies updated resolv.conf to postfix chroot and restarts postfix.
-
-[Service]
-Type=simple
-ExecStart=/etc/resolvconf/update-libc.d/postfix
-
-[Install]
-WantedBy=multi-user.target
diff -Nru postfix-3.8.2/debian/rules postfix-3.8.2/debian/rules
--- postfix-3.8.2/debian/rules	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/rules	2023-12-19 01:23:16.0 +0100
@@ -193,8 +193,6 @@
 
 	install debian/configure-instance.sh $(libdir)
 	install debian/postfix-instance-generator ${base}/lib/systemd/system-generators/
-	install -m 644 debian/postfix@.service ${base}/lib/systemd/system/
-	install -m 644 debian/postfix-resolvconf.* ${base}/lib/systemd/system/
 	install debian/ip-up.d ${base}/etc/ppp/ip-up.d/postfix
 	install debian/ip-down.d ${base}/etc/ppp/ip-down.d/postfix
 	install debian/ip-up.d ${base}/etc/network/if-up.d/postfix
@@ -209,8 +207,7 @@
 	fi
 
 override_dh_installsystemd:
-	dh_installsystemd -p postfix --no-enable --no-start postfix-resolvconf.path
-	dh_installsystemd -p postfix --no-enable --no-start postfix-resolvconf.service
+	dh_installsystemd -p postfix --no-enable --no-start --name postfix-resolvconf
 	dh_installsystemd -p postfix --no-restart-after-upgrade postfix.service
 
 execute_before_dh_gencontrol:

Bug#1058921: ceph: loss of ceph-volume@.service

[Chris Hofstaedtler]

Source: ceph
Version: 18.2.0+ds-1
Severity: serious
User: helm...@debian.org
Usertags: dep17p1
X-Debbugs-Cc: helm...@debian.org

Hi,

the file /lib/systemd/system/ceph-volume@.service was previously
part of the ceph-osd binary package, but has now moved to
ceph-volume. However, this file will also need to move from /lib to
/usr/lib during trixie.

This combination will become a DEP17 P1 problem: "File loss during
canonicalized file move", and is currently prohibited by the file
move moratorium. As an effect, it is likely the ceph-volume@.service
will be lost in some percentage of upgrades.

There are potential mitigations if this file move needs to happen,
but they are hard to understand and therefore even harder to test.
It would be easier for everyone, if this file move could be avoided
altogether.

I'm therefore asking you to consider not moving the file between
binary packages.

If you come to the conclusion that the file must be moved, please
reply on this bug report and keep the problem confined to
experimental for now.


Thanks,
Chris

Bug#1058787: libmirisdr4: introduces new file into /lib while being m-a:same

[Chris Hofstaedtler]

Package: libmirisdr4
Version: 2.0.0-1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p7
X-Debbugs-Cc: helm...@debian.org

Hi,

your package libmirisdr4 is marked Multi-Arch: Same and introduced a
new file into /lib.

I'm filing this bug now so your package will not hit testing.

I see two options forward:

1) introduce the DEP17 P7 M10 mitigations again and move the file to
/usr/lib.

2) just move the file to /usr/lib, possibly triggering the file loss
for users in unstable.
If you want to go with this option, you can do that now; it's your
decision if this is appropriate for your users in unstable.

For the mitigations option, someone will have to find time to write
and test a patch.


**In any case** _please_ upload to _experimental_ first and give the
dumat tool [1] time to check your package.


Chris


[1] https://wiki.debian.org/UsrMerge

Bug#1058767: netplug: unmaintained

[Chris Hofstaedtler]

Source: netplug
Version: 1.2.9.2-3.2
Severity: serious

I'm filing this to get netplug removed from testing, with the goal
of removing it from unstable later, and before that happens, anyone
who wants to actually maintain this package can speak up.

As demonstrated today, having packages in stable that end up used in
downstream distros, and at the same time being completely
unmaintained in Debian for ~7 years is bad for everybody.

If you like to keep netplug in Debian, please start maintaining it
and then close this bug.

Otherwise I'll also file an RM bug for unstable later in this
development cycle.

Chris

Bug#1058749: scanbd: fails to upgrade from bookworm: mv: not replacing '/etc/scanbd/dll.conf'

[Chris Hofstaedtler]

Control: found -1 scanbd/1.5.1-6+b1
Control: block -1 by 1058752

Hi Andreas,

I'm unsure what to do here. This problem is triggered by a behaviour
change in coreutils.

On Fri, Dec 15, 2023 at 03:17:18PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'bookworm'.
> It installed fine in 'bookworm', then the upgrade to 'sid' fails.
[..]
>   Setting up scanbd (1.5.1-7) ...
>   mv: not replacing '/etc/scanbd/dll.conf'

With coreutils from unstable, scanbd from bookworm also fails to
install:

| Preparing to unpack .../scanbd_1.5.1-6+b1_arm64.deb ...
| Unpacking scanbd (1.5.1-6+b1) over (1.5.1-6+b1) ...
| Setting up scanbd (1.5.1-6+b1) ...
| mv: not replacing '/etc/scanbd/dll.conf'
| dpkg: error processing package scanbd (--configure):
|  installed scanbd package post-installation script subprocess returned error 
exit status 1
| Processing triggers for dbus (1.14.10-3) ...
| Errors were encountered while processing:
|  scanbd
| E: Sub-process /usr/bin/dpkg returned an error code (1)

I've marked this bug as found in the old version for now, and have
also opened #1058752 (but also see #1058630).
scanbd is not the only package affected by the coreutils change.

Chris

Bug#1058752: coreutils: cp/mv changed return code in incompatible way

[Chris Hofstaedtler]

Package: coreutils
Version: 9.4-1
Severity: serious
Tags: upstream
Control: affects -1 initramfs-tools scanbd

Hi,

cp and mv -n changed their behaviour with regard to their exit code
when doing nothing, and also now write to stderr.

This causes a few problems in existing packages:

1) initramfs-tools autopkgtests fail, and it is unclear if
initramfs images with busybox actually work. Compare #1058630 and
[1]

2) scanbd now fails to install, see #1058749

And maybe other, so far unreported problems.


The upstream bug report appears to be stalled:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572

What will be done about this?


Should all affected packages (which are these?) workaround the
fallout?


Chris



[1] https://ci.debian.net/packages/i/initramfs-tools/testing/amd64/41037580/

Bug#1057421: sysstat: diff for NMU version 12.6.1-1.1

[Chris Hofstaedtler]

Control: tags 1057421 + pending


Dear maintainer,

I've prepared an NMU for sysstat (versioned as 12.6.1-1.1) and
uploaded it to DELAYED/7. Please feel free to upload yourself in the
meantime.

I'll also push a branch to salsa for the changelog entry.

Chris

diff -Nru sysstat-12.6.1/debian/changelog sysstat-12.6.1/debian/changelog
--- sysstat-12.6.1/debian/changelog	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/changelog	2023-12-15 01:23:13.0 +0100
@@ -1,3 +1,11 @@
+sysstat (12.6.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS after systemdsystemunitdir changed in systemd.pc
+(Closes: #1057421)
+
+ -- Chris Hofstaedtler   Fri, 15 Dec 2023 01:23:13 +0100
+
 sysstat (12.6.1-1) unstable; urgency=medium
 
   * New upstream stable version: fixes size_t overflow in sa_common.c
diff -Nru sysstat-12.6.1/debian/control sysstat-12.6.1/debian/control
--- sysstat-12.6.1/debian/control	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/control	2023-12-15 01:23:13.0 +0100
@@ -6,7 +6,8 @@
gettext,
libsensors-dev,
pkg-config,
-   systemd
+   systemd,
+   systemd-dev
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: http://sebastien.godard.pagesperso-orange.fr/
diff -Nru sysstat-12.6.1/debian/rules sysstat-12.6.1/debian/rules
--- sysstat-12.6.1/debian/rules	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/rules	2023-12-15 01:23:13.0 +0100
@@ -19,6 +19,8 @@
 
 DFLAGS :=
 
+export deb_systemdsystemunitdir=$(shell pkgconf --variable=systemdsystemunitdir systemd | sed s,^/,,)
+
 %:
 	dh ${@}
 
diff -Nru sysstat-12.6.1/debian/sysstat.install sysstat-12.6.1/debian/sysstat.install
--- sysstat-12.6.1/debian/sysstat.install	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/sysstat.install	2023-12-15 01:23:13.0 +0100
@@ -1,5 +1,5 @@
 debian/debian-sa1 usr/lib/sysstat
 debian/tmp/etc/
-debian/tmp/lib/systemd/
+debian/tmp/${env:deb_systemdsystemunitdir}
 debian/tmp/usr/
 debian/tmp/var/

Bug#1057220: Looks like the systemctl links are gone but not the pm-utils ones

[Chris Hofstaedtler]

Hi everyone!

On Tue, Dec 12, 2023 at 03:08:49PM +0100, Helmut Grohne wrote:
[..
> Almost two weeks later, I'm back with what I hope is a solution.
[..]
> At the time of this writing, my preferred solution is restoring the lost
> files in postinst. Fortunately, they are all symlinks in the case of
> systemd-sysv, so restoring them is a rather simple matter. And this is
> what the attached systemd patch does.
[..]
> This is not the option I'm going for now. Rather, given that systemd can
> paper over the loss we can make the loss very unlikely by having
> molly-guard not declare Breaks against systemd-sysv. As a result, apt no
> longer sees a mutual conflict and no longer schedules temporary removal.
> Thus, the loss scenario (usually) does not happen (though systemd-sysv
> still mitigates it).

I think this is a good plan, even though this means quite a few
packages will have to do this in their maintainer scripts. I'll note
that all affected packages will have to cooperate.

[..]
> /usr/sbin/halt -> /usr/sbin/halt.no-molly-guard

I think this is a bit of a problem. My understanding of
molly-guard's primary feature is to hide dangerous programs from
$PATH, to avoid execution by overworked (or otherwise unattentive)
operators.

Keeping the dangerous programs in $PATH, under a similar-enough name
that TAB-completion works, might be a serious downgrade in
functionality to molly-guard's audience.

I would suspect for other packages, like progress-linux-container,
it might be worse, if they expect to completely disable these
programs.

As said above, this is all speculation, but I want to point this
out, and maybe Francois can comment if this is acceptable for
molly-guard?

[..]
> So now I am attaching the result of my work. I invite people to review
> it (even though I understand that this is a complex matter). In
> particular, I am also interested in what kind of tests I should be
> performing in addition.

I've asked you before on IRC about the test cases I thought to be
the "interesting" ones and you pointed out they are already
covered by the attached testcases and they have a success outcome.

Chris

Bug#1057850: libnss-db: Uses db5.3, no replacement in sight

[Chris Hofstaedtler]

Source: libnss-db
Version: 2.2.3pre1-8
Severity: serious
Tags: upstream

libnss-db is the so-called "Berkeley DB NSS". It last saw upstream
changes in 2001, and obviously depends on Berkeley DB 5.3. We want to
get rid of Berkeley DB, and now is as good a time as any other to stop
shipping libnss-db.

Users can probably use any other NSS module that can use some form of
database backend.

After a while I intend to file an RM bug, too.

Chris

Bug#1056980: [devuan-dev] bug#813: Reopen 1056980

[Chris Hofstaedtler]

Control: severity -1 normal
Control: tags -1 = wontfix

* Svante Signell  [231208 19:38]:
> On Fri, 2023-12-08 at 16:15 +0100, Svante Signell wrote:
> > reopen 1056980
> > severity 1056980 serious
> > tags 1056980 patch
> > thanks
> 
> Sorry, forgot the patch!
> 

> --- a/debian/netcat-traditional.postinst  2023-11-27 03:20:27.0 
> +0100
> +++ b/debian/netcat-traditional.postinst  2023-12-04 15:11:31.0 
> +0100
> @@ -4,8 +4,8 @@
>  
>  if [ "$1" = "configure" ]; then
>  update-alternatives \
> ---install /bin/nc nc /bin/nc.traditional 10 \
> ---slave /bin/netcat netcat /bin/nc.traditional \
> +--install /usr/bin/nc nc /usr/bin/nc.traditional 10 \
> +--slave /usr/bin/netcat netcat /usr/bin/nc.traditional \
>  --slave /usr/share/man/man1/nc.1.gz nc.1.gz \
>  /usr/share/man/man1/nc.traditional.1.gz \
>  --slave /usr/share/man/man1/netcat.1.gz netcat.1.gz \

This is absolutely wrong on Debian, and must not be uploaded to
Debian.

If you want to keep it as a Devuan delta, go ahead.

Chris

Bug#984100: libdjconsole: diff for NMU version 0.1.3-3.1

[Chris Hofstaedtler]

Control: tags 984100 + patch
Control: tags 984100 + pending

Dear maintainer,

I've prepared an NMU for libdjconsole (versioned as 0.1.3-3.1) and
uploaded it to DELAYED/7.
Feel free to upload a fix in the meantime or cancel the NMU.

Best,
Chris
diff -Nru libdjconsole-0.1.3/debian/changelog libdjconsole-0.1.3/debian/changelog
--- libdjconsole-0.1.3/debian/changelog	2015-12-16 17:14:43.0 +0100
+++ libdjconsole-0.1.3/debian/changelog	2023-12-08 17:37:04.0 +0100
@@ -1,3 +1,13 @@
+libdjconsole (0.1.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use pkg-config to place udev rules file.
+  * Fix FTBFS by correcting usb_open retval check (Closes: #984100)
+  * Bump to dh compat level 13, away from obsolete level 9.
+Record not installed files in debian/not-installed.
+
+ -- Chris Hofstaedtler   Fri, 08 Dec 2023 17:37:04 +0100
+
 libdjconsole (0.1.3-3) unstable; urgency=medium
 
   * Don't use /usr/share/doc/ symlinks anymore to keep things simple and
diff -Nru libdjconsole-0.1.3/debian/compat libdjconsole-0.1.3/debian/compat
--- libdjconsole-0.1.3/debian/compat	2015-08-28 16:32:22.0 +0200
+++ libdjconsole-0.1.3/debian/compat	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru libdjconsole-0.1.3/debian/control libdjconsole-0.1.3/debian/control
--- libdjconsole-0.1.3/debian/control	2015-08-28 16:32:22.0 +0200
+++ libdjconsole-0.1.3/debian/control	2023-12-08 17:37:04.0 +0100
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Adrien Cunin 
-Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, libusb-dev
+Build-Depends: debhelper-compat (= 13), pkgconf, libusb-dev, systemd-dev
 Standards-Version: 3.9.6
 Homepage: http://djplay.sourceforge.net/
 
diff -Nru libdjconsole-0.1.3/debian/libdjconsole-data.install libdjconsole-0.1.3/debian/libdjconsole-data.install
--- libdjconsole-0.1.3/debian/libdjconsole-data.install	2015-08-28 16:32:22.0 +0200
+++ libdjconsole-0.1.3/debian/libdjconsole-data.install	2023-12-08 17:37:04.0 +0100
@@ -1,2 +1,2 @@
 debian/tmp/usr/share/
-debian/tmp/lib/udev/rules.d/
+debian/tmp/${env:deb_udevdir}
diff -Nru libdjconsole-0.1.3/debian/not-installed libdjconsole-0.1.3/debian/not-installed
--- libdjconsole-0.1.3/debian/not-installed	1970-01-01 01:00:00.0 +0100
+++ libdjconsole-0.1.3/debian/not-installed	2023-12-08 17:37:04.0 +0100
@@ -0,0 +1 @@
+usr/lib/*/libdjconsole.la
diff -Nru libdjconsole-0.1.3/debian/patches/01_install_udev_rules_lib.patch libdjconsole-0.1.3/debian/patches/01_install_udev_rules_lib.patch
--- libdjconsole-0.1.3/debian/patches/01_install_udev_rules_lib.patch	2015-08-28 16:32:22.0 +0200
+++ libdjconsole-0.1.3/debian/patches/01_install_udev_rules_lib.patch	2023-12-08 17:37:04.0 +0100
@@ -7,7 +7,7 @@
  AUTOMAKE_OPTIONS = gnu
  pkgconfigdir=$(libdir)/pkgconfig
 -rulesdir=$(sysconfdir)/udev/rules.d
-+rulesdir=/lib/udev/rules.d
++rulesdir=$(shell pkg-config --variable=udevdir udev)/rules.d
  
  lib_LTLIBRARIES = libdjconsole.la
  
@@ -18,7 +18,7 @@
  AUTOMAKE_OPTIONS = gnu
  pkgconfigdir = $(libdir)/pkgconfig
 -rulesdir = $(sysconfdir)/udev/rules.d
-+rulesdir = /lib/udev/rules.d
++rulesdir=$(shell pkg-config --variable=udevdir udev)/rules.d
  
  lib_LTLIBRARIES = libdjconsole.la
  
diff -Nru libdjconsole-0.1.3/debian/patches/04_usb_open_retval.patch libdjconsole-0.1.3/debian/patches/04_usb_open_retval.patch
--- libdjconsole-0.1.3/debian/patches/04_usb_open_retval.patch	1970-01-01 01:00:00.0 +0100
+++ libdjconsole-0.1.3/debian/patches/04_usb_open_retval.patch	2023-12-08 17:37:04.0 +0100
@@ -0,0 +1,22 @@
+Index: libdjconsole-0.1.3/djconsole.cpp
+===
+--- libdjconsole-0.1.3.orig/djconsole.cpp
 libdjconsole-0.1.3/djconsole.cpp
+@@ -107,7 +107,7 @@ DJConsole::DJConsole(bool load_data)
+ 
+ 	hdev1=usb_open(dev);
+ 
+-	if(hdev1 < 0)
++	if(hdev1 == nullptr)
+ 	{
+ 		printf("Error opening DJ Console device, check permissions\n");
+ 		return;
+@@ -115,7 +115,7 @@ DJConsole::DJConsole(bool load_data)
+ 
+ 	hdev2=usb_open(dev);
+ 
+-	if(hdev2 < 0)
++	if(hdev2 == nullptr)
+ 	{
+ 		printf("Error opening DJ Console device, check permissions\n");
+ 		return;
diff -Nru libdjconsole-0.1.3/debian/patches/series libdjconsole-0.1.3/debian/patches/series
--- libdjconsole-0.1.3/debian/patches/series	2015-08-28 16:32:22.0 +0200
+++ libdjconsole-0.1.3/debian/patches/series	2023-12-08 17:37:04.0 +0100
@@ -1,3 +1,4 @@
 01_install_udev_rules_lib.patch
 02_udev_rules_sysfs_attr.patch
 03_update_pc_file.patch
+04_usb_open_retval.patch
diff -Nru libdjconsole-0.1.3/debian/rules libdjconsole-0.1.3/debian/rules
--- libdjconsole-0.1.3/debian/rules	2015-12-16 17:14:43.0 +0100
+++ libdjconsole-0.1.3/debian/rules	2023-12-08 17:37:04.0 +0100
@@ -1,3 +1,5 @@
 #!/usr/bin/make -f
+export deb_udevdir = $(shell pkg-config --variable=udevdir 

Bug#1057421: sysstat: FTBFS: dh_install: warning: Cannot find (any matches for) "debian/tmp/lib/systemd/" (tried in ., debian/tmp)

[Chris Hofstaedtler]

Control: tags -1 + patch

* Chris Hofstaedtler :
> systemd.pc changed systemd_system_unit_dir to point to /usr. As a
> consequence, your package now FTBFS in unstable.

Please find a patch fixing this attached. It should also work if
sysstat is backported without additional changes.

Best,
Chris
diff -Nru sysstat-12.6.1/debian/changelog sysstat-12.6.1/debian/changelog
--- sysstat-12.6.1/debian/changelog	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/changelog	2023-12-07 21:50:19.0 +0100
@@ -1,3 +1,11 @@
+sysstat (12.6.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FBTS when systemdsystemunitdir changes in systemd.pc. (Closes:
+#1057421)
+
+ -- Chris Hofstaedtler   Thu, 07 Dec 2023 21:50:19 +0100
+
 sysstat (12.6.1-1) unstable; urgency=medium
 
   * New upstream stable version: fixes size_t overflow in sa_common.c
diff -Nru sysstat-12.6.1/debian/control sysstat-12.6.1/debian/control
--- sysstat-12.6.1/debian/control	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/control	2023-12-07 21:48:26.0 +0100
@@ -6,7 +6,8 @@
gettext,
libsensors-dev,
pkg-config,
-   systemd
+   systemd,
+   systemd-dev
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: http://sebastien.godard.pagesperso-orange.fr/
diff -Nru sysstat-12.6.1/debian/rules sysstat-12.6.1/debian/rules
--- sysstat-12.6.1/debian/rules	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/rules	2023-12-07 21:50:09.0 +0100
@@ -19,6 +19,8 @@
 
 DFLAGS :=
 
+export deb_systemdsystemunitdir=$(shell pkgconf --variable=systemdsystemunitdir systemd | sed s,^/,,)
+
 %:
 	dh ${@}
 
diff -Nru sysstat-12.6.1/debian/sysstat.install sysstat-12.6.1/debian/sysstat.install
--- sysstat-12.6.1/debian/sysstat.install	2022-12-04 22:23:25.0 +0100
+++ sysstat-12.6.1/debian/sysstat.install	2023-12-07 21:50:17.0 +0100
@@ -1,5 +1,5 @@
 debian/debian-sa1 usr/lib/sysstat
 debian/tmp/etc/
-debian/tmp/lib/systemd/
+debian/tmp/${env:deb_systemdsystemunitdir}
 debian/tmp/usr/
 debian/tmp/var/

Bug#1057617: tracker-miners: FTBFS: tests failed

[Chris Hofstaedtler]

Source: tracker-miners
Version: 3.4.6-1
Severity: serious
Tags: ftbfs

Dear Maintainer,

your package FTBFS in unstable, in my own test rebuild as well as on the Debian 
buildds.

Build log snippet, hopefully relevant:
   Traceback (most recent call last):
   File "/<>/tests/functional-tests/extractor-generic.py", line 
99, in generic_test_extraction
  jsonld = fixtures.get_tracker_extract_output(extra_env,
   ^^
   File "/<>/tests/functional-tests/fixtures.py", line 385, in 
get_tracker_extract_output
  raise RuntimeError(
   RuntimeError: tracker-extract returned non-zero exit code: -31
   Error output:
   Warning: using insecure memory!
   Disallowed syscall "getsockopt" caught in sandbox
...
dh_auto_test: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb 
LC_ALL=C.UTF-8 MESON_TESTTHREADS=1 meson test --no-rebuild --verbose --no-suite 
functional returned exit code 32
make[1]: *** [debian/rules:54: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:40: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Full build log attached.
Example buildd log:
   
https://buildd.debian.org/status/fetch.php?pkg=tracker-miners=amd64=3.4.6-2=1701438455=0

Best,
Chris




tracker-miners_3.4.6-1.gz
Description: application/gzip

Bug#1057190: libhackrf0: udev rules file lost in upgrade

[Chris Hofstaedtler]

Hello Maitland,

* Chris Hofstaedtler  [231205 20:01]:
> * Maitland Bottoms  [231203 14:57]:
> > Helmut Grohne  writes:
> > > Then when you retry it, please go for experimental first. Then have
> > > Chris or me check your upload is ok and only then proceed with uploading
> > > to unstable.
> > 
> > hackrf_2023.01.1-6 now in experimental is the retry with upstream
> > updates and the udev rules handling.

As Helmut already wrote, hackrf_2023.01.1-6 is good and can go to
unstable. Thanks!

> Do you think you could upload the other packages (rtl-sdr,
> bladerf, libmirisdr, libiio, libosmosdr) to experimental soon, too?

I checked these:

* bladerf 0.2023.02-3
* libiio 0.25-2
* libmirisdr 0.0.4.59ba37-6
* libosmosdr 0.1.8.effcaa7-8

And they are all good and can go to unstable.

rtl-sdr 2.0.1-1 is a bit different. librtlsdr changed its soname to
librtlsdr2. With the soname and package name change, the udev rules
also changed their name (to 60-librtlsdr2.rules).

In this case, the protective diversions are unnecessary, _if_ the
rules file always gets installed into /usr/lib, _and_ librtlsdr2
never gets introduced in bookworm or earlier. So, you have this
choice:

1) librtlsdr2 is exclusive to trixie and newer, then you can drop
the postinst/preinst/postrm fragments

2) you want the option of having librtlsdr2 in bookworm(-backports)
or earlier, then you need to keep these fragments.

Anyway, from my PoV it can also go into unstable now.

Please upload these packages to unstable soon, so we can proceed
with the udev migration.

Thanks,
Chris

Bug#1057483: alex4 depends on alex4-data but is NBS

[Chris Peterson]

Package: alex4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble
X-Debbugs-Cc: chris.peter...@canonical.com

Dear Maintainer,

Forwarding the Ubuntu bug for visibility.

*** /tmp/forwarded-from-ubuntu-0d3o2qla.txt
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/2045607
The description, from Chris Peterson, follows:

alex4-data is currently listed as an NBS due to changes in alex4 v1.1-10, which 
drops alex4-data as as a build target but leaves alex4-data as a potential 
Depends. I've read through (Debian Bug) #1035043 but it is still unclear to me 
(1) the intended fate of alex4-data and (2) if it can be fully replaced by 
game-data-packager.

It appears that alex4-data on Debian is just an old version of alex4 which 
builds it. My assumption is that the answer to (2) is yes, and 
game-data-packager is meant to fully replace alex4-data. In this case my 
suggestion is to drop alex4-data from Depends (patch to follow this post).

I will note that these changes were only from a few days ago, so perhaps I'm 
jumping the gun.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-37-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1057437: pmix: FTBFS: dh_missing: error: missing files, aborting

[Chris Hofstaedtler]

Source: pmix
Version: 5.0.1-3
Severity: serious
Tags: ftbfs

Dear Maintainer,

your package FTBFS in unstable, in my own test rebuild as well as on 
reproducible-builds.org.

Build log snippet, hopefully relevant:
   dh_missing: warning: usr/lib/x86_64-linux-gnu/pmix2/local/bin/cygdb exists 
in debian/tmp but is not installed to anywhere 
   dh_missing: warning: usr/lib/x86_64-linux-gnu/pmix2/local/bin/cython exists 
in debian/tmp but is not installed to anywhere 
   dh_missing: warning: usr/lib/x86_64-linux-gnu/pmix2/local/bin/cythonize 
exists in debian/tmp but is not installed to anywhere 
   dh_missing: error: missing files, aborting
  The following debhelper tools have reported what they installed (with 
files per package)
  * dh_install: libpmix-bin (9), libpmix-dev (4), libpmix2 (35), 
python3-pmix (1)
  * dh_installdocs: libpmix-bin (0), libpmix-dev (3), libpmix2 (0), 
python3-pmix (0)
  * dh_installexamples: libpmix-bin (0), libpmix-dev (27), libpmix2 (0), 
python3-pmix (0)
  * dh_installman: libpmix-bin (0), libpmix-dev (5), libpmix2 (0), 
python3-pmix (0)
  If the missing files are installed by another tool, please file a bug 
against it.
  When filing the report, if the tool is not part of debhelper itself, 
please reference the
  "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for 
debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz)
  Be sure to test with dpkg-buildpackage -A/-B as the results may vary when 
only a subset is built
  If the omission is intentional or no other helper can take care of this 
consider adding the
  paths to debian/not-installed.

  Remember to be careful with paths containing "x86_64-linux-gnu", where 
you might need to
  use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in 
debian/not-installed
  to ensure it works on all architectures (see #961104).
   make: *** [debian/rules:36: binary] Error 25
   dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Full build log attached.
rbo build log here:
   
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/pmix_5.0.1-3.rbuild.log.gz

Best,
Chris



pmix_5.0.1-3.gz
Description: application/gzip

Bug#1057436: ovn: FTBFS: tar (child): /usr/src/openvswitch/openvswitch.tar.gz: Cannot open: No such file or directory

[Chris Hofstaedtler]

Source: ovn
Version: 23.09.0-1
Severity: serious
Tags: ftbfs

Dear Maintainer,

your package FTBFS in unstable, in my own test rebuild as well as on 
reproducible-builds.org.

Build log snippet, hopefully relevant:
   cd ovs && tar -xzf /usr/src/openvswitch/openvswitch.tar.gz 
--strip-components=1
   tar (child): /usr/src/openvswitch/openvswitch.tar.gz: Cannot open: No such 
file or directory
   tar (child): Error is not recoverable: exiting now
   tar: Child returned status 2
   tar: Error is not recoverable: exiting now
   make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 2
   make[1]: Leaving directory '/<>'
   make: *** [debian/rules:7: binary] Error 2
   dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

Full build log attached.
rbo build log here:
   
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/ovn_23.09.0-1.rbuild.log.gz

Best,
Chris

sbuild (Debian sbuild) 0.85.0 (04 January 2023) on cl.home.zeha.at

+==+
| ovn 23.09.0-1 (amd64)Mon, 04 Dec 2023 02:42:26 + |
+==+

Package: ovn
Version: 23.09.0-1
Source Version: 23.09.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

Unpacking /home/ch/.cache/sbuild/unstable-amd64.tar to 
/srv/scratch/sbuild/tmp.sbuild.u2WtD4AYK6...
I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with 
'<>'
I: NOTICE: Log filtering will replace 'build/ovn-XaBoeO/resolver-0rgGjP' with 
'<>'

+--+
| Update chroot|
+--+

Get:1 http://172.16.172.24/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable InRelease [198 kB]
Ign:3 http://172.16.172.24/debian unstable/non-free amd64 Packages
Ign:4 http://172.16.172.24/debian unstable/contrib amd64 Packages
Ign:5 http://172.16.172.24/debian unstable/main amd64 Packages
Ign:6 http://172.16.172.24/debian unstable/non-free-firmware amd64 Packages
Get:3 http://172.16.172.24/debian unstable/non-free amd64 Packages [123 kB]
Get:4 http://172.16.172.24/debian unstable/contrib amd64 Packages [66.0 kB]
Get:5 http://172.16.172.24/debian unstable/main amd64 Packages [9596 kB]
Get:6 http://172.16.172.24/debian unstable/non-free-firmware amd64 Packages 
[6364 B]
Get:7 http://deb.debian.org/debian unstable/contrib Sources [60.8 kB]
Get:8 http://deb.debian.org/debian unstable/non-free-firmware Sources [6548 B]
Get:9 http://deb.debian.org/debian unstable/non-free Sources [85.1 kB]
Get:10 http://deb.debian.org/debian unstable/main Sources [10.3 MB]
Fetched 20.7 MB in 7s (2851 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  binutils binutils-common binutils-x86-64-linux-gnu cpp-13 g++-13 gcc-13
  gcc-13-base libasan8 libatomic1 libbinutils libcc1-0 libctf-nobfd0 libctf0
  libgcc-13-dev libgcc-s1 libgomp1 libgprofng0 libhwasan0 libitm1 liblsan0
  libquadmath0 libsframe1 libstdc++-13-dev libstdc++6 libsystemd0 libtsan2
  libubsan1 libudev1
28 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 61.5 MB of archives.
After this operation, 173 kB of additional disk space will be used.
Get:1 http://172.16.172.24/debian unstable/main amd64 libcc1-0 amd64 13.2.0-8 
[43.0 kB]
Get:2 http://172.16.172.24/debian unstable/main amd64 libgprofng0 amd64 
2.41.50.20231202-1 [769 kB]
Get:3 http://172.16.172.24/debian unstable/main amd64 libctf0 amd64 
2.41.50.20231202-1 [87.1 kB]
Get:4 http://172.16.172.24/debian unstable/main amd64 libctf-nobfd0 amd64 
2.41.50.20231202-1 [151 kB]
Get:5 http://172.16.172.24/debian unstable/main amd64 binutils-x86-64-linux-gnu 
amd64 2.41.50.20231202-1 [2234 kB]
Get:6 http://172.16.172.24/debian unstable/main amd64 libbinutils amd64 
2.41.50.20231202-1 [515 kB]
Get:7 http://172.16.172.24/debian unstable/main amd64 binutils-common amd64 
2.41.50.20231202-1 [2537 kB]
Get:8 http://172.16.172.24/debian unstable/main amd64 binutils amd64 
2.41.50.20231202-1 [80.1 kB]
Get:9 http://172.16.172.24/debian unstable/main amd64 libgomp1 amd64 13.2.0-8 
[131 kB]
Get:10 http://172.16.172.24/debian unstable/main amd64 libitm1 amd64 13.2.0-8 
[26.1 kB]
Get:11 http://172.16.172.24/debian unstable/main amd64 libatomic1 amd64 
13.2.0-8 [9304 B]
Get:12 http://172.16.172.24/debian unstable/main amd64 libasan8 amd64 13.2.0-8 
[2558 kB]
Get:13 http://172.16.172.24/debian unstable/main amd64 liblsan0 amd64 13.2.0-8 
[1102 kB]
Get:14 http://172.16.172.24/debian unstable/main amd64 libtsan2 amd64 13.2.0-8 
[2334 kB]
G

Bug#1057421: sysstat: FTBFS: dh_install: warning: Cannot find (any matches for) "debian/tmp/lib/systemd/" (tried in ., debian/tmp)

[Chris Hofstaedtler]

Source: sysstat
Version: 12.6.1-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: dep17m2

Dear Maintainer,

systemd.pc changed systemd_system_unit_dir to point to /usr. As a
consequence, your package now FTBFS in unstable. Due to a human
mistake this problem was not caught before making the change; we'd
like to apologize.

FTBFS log snippet:
>> if [ -n "/usr/lib/systemd/system" -a -n "/usr/lib/systemd/system-sleep" -a 
>> -d "/<>/debian/tmp/usr/lib/systemd/system-sleep" ]; then \
>>  install -m 755 cron/sysstat.sleep 
>> /<>/debian/tmp/usr/lib/systemd/system-sleep; \
>> fi
>> make[2]: Leaving directory '/<>'
>> mv /<>/debian/tmp/usr/bin/sar 
>> /<>/debian/tmp/usr/bin/sar.sysstat
>> mv /<>/debian/tmp/usr/share/man/man1/sar.1 
>> /<>/debian/tmp/usr/share/man/man1/sar.sysstat.1
>> rm -rf /<>/debian/tmp/usr/doc
>> make[1]: Leaving directory '/<>'
>>dh_install
>> dh_install: warning: Cannot find (any matches for) "debian/tmp/lib/systemd/" 
>> (tried in ., debian/tmp)
>> 
>> dh_install: warning: sysstat missing files: debian/tmp/lib/systemd/
>> dh_install: error: missing files, aborting
>> make: *** [debian/rules:23: binary] Error 25
>> dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
>> status 2


It seems likely you'll need to adapt a debhelper .install file for
the /usr path.

Note: if you intend to backport your package to bookworm or earlier,
please revert any changes for moving to /usr.

Best,
Chris



sysstat_12.6.1-1.gz
Description: application/gzip

Bug#1057420: cfengine3: FTBFS: dh_install: warning: cfengine3 missing files: debian/tmp/lib/systemd

[Chris Hofstaedtler]

Source: cfengine3
Version: 3.21.0-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: dep17m2

Dear Maintainer,

systemd.pc changed systemd_system_unit_dir to point to /usr. As a
consequence, your package now FTBFS in unstable. Due to a human
mistake this problem was not caught before making the change; we'd
like to apologize.

FTBFS log snippet:
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install --exclude=examples --exclude=ChangeLog
dh_install: warning: Cannot find (any matches for)
"debian/tmp/lib/systemd" (tried in ., debian/tmp)

dh_install: warning: cfengine3 missing files: debian/tmp/lib/systemd
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:70: override_dh_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2


It seems likely you'll need to adapt a debhelper .install file for
the /usr path.

Note: if you intend to backport your package to bookworm or earlier,
please revert any changes for moving to /usr.

Best,
Chris



cfengine3_3.21.0-3.gz
Description: application/gzip

Bug#1057413: FTBFS: dh_install: warning: gnustep-make-doc missing files: Documentation/gnustep-make.pdf

[Chris Hofstaedtler]

Source: gnustep-make
Version: 2.9.1-2
Severity: serious
Tags: ftbfs

Dear Maintainer,

gnustep-make-doc currently FTBFS in unstable, in both my own test build
and on reproducible-builds. Here is a part of the build log:

Installing GNUstep configuration file in 
/build/reproducible-path/gnustep-make-2.9.1/debian/tmp/etc/GNUstep/GNUstep.conf
Installing gnustep-make support software
Installing makefiles
Installing Test Framework scripts
Installing Test Framework support files
Installing (and compressing) manpages
make[1]: Leaving directory 
'/build/reproducible-path/gnustep-make-2.9.1/build-gnustep-make'
   dh_install -O--builddirectory=build-gnustep-make
dh_install: warning: Cannot find (any matches for) 
"Documentation/gnustep-make.pdf" (tried in ., debian/tmp)

dh_install: warning: gnustep-make-doc missing files: 
Documentation/gnustep-make.pdf
dh_install: error: missing files, aborting
make: *** [debian/rules:24: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Full log from reproducible-builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gnustep-make_2.9.1-2.rbuild.log.gz

Best,
Chris

Bug#1057381: FTBFS: error: invalid use of incomplete typedef ‘WINDOW’

[Chris Hofstaedtler]

Source: aalib
Version: 1.4p5-50
Severity: serious
Tags: ftbfs

Rebuilding your package in unstable currently fails:


libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-I/usr/include -I/usr/include/ncurses -c aacurses.c  -fPIC -DPIC -o 
.libs/aacurses.o
aacurses.c: In function ‘curses_getsize’:
aacurses.c:80:20: error: invalid use of incomplete typedef ‘WINDOW’ {aka 
‘struct _win_st’}
   80 | *width = stdscr->_maxx + 1;
  |^~
aacurses.c:81:21: error: invalid use of incomplete typedef ‘WINDOW’ {aka 
‘struct _win_st’}
   81 | *height = stdscr->_maxy + 1;
  | ^~
make[4]: *** [Makefile:726: aacurses.lo] Error 1
make[4]: Leaving directory '/<>/src'
make[3]: *** [Makefile:483: all] Error 2
make[3]: Leaving directory '/<>/src'
make[2]: *** [Makefile:492: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Best,
Chris

Bug#1057190: libhackrf0: udev rules file lost in upgrade

[Chris Hofstaedtler]

Hello Maitland,

* Maitland Bottoms  [231203 14:57]:
> Helmut Grohne  writes:
> 
> > Then when you retry it, please go for experimental first. Then have
> > Chris or me check your upload is ok and only then proceed with uploading
> > to unstable.
> 
> hackrf_2023.01.1-6 now in experimental is the retry with upstream
> updates and the udev rules handling.
> 
> Thanks for your attention on this, indeed my lack of attention before
> making uploads is the problem. I am happier with -6 though.

Thank you! -6 is looking good at first glance. Lets give the dumat
tool a bit more time to check it though.

Do you think you could upload the other packages (rtl-sdr,
bladerf, libmirisdr, libiio, libosmosdr) to experimental soon, too?

Best,
Chris

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Chris Hofstaedtler]

Hello Jonas,

* Scott Talbert  [231203 14:06]:
> haskell-pandoc has been accepted into unstable, so I think you should be
> able to update src:pandoc to now build from the pandoc-cli hackage package.
[..]

Sorry for nudging here, but pandoc is used as a build dependency on
quite a few libraries needing intrusive packaging patches for
UsrMerge. The earlier we can have them fixed in (at least)
experimental, the better.
But for that they need their build-deps, obviously :-)

Thanks to everyone here for their work!

Best,
Chris

Bug#1057269: modemmanager: FTBFS dh_missing: warning: lib/systemd/system/ModemManager.service exists in debian/tmp ...

[Chris Hofstaedtler]

Source: modemmanager
Version: 1.22.0-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: dep17m2


Dear Maintainer,

modemmanager currently FTBFS in unstable, like this:

...
dh_auto_configure -- -Dgtk_doc=true \
-Ddbus_policy_dir=/usr/share/dbus-1/system.d \
-Dpolkit=permissive \
-Dsystemdsystemunitdir=/lib/systemd/system \
...
Installing /<>/obj-x86_64-linux-gnu/data/ModemManager.service to 
/<>/debian/tmp/lib/systemd/system
...
dh_missing: warning: lib/systemd/system/ModemManager.service exists in 
debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
...
make: *** [debian/rules:17: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


I see you're already preparing a new build hopefully fixing this in
experimental. Hope it works!

Thanks,
Chris

Bug#1057002: init cannot respawn mingetty after update

[Chris Hofstaedtler]

Control: severity -1 normal
Control: tags -1 = wontfix

* Klaus Ethgen  [231127 19:13]:
> Package: mingetty
> Version: 1.08-5
> Severity: grave
> 
> After the recent update, init runns cracy trying to run mingetty.
> Nov 27 20:00:01 ikki init: cannot execute "/sbin/mingetty"
[..]

> merged-usr: no

This is not a bug in mingetty, but your installation is not in a
supported state. Once you get your install fixed by usrmerge, it
will work.

Chris

Bug#1056926: FTBFS: rm: cannot remove 'underscore.js': No such file or directory

[Chris Hofstaedtler]

Control: tags -1 + patch

* Chris Hofstaedtler  [231126 20:11]:
> your package apparently FTBFS, probably caused by the newer version of
> sphinx.

Please find a patch attached.

Chris

diff -Nru hackrf-2023.01.1/debian/rules hackrf-2023.01.1/debian/rules
--- hackrf-2023.01.1/debian/rules	2023-10-15 02:26:21.0 +0200
+++ hackrf-2023.01.1/debian/rules	2023-11-26 20:37:03.0 +0100
@@ -15,14 +15,16 @@
 	cd docs && make latexpdf
 	cd docs/build/html/_static && rm jquery.js
 	cd docs/build/html/_static && ln -s /usr/share/javascript/jquery/jquery.js jquery.js
-	cd docs/build/html/_static && rm underscore.js
-	cd docs/build/html/_static && ln -s /usr/share/javascript/underscore/underscore.js underscore.js
+	cd docs/build/html/_static && rm _sphinx_javascript_frameworks_compat.js
+	cd docs/build/html/_static && ln -s /usr/share/sphinx/themes/basic/static/_sphinx_javascript_frameworks_compat.js _sphinx_javascript_frameworks_compat.js
 	cd docs/build/html/_static && rm doctools.js
 	cd docs/build/html/_static && ln -s /usr/share/sphinx/themes/basic/static/doctools.js doctools.js
 	cd docs/build/html/_static && rm language_data.js
 	cd docs/build/html/_static && ln -s /usr/share/sphinx/themes/basic/static/language_data.js_t language_data.js
 	cd docs/build/html/_static && rm searchtools.js
 	cd docs/build/html/_static && ln -s /usr/share/sphinx/themes/basic/static/searchtools.js searchtools.js
+	cd docs/build/html/_static && rm sphinx_highlight.js
+	cd docs/build/html/_static && ln -s /usr/share/sphinx/themes/basic/static/sphinx_highlight.js sphinx_highlight.js
 	rm -rf docs/build/html/_static/fonts
 #	cp -p -r firmware-libopencm3/* firmware/libopencm3/
 #	cd firmware && CFLAGS=-Wall CXXFLAGS=-Wall cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DBOARD=HACKRF_ONE -B build_hackrf

Bug#1056926: FTBFS: rm: cannot remove 'underscore.js': No such file or directory

[Chris Hofstaedtler]

Source: hackrf
Version: 2022.09.1-3
Severity: serious
Tags: ftbfs

Dear Maintainer,

your package apparently FTBFS, probably caused by the newer version of
sphinx.

Last few lines from the build log:

make[3]: Leaving directory '/<>/docs/build/latex'
make[2]: Leaving directory '/<>/docs'
cd docs/build/html/_static && rm jquery.js
cd docs/build/html/_static && ln -s /usr/share/javascript/jquery/jquery.js 
jquery.js
cd docs/build/html/_static && rm underscore.js
rm: cannot remove 'underscore.js': No such file or directory
make[1]: *** [debian/rules:18: override_dh_auto_build-indep] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Thanks,
Chris


Package versions: apt_2.7.6 autoconf_2.71-3 automake_1:1.16.5-1.3 
autopoint_0.21-13 autotools-dev_20220109.1 base-files_13 base-passwd_3.6.2 
bash_5.2.15-2+b6 binutils_2.41-6 binutils-aarch64-linux-gnu_2.41-6 
binutils-common_2.41-6 bsdextrautils_2.39.2-6 bsdutils_1:2.39.2-6 
build-essential_12.10 bzip2_1.0.8-5+b1 ca-certificates_20230311 cmake_3.27.8-1 
cmake-data_3.27.8-1 coreutils_9.1-1 cpp_4:13.2.0-1 cpp-13_13.2.0-5 
dash_0.5.12-6 debconf_1.5.82 debhelper_13.11.8 debian-archive-keyring_2023.4 
debianutils_5.14 dfu-util_0.11-1 dh-autoreconf_20 
dh-strip-nondeterminism_1.13.1-1 diffutils_1:3.10-1 
docutils-common_0.20.1+dfsg-2 dpkg_1.22.1 dpkg-dev_1.22.1 dwz_0.15-1 
e2fsprogs_1.47.0-2+b1 fakeroot_1.32.2-1 file_1:5.45-2 findutils_4.9.0-5 
fontconfig-config_2.14.2-6 fonts-dejavu-core_2.37-8 fonts-dejavu-mono_2.37-8 
fonts-font-awesome_5.0.10+really4.7.0~dfsg-4.1 fonts-lato_2.015-1 
fonts-lmodern_2.005-1 g++_4:13.2.0-1 g++-13_13.2.0-5 gcc_4:13.2.0-1 
gcc-13_13.2.0-5 gcc-13-base_13.2.0-5 gettext_0.21-13+b1 gettext-base_0.21-13+b1 
gpgv_2.2.40-1.1 grep_3.11-3 groff-base_1.23.0-3 gzip_1.12-1 hostname_3.23+nmu1 
init-system-helpers_1.65.2 intltool-debian_0.35.0+20060710.6 latexmk_1:4.80-1 
libacl1_2.3.1-3 libapache-pom-java_29-2 libapt-pkg6.0_2.7.6 
libarchive-zip-perl_1.68-1 libarchive13_3.7.2-1 libasan8_13.2.0-5 
libatomic1_13.2.0-5 libattr1_1:2.5.1-4 libaudit-common_1:3.1.1-1 
libaudit1_1:3.1.1-1 libbinutils_2.41-6 libblkid1_2.39.2-6 libbrotli1_1.1.0-2 
libbsd0_0.11.7-4 libbz2-1.0_1.0.8-5+b1 libc-bin_2.37-12 libc-dev-bin_2.37-12 
libc6_2.37-12 libc6-dev_2.37-12 libcairo2_1.18.0-1 libcap-ng0_0.8.3-1+b3 
libcap2_1:2.66-4 libcc1-0_13.2.0-5 libcom-err2_1.47.0-2+b1 
libcommons-logging-java_1.2-4 libcommons-parent-java_56-1 
libcrypt-dev_1:4.4.36-2 libcrypt1_1:4.4.36-2 libctf-nobfd0_2.41-6 
libctf0_2.41-6 libcurl4_8.4.0-2 libdb5.3_5.3.28+dfsg2-4 libdebconfclient0_0.271 
libdebhelper-perl_13.11.8 libdpkg-perl_1.22.1 libelf1_0.190-1 libexpat1_2.5.0-2 
libext2fs2_1.47.0-2+b1 libfakeroot_1.32.2-1 libffi8_3.4.4-1 
libfftw3-bin_3.3.10-1 libfftw3-dev_3.3.10-1 libfftw3-double3_3.3.10-1 
libfftw3-long3_3.3.10-1 libfftw3-single3_3.3.10-1 libfile-find-rule-perl_0.34-3 
libfile-stripnondeterminism-perl_1.13.1-1 libfontbox-java_1:1.8.16-4 
libfontconfig1_2.14.2-6 libfontenc1_1:1.1.4-1 libfreetype6_2.13.2+dfsg-1 
libgcc-13-dev_13.2.0-5 libgcc-s1_13.2.0-5 libgcrypt20_1.10.2-3 
libgdbm-compat4_1.23-3 libgdbm6_1.23-3 libglib2.0-0_2.78.1-4 
libgmp10_2:6.3.0+dfsg-2 libgnutls30_3.8.1-4+b1 libgomp1_13.2.0-5 
libgpg-error0_1.47-3 libgprofng0_2.41-6 libgraphite2-3_1.3.14-1 
libgssapi-krb5-2_1.20.1-5 libharfbuzz0b_8.0.1-1 libhogweed6_3.9.1-2 
libhwasan0_13.2.0-5 libice6_2:1.0.10-1 libicu72_72.1-4 libidn2-0_2.3.4-1+b1 
libisl23_0.26-3 libitm1_13.2.0-5 libjansson4_2.14-2 
libjs-jquery_3.6.1+dfsg+~3.5.14-1 libjs-sphinxdoc_7.2.6-2 
libjs-underscore_1.13.4~dfsg+~1.11.4-3 libjson-perl_4.1-1 
libjsoncpp25_1.9.5-6 libk5crypto3_1.20.1-5 libkeyutils1_1.6.3-2 
libkpathsea6_2023.20230311.66589-8 libkrb5-3_1.20.1-5 libkrb5support0_1.20.1-5 
libldap-2.5-0_2.5.13+dfsg-5 liblsan0_13.2.0-5 liblz4-1_1.9.4-1 
liblzma5_5.4.5-0.1 libmagic-mgc_1:5.45-2 libmagic1_1:5.45-2 libmd0_1.1.0-1 
libmount1_2.39.2-6 libmpc3_1.3.1-1 libmpfr6_4.2.1-1 libncursesw6_6.4+20231016-1 
libnettle8_3.9.1-2 libnghttp2-14_1.58.0-1 libnsl-dev_1.3.0-3 libnsl2_1.3.0-3 
libnumber-compare-perl_0.03-3 libp11-kit0_0.25.0-5 libpam-modules_1.5.2-9.1 
libpam-modules-bin_1.5.2-9.1 libpam-runtime_1.5.2-9.1 libpam0g_1.5.2-9.1 
libpaper-utils_1.1.29 libpaper1_1.1.29 libpcre2-8-0_10.42-4 
libpdfbox-java_1:1.8.16-4 libperl5.36_5.36.0-9 libpipeline1_1.5.7-1 
libpixman-1-0_0.42.2-1 libpkgconf3_1.8.1-1 libpng16-16_1.6.40-2 
libpotrace0_1.16-2 libproc2-0_2:4.0.4-2 libpsl5_0.21.2-1+b1 
libptexenc1_2023.20230311.66589-8 libpython3-stdlib_3.11.4-5+b1 
libpython3.11-minimal_3.11.6-3 libpython3.11-stdlib_3.11.6-3 
libreadline8_8.2-1.3 librhash0_1.4.3-3 librtmp1_2.4+20151223.gitfa8646d.1-2+b2 
libsasl2-2_2.1.28+dfsg1-4 libsasl2-modules-db_2.1.28+dfsg1-4 
libseccomp2_2.5.4-2 libselinux1_3.5-1 libsemanage-common_3.5-1 
libsemanage2_3.5-1 libsepol2_3.5-1 libsframe1_2.41-6 libsm6_2:1.2.3-1 
libsmartcols1_2.39

Bug#1054190: NMU and Merge Request

[Chris Hofstaedtler]

I will upload this patch in a few minutes. For your convenience,
please find an MR here:
https://salsa.debian.org/pkg-security-team/arpon/-/merge_requests/4

Chris

Bug#1056139: tracker.debian.org: Migration data stuck on or before 2023-11-14

[Chris Hofstaedtler]

Package: tracker.debian.org
Severity: serious

Dear tracker.d.o owners,

as you probably have already noticed, the migration data for a lot of
packages appears stuck in the past, probably on or before 2023-11-14.

As an example, https://tracker.debian.org/pkg/multipath-tools shows "Too
young, only 4 of 5 days old", but the package migrated on 2023-11-16:
https://tracker.debian.org/news/1478834/multipath-tools-094-7-migrated-to-testing/

Thanks,
Chris

Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2

[Chris Lamb]

Dear Alberto,

> I think this is likely a problem I already fixed back in February in 
> commit 5dcc6d4.

Ah, cherry-picking that commit fixed it for me. I've gone ahead and
uploaded that to Debian in order to close this RC bug, but please do
feel free to also release a libfiu v1.2 as well.

That would have the added advantage of "clearing out" the other patch
we had to apply re. Link-Time Optimisation.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2

[Chris Lamb]

Hey Alberto,

Hope all is well with you. Just wondering if you received the below
re. a recently-filed bug report against libfiu. I can reproduce it
locally if that helps.


Best wishes,

Chris



- Original message -
From: Lucas Nussbaum 
To: sub...@bugs.debian.org
Subject: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 
LC_ALL=C returned exit code 2
Date: Friday, 27 October 2023 8:31 PM

Source: libfiu
Version: 1.1-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231027 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[4]: Entering directory '/<>/tests/utils'
> mkdir -p libs/
> ln -f ../../preload/posix/fiu_posix_preload.so libs/
> ln -f ../../preload/run/fiu_run_preload.so libs/
> LD_LIBRARY_PATH=../../libfiu/ ./test-basic_ctrl.py > 
> output-test-basic_ctrl.py.txt 2>&1
> LD_LIBRARY_PATH=../../libfiu/ ./test-basic_run.sh > 
> output-test-basic_run.sh.txt 2>&1
> ./generate-test -c tests/fprintf.conf -o tests/fprintf.c
> ./generate-test -c tests/fread.conf -o tests/fread.c
> ./generate-test -c tests/kill.conf -o tests/kill.c
> ./generate-test -c tests/malloc.conf -o tests/malloc.c
> ./generate-test -c tests/mmap.conf -o tests/mmap.c
> cc -I../../libfiu/ -L../../libfiu/ -L./ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE 
> -fPIC -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99 
> -pedantic -Wall -L. binary.c -lfiu -lcoltest -o binary
> ./generate-test -c tests/open.conf -o tests/open.c
> ln -f ../preload/posix/fiu_posix_preload.so libs/
> ln -f ../preload/run/fiu_run_preload.so libs/
> ./generate-test -c tests/open64.conf -o tests/open64.c
> ./generate-test -c tests/pread.conf -o tests/pread.c
> ./generate-test -c tests/pread64.conf -o tests/pread64.c
> ./generate-test -c tests/strdup.conf -o tests/strdup.c
> cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall \
>   -rdynamic -fno-optimize-sibling-calls test-enable_stack.c -lfiu 
> -lpthread -o test-enable_stack
> test-enable_stack.c: In function 'main':
> test-enable_stack.c:32:50: warning: ISO C forbids conversion of function 
> pointer to object pointer type [-Wpedantic]
>32 | r = fiu_enable_stack("fp-1", 1, NULL, 0, (void *) , -1);
>   |  ^
> cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall \
>   -rdynamic -fno-optimize-sibling-calls test-enable_stack_by_name.c -lfiu 
> -lpthread -o test-enable_stack_by_name
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99 
> -pedantic -Wall tests/fopen.c -lfiu -o tests/fopen.bin
> LD_LIBRARY_PATH="./:../../libfiu/" ./binary
> make[4]: Leaving directory '/<>/tests/collisions'
> cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall 
> test-ferror.c -lfiu -lpthread -o test-ferror
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99 
> -pedantic -Wall tests/fprintf.c -lfiu -o tests/fprintf.bin
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99 
> -pedantic -Wall tests/fread.c -lfiu -o tests/fread.bin
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -st

Bug#1054241: nastran: Demonstration problems fail.

[Chris Fisichella]

Package: nastran
Version: 0.1.95-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: ch...@communityrenewables.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   I installed nastran from the debian distribution. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I read the man page. I made a copy of the examples that come with the 
distribution to my home directory. I downloaded the NASTRAN demonstration 
problem manual and read it over. I sucessively copied about ten demonstration 
problems to another directory in my home directory and on each .inp file, 
executed nastran .inp, where  is the example file name that came with 
the distribution.
   * What was the outcome of this action?
   Nastran ran successfully. Nastran found errors on its own and reported them. 
A popular error was
   0*** USER FATAL MESSAGE 8020, SYNTAX ERROR NEAR COLUMN  16 IN THE FOLLOWING 
CARD- 
SBST   1,  3

01 2 3 4 5 
6 7 8
10 0 0 0 0 
0 0 0
this error can be found in the .out file NASTRAN creates. 
   * What outcome did you expect instead?
   I expected the example problems to run successfully. The are used to test 
the system NASTRAN is running on against published known results. 

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-18-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nastran depends on:
ii  libc6 2.31-13+deb11u4
ii  libgcc-s1 10.2.1-6
ii  libgfortran5  10.2.1-6

nastran recommends no packages.

nastran suggests no packages.

-- no debconf information

Bug#1040043: additional info

[Chris Vogel]

I saw in Boris logfile that the log is partly in german as well as my log on a 
Debian Bullseye using rspamd 3.2.1 on a RockPro64.

I opened an issue for yunhost which is the system integration I use on that 
system on the basis of Debian here: 
https://github.com/YunoHost/issues/issues/2269

"Switched the locale back to de_DE.UTF-8, restarted rspamd and reproduced the 
bahviour.

To get my ynh working with rspamd I switched back to C.UTF-8, restarted rspamd 
and got the same errors containing german again. WTF.

After I restarted the daemon a few times and tried after each time to learn 
more ham/spam from existing folders it suddenly started working without crashes 
again.

I guess someone needs to look at the problem on their host to compare results."

Bug#1051563: Backporting mutt patches to Debian Buster

[Chris Frey]

On Wed, Sep 20, 2023 at 02:35:30PM -0300, Santiago Ruano Rincón wrote:
> I kept the original From, tagged the Origin as backport, and kept your
> name as Author.
> Hope that makes sense for you.
> 
> Thanks a lot for your work!

I saw it percolate through the updates today.  Thanks very much!

- Chris

Bug#1051563: Backporting mutt patches to Debian Buster

[Chris Frey]

On Sun, Sep 17, 2023 at 08:34:57PM +0300, Santiago Ruano Rincón wrote:
> Chris, thanks for preparing the patches. Much appreciated. I have a
> question though: Why are you placing those two patches in
> debian-specific, and not in upstream/? They come from the upstream repo.

I only put them there because I had to modify them for a clean patch.
I changed the headers to make it clear that I edited them, but kept
the original wording as well.

I didn't think it was right to modify the patch contents without
changing the name of who did it.

- Chris

Bug#1051563: Backporting mutt patches to Debian Buster

[Chris Frey]

Attached is a patch that applies to the unpackaged sources of Debian Buster's
version of mutt 1.10.

It includes 3 patches:

upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
debian-specific/Check-for-NULL-userhdrs.patch
debian-specific/Fix-write_one_header-illegal-header-check.patch

First one applied from Bullseye.  The other two I modified slightly
to match the older sources.

The CVE's make mention of "specially crafted input" but I don't have
any samples to test with.  I only tested that this built on Buster and
opens mail as before.

I have not adjusted any other files but the 3 above and debian/patches/series.
Hopefully this gives a head start on making these fixes available on buster.

- Chris

diff --git a/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
new file mode 100644
index 000..33f5cb5
--- /dev/null
+++ b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
@@ -0,0 +1,56 @@
+From: Chris Frey 
+Date: Fri, 15 Sep 2023 08:41:00 -0400
+Subject: Check for NULL userhdrs.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4875
+
+The original patch from Kevin McCarthy backported to Debian buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original summary below:
+
+ From: Kevin McCarthy 
+ Date: Mon, 4 Sep 2023 12:50:07 +0800
+ Subject: Check for NULL userhdrs.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6
+
+ When composing an email, miscellaneous extra headers are stored in a
+ userhdrs list.  Mutt first checks to ensure each header contains at
+ least a colon character, passes the entire userhdr field (name, colon,
+ and body) to the rfc2047 decoder, and safe_strdup()'s the result on
+ the userhdrs list.  An empty result would from the decode would result
+ in a NULL headers being added to list.
+
+ The previous commit removed the possibility of the decoded header
+ field being empty, but it's prudent to add a check to the strchr
+ calls, in case there is another unexpected bug resulting in one.
+
+ Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
+ crashes, giving a working example draft message, and providing the
+ stack traces for the two NULL derefences.
+ ---
+  sendlib.c | 4 ++--
+  1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d75e66a 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -2070,7 +2070,7 @@ int mutt_write_rfc822_header (FILE *fp, ENVELOPE *env, BODY *attach,
+   /* Add any user defined headers */
+   for (; tmp; tmp = tmp->next)
+   {
+-if ((p = strchr (tmp->data, ':')))
++if ((p = strchr (NONULL (tmp->data), ':')))
+ {
+   q = p;
+ 
+@@ -2116,7 +2116,7 @@ static void encode_headers (LIST *h)
+ 
+   for (; h; h = h->next)
+   {
+-if (!(p = strchr (h->data, ':')))
++if (!(p = strchr (NONULL (h->data), ':')))
+   continue;
+ 
+ i = p - h->data;
diff --git a/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
new file mode 100644
index 000..8806525
--- /dev/null
+++ b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
@@ -0,0 +1,46 @@
+From: Chris Frey 
+Date: Fri, 15 Sep 2023 10:09:00 -0400
+Subject: Fix write_one_header() illegal header check.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4874
+
+Backporting original patch from Kevin McCarthy to Debian Buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original commentary included below:
+
+ From: Kevin McCarthy 
+ Date: Sun, 3 Sep 2023 14:11:48 +0800
+ Subject: Fix write_one_header() illegal header check.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0
+
+ This is another crash caused by the rfc2047 decoding bug fixed in the
+ second prior commit.
+
+ In this case, an empty header line followed by a header line starting
+ with ":", would result in t==end.
+
+ The mutt_substrdup() further below would go very badly at that point,
+ with t >= end+1.  This could result in either a memcpy onto NULL or a
+ huge malloc call.
+
+ Thanks to Chenyuan Mi (@morningbread) for giving a working example
+ draft message of the rfc2047 decoding flaw.  This allowed me, with
+ further testing, to discover this additional crash bug.
+ ---
+  sendlib.c | 2 +-
+  1 file changed, 1 insertion(+), 1 deletion(-)
+ 
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d821061 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -1832,7 +1832,7 @@ static int write_one_header (FILE *fp, int pfxw, int max, int wraplen,
+   else
+   {
+ t = strchr (start, ':');
+-if (!t || t > end)
++if (!t || t >= end)
+ {
+  

Bug#1051226: python-django: CVE-2023-41164

[Chris Lamb]

Package: python-django
Version: 1:1.11.29-1+deb10u9
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2023-41164[0]:

  Potential denial of service vulnerability in
  django.utils.encoding.uri_to_iri(); this was subject to potential
  denial of service attack via certain inputs with a very large number
  of Unicode characters.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-41164
https://www.cve.org/CVERecord?id=CVE-2023-41164


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1050973: lastpass-cli: Please update to 1.3.5 upstream to fix certificate error

[Chris Lamb]

tags 1050973 + pending
thanks


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1040748: pycairo: diff for NMU version 1.24.0-1.1

[Chris Hofstaedtler]

Source: pycairo
Followup-For: Bug #1040748

Control: tags 1040748 + patch
Control: tags 1040748 + pending

Dear maintainer,

I've prepared an NMU for pycairo (versioned as 1.24.0-1.1) and
uploaded it directly. 

Chris


diff -Nru pycairo-1.24.0/debian/changelog pycairo-1.24.0/debian/changelog
--- pycairo-1.24.0/debian/changelog 2023-07-03 19:31:14.0 +0200
+++ pycairo-1.24.0/debian/changelog 2023-08-06 14:42:07.0 +0200
@@ -1,3 +1,13 @@
+pycairo (1.24.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Workaround automatic Python bytecode compilation leading to
+FTBFS. (Closes: #1040748)
+Fixing this in debhelper for all packages would obviously be preferred,
+but for now this has to do.
+
+ -- Chris Hofstaedtler   Sun, 06 Aug 2023 14:42:07 +0200
+
 pycairo (1.24.0-1) unstable; urgency=medium
 
   * Team upload
diff -Nru pycairo-1.24.0/debian/rules pycairo-1.24.0/debian/rules
--- pycairo-1.24.0/debian/rules 2023-07-03 19:31:14.0 +0200
+++ pycairo-1.24.0/debian/rules 2023-08-06 14:41:01.0 +0200
@@ -5,6 +5,9 @@
 %:
dh $@ --with python3,sphinxdoc --buildsystem=meson
 
+override_dh_auto_configure:
+   dh_auto_configure -- -Dpython.bytecompile=-1
+
 execute_after_dh_auto_build:
python3 -m sphinx -bhtml docs debian/tmp-doc/html
# to fix lintian: privacy-breach-generic

Bug#984010: chkservice: ftbfs with GCC-11

[Chris Hofstaedtler]

Hi,

after trying to fix this bug, on bookworm chkservice only shows
"Failed: Device or resource busy" for me. Also, upstream apparently
deleted the source repository.

Do you think its viable to fix this package or should it maybe be
removed instead?

Chris