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#1059417: ed: diff for NMU version 1.20.1-1.1

[Chris Hofstaedtler]

Lev,

* Sven Joachim  [240427 19:48]:
> On 2024-04-17 14:26 +0200, Chris Hofstaedtler wrote:
> > I've prepared an NMU for ed (versioned as 1.20.1-1.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> 
> Seems your NMU was ignored and reverted in the latest upload. :-(

I'm guessing you didn't see the bug-mail / NMU so far? Are you going
to upload the patch yourself?

Chris

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Chris Hofstaedtler]

On Fri, Apr 26, 2024 at 08:06:15PM +0100, RL wrote:
> the chkrootkit package provides several utilities for examining some of
> these files: chkutmp chkwtmp and check_wtmpx and chklastlog [a] -- it does
> not use pam but reads the files in /var/log
> 
> How would I test these against the new files - i assume the new versions
> are compatable but might need bigger variables in those utilities?

As briefly mentioned on the wiki page, TTBOMK the new files are
sqlite3 databases.

> https://salsa.debian.org/pkg-security-team/chkrootkit

I took a quick look, but I'm not sure which of the checks would be
applicable. For checks that do not rely on the implications of the
old file structure, you can probably use libwtmpdb or use
libsqlite3-0 directly.

Chris

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Chris Hofstaedtler]

Fellow Developers,

you are probably aware of the time_t-64bit migration :-)
However, this does not magically transition all data formats to 64bit
times. One such instance is the set of utmp/wtmp and lastlog files.

Thorsten Kukuk and others have been working on replacements for the
existing file formats and interfaces [1]; these are called wtmpdb
and lastlog2.

Some parties have requested that we do something in Debian [2]. If
we use Thorsten's work (and why not?), this likely means introducing
new packages into the Priority: standard set, and changes to a few
other packages, esp. those that handle user sessions.

Thorsten's code introduces new PAM modules to manage the new files,
so it should transparently work with most packages. Later, the
old interfaces can probably be turned off. This seems like a good
idea as a migration strategy to me.
A bonus seems to be that installs not wanting these features can
remove them - whereas today they are baked into everything.


On the wiki [0] I have summarized what I know; a list of initial
work items; and some open questions mostly concerned with upgrading.

I invite you to read the wiki page and the background info, to
identify gaps, to provide insights on feasability and further
related comments.
I'm hoping that we can build consensus on this plan.

Please keep #1068017 in CC: when discussing substantial matters
about this plan but drop it for only vaguely related sub-threads.

Chris


[0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb
[1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
[2] https://bugs.debian.org/1068017

Bug#1069822: python-gvm: please make the build reproducible

[Chris Lamb]

Source: python-gvm
Version: 24.3.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-gvm could not be built reproducibly.

This is because the docs embed the current build year. A patch is
attached that uses SOURCE_DATE_EPOCH [1] if available.

 [0] https://reproducible-builds.org/
 [0] https://reproducible-builds.org/docs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/Reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/Reproducible-build.patch   2024-04-25 11:55:22.120958744 
+0100
@@ -0,0 +1,33 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-25
+
+--- python-gvm-24.3.0.orig/docs/conf.py
 python-gvm-24.3.0/docs/conf.py
+@@ -16,7 +16,13 @@
+ 
+ import os
+ import sys
+-from datetime import datetime
++import time
++import datetime
++
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
+ 
+ sys.path.insert(0, os.path.abspath(".."))
+ 
+@@ -24,10 +30,8 @@ import gvm  # noqa: E402
+ 
+ # -- Project information -
+ 
+-year = datetime.now().year
+-
+ project = "python-gvm"
+-copyright = f"2018 - {year}, Greenbone AG"
++copyright = f"2018 - {build_date.year}, Greenbone AG"
+ author = "Greenbone AG"
+ 
+ # The short X.Y version
--- a/debian/patches/series 2024-04-25 11:43:24.482946466 +0100
--- b/debian/patches/series 2024-04-25 11:55:21.240959905 +0100
@@ -1,2 +1,3 @@
 change-path-unix-sockets.patch
 Remove-furo-theme-in-docs.patch
+Reproducible-build.patch

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#1069784: python-itemloaders: please make the build reproducible

[Chris Lamb]

Source: python-itemloaders
Version: 1.2.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-itemloaders could not be built reproducibly.

This is because the manual pages embed the build year in copyright
messages. A patch is therefore attached that seeds the date from
SOURCE_DATE_EPOCH if available.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0002-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch  2024-04-24 
16:57:48.698090140 +0100
@@ -0,0 +1,37 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-24
+
+--- python-itemloaders-1.2.0.orig/docs/conf.py
 python-itemloaders-1.2.0/docs/conf.py
+@@ -13,7 +13,8 @@
+ 
+ import os
+ import sys
+-from datetime import datetime
++import time
++import datetime
+ from os import path
+ 
+ import sphinx_rtd_theme
+@@ -24,6 +25,11 @@ import sphinx_rtd_theme
+ sys.path.append(path.dirname(__file__))
+ sys.path.insert(0, path.dirname(path.dirname(__file__)))
+ 
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
++
+ # General configuration
+ # -
+ 
+@@ -51,7 +57,7 @@ master_doc = "index"
+ 
+ # General information about the project.
+ project = "itemloaders"
+-copyright = "2020\u2013{}, Zyte Group Ltd".format(datetime.now().year)
++copyright = "2020\u2013{}, Zyte Group Ltd".format(build_date.year)
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2024-04-24 16:32:44.741767684 +0100
--- b/debian/patches/series 2024-04-24 16:50:13.629191809 +0100
@@ -1 +1,2 @@
 0001-Use-local-intersphinx-files.patch
+0002-Reproducible-build.patch

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#1069779: debirf: Remove this package?

[Chris Hofstaedtler]

Source: debirf
Severity: important

debirf did not make it into bullseye or bookworm. It is currently not in
testing, and has not been for over 3.5 years.

Is it time to remove debirf from Debian?

If you intend to maintain this package, please fix the open RC bugs and
then close this bug too. Otherwise I propose to reassign this bug to
ftp.debian.org for removal.

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#1069709: dpb: please make the build reproducible

[Chris Lamb]

Source: dpb
Version: 0.0~git20240401+4c3057874
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
dpb could not be built reproducibly.

This is because it embedded timestamps in .pdf files and in "generated
on.." comments in  various scripts. (Ideally the latter could be
removed entirely.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

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


--- a/create-buildscript.sh 2024-04-23 09:54:18.460456472 +0100
--- b/create-buildscript.sh 2024-04-23 10:03:12.374039772 +0100
@@ -11,7 +11,7 @@
 "
 
 cat Title.nw Part1.nw Part2.nw Part3.nw Part4.nw Part5.nw Part6.nw > 
BuildWithGBPg.nw
-t=`date +%c`
+t=$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" -R)
 
 function build_script()
 {
--- a/debian/rules  2024-04-23 09:54:18.460456472 +0100
--- b/debian/rules  2024-04-23 09:59:42.766516568 +0100
@@ -5,6 +5,7 @@
 
 export DH_VERBOSE=1
 export DH_OPTIONS=-v
+export FORCE_SOURCE_DATE=1
 
 %:
dh $@

Bug#1069663: dub: please make the build reproducible

[Chris Lamb]

Source: dub
Version: 1.36.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
dub could not be built reproducibly.

This is because the build system embeds timestamps in its man pages:

├── ./usr/share/man/man1/dub-add-local.1.gz
│ ├── dub-add-local.1
│ │ @@ -1,8 +1,8 @@
│ │ -.TH DUB-ADD-LOCAL 1 "2025-05-24" "The D Language Foundation" "The D 
Language Foundation"
│ │ +.TH DUB-ADD-LOCAL 1 "2024-04-21" "The D Language Foundation" "The D 
Language Foundation"

(etc.)

A patch is attached that simply exports dub's custom DIFFABLE
environment variable. This was seemingly introduced to make these
manpages, well, 'diffable' — that is to say, so that they generated in
a deterministic manner.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2024-04-22 10:34:28.039060412 +0100
--- b/debian/rules  2024-04-22 10:48:00.675980092 +0100
@@ -6,7 +6,7 @@
 DEB_VERSION := $(shell dpkg-parsechangelog | awk '/^Version: / { print $$2 }')
 
 export GITVER=$(DEB_VERSION)
-
+export DIFFABLE=1
 export DFLAGS=-frelease -fall-instantiations
 
 %:

Bug#1058834: ponyprog: diff for NMU version 3.1.3+ds-1.1

[Chris Hofstaedtler]

Control: tags 1058834 + patch
Control: tags 1058834 + pending


Dear maintainer,

I've prepared an NMU for ponyprog (versioned as 3.1.3+ds-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru ponyprog-3.1.3+ds/debian/changelog ponyprog-3.1.3+ds/debian/changelog
--- ponyprog-3.1.3+ds/debian/changelog	2022-03-10 16:33:58.0 +0100
+++ ponyprog-3.1.3+ds/debian/changelog	2024-04-22 03:18:43.0 +0200
@@ -1,3 +1,10 @@
+ponyprog (3.1.3+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use udev.pc to place udev files. (Closes: #1058834)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 03:18:43 +0200
+
 ponyprog (3.1.3+ds-1) unstable; urgency=medium
 
   * [6909f06] d/gbp.conf: Update content to filter out
diff -Nru ponyprog-3.1.3+ds/debian/control ponyprog-3.1.3+ds/debian/control
--- ponyprog-3.1.3+ds/debian/control	2022-03-10 16:33:58.0 +0100
+++ ponyprog-3.1.3+ds/debian/control	2024-04-22 03:18:41.0 +0200
@@ -11,8 +11,10 @@
  libftdi1-dev,
  libftdipp1-dev,
  libusb-dev,
+ pkgconf,
  qtbase5-dev,
  qtmultimedia5-dev,
+ systemd-dev,
 Rules-Requires-Root: binary-targets
 Standards-Version: 4.6.0
 Homepage: https://github.com/lancos/ponyprog
diff -Nru ponyprog-3.1.3+ds/debian/ponyprog.install ponyprog-3.1.3+ds/debian/ponyprog.install
--- ponyprog-3.1.3+ds/debian/ponyprog.install	2022-03-10 16:17:22.0 +0100
+++ ponyprog-3.1.3+ds/debian/ponyprog.install	2024-04-22 03:18:41.0 +0200
@@ -1,3 +1,3 @@
 icons/ponyprog.svg usr/share/icons/hicolor/scalable/apps
-lib/udev/rules.d/90-ponyprog.rules
+${env:deb_udevdir}/rules.d/90-ponyprog.rules
 usr
diff -Nru ponyprog-3.1.3+ds/debian/rules ponyprog-3.1.3+ds/debian/rules
--- ponyprog-3.1.3+ds/debian/rules	2022-03-10 16:33:58.0 +0100
+++ ponyprog-3.1.3+ds/debian/rules	2024-04-22 03:18:41.0 +0200
@@ -15,6 +15,8 @@
 CFLAGS+=$(CPPFLAGS)
 CXXFLAGS+=$(CPPFLAGS)
 
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+
 ICON_SIZES=128x128 64x64 48x48 32x32 24x24 16x16
 
 # detect the encoding of the file ponyprog.html
@@ -27,6 +29,7 @@
 DEB_PONYPROG_CMAKE_OPTS := \
 	-DCMAKE_INSTALL_PREFIX=/usr \
 	-DCMAKE_SHARED_LINKER_FLAGS_RELEASE="$(LDFLAGS)" \
+	-DUDEV_INSTALL_DIR="/$(deb_udevdir)/rules.d" \
 	-DUSE_DEBUGGER=ON \
 	-DUSE_QT5=ON \
 	$(NULL)

Bug#1058773: caddy: diff for NMU version 2.6.2-6.1

[Chris Hofstaedtler]

Control: tags 1058773 + patch
Control: tags 1058773 + pending


Dear maintainer,

I've prepared an NMU for caddy (versioned as 2.6.2-6.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru caddy-2.6.2/debian/caddy.install caddy-2.6.2/debian/caddy.install
--- caddy-2.6.2/debian/caddy.install	2023-08-23 13:28:40.0 +0200
+++ caddy-2.6.2/debian/caddy.install	2024-04-22 03:13:07.0 +0200
@@ -1,6 +1,6 @@
 dist/config/Caddyfile   etc/caddy/
-dist/init/caddy.service lib/systemd/system
-dist/init/caddy-api.service lib/systemd/system
+dist/init/caddy.service ${env:deb_systemdsystemunitdir}/
+dist/init/caddy-api.service ${env:deb_systemdsystemunitdir}/
 debian/missing-sources/caddy/welcome/index.html usr/share/caddy/
 debian/generated/completions/caddy  usr/share/bash-completion/completions/
 debian/generated/completions/_caddy usr/share/zsh/vendor-completions/
diff -Nru caddy-2.6.2/debian/changelog caddy-2.6.2/debian/changelog
--- caddy-2.6.2/debian/changelog	2023-08-23 13:28:40.0 +0200
+++ caddy-2.6.2/debian/changelog	2024-04-22 03:13:10.0 +0200
@@ -1,3 +1,10 @@
+caddy (2.6.2-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use systemd.pc to place systemd units. (Closes: #1058773)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 03:13:10 +0200
+
 caddy (2.6.2-6) unstable; urgency=medium
 
   * Team upload
diff -Nru caddy-2.6.2/debian/control caddy-2.6.2/debian/control
--- caddy-2.6.2/debian/control	2023-08-23 13:28:40.0 +0200
+++ caddy-2.6.2/debian/control	2024-04-22 03:13:07.0 +0200
@@ -39,6 +39,8 @@
golang-glog-dev,
golang-golang-x-text-dev,
golang-github-stoewer-go-strcase-dev,
+   pkgconf,
+   systemd-dev,
 Standards-Version: 4.6.1.0
 Vcs-Browser: https://salsa.debian.org/go-team/packages/caddy
 Vcs-Git: https://salsa.debian.org/go-team/packages/caddy.git
diff -Nru caddy-2.6.2/debian/rules caddy-2.6.2/debian/rules
--- caddy-2.6.2/debian/rules	2023-08-23 13:28:40.0 +0200
+++ caddy-2.6.2/debian/rules	2024-04-22 03:13:07.0 +0200
@@ -7,6 +7,8 @@
 export DH_GOLANG_EXCLUDES := integration tracing
 export BUILDDIR := build
 
+export deb_systemdsystemunitdir = $(shell pkg-config --variable=systemdsystemunitdir systemd | sed s,^/,,)
+
 include /usr/share/dpkg/pkg-info.mk
 LDFLAGS := -ldflags '-X $(DH_GOPKG).CustomVersion=$(DEB_VERSION_UPSTREAM) -X $(DH_GOPKG)/cmd.CustomDate="$(SOURCE_DATE_EPOCH)"'
 

Bug#1060343: duo-unix: diff for NMU version 1.11.3-1.2

[Chris Hofstaedtler]

Control: tags 1063523 + pending
Control: tags 1060343 + pending

Dear maintainer,

I've prepared an NMU for duo-unix (versioned as 1.11.3-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru duo-unix-1.11.3/debian/changelog duo-unix-1.11.3/debian/changelog
--- duo-unix-1.11.3/debian/changelog	2024-02-28 03:30:53.0 +0100
+++ duo-unix-1.11.3/debian/changelog	2024-04-22 02:52:25.0 +0200
@@ -1,3 +1,13 @@
+duo-unix (1.11.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install aliased files into /usr (DEP17 M2) (Closes: #1060343)
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS (Closes: #1063523)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 02:52:25 +0200
+
 duo-unix (1.11.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru duo-unix-1.11.3/debian/libpam-duo.install duo-unix-1.11.3/debian/libpam-duo.install
--- duo-unix-1.11.3/debian/libpam-duo.install	2011-09-02 22:21:02.0 +0200
+++ duo-unix-1.11.3/debian/libpam-duo.install	2024-04-22 02:50:44.0 +0200
@@ -1,3 +1,3 @@
-lib/*/security/pam_duo.so
+usr/lib/*/security/pam_duo.so
 debian/pam-configs/* usr/share/pam-configs/
 debian/pam_duo.conf etc/security/
diff -Nru duo-unix-1.11.3/debian/not-installed duo-unix-1.11.3/debian/not-installed
--- duo-unix-1.11.3/debian/not-installed	2020-03-14 18:08:43.0 +0100
+++ duo-unix-1.11.3/debian/not-installed	2024-04-22 02:50:44.0 +0200
@@ -1,7 +1,7 @@
 # We use the debian-specific version from debian/pam_duo.conf instead.
 etc/security/pam_duo.conf
 # We don't need .la files for linking
-lib/x86_64-linux-gnu/security/pam_duo.la
+usr/lib/x86_64-linux-gnu/security/pam_duo.la
 usr/lib/x86_64-linux-gnu/libduo.la
 # We do not support static linking.
 usr/lib/x86_64-linux-gnu/libduo.a
diff -Nru duo-unix-1.11.3/debian/patches/cross.patch duo-unix-1.11.3/debian/patches/cross.patch
--- duo-unix-1.11.3/debian/patches/cross.patch	1970-01-01 01:00:00.0 +0100
+++ duo-unix-1.11.3/debian/patches/cross.patch	2024-04-22 02:52:25.0 +0200
@@ -0,0 +1,24 @@
+--- duo-unix-1.11.3.orig/autotools/ax_check_x509.m4
 duo-unix-1.11.3/autotools/ax_check_x509.m4
+@@ -14,20 +14,16 @@
+ 
+ AU_ALIAS([CHECK_X509], [AX_CHECK_X509])
+ AC_DEFUN([AX_CHECK_X509],[
+-AC_MSG_CHECKING([whether X509_TEA_set_state runs])
+ save_LIBS="$LIBS"
+ save_LDFLAGS="$LDFLAGS"
+ save_CPPFLAGS="$CPPFLAGS"
+ LDFLAGS="$LDFLAGS $OPENSSL_LDFLAGS"
+ LIBS="$OPENSSL_LIBS $LIBS"
+ CPPFLAGS="$OPENSSL_INCLUDES $CPPFLAGS"
+-AC_RUN_IFELSE(
+-[AC_LANG_PROGRAM([void X509_TEA_set_state(int change);], [X509_TEA_set_state(0);])],
++AC_CHECK_FUNC([X509_TEA_set_state],
+ [
+-AC_MSG_RESULT([yes])
+ $1
+ ], [
+-AC_MSG_RESULT([no])
+ $2
+ ])
+ CPPFLAGS="$save_CPPFLAGS"
diff -Nru duo-unix-1.11.3/debian/patches/series duo-unix-1.11.3/debian/patches/series
--- duo-unix-1.11.3/debian/patches/series	2020-03-14 18:08:43.0 +0100
+++ duo-unix-1.11.3/debian/patches/series	2024-04-22 02:52:25.0 +0200
@@ -4,3 +4,4 @@
 libduo-install.patch
 pam_duo-ldflags.patch
 lib-strncpy.patch
+cross.patch
diff -Nru duo-unix-1.11.3/debian/rules duo-unix-1.11.3/debian/rules
--- duo-unix-1.11.3/debian/rules	2020-03-14 18:08:43.0 +0100
+++ duo-unix-1.11.3/debian/rules	2024-04-22 02:50:44.0 +0200
@@ -11,7 +11,7 @@
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --with-pam=/lib/$(DEB_HOST_MULTIARCH)/security \
+	dh_auto_configure -- --with-pam=/usr/lib/$(DEB_HOST_MULTIARCH)/security \
 			 --sysconfdir=/etc/security \
 			 --includedir=\$${prefix}/include/duo
 

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#1060769: foo2zjs: diff for NMU version 20200505dfsg0-2.1

[Chris Hofstaedtler]

Control: tags 1060769 + pending


Dear maintainer,

I've prepared an NMU for foo2zjs (versioned as 20200505dfsg0-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris
diff -Nru foo2zjs-20200505dfsg0/debian/changelog foo2zjs-20200505dfsg0/debian/changelog
--- foo2zjs-20200505dfsg0/debian/changelog	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/changelog	2024-04-22 02:32:30.0 +0200
@@ -1,3 +1,12 @@
+foo2zjs (20200505dfsg0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Helmut Grohne ]
+  * DEP17: Move all aliased files to /usr. (Closes: #1060769)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 02:32:30 +0200
+
 foo2zjs (20200505dfsg0-2) unstable; urgency=medium
 
   * Remove myself from Uploaders
diff -Nru foo2zjs-20200505dfsg0/debian/NEWS foo2zjs-20200505dfsg0/debian/NEWS
--- foo2zjs-20200505dfsg0/debian/NEWS	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/NEWS	2024-04-22 02:32:25.0 +0200
@@ -1,7 +1,7 @@
 foo2zjs (20090908dfsg-2) unstable; urgency=low
 
   Starting with this version all HP firmwares are looked for into
-  /lib/firmware/hp/ instead of upstream /usr/share/foo2zjs/firmware/
+  /usr/lib/firmware/hp/ instead of upstream /usr/share/foo2zjs/firmware/
   (thus solving bug #517957).
 
   The upstream /usr/bin/getweb and /lib/udev/hplj1000 scripts have
diff -Nru foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs-common.install foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs-common.install
--- foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs-common.install	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs-common.install	2024-04-22 02:32:25.0 +0200
@@ -1,7 +1,7 @@
 PPD/* usr/share/ppd/foo2zjs/
 debian/printer-driver-foo2zjs-common.ppd-updater /usr/share/cups/ppd-updaters/
 getweb usr/sbin
-hplj1000 lib/udev
+hplj1000 usr/lib/udev
 hplj1020.desktop usr/share/applications/
 hplj1020_icon.png usr/share/pixmaps
 usr/bin/foo2ddst-wrapper
diff -Nru foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.dirs foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.dirs
--- foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.dirs	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.dirs	2024-04-22 02:32:25.0 +0200
@@ -1 +1 @@
-/lib/firmware/hp/
+/usr/lib/firmware/hp/
diff -Nru foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.links foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.links
--- foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.links	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.links	2024-04-22 02:32:25.0 +0200
@@ -1,10 +1,10 @@
-lib/udev/hplj1000 lib/udev/hplj1005
-lib/udev/hplj1000 lib/udev/hplj1018
-lib/udev/hplj1000 lib/udev/hplj1020
-lib/udev/hplj1000 lib/udev/hpljP1005
-lib/udev/hplj1000 lib/udev/hpljP1006
-lib/udev/hplj1000 lib/udev/hpljP1007
-lib/udev/hplj1000 lib/udev/hpljP1008
-lib/udev/hplj1000 lib/udev/hpljP1505
-lib/udev/hplj1000 lib/udev/hpljP1505n
+usr/lib/udev/hplj1000 usr/lib/udev/hplj1005
+usr/lib/udev/hplj1000 usr/lib/udev/hplj1018
+usr/lib/udev/hplj1000 usr/lib/udev/hplj1020
+usr/lib/udev/hplj1000 usr/lib/udev/hpljP1005
+usr/lib/udev/hplj1000 usr/lib/udev/hpljP1006
+usr/lib/udev/hplj1000 usr/lib/udev/hpljP1007
+usr/lib/udev/hplj1000 usr/lib/udev/hpljP1008
+usr/lib/udev/hplj1000 usr/lib/udev/hpljP1505
+usr/lib/udev/hplj1000 usr/lib/udev/hpljP1505n
 usr/bin/psicc usr/bin/foo2zjs-icc2ps
diff -Nru foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.lintian-overrides foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.lintian-overrides
--- foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.lintian-overrides	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.lintian-overrides	2024-04-22 02:32:25.0 +0200
@@ -1,5 +1,5 @@
 # That's on purpose, getweb can go fetch these from the web
-package-contains-empty-directory lib/firmware/hp/
+package-contains-empty-directory usr/lib/firmware/hp/
 
 # Manpages are shipped in printer-driver-foo2zjs-common
 no-manual-page usr/bin/arm2hpdl
diff -Nru foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.postinst foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.postinst
--- foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.postinst	2021-09-02 14:45:45.0 +0200
+++ foo2zjs-20200505dfsg0/debian/printer-driver-foo2zjs.postinst	2024-04-22 02:32:25.0 +0200
@@ -3,9 +3,13 @@
 set -e
 
 if [ "$1" = configure ]; then
+# begin-remove-after: released:trixie
+# Mitigate empty directory loss in upgrade DEP17 P6.
+mkdir -p /usr/lib/firmware/hp
+# end-remove-after
 # Move user-downloaded firmware files
 if ls /usr/share/foo2zjs/firmware/*.dl >/dev/null 2>/dev/null; then
-	mv /usr/share/foo2zjs/firmware/*.dl /lib/firmware/hp/ 2>/dev/null
+	mv /usr/share/foo2zjs/firmware/*.dl /usr/lib/

Bug#1059515: mdns-reflector: diff for NMU version 0.0.1+git20230914.4b4cd3b-2.1

[Chris Hofstaedtler]

Control: tags 1059515 + patch
Control: tags 1059515 + pending


Dear maintainer,

I've prepared an NMU for mdns-reflector (versioned as 
0.0.1+git20230914.4b4cd3b-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/changelog mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/changelog
--- mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/changelog	2024-02-01 22:16:11.0 +0100
+++ mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/changelog	2024-04-22 02:24:48.0 +0200
@@ -1,3 +1,10 @@
+mdns-reflector (0.0.1+git20230914.4b4cd3b-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units into /usr (DEP17 M2) (Closes: #1059515)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 02:24:48 +0200
+
 mdns-reflector (0.0.1+git20230914.4b4cd3b-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/install mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/install
--- mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/install	2023-03-21 18:38:11.0 +0100
+++ mdns-reflector-0.0.1+git20230914.4b4cd3b/debian/install	2024-04-22 02:24:46.0 +0200
@@ -1,3 +1,3 @@
 misc/mdns-reflector etc/
-misc/mdns-reflector.service lib/systemd/system
-misc/mdns-reflector@.service lib/systemd/system
+misc/mdns-reflector.service usr/lib/systemd/system
+misc/mdns-reflector@.service usr/lib/systemd/system

Bug#966288: [Pkg-puppet-devel] Bug#966288: mcollective - RM for bullseye?

[Chris Hofstaedtler]

Control: clone -1 -2
Control: severity -1 serious
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: mcollective -- ROQA; dead upstream, alternatives exist
Control: tags -2 = moreinfo

On Mon, Apr 01, 2024 at 12:21:57PM -0700, Matt Taggart wrote:
> The last mcollective release was v.3.1.2 tagged on Oct 14, 2018, and zero
> commits after that, so is effectively dead upstream.
> 
> Here are the popcon stats
>   https://qa.debian.org/popcon.php?package=mcollective
> 
> I think it could probably be removed from debian now.
> 
> This bug mentioned "bolt" as a possible replacement, that seems to be this:
>   https://www.puppet.com/docs/bolt/latest/bolt.html

I've cloned this bug to request RM for trixie. While bolt is not
packaged in Debian, it seems mcollective has no users and whoever
was running it has very likely replaced it by now with something
else. I know a number of sites now using Puppet + ansible instead
of Puppet + mcollective.

AFAIK the old mcollective doesn't work with current Puppet, but I
haven't looked since 2018 either :-)

Chris

Bug#1060083: cgroupfs-mount: diff for NMU version 1.4+nmu1

[Chris Hofstaedtler]

Control: tags 1060083 + patch
Control: tags 1060083 + pending


Dear maintainer,

I've prepared an NMU for cgroupfs-mount (versioned as 1.4+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru cgroupfs-mount-1.4/debian/changelog cgroupfs-mount-1.4+nmu1/debian/changelog
--- cgroupfs-mount-1.4/debian/changelog	2017-03-08 23:05:14.0 +0100
+++ cgroupfs-mount-1.4+nmu1/debian/changelog	2024-04-22 01:59:39.0 +0200
@@ -1,3 +1,10 @@
+cgroupfs-mount (1.4+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install initscript mask into /usr/lib (DEP17 M2). (Closes: #1060083)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:59:39 +0200
+
 cgroupfs-mount (1.4) unstable; urgency=medium
 
   * Add a short blurb about installation in README.md
diff -Nru cgroupfs-mount-1.4/debian/links cgroupfs-mount-1.4+nmu1/debian/links
--- cgroupfs-mount-1.4/debian/links	2017-03-08 22:53:04.0 +0100
+++ cgroupfs-mount-1.4+nmu1/debian/links	2024-04-22 01:59:35.0 +0200
@@ -2,4 +2,4 @@
 
 # http://0pointer.de/blog/projects/three-levels-of-off
 # "mask" the cgroupfs-mount service in systemd
-/dev/null lib/systemd/system/cgroupfs-mount.service
+/dev/null usr/lib/systemd/system/cgroupfs-mount.service

Bug#1059409: net-tools: diff for NMU version 2.10-1.1

[Chris Hofstaedtler]

Control: tags 1059409 + patch
Control: tags 1059409 + pending


Dear maintainer,

I've prepared an NMU for net-tools (versioned as 2.10-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru net-tools-2.10/debian/changelog net-tools-2.10/debian/changelog
--- net-tools-2.10/debian/changelog	2023-11-23 15:41:07.0 +0100
+++ net-tools-2.10/debian/changelog	2024-04-22 01:55:29.0 +0200
@@ -1,3 +1,10 @@
+net-tools (2.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Release to unstable. (Closes: #1059409)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:55:29 +0200
+
 net-tools (2.10-1) experimental; urgency=medium
 
   * Move to /usr-merge (DEP17).

Bug#1061239: pam-tmpdir: diff for NMU version 0.09+nmu1

[Chris Hofstaedtler]

Control: tags 1061239 + patch
Control: tags 1061239 + pending


Dear maintainer,

I've prepared an NMU for pam-tmpdir (versioned as 0.09+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru pam-tmpdir-0.09/debian/changelog pam-tmpdir-0.09+nmu1/debian/changelog
--- pam-tmpdir-0.09/debian/changelog	2012-03-08 23:43:05.0 +0100
+++ pam-tmpdir-0.09+nmu1/debian/changelog	2024-04-22 01:48:11.0 +0200
@@ -1,3 +1,11 @@
+pam-tmpdir (0.09+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install into /usr (DEP17 M2) (Closes: #1061239)
+  * Update lintian override to currently correct tag and format.
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:48:11 +0200
+
 pam-tmpdir (0.09) unstable; urgency=low
 
   * Add README.Debian explaining a bit about how pam-tmpdir works.
diff -Nru pam-tmpdir-0.09/debian/lintian-overrides/libpam-tmpdir pam-tmpdir-0.09+nmu1/debian/lintian-overrides/libpam-tmpdir
--- pam-tmpdir-0.09/debian/lintian-overrides/libpam-tmpdir	2012-03-08 23:18:29.0 +0100
+++ pam-tmpdir-0.09+nmu1/debian/lintian-overrides/libpam-tmpdir	2024-04-22 01:48:11.0 +0200
@@ -1 +1 @@
-libpam-tmpdir: setuid-binary sbin/pam-tmpdir-helper 4755 root/root
+libpam-tmpdir: elevated-privileges 4755 root/root [usr/sbin/pam-tmpdir-helper]
diff -Nru pam-tmpdir-0.09/debian/rules pam-tmpdir-0.09+nmu1/debian/rules
--- pam-tmpdir-0.09/debian/rules	2012-03-08 23:47:58.0 +0100
+++ pam-tmpdir-0.09+nmu1/debian/rules	2024-04-22 01:48:06.0 +0200
@@ -8,9 +8,9 @@
 	dh $@ --with autoreconf
 
 override_dh_auto_configure:
-	dh_auto_configure -- --exec-prefix=/ --with-pam-dir=/lib/$(DEB_HOST_MULTIARCH)/security 
+	dh_auto_configure -- --with-pam-dir=/usr/lib/$(DEB_HOST_MULTIARCH)/security
 
 
 override_dh_fixperms:
 	dh_fixperms
-	chmod u+s debian/libpam-tmpdir/sbin/pam-tmpdir-helper
+	chmod u+s debian/libpam-tmpdir/usr/sbin/pam-tmpdir-helper

Bug#1060351: vlan: diff for NMU version 2.0.5+nmu1

[Chris Hofstaedtler]

Control: tags 1060351 + patch
Control: tags 1060351 + pending


Dear maintainer,

I've prepared an NMU for vlan (versioned as 2.0.5+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru vlan-2.0.5/debian/changelog vlan-2.0.5+nmu1/debian/changelog
--- vlan-2.0.5/debian/changelog	2019-02-21 08:29:59.0 +0100
+++ vlan-2.0.5+nmu1/debian/changelog	2024-04-22 01:44:32.0 +0200
@@ -1,3 +1,10 @@
+vlan (2.0.5+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install into /usr for DEP17 M2. (Closes: #1060351)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:44:32 +0200
+
 vlan (2.0.5) unstable; urgency=medium
 
   * debian/network/if-pre-up.d/vlan: add missing biosdevname (Closes: #922801).
diff -Nru vlan-2.0.5/debian/vlan.install vlan-2.0.5+nmu1/debian/vlan.install
--- vlan-2.0.5/debian/vlan.install	2019-02-04 12:11:29.0 +0100
+++ vlan-2.0.5+nmu1/debian/vlan.install	2024-04-22 01:44:27.0 +0200
@@ -1,2 +1,2 @@
 debian/network  etc
-vconfig sbin
+vconfig usr/sbin

Bug#1059412: netcat-openbsd: diff for NMU version 1.226-1.1

[Chris Hofstaedtler]

Control: tags 1059412 + patch
Control: tags 1059412 + pending


Dear maintainer,

I've prepared an NMU for netcat-openbsd (versioned as 1.226-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru netcat-openbsd-1.226/debian/changelog netcat-openbsd-1.226/debian/changelog
--- netcat-openbsd-1.226/debian/changelog	2023-10-16 19:31:08.0 +0200
+++ netcat-openbsd-1.226/debian/changelog	2024-04-22 01:39:53.0 +0200
@@ -1,3 +1,12 @@
+netcat-openbsd (1.226-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install nc.openbsd into /usr/bin. (Closes: #1059412)
+Keep update-alternatives calls unchanged to preserve pre-existing
+user/admin configuration.
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:39:53 +0200
+
 netcat-openbsd (1.226-1) unstable; urgency=medium
 
   [ Guilhem Moulin ]
diff -Nru netcat-openbsd-1.226/debian/netcat-openbsd.install netcat-openbsd-1.226/debian/netcat-openbsd.install
--- netcat-openbsd-1.226/debian/netcat-openbsd.install	2023-10-16 19:31:08.0 +0200
+++ netcat-openbsd-1.226/debian/netcat-openbsd.install	2024-04-22 01:39:51.0 +0200
@@ -1 +1 @@
-nc bin/
+nc usr/bin/
diff -Nru netcat-openbsd-1.226/debian/rules netcat-openbsd-1.226/debian/rules
--- netcat-openbsd-1.226/debian/rules	2023-10-16 19:31:08.0 +0200
+++ netcat-openbsd-1.226/debian/rules	2024-04-22 01:39:51.0 +0200
@@ -39,7 +39,7 @@
 endif
 
 execute_after_dh_install:
-	mv -T $(prefix)/bin/nc $(prefix)/bin/nc.openbsd
+	mv -T $(prefix)/usr/bin/nc $(prefix)/usr/bin/nc.openbsd
 
 execute_after_dh_installman:
 	mv -T $(man1dir)/nc.1 $(man1dir)/nc_openbsd.1

Bug#1059189: quota: diff for NMU version 4.06-1.1

[Chris Hofstaedtler]

Control: tags 1059189 + patch
Control: tags 1059189 + pending


Dear maintainer,

I've prepared an NMU for quota (versioned as 4.06-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru quota-4.06/debian/changelog quota-4.06/debian/changelog
--- quota-4.06/debian/changelog	2021-02-09 13:22:57.0 +0100
+++ quota-4.06/debian/changelog	2024-04-22 01:36:54.0 +0200
@@ -1,3 +1,11 @@
+quota (4.06-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install binary programs into /usr/sbin. (Closes: #1059189)
+  * Update paths to /usr/sbin in (init) scripts, systemd service.
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:36:54 +0200
+
 quota (4.06-1) unstable; urgency=medium
 
   * New upstream version 4.06
diff -Nru quota-4.06/debian/dirs quota-4.06/debian/dirs
--- quota-4.06/debian/dirs	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/dirs	2024-04-22 01:36:52.0 +0200
@@ -1,6 +1,5 @@
 usr/bin
 usr/sbin
-sbin
 etc/init.d
 usr/share/man/man1
 usr/share/man/man2
diff -Nru quota-4.06/debian/quota.init quota-4.06/debian/quota.init
--- quota-4.06/debian/quota.init	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/quota.init	2024-04-22 01:36:52.0 +0200
@@ -13,7 +13,7 @@
 DESC="quota service"
 
 # names of binaries
-on=/sbin/quotaon
+on=/usr/sbin/quotaon
 
 set -e
 
diff -Nru quota-4.06/debian/quota-initial-check.sh quota-4.06/debian/quota-initial-check.sh
--- quota-4.06/debian/quota-initial-check.sh	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/quota-initial-check.sh	2024-04-22 01:36:52.0 +0200
@@ -1,8 +1,8 @@
 #!/bin/sh
 
 # names of binaries
-check=/sbin/quotacheck
-on=/sbin/quotaon
+check=/usr/sbin/quotacheck
+on=/usr/sbin/quotaon
 quotaisnew=/var/lib/quota/new
 
 ALLFLAGS=-aug
diff -Nru quota-4.06/debian/quotaoff.sh quota-4.06/debian/quotaoff.sh
--- quota-4.06/debian/quotaoff.sh	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/quotaoff.sh	2024-04-22 01:36:52.0 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 
 # names of binaries
-off=/sbin/quotaoff
+off=/usr/sbin/quotaoff
 quotaisoff=/var/lib/quota/off
 ALLFLAGS=-aug
 
diff -Nru quota-4.06/debian/quotaon.sh quota-4.06/debian/quotaon.sh
--- quota-4.06/debian/quotaon.sh	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/quotaon.sh	2024-04-22 01:36:52.0 +0200
@@ -1,8 +1,8 @@
 #!/bin/sh
 
 # names of binaries
-check=/sbin/quotacheck
-on=/sbin/quotaon
+check=/usr/sbin/quotacheck
+on=/usr/sbin/quotaon
 quotaisoff=/var/lib/quota/off
 quotaisnew=/var/lib/quota/new
 forcequotacheck=/forcequotacheck
diff -Nru quota-4.06/debian/quotarpc.service quota-4.06/debian/quotarpc.service
--- quota-4.06/debian/quotarpc.service	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/quotarpc.service	2024-04-22 01:36:52.0 +0200
@@ -5,7 +5,7 @@
 PartOf=nfs-server.target
 After=rpcbind.service
 Before=nfs-server.target
-ConditionFileIsExecutable=/sbin/rpcbind
+ConditionFileIsExecutable=/usr/sbin/rpcbind
  
 [Service]
 Type=forking
diff -Nru quota-4.06/debian/rules quota-4.06/debian/rules
--- quota-4.06/debian/rules	2021-02-09 13:05:00.0 +0100
+++ quota-4.06/debian/rules	2024-04-22 01:36:52.0 +0200
@@ -57,10 +57,6 @@
 	# Add here commands to install the package into debian/quota.
 	$(MAKE) DESTDIR=`pwd`/debian/quota install
 
-	-mv `pwd`/debian/quota/usr/sbin/quotacheck `pwd`/debian/quota/sbin
-	-mv `pwd`/debian/quota/usr/sbin/quotaon `pwd`/debian/quota/sbin
-	-mv `pwd`/debian/quota/usr/sbin/quotaoff `pwd`/debian/quota/sbin
-
 # Build architecture-independent files here.
 binary-indep: build install
 # We have nothing to do by default.

Bug#1059178: approx: diff for NMU version 5.12-2.1

[Chris Hofstaedtler]

Control: tags 1059178 + patch
Control: tags 1059178 + pending

Dear maintainer,

I've prepared an NMU for approx (versioned as 5.12-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru approx-5.12/debian/approx.install approx-5.12/debian/approx.install
--- approx-5.12/debian/approx.install	2023-09-10 06:10:50.0 +0200
+++ approx-5.12/debian/approx.install	2024-04-22 01:33:12.0 +0200
@@ -1,5 +1,5 @@
 approx		usr/sbin
 approx-import	usr/sbin
 etc/approx.conf	etc/approx
-etc/approx.socket	lib/systemd/system
-etc/approx@.service	lib/systemd/system
+etc/approx.socket	usr/lib/systemd/system
+etc/approx@.service	usr/lib/systemd/system
diff -Nru approx-5.12/debian/changelog approx-5.12/debian/changelog
--- approx-5.12/debian/changelog	2023-09-10 06:10:50.0 +0200
+++ approx-5.12/debian/changelog	2024-04-22 01:33:25.0 +0200
@@ -1,3 +1,11 @@
+approx (5.12-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units into /usr/lib/systemd/system.
+(Closes: #1059178)
+
+ -- Chris Hofstaedtler   Mon, 22 Apr 2024 01:33:25 +0200
+
 approx (5.12-2) unstable; urgency=medium
 
   * Team upload

Bug#1056901: network-manager-fortisslvpn: 1.4.0-1

[Chris Boot]

Control: severity -1 serious
Control: tags -1 ftbfs
X-Debbugs-Cc: pkg-utopia-maintain...@lists.alioth.debian.org

On 12/01/2024 21:13, Bastian Germann wrote:

On Sun, 26 Nov 2023 11:21:56 + Chris Boot  wrote:

I'm preparing to upload ppp-2.5.0 to unstable, and
network-manager-fortisslvpn fails to build with the updated pppd plugin
API in ppp-2.5.0. I see there is a patch[1] in the GNOME GitLab instance
which may resolve this issue.

Please could you upload a fixed version to unstable soon?

I'll upgrade the bug to RC when I upload ppp-2.5.0 to unstable.


Hi,

I've just uploaded 2.5.0-1+2 to unstable. Please upload a patched 
network-manager-fortisslvpn as soon as you can.


Thanks,
Chris

--
Chris Boot
bo...@debian.org

Bug#1056898: pptpd: Build failures with ppp-2.5.0

[Chris Boot]

Control: severity -1 serious
Control: tags -1 ftbfs

On 26/11/2023 13:06, Christoph Biedl wrote:

Chris Boot wrote...

[...]

I'll upgrade the bug to RC when I upload ppp-2.5.0 to unstable.


Okay, just let me know when it's a good time to upload an updated
pptpd package.


Hi Christoph,

I've just uploaded 2.5.0-1+2 to unstable. Please upload your patched 
pptpd as soon as you can.


Thanks,
Chris

--
Chris Boot
bo...@debian.org

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

[Chris Hofstaedtler]

On Thu, Apr 18, 2024 at 11:29:11PM +0300, Maytham Alsudany wrote:
> +``Static-Built-Using``
> +~~

IMO this should not only state when it is to be used, but also what
it is used for and by whom. IOW who is the intended receiver. What
will they do with the info provided in this field?

> +When a binary is statically linked to libraries in other packages and
> +incorporated into the build process,

Should this also include non-libraries that were included?
publicsuffix is a package providing *data* that is often translated
into binary data during package builds and thus included. But it is
not a "library" in the traditional way.

Chris

Bug#1056574: transition: ppp

[Chris Boot]

On 26/11/2023 11:36, Chris Boot wrote:

On 26/11/2023 10:56, Chris Boot wrote:
Any way to reduce possible breakage, or to detect and fix it before 
the transition starts? Like rebuilding rdeps, or checking rdep 
autopkgtests?


I'll go an do some rebuilds now and see how they go. If any breakage 
occurs it will be obvious at build time.


The status of the rdeps (list taken from the tracker):

connman: OK
network-manager: OK
pptpd: https://bugs.debian.org/1056898
sstp-client: https://bugs.debian.org/1056900

network-manager-fortisslvpn: https://bugs.debian.org/1056901
network-manager-l2tp: OK
network-manager-pptp: OK
network-manager-sstp: https://bugs.debian.org/1056903


All that's left now is pptpd (with an offer from Christoph to upload 
when ready) and network-manager-fortisslvpn (with commits fixing the 
issues upstream, but no upstream release).


In the mean time, #1065940 has become a blocker for the time_t 
transition. I think I'd rather upload 2.5.0 and break 
network-manager-fortisslvpn than just the patch to fix the breakage.


Would the release team be happy to continue with this transition?

Thanks,
Chris

--
Chris Boot
bo...@debian.org

Bug#1068890: diffoscope: --hard-timeout option

[Chris Lamb]

Vagrant Cascadian wrote:

> On 2024-04-16, Chris Lamb wrote:
>> However, I think this first iteration of --hard-timeout time has a few
>> things that would need ironing out first, and potentially make it not
>> worth implementing:
>>
>> (1) You suggest it should start again with "--max-container-depth 3",
>> but it would surely need some syntax (or another option?) to control
>> that "3" (but for the second time only).
>
> What about going the other direction ... starting with a very small
> value for max-container-depth, and incrementally increasing it,
> generating a report (or at least storing sufficient data to generate
> one) in between each increment, so you always get some information, but
> essentially incrementally increase the resolution?
>
> Or would that approach just be too inefficient?

This is probably a separate required best suited to another  issue  at
this point, but I do like the idea  of  being  able  to  incrementally
increase the resolution over time.  Depending  on  how  it  worked  in
practice, there should not be significant overhead  in  managing  this
if, say, the commands that could not be run "in time" would have token
placeholders internally that rendered to text  in  the  output  rather
than non-trivial/expensive binary diffs.

On the negative side though, I think this would still require a robust
way of killing long-running processes  as  outlined  previously.   But
moreover it would require a HUGE reworking of how  diffoscope  handles
containers and recurses into nested structures in its tree-like style.
Indeed, thinking about it, this change would pretty  much  be  exactly
the same work needed to make diffoscope  run  in  parallel  (!)  which
hopefully communicates both the scope of the  changes  that  would  be
needed to achieve this, and that making  diffoscope  run  in  parallel
also  has   other   benefits.Anyway,   mini   brain   dump   over.


Regards,

-- 
  o
⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1068890: diffoscope: --hard-timeout option

[Chris Lamb]

Holger Levsen wrote:

>> (1) You suggest it should start again with "--max-container-depth 3",
>> but it would surely need some syntax (or another option?) to control
>> that "3" (but for the second time only).
>
> another option, --second-pass-max-container-depth or some such
>
>> (2) In fact, its easy to imagine that one would want to restart with
>> other restrictions as well: not just --max-container-depth. For
>> instance, excluding external commands like readelf and objdump that
>> you know to be slow.
>
> yes, that's a good idea and IMO should be automatically implied for the
> 2nd pass or round or try.

It's definitely a "good idea" in the sense that I can  definitely  see
someone   wanting   to   achieve   that   as   an   end   result:)

Yet… upon thinking about it a bit, I don't think it is a good idea  at
all for diffoscope to  grow  a  bunch  of  new  options  or  hardcoded
defaults for a second run.  What (1) and (2) show here is that as soon
as a user would like to adjust these second pass options in  any  way,
then the whole interface becomes very  unwieldy.  Not  only  that, but
from the user's point of view it's neither flexible nor transparent as
well, especially when compared to "just" running diffoscope twice with
different options.  There's no "magic" there, if you see what I  mean.

Can we implement running diffoscope twice  on  tests.r-b.org  manually
first and see how that  goes?   I'm  not  100%  against  the  idea  of
implementing this in diffoscope eventually, but it would make a lot of
sense to try out the "manual" version first and gain  some  real-world
experience first.


Regards,

-- 
  o
⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1067318: autorm ping

[Chris Hofstaedtler]

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

Bug#1059417: ed: diff for NMU version 1.20.1-1.1

[Chris Hofstaedtler]

Control: tags 1059417 + patch
Control: tags 1059417 + pending


Dear maintainer,

I've prepared an NMU for ed (versioned as 1.20.1-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru ed-1.20.1/debian/changelog ed-1.20.1/debian/changelog
--- ed-1.20.1/debian/changelog	2024-02-17 12:12:41.0 +0100
+++ ed-1.20.1/debian/changelog	2024-04-17 14:22:21.0 +0200
@@ -1,3 +1,12 @@
+ed (1.20.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install ed, red into /usr/bin. (Closes: #1059417)
+Keep update-alternatives calls unchanged, to preserve existing
+user configuration.
+
+ -- Chris Hofstaedtler   Wed, 17 Apr 2024 14:22:21 +0200
+
 ed (1.20.1-1) unstable; urgency=medium
 
   * New upstream version 1.20.1
diff -Nru ed-1.20.1/debian/rules ed-1.20.1/debian/rules
--- ed-1.20.1/debian/rules	2024-02-17 12:12:41.0 +0100
+++ ed-1.20.1/debian/rules	2024-04-17 14:21:33.0 +0200
@@ -12,7 +12,7 @@
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --bindir=/bin $(CROSS) \
+	dh_auto_configure -- $(CROSS) \
 	  $(foreach v,CPPFLAGS CFLAGS LDFLAGS,'$(v)=$($(v))')
 
 override_dh_auto_test:

Bug#1069169: gap-polymaking: please make the build reproducible

[Chris Lamb]

Source: gap-polymaking
Version: 0.8.7-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
gap-polymaking could not be built reproducibly.

This is because the .tst files *AND* its surrounding directory will
retain its group-writeable bit due to the use of dh_fixperms -Xtst,
and will thus vary when the package is built with a different umask.

A patch is attached that limits the "-Xtst" → "-X.tst" (to prevent the
surrounding "/tst/" directory being matched), and then normalises the
group-writable bits of the .tst files themselves.

 [0] https://reproducible-builds.org/


Regards,

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


--- a/debian/rules  2024-04-17 11:00:54.347285261 +0100
--- b/debian/rules  2024-04-17 11:10:56.519616668 +0100
@@ -25,7 +25,8 @@
make -C doc install DESTDIR=../debian/gap-polymaking
 
 override_dh_fixperms:
-   dh_fixperms -Xtst
+   dh_fixperms -X.tst
+   chmod g-w debian/gap-polymaking/usr/share/gap/pkg/polymaking/tst/*.tst
 
 override_dh_installdocs:
dh_installdocs README.md

Bug#1069168: sagemath-database-conway-polynomials: please make the build reproducible

[Chris Lamb]

Source: sagemath-database-conway-polynomials
Version: 0.9-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
sagemath-database-conway-polynomials could not be built reproducibly.

This is because it shipped .pyc files in the binary package which are
not reproducible. This was caused by dh_python3 not cleaning the build
tree before the .deb was assembled, which, in turn, was because
pybuild could not determine which binary packages to act upon.

Adding ${python3:Depends} to the (single) binary package fixes this
and thus makes the package reproducible.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

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

--- a/debian/control2024-04-17 11:00:50.303242241 +0100
--- b/debian/control2024-04-17 11:03:45.412887051 +0100
@@ -13,7 +13,7 @@
 Package: sagemath-database-conway-polynomials
 Architecture: all
 Multi-Arch: foreign
-Depends: ${misc:Depends}
+Depends: ${misc:Depends}, ${python3:Depends}
 Description: Database of Conway polynomials
  This package contains a small database of Conway polynomials, for
  primes up to 109987 and a various number of exponents.

Bug#1069167: apt: Please provide lock wait timeout for /var/lib/apt/lists/lock

[Chris Hofstaedtler]

Package: apt
Version: 2.6.1
Severity: wishlist

Dear APT maintainers,

thanks for implementing DPkg::Lock::Timeout. This is very useful for
dpkg. A similar option would be very welcome for `apt update`, i.e. the
lockfile usually placed at /var/lib/apt/lists/lock.

Without this, scheduled/timed `apt-get update` executions (correctly)
block manually started `apt-get update` executions, but the manual
execution also fails. The failure behaviour is somewhat annoying in
deployment scripts, where it can be worked around with a busy loop, but
I think this is less than ideal.

TL;DR: please provide an option for `apt-get update` to wait on its
lock.

Thanks,
Chris

Bug#1068890: diffoscope: --hard-timeout option

[Chris Lamb]

Holger Levsen wrote:

> Anyhow, about my --hard-timeout option idea:
>
> my idea of "--hard-timeout $time" is that diffoscope terminates itself 
> after $time, no matter what *and* then re-starts itself with 
> "--max-container-depth 3"

Just to say that I am totally on board with the idea of ensuring we
get _something_ out of diffoscope on tests.reproducible-builds.org.
Way better than 250 timeouts.

However, I think this first iteration of --hard-timeout time has a few
things that would need ironing out first, and potentially make it not
worth implementing:

(1) You suggest it should start again with "--max-container-depth 3",
but it would surely need some syntax (or another option?) to control
that "3" (but for the second time only).

(2) In fact, its easy to imagine that one would want to restart with
other restrictions as well: not just --max-container-depth. For
instance, excluding external commands like readelf and objdump that
you know to be slow.

(3) The output might need some comment saying "this was re-run with
restrictions as we hit a timeout".

(4) My gut feel that it would not be all that great to rely on CPython
to really properly clear up child processes after a certain amount of
time. Although I believe the most reliable top-level description to do
this kind of thing inside CPython is to start a watchdog thread that
sleeps until the timeout and then tries to kill everything, but my
experience of doing anything like this within Python itself is not
great, and essentially always needed something at the process level
outside of it for it to be reliable. A container would be even more
effective, I'm sure.

In other words, I think the best way of achieving the result we want
is, alas, by doing it outside of diffoscope at the level of the
Jenkins. As in, exactly what you describe here:

> Else we could also extend the current code for tests.r-b.o/debian, 
> which currently
> just kills diffoscope after 2h, to then run diffoscope 
> --max-container-depth 3 :)

Is that a massive faff?  :/


Best wishes,

-- 
  o
⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1058823: usbauth: diff for NMU version 1.0.5-1.1

[Chris Hofstaedtler]

Control: tags 1058823 + patch
Control: tags 1058823 + pending

Dear maintainer,

I've prepared an NMU for usbauth (versioned as 1.0.5-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru usbauth-1.0.5/debian/changelog usbauth-1.0.5/debian/changelog
--- usbauth-1.0.5/debian/changelog	2023-01-11 09:51:24.0 +0100
+++ usbauth-1.0.5/debian/changelog	2023-12-16 22:35:58.0 +0100
@@ -1,3 +1,11 @@
+usbauth (1.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use udev.pc to place udev files. (Closes: #1058823)
+  * Switch from obsolete pkg-config to pkgconf.
+
+ -- Chris Hofstaedtler   Sat, 16 Dec 2023 22:35:58 +0100
+
 usbauth (1.0.5-1) unstable; urgency=medium
 
   [ Kun-Hung Tsai (蔡昆宏) ]
diff -Nru usbauth-1.0.5/debian/control usbauth-1.0.5/debian/control
--- usbauth-1.0.5/debian/control	2023-01-11 09:50:44.0 +0100
+++ usbauth-1.0.5/debian/control	2023-12-16 22:35:58.0 +0100
@@ -4,14 +4,15 @@
 Maintainer: Kun-Hung Tsai (蔡昆宏) 
 Uploaders: SZ Lin (林上智) 
 Build-Depends: debhelper-compat (= 13),
-   pkg-config,
automake,
flex,
bison,
libudev-dev,
libusbauth-configparser-dev,
libdbus-1-dev,
-   m4
+   m4,
+   pkgconf,
+   systemd-dev
 Standards-Version: 4.6.1
 Homepage: https://github.com/kochstefan/usbauth-all/tree/master/usbauth
 Vcs-Git: https://salsa.debian.org/debian/usbauth.git
diff -Nru usbauth-1.0.5/debian/rules usbauth-1.0.5/debian/rules
--- usbauth-1.0.5/debian/rules	2023-01-11 09:50:44.0 +0100
+++ usbauth-1.0.5/debian/rules	2023-12-16 22:35:58.0 +0100
@@ -6,5 +6,8 @@
 %:
 	dh $@
 
+override_dh_auto_install:
+	dh_auto_install -- udevrulesdir=$(shell pkg-config --variable=udevdir udev)/rules.d
+
 override_dh_missing:
 	dh_missing --fail-missing

Bug#1057804: guestfsd: move /lib/udev/rules.d/99-guestfs-serial.rules into /usr

[Chris Hofstaedtler]

Hi Hilko,

On Fri, Dec 08, 2023 at 06:28:14PM +0100, Chris Hofstaedtler wrote:
> your package installs a udev rule, into
> /lib/udev/rules.d/99-guestfs-serial.rules. This path appears
> hard-coded in the Debian packaging. Please move the rule into
> /usr/lib/udev, in trixie.

I see a number of uploads since this bug was filed. Did you see the
bug?

Thanks,
Chris

Bug#1057779: hdparm: diff for NMU version 9.65+ds-1.1

[Chris Hofstaedtler]

Control: tags 1057779 + patch
Control: tags 1057779 + pending


Dear maintainer,

I've prepared an NMU for hdparm (versioned as 9.65+ds-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru hdparm-9.65+ds/debian/95hdparm-apm hdparm-9.65+ds/debian/95hdparm-apm
--- hdparm-9.65+ds/debian/95hdparm-apm	2022-10-06 14:47:47.0 +0200
+++ hdparm-9.65+ds/debian/95hdparm-apm	2024-04-16 09:54:44.0 +0200
@@ -29,7 +29,7 @@
 fi
 fi
 
-. /lib/hdparm/hdparm-functions
+. /usr/lib/hdparm/hdparm-functions
 
 resume_hdparm_apm()
 {
diff -Nru hdparm-9.65+ds/debian/changelog hdparm-9.65+ds/debian/changelog
--- hdparm-9.65+ds/debian/changelog	2022-10-06 15:33:00.0 +0200
+++ hdparm-9.65+ds/debian/changelog	2024-04-16 09:54:44.0 +0200
@@ -1,3 +1,14 @@
+hdparm (9.65+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move all files below /usr (Closes: #1057779)
+  * Drop Build-Depends: lsb-base (obsolete).
+
+  [ Debian Janitor ]
+  * Set upstream metadata fields: Archive, Bug-Database.
+
+ -- Chris Hofstaedtler   Tue, 16 Apr 2024 09:54:44 +0200
+
 hdparm (9.65+ds-1) unstable; urgency=medium
 
   * New upstream release (Closes: #1018078).
diff -Nru hdparm-9.65+ds/debian/control hdparm-9.65+ds/debian/control
--- hdparm-9.65+ds/debian/control	2022-10-06 15:20:31.0 +0200
+++ hdparm-9.65+ds/debian/control	2024-04-16 09:54:44.0 +0200
@@ -13,8 +13,7 @@
 Package: hdparm
 Architecture: any
 Depends: ${shlibs:Depends},
- ${misc:Depends},
- lsb-base
+ ${misc:Depends}
 Recommends: powermgmt-base
 Description: tune hard disk parameters for high performance
  Get/set device parameters for Linux SATA/IDE drives.
diff -Nru hdparm-9.65+ds/debian/hdparm.conf hdparm-9.65+ds/debian/hdparm.conf
--- hdparm-9.65+ds/debian/hdparm.conf	2022-10-06 14:47:47.0 +0200
+++ hdparm-9.65+ds/debian/hdparm.conf	2024-04-16 09:54:44.0 +0200
@@ -5,7 +5,7 @@
 ## ignored, so you can space control fields as you like.  ANYTHING ELSE
 ## IS PARSED!!  This means that lines with stray characters or lines that
 ## use non # comment characters will be interpreted by the helper scripts (
-## /lib/udev/hdparm, /usr/lib/pm-utils/power.d/95hdparm-apm ).
+## /usr/lib/udev/hdparm, /usr/lib/pm-utils/power.d/95hdparm-apm ).
 ## This has probably minor, but potentially serious, side effects for your
 ## hard drives, so please follow the guidelines.  Patches to improve
 ## flexibilty welcome.  Please read /usr/share/doc/hdparm/README.Debian for
@@ -19,13 +19,13 @@
 ##
 ## If an option is listed twice, the second instance replaces the first.
 ##
-## /sbin/hdparm parses blocks of the form:
+## /usr/sbin/hdparm parses blocks of the form:
 ##  DEV {
 ## option
 ## option
 ## ...
 ##  }
-## This blocks will cause /sbin/hdparm OPTIONS DEV to be run.
+## This blocks will cause /usr/sbin/hdparm OPTIONS DEV to be run.
 ## Where OPTIONS is the concatenation of all options previously defined
 ## outside of a block and all options defined with in the block.
 
diff -Nru hdparm-9.65+ds/debian/hdparm.conf.5 hdparm-9.65+ds/debian/hdparm.conf.5
--- hdparm-9.65+ds/debian/hdparm.conf.5	2022-10-06 14:47:47.0 +0200
+++ hdparm-9.65+ds/debian/hdparm.conf.5	2024-04-16 09:54:44.0 +0200
@@ -18,7 +18,7 @@
 .LP
 or by calling
 .LP
-.B DEVNAME=/dev/ /lib/udev/hdparm
+.B DEVNAME=/dev/ /usr/lib/udev/hdparm
 .LP
 Note that an in\-line comment is not supported.  If a line
 consists of whitespace only (tabs, spaces, carriage return), it will be
diff -Nru hdparm-9.65+ds/debian/hdparm.install hdparm-9.65+ds/debian/hdparm.install
--- hdparm-9.65+ds/debian/hdparm.install	2022-10-06 14:47:47.0 +0200
+++ hdparm-9.65+ds/debian/hdparm.install	2024-04-16 09:54:44.0 +0200
@@ -1,9 +1,9 @@
 debian/hdparm.conf	etc/
-debian/hdparm-functions lib/hdparm/
+debian/hdparm-functions usr/lib/hdparm/
 debian/95hdparm-apm	usr/lib/pm-utils/power.d/
-debian/tmp/sbin/hdparm
-debian/udev-scripts/hdparm	lib/udev/
-debian/systemd-sleep/hdparm	lib/systemd/system-sleep/
+debian/tmp/usr/sbin/hdparm
+debian/udev-scripts/hdparm	usr/lib/udev/
+debian/systemd-sleep/hdparm	usr/lib/systemd/system-sleep/
 
 wiper/wiper.sh		usr/share/doc/hdparm/wiper
 wiper/README.txt	usr/share/doc/hdparm/wiper
diff -Nru hdparm-9.65+ds/debian/hdparm-udeb.install hdparm-9.65+ds/debian/hdparm-udeb.install
--- hdparm-9.65+ds/debian/hdparm-udeb.install	2022-10-06 14:47:47.0 +0200
+++ hdparm-9.65+ds/debian/hdparm-udeb.install	2024-04-16 09:54:44.0 +0200
@@ -1 +1 @@
-debian/tmp/sbin/hdparm
+debian/tmp/usr/sbin/hdparm
diff -Nru hdparm-9.65+ds/debian/hdparm.udev hdparm-9.65+ds/debian/hdparm.udev
--- hdparm-9.65+ds/debian/hdparm.udev	2022-10-06 14:47:47.0 +0200
+++ hdparm-9.65+ds/debian/hdparm.udev	2024-04-16 09:54:44.0 +0200
@@ -1,2 +1,2 @@
-ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]", R

Bug#1057742: amazon-ec2-utils: diff for NMU version 2.1.0-1.1

[Chris Hofstaedtler]

Control: tags 1057742 + patch
Control: tags 1057742 + pending


Dear maintainer,

I've prepared an NMU for amazon-ec2-utils (versioned as 2.1.0-1.1) and
uploaded it to DELAYED/7.

Chris

diff -Nru amazon-ec2-utils-2.1.0/debian/amazon-ec2-utils.install amazon-ec2-utils-2.1.0/debian/amazon-ec2-utils.install
--- amazon-ec2-utils-2.1.0/debian/amazon-ec2-utils.install	2023-09-30 00:40:28.0 +0200
+++ amazon-ec2-utils-2.1.0/debian/amazon-ec2-utils.install	2024-04-16 09:49:49.0 +0200
@@ -1,4 +1,4 @@
 ebsnvme-id /usr/sbin/
 ec2-metadata /usr/bin/
-ec2nvme-nsid /lib/udev/
-70-ec2-nvme-devices.rules /lib/udev/rules.d/
+ec2nvme-nsid ${env:deb_udevdir}/
+70-ec2-nvme-devices.rules ${env:deb_udevdir}/rules.d/
diff -Nru amazon-ec2-utils-2.1.0/debian/changelog amazon-ec2-utils-2.1.0/debian/changelog
--- amazon-ec2-utils-2.1.0/debian/changelog	2023-09-30 01:18:53.0 +0200
+++ amazon-ec2-utils-2.1.0/debian/changelog	2024-04-16 09:49:54.0 +0200
@@ -1,3 +1,10 @@
+amazon-ec2-utils (2.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Delegate placement of udev files to udev.pc. (Closes: #1057742)
+
+ -- Chris Hofstaedtler   Tue, 16 Apr 2024 09:49:54 +0200
+
 amazon-ec2-utils (2.1.0-1) unstable; urgency=medium
 
   * New upstream release 2.1.0
diff -Nru amazon-ec2-utils-2.1.0/debian/control amazon-ec2-utils-2.1.0/debian/control
--- amazon-ec2-utils-2.1.0/debian/control	2023-09-30 00:40:28.0 +0200
+++ amazon-ec2-utils-2.1.0/debian/control	2024-04-16 09:49:49.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Cloud Team 
 Uploaders: Noah Meyerhans 
-Build-Depends: debhelper-compat (= 12)
+Build-Depends: debhelper-compat (= 13), pkgconf, systemd-dev
 Standards-Version: 4.5.0
 Homepage: https://github.com/aws/amazon-ec2-utils
 Vcs-Browser: https://salsa.debian.org/cloud-team/amazon-ec2-utils
diff -Nru amazon-ec2-utils-2.1.0/debian/rules amazon-ec2-utils-2.1.0/debian/rules
--- amazon-ec2-utils-2.1.0/debian/rules	2023-09-30 00:40:28.0 +0200
+++ amazon-ec2-utils-2.1.0/debian/rules	2024-04-16 09:49:49.0 +0200
@@ -3,5 +3,7 @@
 # output every command that modifies files on the build system.
 #export DH_VERBOSE = 1
 
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev)
+
 %:
 	dh $@

Bug#1056975: dphys-swapfile: diff for NMU version 20100506-7.2

[Chris Hofstaedtler]

Control: tags 1056975 + patch
Control: tags 1056975 + pending


Dear maintainer,

I've prepared an NMU for dphys-swapfile (versioned as 20100506-7.2) and
uploaded it to DELAYED/7.

Chris

diff -Nru dphys-swapfile-20100506/debian/changelog dphys-swapfile-20100506/debian/changelog
--- dphys-swapfile-20100506/debian/changelog	2022-10-15 12:01:41.0 +0200
+++ dphys-swapfile-20100506/debian/changelog	2024-04-16 09:38:00.0 +0200
@@ -1,3 +1,10 @@
+dphys-swapfile (20100506-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr/sbin instead of /sbin. (Closes: #1056975)
+
+ -- Chris Hofstaedtler   Tue, 16 Apr 2024 09:38:00 +0200
+
 dphys-swapfile (20100506-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dphys-swapfile-20100506/debian/dirs dphys-swapfile-20100506/debian/dirs
--- dphys-swapfile-20100506/debian/dirs	2016-10-24 01:10:58.0 +0200
+++ dphys-swapfile-20100506/debian/dirs	2024-04-16 09:37:36.0 +0200
@@ -1,2 +1,2 @@
-sbin
 etc
+usr/sbin
diff -Nru dphys-swapfile-20100506/debian/patches/series dphys-swapfile-20100506/debian/patches/series
--- dphys-swapfile-20100506/debian/patches/series	2021-01-17 03:22:11.0 +0100
+++ dphys-swapfile-20100506/debian/patches/series	2024-04-16 09:37:36.0 +0200
@@ -3,3 +3,4 @@
 change-example-from-var-run-to-var-tmp.patch
 replace-p-q-with-p-for-newer-dc.patch
 disable-swap-copy-on-write-for-copy-on-write-file-systems.patch
+usr-sbin.patch
diff -Nru dphys-swapfile-20100506/debian/patches/usr-sbin.patch dphys-swapfile-20100506/debian/patches/usr-sbin.patch
--- dphys-swapfile-20100506/debian/patches/usr-sbin.patch	1970-01-01 01:00:00.0 +0100
+++ dphys-swapfile-20100506/debian/patches/usr-sbin.patch	2024-04-16 09:37:36.0 +0200
@@ -0,0 +1,35 @@
+Index: dphys-swapfile-20100506/Makefile
+===
+--- dphys-swapfile-20100506.orig/Makefile
 dphys-swapfile-20100506/Makefile
+@@ -22,10 +22,6 @@ MAN8DIR = $(PREFIX)/share/man/man8
+ DOCDIR  = $(PREFIX)/share/doc/dphys-swapfile
+ EXADIR  = $(DOCDIR)/examples
+ 
+-# use R_PREFIX (root prefix) as not in /usr, this is early run start up stuff
+-R_PREFIX  = $(DESTDIR)
+-R_SBINDIR = $(R_PREFIX)/sbin
+-
+ 
+ # --- code for acting out the various  make  targets
+ 
+@@ -38,8 +34,8 @@ clean:
+ distclean: clean
+ 
+ install:
+-	@mkdir -p $(R_SBINDIR)
+-	@cp -p dphys-swapfile   $(R_SBINDIR)
++	@mkdir -p $(SBINDIR)
++	@cp -p dphys-swapfile   $(SBINDIR)
+ 
+ 	@mkdir -p $(MAN8DIR)
+ 	@cp -p dphys-swapfile.8.gz  $(MAN8DIR)
+@@ -55,7 +51,7 @@ uninstall:
+ 
+ 	@rm -f $(MAN8DIR)/dphys-swapfile.8.gz
+ 
+-	@rm -f $(R_SBINDIR)/dphys-swapfile
++	@rm -f $(SBINDIR)/dphys-swapfile
+ 
+ 
+ # --- project management stuff

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#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye

[Chris Lamb]

Fay Stegerman wrote:

> https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/140

Nice; I have applied this locally in Git and will release shortly. :)


Regards,

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

Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble

[Chris Knadle]

Hello Remus-Gabriel.

Okay I've queued up the Romanian translation file to be included with 
the next upload of Mumble.


There are several library transitions going on in Debian, so I'm going 
to wait a bit for those.


I also did an NMU on zeroc-ice which was blocked from transition to 
Testing due to a FTBFS bug related to the time_t transition because of a 
newly enabled build flag that caused the build to break with an error.


Let me know if you've contacted Mumble upstream about the Romanian 
translation; if not I'll contact them to see if we can get it included 
in the source directly.


On 4/9/24 18:11, Remus-Gabriel Chelu wrote:

Hello Chris,

În 08.04.2024 22:22, Chris Knadle a scris:

Is it as simple as renaming the mumble_debconf_ro.po file to ro.po 
and moving it to debian/po/ro.po ?


Yes, this is the way to introduce translation within the project, or, 
even simpler:


mv mumble_debconf_ro.po debian/po/ro.po

renaming and moving into a single command.


Respects,
Remus-Gabriel

PS: Sorry for the inconvenience caused, I grouped into my machine 
several translation files (of
several programs) in the same folder, for their own convenience; so I 
had to differentiate them
somehow from each other, and I chose to prefix their names with the 
name of the program for which

they are made.


The only inconvenience was not knowing how to incorporate the file into 
the Debian package -- the workflow described above makes sense. As long 
as I know what to do and can make the time I'm willing to do the work 
needed to incorporate desired changes.


Thanks very much for your work

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

Bug#1068844: nmu: tuxmath_2.0.3-9

[Chris Hofstaedtler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: tuxm...@packages.debian.org
Control: affects -1 + src:tuxmath

nmu tuxmath_2.0.3-9 . armel armhf s390x . unstable . -m "Rebuild for time_t"

Please rebuild tuxmath on the listed archs now that t4kcommon has built
on those archs.

Chris

Bug#1068843: nmu: libnbd_1.20.0-1

[Chris Hofstaedtler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libnbd

nmu libnbd_1.20.0-1 . ANY . unstable . -m "Rebuild on buildds"

Please rebuild libnbd to replace the profile nocheck builds on armhf,
armel.

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#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye

[Chris Lamb]

tags 1068705 + pending
thanks

Fay Stegerman wrote:

> The attached patch avoids the crash in this case, FWIW. […]

Applied in Git with attribution taken from your email.

> I would still recommend catching the error for other cases.

Fixed as well. And it adds a nice comment displaying the issue.


Regards,

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

Bug#1068795: pympress: please make the build reproducible

[Chris Lamb]

Source: pympress
Version: 1.8.5-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
pympress could not be built reproducibly.

This is because the generated documentation included memory references
such as the following:

  pointer = 

A patch attached that uses Python's "default = None […] if default is
None: default = realdefault" pattern.

 [0] https://reproducible-builds.org/


Regards,

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


--- a/debian/patches/0005-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0005-Reproducible-build.patch  2024-04-11 
09:53:13.602746588 +0100
@@ -0,0 +1,41 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-11
+
+--- pympress-1.8.5.orig/pympress/app.py
 pympress-1.8.5/pympress/app.py
+@@ -150,11 +150,14 @@ class Pympress(Gtk.Application):
+ Gtk.Application.do_startup(self)
+ 
+ 
+-def do_activate(self, timestamp=GLib.get_current_time()):
++def do_activate(self, timestamp=None):
+ """ Activate: show UI windows.
+ 
+ Build them if they do not exist, otherwise bring to front.
+ """
++if timestamp is None:
++timestamp = GLib.get_current_time()
++
+ if self.gui is None:
+ if self.auto_log_level:
+ self.activate_action('log-level', logging.INFO)
+--- pympress-1.8.5.orig/pympress/pointer.py
 pympress-1.8.5/pympress/pointer.py
+@@ -57,7 +57,7 @@ class Pointer(object):
+ builder (:class:`~pympress.builder.Builder`): A builder from which to 
load widgets
+ """
+ #: :class:`~GdkPixbuf.Pixbuf` to read XML descriptions of GUIs and load 
them.
+-pointer = GdkPixbuf.Pixbuf()
++pointer = None
+ #: `(float, float)` of position relative to slide, where the pointer 
should appear
+ pointer_pos = (.5, .5)
+ #: `bool` indicating whether we should show the pointer
+@@ -84,6 +84,7 @@ class Pointer(object):
+ 
+ def __init__(self, config, builder):
+ super(Pointer, self).__init__()
++self.pointer = GdkPixbuf.Pixbuf()
+ self.config = config
+ 
+ builder.load_widgets(self)
--- a/debian/patches/series 2024-04-11 09:37:21.205740724 +0100
--- b/debian/patches/series 2024-04-11 09:48:11.045127589 +0100
@@ -1,3 +1,4 @@
 0002-intersphinx.patch
 0003-README-privacy.patch
 0004-Options-privacy.patch
+0005-Reproducible-build.patch

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#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye

[Chris Lamb]

Fay Stegerman wrote:

> Salsa is probably better for figuring out what to do next, but I get
> these mails too :)

Oh, hey! o/

> unzip does seem to extract all the files, though it errors out.  Not sure what
> diffoscope should do here.  This is definitely a broken ZIP file.

First; great debugging there, thank you. :)

Okay, separate from your suggestion that a bug should be filed against
libscout with its broken zip file, I think that diffoscope should not
traceback and crash on this particular input. We do this elsewhere with
(most) invalid inputs and it makes a lot of sense here as well.

I'll modify diffoscope tomorrow morning to catch the specific
exception being thrown by Python's builtin zipfile module and add a
suitable message as a user-visible 'comment' — again, something we have
plenty of prior art for elsewhere in the codebase. Thanks again.


Best wishes,

-- 
  o
    ⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye

[Chris Lamb]

Holger Levsen wrote:

> when building libscout 2.3.2-3 on current unstable, the result is also 
> unreproducible, but diffoscope crashes when analysing the diff.

I think this is somewhat related to:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/362

… which was said to be fixed by Fay in cc3b077f6ef97b4e20036e9823926fe633c7d4d0
that released as diffoscope version 263 on 2024-04-05.

However, I can see that the current output of libscout/amd64 on
tests.reproducible-builds.org is failing with this very version:

  Tue Apr  9 12:14:14 UTC 2024  I: diffoscope 263 will be used to compare the 
two builds:

  From https://gist.github.com/lamby/e5db96d4d61612485a469b826590192e/raw
  (saved output for posterity)

Will loop Fay in via Salsa presently.


Regards,

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

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#1068377: python-oslo.messaging: please make the build reproducible

[Chris Lamb]

Thomas Goirand wrote:

> However, a better patch would be to use the sample_default= directive of 
> oslo.config, which is printing in the generated doc, whatever the value 
> of sample_default, while continuing to keep the default= value that can 
> contain something programmatic. This avoids writing the "if blah is 
> None" as you've put it.

Ah — now I remember this was introduced a while back for precisely
this reason. Many thanks. :)


Regards,

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

Bug#1068691: util-linux: enosys program missing on m68k and sh4

[Chris Hofstaedtler]

Hi,

* John Paul Adrian Glaubitz  [240409 09:36]:
> the program enosys doesn't seem to be available on m68k and sh4, so it needs 
> to
> be excluded from the install files with the help of dh-exec:

I imagine the other option is to expand audit-arch.h to cover these
archs. Do you mind reviewing this, then I could sent it upstream? Do
note that I've mostly guessed what might be right.

Relevant uapi header:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/audit.h#L432

diff --git a/include/audit-arch.h b/include/audit-arch.h
index ade182417..9afc663cd 100644
--- a/include/audit-arch.h
+++ b/include/audit-arch.h
@@ -35,6 +35,8 @@
 #endif
 #elif __powerpc__
 #define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PPC
+#elif __m68k__
+#define SECCOMP_ARCH_NATIVE AUDIT_ARCH_M68K
 #elif __mips__
 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 #   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_MIPS
@@ -47,6 +49,12 @@
 #else
 #   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_ARCV2
 #endif
+#elif __sh__
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SH
+#else
+#   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SHEL
+#endif
 #elif __sparc__
 #if __SIZEOF_POINTER__ == 4
 #   define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SPARC

Bug#1068377: python-oslo.messaging: please make the build reproducible

[Chris Lamb]

affects 1068377 + zaqar
thanks

Chris Lamb wrote:

> > Whilst working on the Reproducible Builds effort [0], we noticed that
> > python-oslo.messaging could not be built reproducibly.
>
> The underlying bit of code is actually also causing src:magnum to be
> unreproducible as well.

And zaqar. :)


Regards,

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

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#1032807: [INTL:ro] Romanian debconf templates translation of mumble

[Chris Knadle]

Hello Remus-Gabriel.

I would like to know how to incorporate the Romanian translation file 
into the Mumble 1.5.517 package.


Is it as simple as renaming the mumble_debconf_ro.po file to ro.po and 
moving it to debian/po/ro.po ?


It has been some time since I've dealt with translation files and I'm 
trying to figure out if there's something special necessary to do with 
the translation file for the packaging.


Thanks
   -- Chris

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


On 4/5/23 19:18, Remus-Gabriel Chelu wrote:

3 aprilie 2023 la 07:44, "Chris Knadle"  a scris:

[...]

Hello, Chris!

I just finished checking the status of the debconf-mumble translation file (in
Romanian) with the following commands:

$: git clone https://salsa.debian.org/pkg-voip-team/mumble
$: cp -v ../Documente/mumble_debconf_ro.po mumble/debian/po/ro.po
$: LANG=en msgfmt -c -v -o /dev/null mumble/debian/po/ro.po
8 translated messages.

and:

#: cd mumble/
#: podebconf-display-po -fdialog debian/po/ro.po

with good results; exactly as expected.

So, from my side, considering the results of the test performed, the "ro.po" 
file
can be added to mumble 1.5.517 without any problems.

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#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

* Iker Pedrosa  [240408 09:19]:
> > >- Did you consider using a systemd service to upgrade from lastlog to
> > >lastlog2 data?
> >
> > No, I did not consider this, as I wasn't aware of any
> > implementations for this. Does u-l upstream ship such a service?
> >
> 
> Yes,
> https://github.com/util-linux/util-linux/blob/master/misc-utils/lastlog2-import.service.in

Thanks!

ISTM we could do this in the postinst script instead, to avoid
installing single-use services on all systems.

Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

* Colin Watson  [240408 10:55]:
> On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote:
> > On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:
> > > util-linux upstream provides three binary objects to be built:
> > > - liblastlog2.so
> > > - pam_lastlog2.so
> > > - lastlog2 (program)
> > >
> > > Debian's PAM policy says to put PAM modules into their own package,
> > > thus libpam-lastlog2. liblastlog2.so would go into the
> > >
> > liblastlog2(-0) package. The lastlog2 program either into its own
> > > lastlog2 package, or elsewhere.
> > >
> > 
> > Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
> > pam modules start with the prefix pam_*.
> 
> The file names do, but the package names almost always start with
> "libpam-".  (Also, Debian package names may not contain "_".)
> 
>   $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
> ^libpam-
>   68
>   $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
> ^pam-
>   1
> 
> And the Debian PAM mini-policy says:
> 
>   1) Packages should use the naming scheme of `libpam-' (eg.
>   libpam-ldap).

Indeed. To clarify, because I think there is still some ongoing
confusion regarding binary files and binary packages, here a table:

Debian package name  | (primary) file(s)

liblastlog2-0| /usr/lib/.../liblastlog2.so.*
libpam-lastlog2  | /usr/lib/.../pam_lastlog2.so
lastlog2 | /usr/bin/lastlog2 (probably + symlink "last")

I think my biggest open questions for the packaging itself are:

* Which package will pull in lastlog2 and libpam-lastlog2, for
  for upgrades from bookworm?

* Should /usr/bin/lastlog2 be in a separate lastlog2 package or not?

* Should lastlog2 Depend: libpam-lastlog2? Vice versa? Only
  Recommends?

Chris

Bug#1068377: python-oslo.messaging: please make the build reproducible

[Chris Lamb]

affects 1068377 + magnum
thanks

Chris Lamb wrote:

> Whilst working on the Reproducible Builds effort [0], we noticed that
> python-oslo.messaging could not be built reproducibly.

The underlying bit of code is actually also causing src:magnum to be
unreproducible as well.


Regards,

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

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#1068504: mumble-server: wrong path for systemd-sysusers file

[Chris Knadle]

Greetings.

As far as I know /etc/sysconfig.d/ is a directory used by Fedora/Red Hat 
based distros, not Debian.


Looking through the Git log I see I added this on Feb 1 2023 with the 
following commit message:


    add etc/sysconfid./mumble-server.conf as the build breaks without 
it at compat 13

    (it's commit f0cdad5245c6d1de6bff9223c6ce5767c13f9e45)

/usr/lib/sysusers.d/*.conf does seem like where this file should go.

I've made local Git commits to fix this for the next bugfix upload 
(1.5.517-3). Before doing any more uploads I need to look at what's 
going on with a number of library transitions going on that could get 
negatively affected by uploads of mumble.


   -- Chris

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

On 4/6/24 09:12, Stefan Schweizer via Pkg-voip-maintainers wrote:

Package: mumble-server
Severity: normal

Hi,

mumble-server installs a systemd-sysusers file to /etc/sysconfig.d

According to the sysusers.d(5) man page sysusers files can be placed in
/etc/sysusers.d/*.conf
/run/sysusers.d/*.conf
/usr/lib/sysusers.d/*.conf

So installing the sysusers file to /etc/sysconfig.d has no
effect and it should be moved to /usr/lib/sysusers.d.

Since the mumble-server user is created by the debian package I think
the sysusers file is unnecessary and can be omitted until a switch to
sysusers is made.

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi,

* Iker Pedrosa  [240403 09:43]:
> Hi Chris,
> 
> I have some questions regarding your proposal:
> 
>- What is the difference between liblastlog2 and libpam-lastlog2
>binaries? Upstream util-linux only provides one binary (lastlog2) so this
>confuses me.

util-linux upstream provides three binary objects to be built:
- liblastlog2.so
- pam_lastlog2.so
- lastlog2 (program)

Debian's PAM policy says to put PAM modules into their own package,
thus libpam-lastlog2. liblastlog2.so would go into the
liblastlog2(-0) package. The lastlog2 program either into its own
lastlog2 package, or elsewhere.

>- Did you consider using a systemd service to upgrade from lastlog to
>lastlog2 data?

No, I did not consider this, as I wasn't aware of any
implementations for this. Does u-l upstream ship such a service?

> This way when the distribution is updated to the next
>version you can also remove the lastlog binary and all its dependencies. In
>addition, you can use "--disable-lastlog" in shadow to stop building this
>binary.

Chris

Bug#1063711: mumble: autopkgtest fixes

[Chris Knadle]

Hello Diederik.

Thanks for working on the autopkg test failure and including patches -- 
I'm about to try to incorporate them.


I also pushed the Mumble 1.5.517 release from my local Git to Salsa; 
sorry I missed that.


I wasn't in the Debian VoIP Packaging Team mailing list, so that's how I 
missed these bugs for a couple of months.


I'm under heavy life burden right now but I hope I'm turning the corner 
and will be able to free up some time in a few weeks.


Thanks

   -- Chris

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

Bug#1060254: mumble: please make the build reproducible

[Chris Knadle]

Hello Chris and Diederik

I missed that a couple of bugs came in for Mumble because it turns out 
up to now I had not signed up for the Debian VoIP Packaging Team mailing 
list. *sigh* It's going to take me some time to figure out the correct 
'sieve' rules to get the Mumble bug messages to show up in my 
'Debian-Bugs' mail folder so that I'll be able to quickly catch new bugs 
coming in.


It's going to take a few weeks before I will be able to start work on 
packaging Mumble v.1.5.613, but I hope I can do an upload with the 
patches for reproducibility and fixing the autopkgtest 'smoke' test.


Thanks for working on reproducibility in the Mumble package.

  -- Chris

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

Bug#400046: closed by Gioele Barabucci (Re: Bug#400046: bash: man page tells me "typeset +r" will undo a "typeset -r" but it doesn't)

[Chris Moore]

Thanks for getting back to me. :)

Bug#1068377: python-oslo.messaging: please make the build reproducible

[Chris Lamb]

Source: python-oslo.messaging
Version: 14.7.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-oslo.messaging could not be built reproducibly.

This is because the documentation captures the hostname of the build
system. Specifically:

├── ./usr/share/doc/python3-oslo.messaging/html/configuration/opts.htm
│ │  Type:
│ │  string
│ │  Default:
| │ -ionos11-amd64
│ │ │ │ │ +i-capture-the-hostname
│ │Hostname used by queue manager


Patch attached that uses the Python "blah = None" / "if blah is None"
pattern so that the Python default is the value "None" whilst the
underlying functionality remains the same — ie. defaulting to
socket.gethostname().

 [0] https://reproducible-builds.org/


Regards,

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


--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-04-04 10:31:01.530250426 
+0100
@@ -0,0 +1,35 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-04
+
+--- python-oslo.messaging-14.7.0.orig/oslo_messaging/_drivers/impl_rabbit.py
 python-oslo.messaging-14.7.0/oslo_messaging/_drivers/impl_rabbit.py
+@@ -246,7 +246,7 @@ rabbit_opts = [
+ default=False,
+ help='Should we use consistant queue names or random ones'),
+ cfg.StrOpt('hostname',
+-   default=socket.gethostname(),
++   default=None,
+help='Hostname used by queue manager'),
+ cfg.StrOpt('processname',
+default=os.path.basename(sys.argv[0]),
+@@ -697,6 +697,10 @@ class Connection(object):
+ self.enable_cancel_on_failover = driver_conf.enable_cancel_on_failover
+ self.use_queue_manager = driver_conf.use_queue_manager
+ 
++self.hostname = driver_conf.hostname
++if self.hostname is None:
++self.hostname = socket.gethostname()
++
+ if self.rabbit_stream_fanout and self.rabbit_qos_prefetch_count <= 0:
+ raise RuntimeError('Configuration Error: rabbit_stream_fanout '
+'need rabbit_qos_prefetch_count to be set to '
+@@ -888,7 +892,7 @@ class Connection(object):
+ 
+ if self.use_queue_manager:
+ self._q_manager = amqpdriver.QManager(
+-hostname=driver_conf.hostname,
++hostname=self.hostname,
+ processname=driver_conf.processname)
+ else:
+ self._q_manager = None
--- a/debian/patches/series 2024-04-04 10:18:59.452475473 +0100
--- b/debian/patches/series 2024-04-04 10:31:00.538244802 +0100
@@ -1 +1,2 @@
 no-functional-test.patch
+reproducible-build.patch

Bug#1068375: ludevit: please make the build reproducible

[Chris Lamb]

Source: ludevit
Version: 9.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
ludevit could not be built reproducibly.

This is because it ships an .egg file in the binary package that
contains files varying by the current time. A patch is attached that
follows dh-python by specifying --single-version-externally-managed
and --root=/ such that the .egg file is not created.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2024-04-04 10:18:55.680431222 +0100
--- b/debian/rules  2024-04-04 10:35:51.167758995 +0100
@@ -33,7 +33,7 @@
dh_testroot
dh_prep
dh_installdirs
-   python3 setup.py install --no-compile --prefix 
$(CURDIR)/debian/ludevit/usr
+   python3 setup.py install --no-compile 
--single-version-externally-managed --root=/ --prefix 
$(CURDIR)/debian/ludevit/usr
 
 
 # Build architecture-independent files here.

Bug#1068374: ttconv: please make the build reproducible

[Chris Lamb]

Source: ttconv
Version: 1.0.8-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
ttconv could not be built reproducibly.

This is because the testsuite generates a file (tests.json) with
nondeterministic contents that ends up in the binary package. A patch
is attached that removes this after the test run via
PYBUILD_AFTER_TEST.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2024-04-04 10:18:51.372380412 +0100
--- b/debian/rules  2024-04-04 10:33:05.582926572 +0100
@@ -4,6 +4,7 @@
 export PYBUILD_NAME=ttconv
 
 export PYBUILD_BEFORE_TEST=mkdir -p {build_dir}/src; cp -a src/test 
{build_dir}/src; cp -a debian/missing-sources/imsc-tests 
{build_dir}/src/test/resources/ttml/
+export PYBUILD_AFTER_TEST=find {build_dir} -name tests.json -type f -delete
 
 %:
dh $@ --buildsystem=pybuild

Bug#1068372: grokevt: please make the build reproducible

[Chris Lamb]

Source: grokevt
Version: 0.5.0-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
grokevt could not be built reproducibly.

This is because it ships an .egg file in the binary package that
contains files varying by timezone.. A patch is attached that follows
dh-python by specifying --single-version-externally-managed and
--root=/ such that the .egg file is not created.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/no_egg.patch   1970-01-01 01:00:00.0 +0100
--- b/debian/patches/no_egg.patch   2024-04-04 10:25:05.795926508 +0100
@@ -0,0 +1,17 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-04
+
+--- grokevt-0.5.0.orig/Makefile
 grokevt-0.5.0/Makefile
+@@ -35,8 +35,8 @@ install: all
+   cp -r $(BUILD_BIN)/* $(BIN_PREFIX)
+   cp -r $(BUILD_ETC)/* $(ETC_PREFIX)
+   cp -r $(BUILD_DOC)/* $(DOC_PREFIX)
+-  if [ "x$(PYTHON_PATH)" != "x" ]; then $(PYTHON_PATH) 
grokevt-distutils.py install --install-layout=deb --prefix $(PREFIX); fi
+-  if [ "x$(PYTHON3_PATH)" != "x" ]; then $(PYTHON3_PATH) 
grokevt-distutils.py install --install-layout=deb --prefix $(PREFIX); fi
++  if [ "x$(PYTHON_PATH)" != "x" ]; then $(PYTHON_PATH) 
grokevt-distutils.py install --install-layout=deb 
--single-version-externally-managed --root=/ --prefix $(PREFIX); fi
++  if [ "x$(PYTHON3_PATH)" != "x" ]; then $(PYTHON3_PATH) 
grokevt-distutils.py install --install-layout=deb 
--single-version-externally-managed --root=/ --prefix $(PREFIX); fi
+   $(MAKE) -C doc install
+ 
+ 
--- a/debian/patches/series 2024-04-04 10:19:06.124553201 +0100
--- b/debian/patches/series 2024-04-04 10:24:30.719654371 +0100
@@ -1,3 +1,4 @@
 example_configuration_path
 makefile.patch
 python3-shebang.patch
+no_egg.patch

Bug#1068365: util-linux: FTBFS on mips64el in lsfd/mkfds-multiplexing-pselect6 test et al

[Chris Hofstaedtler]

Source: util-linux
Version: 2.40-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debian-m...@lists.debian.org
Control: forwarded -1 https://github.com/util-linux/util-linux/issues/2867

Apparently on mips64el we have a kernel issue that make
mkfds-multiplexing-{pselect6,poll,ppoll} fail.
Upstream discussion here: https://github.com/util-linux/util-linux/issues/2867

FlyGoat commented last week:
> Thanks for reporting, will ask for stable backport after getting this merged.

MIPS porters, please also check the upstream discussion and if possible
see if we can get this into the Debian kernels.

Thanks,
Chris

Bug#1068300: eo-spell: please make the build reproducible

[Chris Lamb]

Source: eo-spell
Version: 3.7-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: datetime
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
eo-spell could not be built reproducibly.

This is because the build system embeds the output of calling "date":

│ │ │ ├── ./usr/lib/ispell/esperanto.aff
│ │ │ │ @@ -1,13 +1,13 @@
│ │ │ │  # -*- coding: latin-3 -*-
│ │ │ │  # Nomo:eo.aff
│ │ │ │  # Funkcio: Afiksaro por Esperanto-vortaro
│ │ │ │  # Komencita:   1997-08-30 de Sergio Pokrovskij 

│ │ │ │  # Versio:  3.5
│ │ │ │ -# Generita:Tue Apr  2 21:52:24  2024
│ │ │ │ +# Generita:Tue Apr  2 21:53:34  2024

Patch attached that replaces this with a call to the Debian-specific
"dpkg-parsechangelog -SDate". However, you could make this distribution
agnostic by calling date(1) seeded by SOURCE_DATE_EPOCH if it exists…
or simply by removing this date entirely.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
     : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/1000_reproducible-build.diff   1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/1000_reproducible-build.diff   2024-04-03 
10:26:23.476786697 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-03
+
+--- eo-spell-3.7.orig/src/eo-aff.m4
 eo-spell-3.7/src/eo-aff.m4
+@@ -123,7 +123,7 @@ divert(0)dnl
+ # Funkcio:Afiksaro por Esperanto-vortaro
+ # Komencita:  1997-08-30 de Sergio Pokrovskij 
+ Versio
+-{# Generita:} esyscmd(date)
++{# Generita:} esyscmd(dpkg-parsechangelog -SDate)
+ #
+ # Copyright 1997 -- 2012 Sergio Pokrovskij
+ #
--- a/debian/patches/series 2024-04-03 10:24:24.558673371 +0100
--- b/debian/patches/series 2024-04-03 10:26:22.340766797 +0100
@@ -1 +1,2 @@
 _change-aff-rules.diff
+1000_reproducible-build.diff

Bug#1068289: ITP: wtmpdb -- Y2038 safe wtmp implementation

[Chris Hofstaedtler]

Package: wnpp
Severity: wishlist
Owner: Chris Hofstaedtler 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: wtmpdb
  Version : 0.11.0
  Upstream Contact: Thorsten Kukuk
* URL : https://github.com/thkukuk/wtmpdb
* License : BSD
  Programming Lang: C
  Description : Y2038 safe wtmp implementation

Replacement implementation of utmp/wtmp/last that is supposed to be
Y2038 safe. Provides PAM module to plug into the existing auth stack.

Git Repo will be at https://salsa.debian.org/debian/wtmpdb 

Bug#1064931: RM: makedev -- RoQA; obsolete

[Chris Hofstaedtler]

Control: tags -1 - moreinfo

> Em ter., 27 de fev. de 2024 às 17:45, Chris Hofstaedtler
>  escreveu:
> > I propose to remove makedev. All its uses should be obsoleted by udev.
> >
> > The source package has some build requirements making building it
> > non-trivial in various environments (however the official buildds with
> > root support are fine).
> 
On Tue, Feb 27, 2024 at 07:04:09PM -0300, Guilherme Xavier wrote:
> I am not opposed to removing the referenced package if Debian decides
> that it is no longer relevant.

Given the buildds will probably also move away from full root
support very soon, I'm removing the moreinfo tag now, to accelerate
this.

Best,
Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi everyone,

* Chris Hofstaedtler  [240330 01:42]:
> > So, after some of the current fog clears, src:util-linux could
[..]
> > 
> > Does this seem right?

I've put everything I know of into this wiki page:

   https://wiki.debian.org/PamLastlog2

I would invite you all to review / edit it as you see fit, and/or
start a discussion in this bug.

After we have something that we can agree on, I'd send it as a
proposed plan to debian-devel.

Please also let me know if you think it's fine as is.

Thanks!
Chris

Bug#1068241: authselect: pam_lastlog.so is gone

[Chris Hofstaedtler]

Source: authselect
Version: 1.5.0-1

Hi,

it appears authselect references pam_lastlog.so. However, this
module has been disabled in PAM upstream, and is also no longer
shipped in Debian's PAM.

Please adapt your package.

Chris

Bug#1068017: reassign 1068229 to login

[Chris Hofstaedtler]

reassign 1068229 login 
thanks

shadow maintainers: this bug started in libpam-runtime because
pam_lastlog.so became unavailable. I propose that you drop
pam_lastlog.so from login's PAM snippet.

I'm also preparing a wiki page to discuss the changes better.
Addtl. discussion can be in #1068017.

Chris

Bug#1066060: libpam-modules: pam_lastlog.so missing

[Chris Hofstaedtler]

Control: clone -1 -2
Control: reassign -2 src:login
Control: retitle -2 login: remove pam_lastlog.so from config

Hi,

On Sat, Mar 30, 2024 at 10:31:39PM +, Colin Watson wrote:
> On Mon, Mar 11, 2024 at 10:12:29PM +0100, Mourad De Clerck wrote:
> > I noticed the following line in my logs:
> > 
> > login[2449]: PAM unable to dlopen(pam_lastlog.so): 
> > /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such 
> > file or directory
[..]
> 
> I don't know what the Debian pam maintainers intend to do about it, but
> this is surely the result of:
> 
>   
> https://github.com/linux-pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816
> 
> A note in NEWS.Debian might be worthwhile.

login should also stop having pam_lastlog.so in its PAM
configuration, but this is something src:login needs to do.
I've cloned this bug report to src:login for this part.

I'll note that #1068017 has discussion about enabling
pam_lastlog2.so, where we'd also appreciate your input regarding
sshd, Colin.

Chris

Bug#1068176: goldendict-ng: please make the build reproducible

[Chris Lamb]

Source: goldendict-ng
Version: 23.12.26-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
goldendict-ng could not be built reproducibly.

This is because it does not specify the "UTC" argument to CMake's
TIMESTAMP macro function, so the build time embedded in the final
binary, whilst based on SOURCE_DATE_EPOCH, varies by the build
timezone.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

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


--- a/debian/patches/0002-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch  2024-04-01 
11:02:36.411764040 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-01
+
+--- goldendict-ng-23.12.26.orig/CMakeLists.txt
 goldendict-ng-23.12.26/CMakeLists.txt
+@@ -54,7 +54,7 @@ set(CMAKE_AUTORCC ON) # not included in
+  Things required during configuration
+ 
+ block() # generate version.txt
+-string(TIMESTAMP build_time)
++string(TIMESTAMP build_time UTC)
+ find_package(Git)
+ if (EXISTS "${CMAKE_SOURCE_DIR}/.git" AND GIT_FOUND)
+ execute_process(
--- a/debian/patches/series 2024-04-01 09:53:57.209332464 +0100
--- b/debian/patches/series 2024-04-01 11:02:35.515760642 +0100
@@ -1 +1,2 @@
 0001-Disable-checkUpdate-by-default.patch
+0002-Reproducible-build.patch

Bug#1068173: pg-gvm: please make the build reproducible

[Chris Lamb]

Source: pg-gvm
Version: 22.6.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
pg-gvm could not be built reproducibly.

This is because it iterated over input files in the underlying (i.e.
nondeterministic) filesystem order.

A patch is attached that uses sort(1) to sort them, ensuring that it
will work irrespective of the current locale and whether there are
spaces in the build path.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-04-01 10:17:16.629152522 
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-01
+
+--- pg-gvm-22.6.2.orig/CMakeLists.txt
 pg-gvm-22.6.2/CMakeLists.txt
+@@ -175,7 +175,7 @@ add_custom_command(
+ OUTPUT ${SQLOUT}
+ COMMAND mkdir -p ${CMAKE_BINARY_DIR}/sqlin
+ COMMAND cp ${SQL} ${CMAKE_BINARY_DIR}/sqlin/
+-COMMAND cd ${CMAKE_BINARY_DIR}/sqlin/ && find -type f | xargs cat > 
${CMAKE_BINARY_DIR}/${SQLOUT}
++COMMAND cd ${CMAKE_BINARY_DIR}/sqlin/ && find -type f -print0 | LC_ALL=C 
sort -z | xargs -0 cat > ${CMAKE_BINARY_DIR}/${SQLOUT}
+ WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
+ DEPENDS ${SQL})
+ 
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-04-01 10:17:15.685149789 +0100
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1068132: O: cciss-vol-status -- HP SmartArray RAID Volume Status Checker

[Chris Hofstaedtler]

Package: wnpp
Severity: normal
X-Debbugs-Cc: cciss-vol-sta...@packages.debian.org
Control: affects -1 + src:cciss-vol-status

I intend to orphan the cciss-vol-status package.

I no longer have hardware to use with this package. Upstream might also
be abandoned.

The package description is:
 A RAID monitor for HP SmartArray Controllers, as supported by the "cciss",
 "hpsa", "hpahcisr" kernel drivers.
 It will check for problems on your configured logical drives, without relying
 on the controller's event log.
 .
 It also supports MSA500 and MSA1000 controllers.

Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi OpenSSH, shadow Maintainers,

On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > It seems desirable to ship liblastlog2 in trixie, considering that the
> > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > recorded in /var/log/lastlog.
> 
[..]
> At the same time, all traditional writing to /var/log/lastlog should
> stop.
> 
> So, after some of the current fog clears, src:util-linux could
> introduce new binary packages (at least libpam-lastlog2), but
> src:pam would need to add it to the common-* config files.
> 
> Does this seem right?

Answering my own question, not quite.

Apparently, traditionally we have:

* sshd writes to /var/log/lastlog by itself.
* login has pam_lastlog.so in its PAM snippet. 

Both of these would need to be replaced by pam_lastlog2.so. I don't
really know what the other distros are doing right now, and/or if
we should align on this.

So we could either put pam_lastlog2.so into a common-* file from
src:pam, or openssh and shadow should switch their setup.

What do we all think about that?

Chris

Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi Sven,
Hi Sam, Steve,

On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> It seems desirable to ship liblastlog2 in trixie, considering that the
> /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> recorded in /var/log/lastlog.
> 
> I have not looked closely yet, but I guess that would mean additional
> packages liblastlog2-2 for the library, liblastlog2-dev for the
> development files and libpam-lastlog2 for the pam module.  The lastlog2
> binary could probably be included in util-linux-extra.

I generally agree that we should ship lastlog2 and the pam module.
But this needs to be happen coordinated with src:pam. Installing the
modules and the binary and not using them is not a good plan.
At the same time, all traditional writing to /var/log/lastlog should
stop.

So, after some of the current fog clears, src:util-linux could
introduce new binary packages (at least libpam-lastlog2), but
src:pam would need to add it to the common-* config files.

Does this seem right?

PAM Maintainers, do you agree with this plan? Which timing would
work for you?

Chris


PS: the bug never made it into my mailbox. If necessary, please poke
on IRC.

Bug#1067947: golang-github-stvp-tempredis: please make the build reproducible

[Chris Lamb]

Source: golang-github-stvp-tempredis
Version: 0.0~git20231107.8a695b6-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
golang-github-stvp-tempredis could not be built reproducibly.

This is because the package build generates a Redis dump.rdb database
during the tests. This (nondeterministic) file is then shipped in the
binary package.

Patch attached that removes these after running the tests.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2024-03-29 10:35:18.997786394 +
--- b/debian/rules  2024-03-29 10:55:36.280785041 +
@@ -2,3 +2,6 @@
 
 %:
dh $@ --buildsystem=golang --with=golang
+
+execute_after_dh_auto_test:
+   find obj-* -name dump.rdb -delete

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#1067617: gnuchess: pgnsave only saves last move

[Chris Moser]

Package: gnuchess
Version: 6.2.7-1
Severity: normal
X-Debbugs-Cc: chrismmo...@gmail.com

Dear Maintainer,

To reproduce:
Run gnuchess from the CLI
gnuchess

Make a move, wait for gnuchess to make a move
e4

Save the game
pgnsave game0.pgn

Exit gnuchess and examine the game file
exit
cat game0.pgn

The move list shows only the final move of gnuchess ("e5" for example)
It should show the turn number and both the user and gnuchess moves "1. e4 e5"  

-Chris


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
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 gnuchess depends on:
ii  libc6  2.37-15

Versions of packages gnuchess recommends:
ii  gnuchess-book  1.02-2.1

Versions of packages gnuchess suggests:
ii  xboard  4.9.1-2+b1

-- no debconf information

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
   `-