Bug#1072698: debhelper: Mark 14 as stable?

[Niels Thykier]

Niels Thykier:

[...]

Depends on whether there are more things that need changing, whether I 
feel the existing changes have been tested sufficiently, and that the 
Debian tooling is ready for it (such as lintian and lintian-brush).


As an example, until #1067653 is fixed, then lintian will give 
contradicting advice to one of the compat 14 changes, which I consider 
"not very nice". Especially not if lintian-brush will then "auto-fix" it 
favor of lintian's world view.


If you want compat 14 sooner, consider:

  1) testing compat 14 works as intended on a subset of your packages if
     you have any where a bit of instability is an acceptable risk (or
     do it in experimental only)
  2) try out how other tools such as lintian and lintian-brush react and
     report any issues there.

Best regards,
Niels



I have added known bugs as blockers for this one (thanks for filing the 
one for lintian-brush).  Please consider adding any other that you file 
or find. :)


Best regards,
Niels

Bug#1072741: lintian: Please recognize X-DH-Compat as replacement for debian/compat

[Niels Thykier]

Package: lintian
Severity: minor
X-Debbugs-Cc: ni...@thykier.net
Control: block 1072698 by -1

As of debhelper/13.15, the debhelper compat level can be set via 
`X-DH-Compat: 14` in the source stanza of `debian/control`.


Please recognize `X-DH-Compat` as the canonicalize spelling of that 
field (currently it incorrectly triggers `cute-field`) and as an 
alternative to `debian/compat`.


Related, `debian/compat` be phased out starting with compat 14.

Note: `lintian` can use `dh_assistant` to determine the compat level 
instead of implementing the logic itself for checking various fields and 
files (the `export DH_COMPAT` checks for `debian/rules` might still be 
necessary).  Though, this implies debhelper/13.15+ as a dependency for 
it to recognize `X-DH-Compat`.


Best regards,
Niels

Bug#1072698: debhelper: Mark 14 as stable?

[Niels Thykier]

Jeremy Bícha:

Source: debhelper
Version: 13.15.3

Do you intend to mark debhelper 14 as stable in time for the next
major Debian stable release (Debian 13 "Trixie")?

There are interesting features and improvements in compat 14 that I
would like to use in my packages but I hesitate because as long as 14
is open for development, there is a risk that changes could cause
packages to fail to build.

Thank you,
Jeremy Bícha



Depends on whether there are more things that need changing, whether I 
feel the existing changes have been tested sufficiently, and that the 
Debian tooling is ready for it (such as lintian and lintian-brush).


As an example, until #1067653 is fixed, then lintian will give 
contradicting advice to one of the compat 14 changes, which I consider 
"not very nice". Especially not if lintian-brush will then "auto-fix" it 
favor of lintian's world view.


If you want compat 14 sooner, consider:

 1) testing compat 14 works as intended on a subset of your packages if
you have any where a bit of instability is an acceptable risk (or
do it in experimental only)
 2) try out how other tools such as lintian and lintian-brush react and
report any issues there.

Best regards,
Niels

Bug#1069176: debhelper: Issues in Debhelper documentation strings

[Niels Thykier]

Christoph Brinkhaus:

Package: debhelper
Version: 13.15.3
Severity: minor

Dear Maintainer,
while updating the strings in the debhelper documentation the l10
documentation team noticed a few issues in the text which I report
in the attached text file. Some issues are related to the presentation
of text in the final documents.  Others are simple typos. A few
sentences are unclear.

Just for reference: The update of the german translation has been
reported in a separate report as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069112. The remarks
listed below appear in the po template as FIXME, too.

In case the documentation is updated I will be happy to update the
translation accordingly.

Thank you very much for maintaining this huge project,
Christoph Brinkhaus


Hi Christoph

Thanks for the feedback and sorry for the very late response on my end.

For 1) and 2): Ok. I think I will use `B` then to match the 
casing of the field that the stanza is named for.


For 3-6): Looks good. Thanks for catching these.

For 7), The original sentence should have been `The B 
tool would no longer *install* the maintainer ...` (that is replace 
`installs` with `install`). I think you put more weight on to the 
`installs` rather than the `would have` given that your proposed 
solution reads to me with an inverted meaning than I intended (all the 
more reason to improve the sentence).


The point is that `X historically changed to *not* do Y. However, 
omitting Y is incorrect because of a change in dpkg, so Y is now done 
again as of compat 12+.`  With that in mind, do you have a suggestion 
for a revised sentence? :)



For 8), the point is that you can mostly restore the behavior by using 
PERL5LIB. The emulation is a hint to the fact there might be subtle 
differences between the historical Perl behavior and the proposed 
replacement.
  Perhaps, `Packages that relies on this behavior can often use the 
B environment variable as a substitute` is better. It would 
avoid the `emulate`/`emulation` and still imply via "can often" that we 
are not promising it is a perfect solution for all cases.


For 9), I have no idea either. The phrasing originates from the original 
maintainer and was inserted back in 2003, where the landscape was 
probably considerably different.
  In practice both options involved (`--dbg-package` and 
`--keep-debug`) are *now* special-case and rarely used options. They are 
not worth a lot of effort and maybe the best solution is to remove the 
last sentence, so it just becomes `Debug symbols will be retained, but 
split into an independent file in F in the package build 
directory.` and work from there.


The point with `--keep-debug` is that you preserve the debug symbols in 
the same package as the one containing the binaries they relate to, but 
split out as they would be when split into a separate debug package.  I 
assume the point (from 2003) is that you as a maintainer then manually 
shove those symbols into a different package, because otherwise the use 
of `dh_strip` seems to be more theoretical than practical.


Once again, thanks for your proposal and I hope I can convince to review 
the points above to help me get all the way through.


Best regards,
Niels

Bug#1071594: debhelper: fails to start openssh-server after creating host keys due to systemd 255 change

[Niels Thykier]

Hi Michael and Luca

I suspect you are better suited to debug this one. Let me know if I 
should change anything in the maintscript generated.


Lucas Nussbaum:

Package: debhelper
Version: 13.15.3
Severity: normal

Hi,

I maintain the Debian Vagrant boxes. Recently, booting the 'testing'
image started to fail randomly.
The Debian Vagrant images ship without SSH host keys. A systemd service
is responsible for triggering a 'dpkg-reconfigure openssh-server' that
will generate the ssh keys and then start ssh.

Until systemd v254.5-1, that worked fine:
ssh.service was started but fails to start;
we get the 'ssh.service: Start request repeated too quickly.' error;
dpkg-reconfigure openssh-server creates the key and starts ssh.service
successfully.

With v255.2-1, that no longer works.
If ssh.service reached the 'Start request repeated too quickly.' state,
dpkg-reconfigure openssh-server is no longer able to start it.

The following code is in charge of starting ssh.service:


# Automatically added by dh_installsystemd/13.15.3
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ 
"$1" = "abort-remove" ] ; then
 if [ -d /run/systemd/system ]; then
 systemctl --system daemon-reload >/dev/null || true
 if [ -n "$2" ]; then
 _dh_action=restart
 else
 _dh_action=start
 fi
 deb-systemd-invoke $_dh_action 'ssh.service' >/dev/null || true
 fi
fi
# End automatically added section


A MWE to reproduce is:

systemctl stop ssh
rm /etc/ssh/ssh_host_*
for i in $(seq 1 10); do systemctl start ssh ; done
systemctl status ssh
dpkg-reconfigure openssh-server
systemctl status ssh


I tried to identify when and why it was changed in systemd, but failed.
It could be argued that this is a regression in systemd.

Lucas

Bug#1070794: dh_clean should not remove __pycache__ folder by default

[Niels Thykier]

Control: tags 1070794 wontfix
# Solution options provided below.
# (BTS processing instructions have to go in the top)

On Thu, 9 May 2024 09:20:01 + Hang Lei  wrote:

Package: debhelper
Version: 13.11.10

Dear Maintainer,

I'm writing to discuss a change introduced in debhelper 13.10.10: this 
PR fixes 
#1048890 by deleting the 
__pycache__ folder.

[...]

Considering the impact on performance, I believe that removing the __pycache__ 
directory may not be beneficial. Could we explore the possibility of reverting 
this change?

Thanks for your time and consideration.

Related issue: [Packaging] Add Ubuntu 24.04 Noble Numbat support by bebound * Pull 
Request #2 * Azure/azure-cli 
(github.com)

Cheers,
Hang


Hi Hang

Thanks for reaching out. :)

No Debian package ships `.pyc` files directly in the `.deb`. Instead 
they generate them during installation. I am not super well-versed in 
this area, so I cannot be fully helpful on all of the rationales behind 
the decision to byte-compile on install (and clean up on removal). You 
would have to ask the Debian Python Team / Debian Python Policy 
maintainers if that rationale is important. As I recall, it involves (or 
involved) cases like people running python code as root, reproducible 
builds, multiple interpreter support (including embedded interpreters) 
and special cases in that ballpark.


What I do know, is that this byte compilation for Debian packages is 
generally triggered by using `dh_python3` from the `dh-python` package 
for python3 files[1]. The `dh_python3` helper is *not* enabled by 
default.  With modern debhelper versions adding `dh-sequence-python3` to 
Build-Depends would do. Older versions of `debhelper` would require a 
`dh ... --with python3`.


Since the package in question does not seem to install the python files 
in the "standard" locations (I noted an `/opt` in the GitHub PR), you 
may have to consult the `dh-python` documentation for having it set up 
the recompilation correctly. See 
https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dh_python3.rst?ref_type=heads 
(heading "private dirs" seems relevant)


That documentation also has sections for exceptions to the byte 
compilation via the `bcep` files. Like if certain files can only be 
compiled with a given version of python (etc.).


This is the only solution I can offer you with the current Python 
landscape in Debian. If you want to change that landscape, I am afraid I 
will have to ask you to raise the concerns with the Python team and they 
are the authority on this topic.  Because it is not my jurisdiction and 
I cannot offer to be middleman in challenging the landscape, I have 
tagged this bug as `wontfix`, since it is the closest tag we have for 
this case.


I hope it was helpful and enable you to restore the original performance.

Best regards,
Niels

[1]: Historically, there was also a `dh_python`, which may be relevant 
if you still support python2 and Debian/Ubuntu releases that still have 
`python2`. That is probably so old that it only works with

`dh ... --with python`.

Bug#1070473: debhelper: Run dh_installsysusers after dh_installtmpfiles

[Niels Thykier]

Jeremy Bícha:

Source: debhelper
Version: 13.15.3
Control: affects -1 src:gnome-remote-desktop
X-Debbugs: syst...@packages.debian.org

gnome-remote-desktop 46 upstream has decided to implement both
tmpfiles.d and sysusers.d to create a system user and its home
directory. systemd-tmpfiles needs to run before systemd-sysusers. If
not, on a new install, this command hangs for about 90 seconds:

Creating user 'gnome-remote-desktop' (GNOME Remote Desktop) with UID
*** and GID ***.

Then this error:
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.

Then the installation completes successfully.

Therefore, I recommend that debhelper automatically runs
dh_installtmpfiles before running dh_installsysusers in case any other
projects want to do what gnome-remote-desktop does.

I was able to workaround this issue:
https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/8490919

Thank you,
Jeremy Bícha



Hi Michael and Luca

What is the correct order for tmpfiles vs. sysusers?

I thought the order was sysusers (to create the user) and then tmpfiles 
(to create files/directories and set ownership accordingly). In this bug 
report, the request is to have the directories first before the user is 
created.


Could you please assert what the correct order is for the default case?

Best regards,
Niels

Bug#1070165: RM: libapache2-mod-auth-pgsql -- RoQA; RC-buggy, unmaintained, not in stable

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ni...@thykier.net
User: ftp.debian@packages.debian.org
Usertags: remove

The RC bug #947039 was filed against libapache2-mod-auth-pgsql 4½ years 
ago and remains both unfixed and unanswered.


Best regards,
Niels

Bug#1069362: libcleri: FTBFS on arm64: make: *** [debian/rules:7: binary] Error 25

[Niels Thykier]

Control: reassign -1 debputy
Control: affects -1 libcleri

On Sat, 20 Apr 2024 14:06:18 +0200 Lucas Nussbaum  wrote:

Source: libcleri
Version: 1.0.2-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64

Hi,

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


[...]


Inverted boolean assertion in `debputy`, reassigning.

Best regards,
Niels

Bug#1069668: python3-colored: Please provide PEP-0561 "py.typed" marker

[Niels Thykier]

Package: python3-colored
Version: 2.2.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: ni...@thykier.net

Hi

When depending on `python3-colored` and using `mypy`, `mypy` will 
complain about `python3-colored` is not typed. Upstream does seem to 
have some typing, but has not marked the their library has typed in a 
PEP-0561 complaint way.


As I understand the PEP, all that is needed is that 
`/usr/lib/python3/dist-packages/colored/py.typed` exists as an empty 
file in this case (a simple `touch` in `debian/rules` would be 
sufficient as a work around for now). I have tried that locally and that 
seems to solve my `mypy` error.


This is really an upstream bug. I have not reported this to upstream as 
they are on `gitlab.com`, since I do not have an account there. For 
upstream, there is guidance in PEP-0561 
(https://peps.python.org/pep-0561/). But basically it is creating the 
empty file and ensuring it is included in the dist (usually via 
`setup(..., package_data=...)` or similar).


Best regards,
Niels

Bug#1069666: python-levenshtein: Current upstream looks dead, consider rebasing on https://github.com/rapidfuzz/Levenshtein

[Niels Thykier]

Package: python3-levenshtein
Version: 0.12.2-2+b5
Severity: normal
X-Debbugs-Cc: ni...@thykier.net


Hi

Based on the discussions in
https://github.com/ztane/python-Levenshtein/issues/86, it seems that the 
current upstream has been superseded by 
https://github.com/rapidfuzz/Levenshtein/


This also fits with https://pypi.org/project/Levenshtein/ referencing 
https://rapidfuzz.github.io/Levenshtein/ as documentation page and 
https://github.com/rapidfuzz/Levenshtein being the (current) project 
homepage.


Please migrate to rapidfuzz's Levenshtein since it seems to be actively 
maintained, it provides proper Python type hints and other improvements.


Best regards,
Niels

Bug#1069643: dh_installman: doesn't honor nodoc build profile

[Niels Thykier]

Fab Stz:

[...]


If dh_installman doesn't support nodoc as written in its manpage, then maybe
the manpage should be changed.

For instance this may have to be removed since I was mistaken by it.

"In compat 11 and later, it also supports the default searchdir plus --
sourcedir like dh_install(1) and has the advantage that it respects the nodoc
build profile (unlike dh_install(1))."

Regards
Fab




I am happy to consider patches for improving the documentation. But, I 
think your confusion is at a much more fundamental level. As I 
understand your email, you seem to be confusing `dh_installman` reacting 
to `nodoc` vs. `dh` skipping a hook target with `nodoc` which are two 
very different aspects.


The statement about `dh_installman` respecting `nodoc` above is still 
correct because it is whether `dh_installman` will react to `nodoc` and 
ignore missing documentation (manpages) in the `debian/.manpages` 
files.


Nothing you showed me in the mount-zip package is about whether 
`dh_installman` reacts to `nodoc`. That was 100% whether `dh` reacts to 
`nodoc` by skipping commands and hook targets. So if any docs should be 
changed, I would expect the change to be in `dh(1)` rather than 
`dh_installman(1)`.


Best regards,
Niels

Bug#1069643: dh_installman: doesn't honor nodoc build profile

[Niels Thykier]

Control: tags -1 moreinfo

On Mon, 22 Apr 2024 09:37:55 +0200 Fab Stz  wrote:

Package: debhelper
Version: 13.15.3
Severity: normal

Dear Maintainer,

According to dh_installman, it should honor the nodoc build profile.
However, it doesn't. As well as execute_before_dh_install.


[...]


Hi,

Could you please provide the URL the packaging in question where it does 
not work along with a bit more details of what you expected vs. what you 
see? Notably, `dh_installman` will allow documentation to be missing 
during `nodoc` but it will still operate on the documentation there is 
(that has been the way of handling `nodoc` from the start in `debhelper`).


Additionally, I am not sure what the `execute_before_dh_install` remark 
is about. The `execute_before_dh_install` hook targeted is not affected 
by `nodoc`. First off because it is `dh_install` and not one of the 
`dh_install{docs,man}` and secondly, most of the documentation commands 
still do something even under `nodoc` (unlike `dh_strip` with 
`nostrip`), so the commands are still run. Thirdly, even if it was to be 
affected, it would react to `DEB_BUILD_OPTIONS` and not the profile 
(which are not the same thing and that has been confusing people a lot 
at least with nocheck)


Best regards,
Niels

Bug#1068523: dh-debputy: To contact or to contract

[Niels Thykier]

gregor herrmann:

Package: dh-debputy
Version: 0.1.27
Severity: normal

I was very excited when I read about `debputy lint` as I like to
automatically fix packaging errors. Alas, my first experience leaves
me a bit underexcited because (seen with several packages):

% debputy lint
warning: File: ./debian/copyright:3:0:3:16: The "Upstream-Contact" looks like a typo of 
"Upstream-Contract". [Correctable via --auto-fix]

And I'm rather sure I don't want to change Upstream-Contact to Upstream-Contract
:)


Cheers,
gregor



Cannot have it be underexciting! New release incoming. :)

Thanks for trying `debputy' and reporting the bug! Please keep them coming!

Best regards,
Niels

Bug#1042506: fixed in lincity-ng 2.10.1-1

[Niels Thykier]

Hi Alexandre

Looks like you typoed the bug number in lincity-ng (#1042506 was filed 
against ares).


Best regards,
Niels


On Mon, 01 Apr 2024 17:19:51 + Debian FTP Masters 
 wrote:

Source: lincity-ng
Source-Version: 2.10.1-1
Done: Alexandre Detiste 

We believe that the bug you reported is fixed in the latest version of
lincity-ng, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1042...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alexandre Detiste  (supplier of updated lincity-ng package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 01 Apr 2024 18:58:18 +0200
Source: lincity-ng
Architecture: source
Version: 2.10.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team 
Changed-By: Alexandre Detiste 
Closes: 1042506
Changes:
 lincity-ng (2.10.1-1) unstable; urgency=medium
 .
   * Team Upload
   * New upstream version 2.10.1
   * replace old autoconf+jam build with modern CMake (Closes: #1042506)
Checksums-Sha1:
 7204930ea578ea873eb362b9fe20d5f4f6825ba2 2177 lincity-ng_2.10.1-1.dsc
 cbc7e48068b762be77bfcfb8421fc685355cff2f 114742047 
lincity-ng_2.10.1.orig.tar.gz
 98e92387e23614a22b037dc36dbb8db14c48c973 8524 lincity-ng_2.10.1-1.debian.tar.xz
 753f736f5333e9e4a5c913f6b28e4f352316e8b9 15129 
lincity-ng_2.10.1-1_source.buildinfo
Checksums-Sha256:
 bdea5c39e380fc2d8238c795503b65a4624083283525297c08c96c276da0fc55 2177 
lincity-ng_2.10.1-1.dsc
 4246099f66bd7580b00c730d597d32196c5ded72d8f391cff21f8d0136e5bf7d 114742047 
lincity-ng_2.10.1.orig.tar.gz
 87ca3f86205b7df0d13d2c83d4554467a60078b01ac67d856c81a720326cde3c 8524 
lincity-ng_2.10.1-1.debian.tar.xz
 b30b015b2ebacc2837d47a893ac4e98bc00dd042b771b0b8d5b4fa109ac152bd 15129 
lincity-ng_2.10.1-1_source.buildinfo
Files:
 69a1cd7007f276adf5248ff52f0c9603 2177 games optional lincity-ng_2.10.1-1.dsc
 f4232d2b609ea510a327d0c143571cb1 114742047 games optional 
lincity-ng_2.10.1.orig.tar.gz
 892d8e0530f343a0e992c276708e65f1 8524 games optional 
lincity-ng_2.10.1-1.debian.tar.xz
 510f4a948e84ec6a7773dc71ab62d28e 15129 games optional 
lincity-ng_2.10.1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS

[Niels Thykier]

Salvatore Bonaccorso:

Source: debhelper
Version: 13.15
Severity: serious
Tags: ftbfs
Justification: Regression for other package builds, FTBFS
X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64

Hi Niels,

Not fully investigated, but starting to fill a bugreport. I noticed
that the src:linux pipeline on salsa started to fail for the
jobs in th build-signed stage (in the build-signed job).

https://salsa.debian.org/carnil/linux/-/jobs/5527774

(and for saving the output):

[...]

(attached as well the raw log)

I'm not 100% sure yet, this might be a problem in our packaging in
which case we can re-eassign. But it only got triggered with the
change recently in debhelper:

https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff

Regards,
Salvatore


Hi Salvatore

It was a suggestion raised (I think on IRC) to have debhelper explicitly 
check these parameters, because a lot of t64 breakage was "unnoticed" by 
debhelper. That is, when people forgot to update --link-doc parameters 
(etc.).


The code for `--link-doc` uses `${binary:Version}` for the dependency, 
so the package should really be from the same source[1]. In my view, it 
was never a case that was expected to work between source packages.


I think `linux` with `linux-signed` is doing something really special 
here (especially considering it has worked so far), and I think the 
question is whether `linux`/`linux-signed` should get a special-case or 
concluding that the `--link-doc` is not suitable for the 
`linux`/`linux-signed` case.


I would like to hear your case for what makes `--link-doc` sensible for 
the `linux-signed` case. I know of `linux-signed`, but I have no idea 
what you are dealing with in practice, so it is hard for me to make a 
judgement call on this (other than my biased gut feeling of wanting to 
minimize special-cases).


Best regards,
Niels

[1]: Policy also documents the "same source" requirement.

https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

Bug#1055599: dh_installsystemd tries to start static unit which deb-systemd-invoke rejects

[Niels Thykier]

Hi Michael and Luca

Is this a bug you have an opinion on?

Best regards,
Niels

Daniel Carpenter:

Package: debhelper
Version: 13.11.4

If I include this static (i.e. no [Install] section) systemd service:

# debian/debhelper-example.service
[Service]
Type=oneshot
ExecStart=true

then dh_installsystemd will insert this snippet in postinst:

if [ -n "$2" ]; then
 _dh_action=restart
else
 _dh_action=start
fi
deb-systemd-invoke $_dh_action 'debhelper-example.service' >/dev/null ||
true

When I install the package, deb-systemd-invoke issues a warning:

debhelper-example.service is a disabled or a static unit, not starting it.

Indeed, such a unit should not be started on package installation (but
rather by a path, socket or timer unit). I notice that dh_installsystemd
produces another snippet which enables the unit if it contains an [Install]
section. I think both snippets should be omitted for static units.

On upgrades, the restart part makes more sense, but for type=oneshot I
think that's only relevant if RemainAfterExit=true.

As a workaround, I can write:

override_dh_installsystemd:
 dh_installsystemd --no-start

in debian/rules, but that prevents any units from being started, not just
the static ones. I assume you have to list the static units with
--no-start, and the others without it, but that's more error prone than
letting debhelper handle it.

Bug#1068102: FileNotFoundError in process_manpages()

[Niels Thykier]

Andrey Rakhmatullin:

Package: dh-debputy
Version: 0.1.23
Severity: normal

I've tried to convert the cpuid package to dh-sequence-zz-debputy, when
building it I got:

[...]


Note that cpuid.1 is not mentioned in the packaging. It's installed to
debian/cpuid/usr/share/man/man1/cpuid.1.gz at the moment of the error.

All changes:

[...]


Thanks for trying `debputy` and reporting the bug. :)

The issue was caused by the manpage was being pre-compressed and 
`debputy` did not account for that special-case correctly.  With the 
patched version of `debputy`, I could successfully test build `cpuid`.


I hope to upload a fixed version `debputy` shortly after the current one 
migrates to testing.


Best regards,
Niels

Bug#1067767: dpkg-gencontrol: Don't fail on syntax error in removed field

[Niels Thykier]

David Kalnischkies:

Package: dpkg-dev
Version: 1.22.6
Severity: normal
X-Debbugs-Cc: debhel...@packages.debian.org

Hi,

since recently my arch:any package `ycmd` fails to built from source in
a fresh unstable sbuild environment with at least dpkg 1.22.6 and
debhelper 13.15.2 (compat 13) while generating the dbgsym package:

[...]


Best regards

David Kalnischkies



For what it is worth, the debhelper side of this is #1067711. I will 
leave it to Guillem to evaluate whether there should be any changes on 
the `dpkg` side.


Best regards,
Niels

Bug#1067711: Bug related to "dpkg-gencontrol: warning: can't parse dependency pkg (= )" for -dbgsym packages

[Niels Thykier]

Control: reassign 1067711 debhelper
Control: reassign 1067728 debhelper
Control: forcemerge 1067711 1067728
Control: retitle 1067711 dh_gencontrol: substvars and -dbgsym packages
Control: affects 1067711 mrpt genomethreader

Hi,

I think this kind of bugs are likely to be a bug in debhelper.

Best regards,
Niels

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

[Niels Thykier]

Sergey Ponomarev:

Hi Niels,

I upgraded to Ubuntu 24.04 and now have debhelper 13.14.1ubuntu1.



Hi,

In case you are using Ubuntu, you should be filing the bug against 
Ubuntu for future reference. Notably, Ubuntu has patched debhelper and 
even monkey-patch(ed?) debhelper in their official builds on top that.
Therefore, they have to screen incoming bug reports first to ensure the 
bug is not introduced by their patches.



Once executed the debuild nothing was generated.
When executed the dh_installsystemduser manually also nothing was generated.
 From it's sources I found that it looks for some dependency and I added to
the /debian/control:

 Depends: ${misc:Depends}

Now this helped and two install/uninstall scripts were generated
/debian/sshtunnel.postinst.debhelper
/debian/sshtunnel.postrm.debhelper

I manually included the scripts to /debian/postinst and /debian/postrm and
built the deb.



If you had to "manually" include those snippets into the deb in a clean 
build, then I think there is something seriously wrong with the 
packaging. Normally, `dh_installdeb` would do that for you if the 
commands are run in the correct sequence.


Now, you mention you ran it manually. So it is possible you did that 
manually after building the deb, in which case you would see this 
behavior. This would also fit that your `debian/rules` likes quite 
standard without any room for mistakes of this kind when I checked it.




It was installed successfully but didn't start the service.
I started manually. During uninstall it has not been stopped. There is no
prerm script that will do that.



No, this feature is first added in compat 14 apparently (which is not 
stable yet). Sadly, this is not documented in the upgrade checklist for 
reasons I do not understand. The commit that introduced the feature 
recorded it in the wrong place and the remark seems to be completely gone.


I will follow up on this part.


So the issues are:
1. The debhelper did not execute the dh_installsystemduser. I guess I must
add it manually to /debian/rules


Either that or you could use the proper debhelper-compat level.  That is 
compat 12 or later would do. The package you linked to used compat 11 as 
I recall.


Remember to check the debhelper compat upgrade checklist before you 
update the compat level.


It is in `man 7 debhelper-compat-upgrade-checklist` or `man 7 debhelper` 
(depending on the debhelper version).



2. The generated scripts do not start the service after installation.
3. Missing prerm script to stop the service.


As mentioned above, this is compat 14 stuff.


4. Surprising need for for ${misc:Depends}



There is no such need in the Debian version of debhelper for 
dh_installsystemduser to generate the snippets. However, 
dh_installsystemduser must either install the services files *or* be run 
after they are installed at the correct location.
  My best guess is that you ran dh_installsystemduser to "early" the 
first time, then the files were in place, followed by you tweaking 
debian/control and then running dh_installsystemduser without clean 
first. That is basically the one way I can make sense of what happened.


That said, you ought have that dependency anyway for other reasons (at 
least up to compat 14, where it will be applied automatically).



So far I will anyway continue to use the manual scripts because I wish to
support old distros.
Anyway I wanted to have good and proper "official" scripts to install the
user service.

You can play with my simple package here:
http://github.com/yurt-page/sshtunnel

It can be a good sample and test ground.

Best regards and thank you for your work,
Sergey

[...]


From my PoV, I will acknowledge that the compat checklist is missing 
the remark that `dh_installsystemduser` changes behavior in compat 14 by 
adding start+stop snippets for user services.


For the other parts, I am not seeing anything that I can be sure is a 
bug in debhelper vs. issues caused by ad-hoc debugging / something else. 
At least not in Debian's version of debhelper.


Best regards,
Niels

PS: I suspect your `debian/dirs` file is (mostly?) redundant, since your 
`Makefile` does the `mkdir -p` necessary.

Bug#1067653: lintian: debhelper-but-no-misc-depends and other relationship substvar hints are no longer universally applicable

[Niels Thykier]

Package: lintian
Severity: normal
X-Debbugs-Cc: ni...@thykier.net

Hi

With debhelper compat 14+ or any use of debputy (dh-sequence-debputy, 
dh-sequence-zz-debputy, or dh-sequence-zz-debputy-rrr), relationship 
substvars are now applied automatically.


This means that packages no longer need `Depends: ${misc:Depends}` or 
`Depends: ${shlibs:Depends}` to be correct.


See https://lists.debian.org/debian-devel/2024/03/msg00030.html for more 
details.


Best regards,
Niels

Bug#1067590: elpa-dpkg-dev-el: Please provide major mode for debian/tests/control

[Niels Thykier]

Package: elpa-dpkg-dev-el
Version: 37.11
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net

Currently, there is no editor support for `debian/tests/control` in 
emacs via elpa-dpkg-dev-el. It would be nice to have basic syntax 
highlighting of the file similar to how the `debian/control` feature is 
setup.


Best regards,
Niels

Bug#1067589: elpa-dpkg-dev-el: Please improve syntax highlighting of d/copyright

[Niels Thykier]

Package: elpa-dpkg-dev-el
Version: 37.11
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

The `debian-copyright-mode` currently feels a bit lacking when it comes 
to syntax highlighting:


 1) There is a URL highlighting, but it does not cover http**s**. Only
ftp/http URLs change color. Given most URLs these days are https,
this feels sub-optimal to me.

 2) There is (almost) no syntax highlighting of the fields at all.
`Copyright:` as the only thing will be highlighted, but only if
it is at the start of the line and it is the **only** thing on
the line. Please highlight other DEP-5 fields and also highlight
non-empty fields!

Best regards,
Niels

Bug#1030011: Bug#1062508: marked as pending in debhelper

[Niels Thykier]

Jeremy Bícha:

On Sun, Mar 17, 2024 at 3:33 AM Niels Thykier  wrote:

meson.pm: Pass --auto-features=auto in compat 14+


The meson default is already --auto-features=auto. We are requesting
that it be changed in debhelper compat 14 to --auto-features=enabled.

https://mesonbuild.com/Build-options.html#features

Fedora does this and this Fedora maintainer assumed that all other
major Linux distros were doing it too:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/

Thank you,
Jeremy Bícha



Thanks for spotting that.

I have fixed that in the main branch.

Best regards,
Niels

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

[Niels Thykier]

Control: tags -1 moreinfo

Niels Thykier:

Sergey Ponomarev:

debhelper package version: 13.11.6ubuntu1
Ubuntu 23.10 Mantic

Is there any plan for support of user services?
The user service is complicated by itself because it differs by commands
from system services.
That's why I also asked to make a review of mine scripts to have at least
one right example of this.


[...]


User services are handled by `dh_installsystemduser` (not 
`dh_installsystemd`) and that command used `/usr/lib` since the 
beginning as far as I can tell. That command was added in 10.9.1 and 
should be in the default sequence.


Best regards,
Niels




Hi Sergey,

I hope the above solved your issues.  If so, I will close this bug as 
resolved. :)


Best regards,
Niels

Bug#1065742: dh_install: cannot use empty lines or comments in substitution

[Niels Thykier]

Control: tags -1 wontfix

Andreas Metzler:

On 2024-03-10 Niels Thykier  wrote:

Andreas Metzler:

[...]

supporting build-profiles like nodoc with dh_install seems to cumbersome.



Any reason for not using dh_installdocs, which does `nodoc` out of the box?


Hello Niels

Because for this specific case I need to handle files outside of
/usr/share/doc/$package.

cu Andreas


Ok, thanks for clarifying.

The use of substitution is not intended as a filtering mechanism. The 
go-to solution for having filtering beyond debhelper's built-in is 
`dh-exec` which has architecture and build-profile filtering.


I understand that this might not be what you want. However, this is the 
feature set provided. If you really want to do all this logic in 
debian/rules, then you can simply do a `install foo bar` directly in the 
d/rules (or a `dh_install foo bar`).


Best regards,
Niels

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

[Niels Thykier]

Sergey Ponomarev:

debhelper package version: 13.11.6ubuntu1
Ubuntu 23.10 Mantic

Is there any plan for support of user services?
The user service is complicated by itself because it differs by commands
from system services.
That's why I also asked to make a review of mine scripts to have at least
one right example of this.


[...]


User services are handled by `dh_installsystemduser` (not 
`dh_installsystemd`) and that command used `/usr/lib` since the 
beginning as far as I can tell. That command was added in 10.9.1 and 
should be in the default sequence.


Best regards,
Niels

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

[Niels Thykier]

Sergey Ponomarev:

Package: dh-systemd

I created a systemd service to establish SSH connections.
At beginning I installed the service file
into /usr/lib/systemd/system/sshtunnel
So the dh_systemd generated post install and post remove scripts to call
sysctl daemon-reload.
I copied them, made a small cleanup and included manually:
https://github.com/yurt-page/sshtunnel/commit/1b8f5f4a495802270b894ccf7f047aadab8772ac

Then I wanted to make the tunnel starting from a user and moved the service
file into /usr/lib/systemd/user/sshtunnel

But the dh_installsystemd didn't anything about the service file and I had
to create manually the install scripts:
https://github.com/yurt-page/sshtunnel/blob/master/debian/postinst
https://github.com/yurt-page/sshtunnel/blob/master/debian/prerm
https://github.com/yurt-page/sshtunnel/blob/master/debian/postrm

So could you please review the scripts and their generation to the
dh_installsystemd?

Here is a man page for the dh_installsystemd
https://manpages.debian.org/testing/debhelper/dh_installsystemd.1.en.html



Hi,

Which version of debhelper are you using?  Support for /usr is only in 
unstable/testing. I would recommend adding a Build-Depends on `debhelper 
(>=13.11.9~) to ensure you have all the `/usr-merge` related feature 
support.  In the concrete case, 13.11.8~ might be sufficient (and 
happens to be available in stable-backports)


Best regards,
Niels

Bug#1065742: dh_install: cannot use empty lines or comments in substitution

[Niels Thykier]

Andreas Metzler:

Package: debhelper
Version: 13.14.1
Severity: normal

Hello,

supporting build-profiles like nodoc with dh_install seems to cumbersome.



Any reason for not using dh_installdocs, which does `nodoc` out of the box?

Best regards,
Niels

Bug#1065584: dh_update_autotools_config: cp: warning: behavior of -n is non-portable and may change…

[Niels Thykier]

Thorsten Glaser:

Package: debhelper
Version: 13.14.1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

dh_update_autotools_config -a -O--builddirectory=debian/build
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead

(showing up in build logs)



Fixed and reverted previously (see #1061610).

This will probably not be fixed until relevant coreutils is in stable.

Best regards,
Niels

Bug#1065377: elpa-dpkg-dev-el: Add more known fields to d/control

[Niels Thykier]

Package: elpa-dpkg-dev-el
Version: 37.11
Severity: wishlist
Tags: patch
X-Debbugs-Cc: ni...@thykier.net

Hi,

I found a number of fields that `elpa-dpkg-dev-el` does not recognize 
for debian/control. I have added them in the following MR:


https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/merge_requests/1/

Best regards,
Niels

Bug#1065054: pbuilder: Allow manual umount'ing after login

[Niels Thykier]

Package: pbuilder
Version: 0.231
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net

Hi

When using cowbuilder --login with a bindmount, I occasionally hit a 
problem where umounting fails on exiting from the chroot.


Here, pbuilder/cowbuilder as a precaution aborts the exit and forces you 
to solve the problem to avoid trashing your files. This is great.


In my case, I cannot always figure out why the mount point refuses to 
unmount but a lazy unmount (umount -l) gets the job done enough that my 
files are no longer in danger.  Doing that causes pbuilder to still fail 
on exit now with:


umount: /var/cache/pbuilder/build/cow.XXX/path/to/mp: not mounted.

And then throws me back into the chroot. So, to "unstuck" this, I end up 
having first to umount the mountpoint manually and then manually remount 
something else at that mountpoint, so pbuilder/cowbuilder get continue.


I think it would be nice if pbuilder could test if the mountpoint is 
still a mountpoint.  Since `mountpoint` is in `util-linux` (Essential: 
yes), this could be done with:



  IS_MOUNTED=true
  mountpoint -q "$MP" || RC=$?
  if [ "${RC}" = "32" ]; then
  IS_MOUNTED=false
  fi


For safety, I would recommend always doing umount, if that fails but 
mountpoint says the path is not a mountpoint, then it can progress.


Best regards,
Niels

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Niels Thykier]

Christoph Anton Mitterer:

On Thu, 2024-02-22 at 08:59 +0100, Niels Thykier wrote:

One challenge we have here is that a package can have multiple
versions
in a given suite at the same time; notably in unstable.


And multiple arches...



Indeed. Though, `apt-file` has the information needed to filter here and 
if you ask for only things in one architecture, you only get those (plus 
maybe the implicit arch:all).





For people that want better support here, please request the archive
maintainers to provide an index with versioning so that apt-file can
do
proper filtering.


Against what would one file such request? ftp.debian.org?


Cheers,
Chris.



That would be my best guess indeed. They are the provided of the 
metadata, apt-file consumes. I do not think it would need to be a major 
change to the format. Adding the version next to the package name would 
be sufficient (like turn foo/section to foo_version/section).


Best regards,
Niels

Bug#977322: Following advice of cute-field tag for X-DhRuby-Root breaks build

[Niels Thykier]

Control: clone -1 -2
Control: retitle -2 gem2deb: Case sensitive handling of d/control
Control: reassign -2 gem2deb

On Sun, 13 Dec 2020 15:27:20 -0800 Russ Allbery  wrote:

Package: lintian
Version: 2.104.0
Severity: normal

Lintian now emits the following pedantic tag for packages using
X-DhRuby-Root:

P: remctl source: cute-field debian/control@ruby-remctl X-DhRuby-Root vs 
X-Dhruby-Root
N:
P: cute-field
N:
N:   The named field uses a free-style form of capitalization, which is
N:   permitted by policy. The alternative offered is probably a more common
N:   variant in the archive.
N:   
N:   Refer to Debian Policy Manual section 5.1 (Syntax of control files)

N:   for details.
N:   
N:   Severity: pedantic
N:   
N:   Check: fields/style


However, following this advice breaks the Ruby package tooling.  The
build products are not copied into the package correctly and the resulting
package is empty.  Apparently the Ruby package tooling requires that
specific capitalization.

This is with gem2deb 1.4.

[...]


Hi

On one end, I do not think `lintian` decides the canonical case / 
spelling of a field. In that sense, I feel this bug is valid.


On the flip side, gem2deb does not follow the deb822 if field name case 
matters. The format is defined as case-insensitive.


"""
Field names are not case-sensitive, but it is usual to capitalize the 
field names using mixed case as shown below. Field values are 
case-sensitive unless the description of the field says otherwise.

"""

Cloned and reassigned accordingly.

Best regards,
Niels

Bug#1064454: debian-policy: Restrict deb822 field names more

[Niels Thykier]

Simon Josefsson:

Would it make sense to change this to use an inclusive list of permitted
characters instead?  How about checking the field names that is in use
today, and construct a regexp of permitted symbols out of that?
Starting point: [A-Za-z][A-Za-z0-9-_]*

/Simon


That is an option and would work for me.

Though, the starting point should include "_" as allowed for first 
character for the reasons listed in my opening email.


Best regards,
Niels

Bug#1064454: debian-policy: Restrict deb822 field names more

[Niels Thykier]

Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net
X-Debbugs-Cc: lintian-ma...@debian.org
X-Debbugs-Cc: de...@lists.debian.org
X-Debbugs-Cc: debian-d...@lists.debian.org

Hi

I am hoping we can agree to some tighter bounds on the field names 
followed by relevant tools implementing the same restrictions in our 
next versions. Ideally all deb822 parsers should follow suit; I have 
CC'ed the major ones I could think of.
 I will submit a MR for the  python-debian's parser if a change is 
agreed, which would eventually cover dak.


My rationale for this request is as follows.


The policy says the following about a field name:



The field name is composed of US-ASCII characters excluding control characters, 
space, and colon (i.e., characters in the ranges U+0021 (!) through U+0039 (9), 
and U+003B (;) through U+007E (~), inclusive). Field names must not begin with 
the comment character (U+0023 #), nor with the hyphen character (U+002D -).



Which leads to the interesting case that:

```
Package: foo
Depends: bar,
${shlib:Depends}
```

is a *valid* deb822 paragraph with 3 fields. The last being named 
`${shlib` with the value `Depends}`. I spotted this while debugging the 
python-debian parser that did not react to what I thought was a clear 
syntax error.


While the parser is technically correct given the Policy description 
above, I cannot see any case where this is a desirable outcome. Instead, 
I think we should classify this as a syntax error such that users are 
instructed to indent `${shlib:Depends}` token.


A simple fix would be to forbid `$` at the start of the field. Though, I 
think at this point it would make sense to prune more special characters 
from the list like `%&{}[]()/\\<>|$` from anywhere in the field. Note 
that we definitely need to keep `_` as it is used in debconf template 
files for translations. Both single and double underscore is used here, 
though they always come first in the field name.


The reason why I want a tighter bound is that currently, the following 
things are also considered valid field names:



|foo(>=1:2.0),
foo(>=2:2.0),
,foo(>=3:2.0)
,foo(>=4:2.0)[amd64]
)': We can make inverted crying smileys as field names!
`Foo`: Now with markdown formatting of the field name!
$(foo): Can we trick something into running shell commands?
/etc/passwd: Maybe path traversal


In all cases, I see no value to allowing these absurd field names and 
only potential downsides.



Best regards,
Niels

PS: I doubt anything actually uses field names in an unsafe manner any 
more. But we do have some history with deb822 files.


But someone will eventually try to do this. We already received a bug 
report against debhelper long ago about being able to do path traversal 
via questionable package names. Largely, this was considered a non-issue 
because dpkg in its default configuration would abort and debhelper has 
a "run arbitrary code via the upstream build system" feature anyway.


Additionally, 10+ years ago. lintian would create a file per field of 
the file it scanned. Here, if it had used perl's "2-arg" open, you might 
have been able to do something "fun". I do not remember if it did and 
the exploit is a decade overdue even if.

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Niels Thykier]

Christoph Anton Mitterer:

Hey.

I took the liberty to forcemerge these two bugs (578727 and 525813) as
they seem to be about the same thing.

My suggestion would be that per default, the apt-file should print the
package name with =version.
Perhaps with the exception if only one version is available (or maybe
there should be an option, that causes the =version to be omitted, if
and only if, only on version is available).

When specifying the package name I think it should also allow =version
to be appended and follow the behaviour of e.g. apt-get cache, that is:
- if no version is given, match all available versions
- if one is given, match only that.


Cheers,
Chris.



Hi

One challenge we have here is that a package can have multiple versions 
in a given suite at the same time; notably in unstable. There is no 
metadata that tells apt-file which file is in which version of the 
package. So in this case, even adding a version could produce the wrong 
result. I have no plan to support versioning for selecting the suite 
because of the above problem, because it will not fix the root issue - 
only gloss over it in some cases.


For people that want better support here, please request the archive 
maintainers to provide an index with versioning so that apt-file can do 
proper filtering.


Best regards,
Niels

Bug#901631: Bug#901507: lintian: warn if debhelper is in B-D-Arch or B-D-Indep but not Build-Depends

[Niels Thykier]

On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie  wrote:

On Sat, 16 Jun 2018 at 18:45:56 +0100, Chris Lamb wrote:
> I'm also seeing a bunch of false-positives in the addon checker -
> using the dh Python addon shouldn't mean that python can't be in
> Build-Depends-Indep. Or dpatch!

Sure - I hadn't intended that you'd add this mechanism for packages that
ship debhelper addons alongside other content, just the ones that have
little or no purpose other than their debhelper addons, like most/all
of the dh-$addon family, and maybe some of the pkg-$team-tools family.



Hi,

Drive by remark from the debhelper maintainer.

Some dh add-ons can be in ``Build-Depends-Indep`` now and is used to 
support cross-building in some cases. I do not remember when the feature 
was added though, so it might not have been possible at the time this 
was filed.


It is hard to tell which add-ons can be in B-D-I, and which cannot. If
lintian is going to warn about it, I would recommend a static data list
for this.
Best regards,
Niels

Bug#1063126: debhelper: dh_makeshlibs should not generate shlibs for /usr/lib/python*/ and /usr/lib/jni

[Niels Thykier]

Niels Thykier:

Package: debhelper
Version: 13.13
Severity: normal
X-Debbugs-Cc: vor...@debian.org, ni...@thykier.net
Control: reporter -1 vor...@debian.org

Raised on IRC that `dh_makeshlibs` includes a lot of "irrelevant" files 
in the shlibs. Particularly, Python libraries (usr/lib/python*) and Java 
libraries (usr/lib/jni + usr/lib/$MA/jni) looks like low-hanging fruits 
that can easily be skipped in the shlibs. Note part of the problem is 
that these files includes a SONAME even though it is not a public ABI 
library.


Excluding these libraries would have made the t64 transition simpler as 
they used the shlibs as basis for which packages had libraries with 
public ABIs, where the above mentioned paths were false positives.


Best regards,
Niels



The bug #204975 is related on getting unnecessary triggers, where the 
proposal was to use an allow list of directories.


Best regards,
Niels

Bug#1063126: debhelper: dh_makeshlibs should not generate shlibs for /usr/lib/python*/ and /usr/lib/jni

[Niels Thykier]

Package: debhelper
Version: 13.13
Severity: normal
X-Debbugs-Cc: vor...@debian.org, ni...@thykier.net
Control: reporter -1 vor...@debian.org

Raised on IRC that `dh_makeshlibs` includes a lot of "irrelevant" files 
in the shlibs. Particularly, Python libraries (usr/lib/python*) and Java 
libraries (usr/lib/jni + usr/lib/$MA/jni) looks like low-hanging fruits 
that can easily be skipped in the shlibs. Note part of the problem is 
that these files includes a SONAME even though it is not a public ABI 
library.


Excluding these libraries would have made the t64 transition simpler as 
they used the shlibs as basis for which packages had libraries with 
public ABIs, where the above mentioned paths were false positives.


Best regards,
Niels

Bug#995053: dh_assistant command for listing installed files

[Niels Thykier]

Jelmer Vernooij:

Hi Niels,

[... past correspondence removed ]
> Part of the challenge here is that I'm still trying to figure out
exactly what we can do here as well.



Hi Jelmer

I have news on what is possible. It is not directly what you asked for, 
but I think you will find it interesting.


 $ apt satisfy 'debhelper (>= 13.13), dh-debputy (>= 0.1.18)'
 $ git clone https://salsa.debian.org/debian/debhelper && cd debhelper
 # or another package of choice
 $ debputy tool-support annotate-debian-directory
{
"result": [
{
"path": "debian/changelog",
"binary-package": "debhelper",
"file-categories": [
"ppf-file"
],
"documentation-uris": [
"man:dh_installchangelogs(1)"
]
},
{
"path": "debian/copyright",
"binary-package": "debhelper",
"install-path": "/usr/share/doc/debhelper/copyright",
"install-pattern": "usr/share/doc/{owning_package}/copyright",
"file-categories": [
"ppf-file"
],
"documentation-uris": [
"man:dh_installdocs(1)"
]
},
{
"path": "debian/debhelper.docs",
"binary-package": "debhelper",
"install-path": "/usr/share/doc/debhelper",
"config-features": [
"dh-docs-only",
"dh-dollar-subst",
"dh-executable-config",
"dh-filearray",
"dh-install-list-fixed-dest-dir"
],
"install-pattern": "usr/share/doc/{owning_package}",
"file-categories": [
"pkg-helper-config"
],
"documentation-uris": [
"man:dh_installdocs(1)"
]
},
[...]
{
"path": "debian/debhelper.install",
"binary-package": "debhelper",
"config-features": [
"dh-dollar-subst",
"dh-executable-config",
"dh-filedoublearray",
"dh-glob-after-execute",
"dh-install-list-dest-dir-like-dh_install",
"dh-late-glob",
"dh-partial-glob",
"dh-exec-rename"
],
"file-categories": [
"pkg-helper-config"
],
"documentation-uris": [
"man:dh_install(1)"
]
},
[...]
],
"reference-datasets": [
"config-features",
"file-categories"
]
}
   # Reference data accessible as JSON via:
   $ debputy tool-support export-reference-data --output-format=json
   # or in terminal as ASCII art text:
   $ debputy tool-support export-reference-data config-features

The output works the "same" whether the package is built using `dh` or 
`debputy`. For many files, they will only be tagged if the relevant 
helper is active (only applies to dynamically resolved files, static 
files like `debian/debputy.manifest` is always tagged even though 
debputy is not used).  Output for classic debhelper or helper-less 
packages is ... not tested at all and probably not helpful. For classic 
debhelper, I support it will be okayish but not fully aligned with the 
tools used in d/rules. For helper-less, you will probably not get a lot 
of useful output.


With this output, you will get insights into:

 1) Which files in debian is or might be picked up by some tool. It also
lists (to the Janitor) irrelevant files, because the underlying code
can also be used find documentation for known packaging files.

 2) Where a file like debian/pam is installed in the package, `debputy`
will attempt to provide you resolve the path for you assuming it was
given a pattern for it in the `install-path` attribute. Note
especially debian/pam is exciting because the path changes in compat
13 and I think you will like this one. These are tagged with
`ppf-file`

 3) With files debian/docs, `debputy` will provide you with the dest
directory for the file (usr/share/doc/) via the
`install-path`. Additionally, the `config-features` will enumerate
known tags for the file. The description for these tags are in the
reference data ("config-features").

 4) Some files will appear multiple times if they are processed multiple
times (such as, debian/changelog, which will be installed once per
package).

 5) `debputy` will resolve *obvious* uses of `dh $@ --with foo` for you.
Sequences in Build-Depends will also be resolved. Sequences not
installed will work but cause reduced data availability and an
"issues" section in the json file (which in some cases will tell you
which sequences are missing, so you can install them and re-run the
tool).

The [debhelper-documentation plugin] is probably the most interesting 
source of data for you. Most likely, it 

Bug#663148: po4a: Text (-o control=...) chokes on a normal dctrl file

[Niels Thykier]

On Sat, 06 Jan 2024 00:27:02 +0100 Martin Quinson 
 wrote:
> I believe the libdpkg-perl package has a dpkg parser that handles the 
> basic parsing.
> 


Indeed, I think that the parser in /usr/share/perl5/Dpkg/Control/HashCore.pm
would cover my needs. I'm still unsure of whether I should use this parser as
is, or copy/paste the code. The second is always crude, but the first one may
be difficult on non-Debian systems, as dpkg is meant to embeed all its
dependency to reduce bootstraping issues.

Anyway, I'm running out of time on po4a for this time and mostly write it down
for future reference.

Thanks for the fish,
Mt




For the record, the module is also on CPAN 
(https://metacpan.org/pod/Dpkg) in case that makes the situation easier 
to resolve.


Best regards,
Niels

Bug#663148: po4a: Text (-o control=...) chokes on a normal dctrl file

[Niels Thykier]

Martin Quinson:

Hello,

I am sorry I didn't answer to this bug in all these years...

The support for Deb822 files seems very limited right now. Beside of the bug
you reported, it fails to handle folded entries, as your Info: fields where the
first line is not specific and should be added to the content afterward.
Comments are also badly handled. Etc etc.

I think that the best would be to reimplement it from scratch. I'm not a big
fan of reimplementing things from scratch, but the existing po4a parser for
control files is 50 lines long only. Not a big loss.

Do you guys know a good and simple parser of such files that would be written
in Perl? If it's a library I'd reuse it, and if it's part of another program
I'd copy/paste and adapt it to our use case. Given the time I can devote to
this project despite IRL, I need to be efficient.

Thanks, and sorry for the delay,
Mt


Hi Martin

I believe the libdpkg-perl package has a dpkg parser that handles the 
basic parsing.


Best regards,
Niels

Bug#703941: -p (path) option clashes with generic debhelper -p (package) option

[Niels Thykier]

On Mon, 30 Oct 2017 09:43:55 + Simon McVittie  wrote:

On Tue, 26 Mar 2013 at 00:27:07 +0100, Michael Biebl wrote:
> Using -p as option to specify the path is a poor choice since it clashes
> with the generic -p option which is used to specify the package.
> 
> Looking at e.g. gnome-shell's debian/rules, I'm actually not sure what

> the result of this call will be:
> dh_girepository -p$(cdbs_curpkg) -l src -p /usr/lib/mutter

The answer seems to be that -p is always interpreted as dh_girepository's
local -p option, and the second -p overwrites the first, so it's
equivalent to dh_girepository -l src -p /usr/lib/mutter. To get the
effect that was intended, write:
dh_girepository --package=$(cdbs_curpkg) -l src -p /usr/lib/mutter

Regards,
smcv




Hi

I would recommend that `dh_girepository` would detect `-p` without a `/` 
(or without `:`) and produce an error or a warning for that case until a 
better solution comes around.


A path without `/` implies a top-level directory, which is in itself 
exceedingly unlikely to be intentional for `-p` and therefore a very 
strong indicator that someone wanted `-p `.


Secondly, even if the user *wanted* that top-level directory, it is 
trivial to bypass the check by prefixing with ./ or adding a trailing 
slash - both would clearly mark it as "not a package" and happens to 
work with path looks up out of the box.


Code-wise, this would be something like:

```diff
 if ($dh{P_PARAMS}) {
+if ($dh{P_PARAMS} !~ m{[/:]}) {
+error("Use --package ... or prefix path with './' ...");
+}
 push @privdirs, split /:/, $dh{P_PARAMS};
 }
```
(hand-written delta; not expecting it to apply)

With this, there would at least be less surprises that the user would 
not be using the standard debhelper `-p` for cases that uses a package name.


If you want to do a more permanent fix where `-p` goes back to being the 
regular `debhelper -p`, I can recommend using a compat check to 
conditionally assign the `-p` and we can document the change in the 
standard debhelper compat upgrade check list.


Best regards,
Niels

Bug#1059551: Remove obsolete command 'dget'

[Niels Thykier]

On Thu, 28 Dec 2023 14:26:56 + Steve McIntyre  wrote:

Ummm, no. dget is a very useful tool with very different use cases
from apt-get - particularly when grabbing source packages.

Leave it alone.

[...]


Hi

Adding some context to Steve's mail.

One use-case that `dget` offers that `apt-get source` does not is the 
ability to download a `.dsc` plus related files from "non-Debian 
mirrors" (such as but not limited to mentors.debian.net) without 
requiring archive metadata such as Sources + Release.


This use-case is `dget https://.../foo_version.dsc` rather than `dget foo`.

Best regards,
Niels

Bug#1059565: pkg-js-tools: Tests (autopkgtests) uses `fakeroot` without dependency

[Niels Thykier]

Package: pkg-js-tools
Severity: serious
X-Debbugs-Cc: ni...@thykier.net
Control: affects -1 src:devscripts
Justification: Autopkgtests failures are RC per RT decision

Hi

A new version of `devscripts` removed its dependency on `fakeroot`. 
After this, the pkg-js-tools's autopkgtests started failing with errors 
like:


759s Can't exec "fakeroot": No such file or directory at 
/usr/share/perl5/Dpkg/IPC.pm line 312.
759s dh_eslint.t: error: unable to execute fakeroot dh_auto_install 
--buildsystem=nodejs: No such file or directory
759s dh_eslint.t: error: fakeroot dh_auto_install --buildsystem=nodejs 
subprocess returned exit status 25



https://ci.debian.net/packages/p/pkg-js-tools/testing/amd64/41355085/#L12525

This implies that `pkg-js-tools` was missing a (test) dependency on 
`fakeroot`.  Looking a bit deeper into the tests, I think the `fakeroot` 
usage is unnecessary. Example from dh_badfilesfield.t:


spawn(

exec   => [ 'fakeroot', 'dh_auto_install', '...' ],

wait_child => 1

);


Generally, `dh_auto_install` (nor any other `debhelper` tool) does not 
require `fakeroot` and should be runnable without it assuming the 
underlying build system is ready for it (which is generally should be 
these days).  You *may* need to set `DEB_RULES_REQUIRES_ROOT=no` to 
avoid triggering a safety check inside debhelper.


I would recommend that you remove all uses of `fakeroot` where possible 
instead of just blindly adding the depends.


Best regards,
Niels

Bug#1057001: dh-debputy: HTML documentation is compressed

[Niels Thykier]

Sven Joachim:

Package: dh-debputy
Version: 0.1.9
Severity: normal

I was playing around with dh-debputy and tried to convert xterm to it.
That seems to mostly work, however two HTML files are now compressed:

,
| [...]
`

It seems that the list of extensions not to compress was converted
incorrectly from dh_compress, for the latter ignores *.htm* files,
except for changelog.html.


[...]

Hi Sven

Thanks for trying `debputy` and for reporting the bug.

I just uploaded debputy/0.1.9.1, which should fix this bug and also 
remove the `doc-base` benign delta you are seeing.


Best regards,
Niels

Bug#1055760: debian-policy,dpkg: Please document maintscript flow with `prerm deconfigure`

[Niels Thykier]

Package: debian-policy,dpkg
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net,debian-d...@lists.debian.org

Hi

The flow charts at 
https://www.debian.org/doc/debian-policy/ap-flowcharts.html 
unfortunately does not cover the `prerm deconfigure [...]`


This makes it hard to figure whether a package needs to consider 
`deconfigure` when it needs to have `prerm` code.


Like if a `prerm deconfigure` will be followed by a `prerm remove` then 
doing anything in `prerm deconfigure` is basically redundant (?) as you 
can just do it in `prerm remove` instead. Or does `deconfigure` imply a 
`remove` (despite the name suggesting it would only move the package to 
"configured -> unpacked")


This would also be relevant to understand whether postinst need to react 
to `abort-deconfigure` or can one assume that a `configure` will always 
(timely) follow an `abort-deconfigure`?


I had a look at `deb-prerm` and `deb-postinst`. Sadly, these does not 
answer my questions (they say when the action occurs). However, I am 
missing an overview and the terse descriptions do not give me that (nor 
tell me what state the package is in after success/failure, which could 
have helped in some cases).


Best regards,
Niels

PS: In debhelper, I have liberally sprinkled in `abort-*` cases in to 
the postinst and avoided any conditions in the prerm scripts. But it is 
not out of understanding but out of assumptions.

Bug#1054368: debhelper: Does not support double build (possible violation of Policy 4.9)

[Niels Thykier]

Control: tags -1 wontfix

Helge Kreutzmann:

Package: debhelper
Version: 13.11.4
Severity: minor
User: debian...@lists.debian.org
Usertags: qa-doublebuild

[...]

I first checked (my) upstream build system. Except for one stamp file
(which is *much* less than done by debhelper) the build is idempotent,
i.e.:

./configure && make && make clean

returns the sources into the state as shipped.

[...]

dh seems to delete quite a few files shipped in the package.



Deleting files shipped in the package is a non-issue (dpkg ignores that 
with a warning).



For me, this is a clear bug in dh, as linuxinfo just uses it plain and
there is no "manipulation" of build files happening (on purpose).



The root cause seems to be that the upstream tarball contains binary 
".gmo" files that will be regenerated when you build with dh and are not 
reset/deleted when you clean.


Most likely this is a consequence of dh_autoreconf (which is not 
debhelper but a separate package that debhelper depends on) or 
`dh_auto_clean` using `make distclean` rather than `make clean` (as you 
tested with).



I checked dh_clean(1) and dh(1), but could not find any mention of how
to modify this (which I would not have expected anyhow).



Both `dh_clean` and `dh` are red herrings in this case.


If the severity of 1047898 is changed, then I will change this one (as
it is the root cause). In linuxinfo I probably could work around this,
by backing up all affected files before clean and restoring them after
clean (using an override). But this is a band aid, not a solution.



From my point of view, running an upstream build system is running 
arbitrary code. There is no way debhelper can reliably detect and manage 
all possible variations of upstreams and how they implement 
"./configure" vs. whether they include binary .gmo files in their source 
tarball that may or may not be regenerated during build and how they 
structure their source code internally.
  As a consequence, it is my view that the root cause is not solely 
debhelper and that you will have to work around this in your package 
somehow. This could be by:


  * Disabling dh features that cause this problem, OR by

  * Telling dh_clean to purge the `*.gmo` files
(`echo 'po/*.gmo' > debian/clean` should do), OR by

  * Repacking the upstream tarball to not include the binary files being
mutated in the first place.

As the maintainer of debhelper, this is my principle stance on this 
matter. If you disagree, you are welcome to either:


 * provide a "small non-intrusive" patch that solves your problem
   without causing a significant number of regressions. Onus is on
   you (whoever providing the patch) to research alternatives, and, if
   the patch is controversial/likely to break other packages, provide
   archive-wide test results and as necessary show project wide
   consensus on debian-devel, OR

 * raise this issue to the tech-ctte according to constitution 6.1.1
   (AFAICT). However, if you do put this before the tech-ctte, be
   advised that they cannot do detailed design work (constitution
   6.3.5). This means for them to make a decision someone else has to
   come up with a practical technical solution that they can vote in
   over the status quo. And by doing that, that someone might as well
   provide a patch per the first bullet point because the tech-ctte
   will probably have the same questions/requirements as I laid out
   above.

Best regards,
Niels

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Niels Thykier]

Control: retitle -1 debhelper: dh_install, globs vs. executable files
Control: tags -1 -moreinfo

Gioele Barabucci:

On 12/10/23 14:54, Niels Thykier wrote:

Gioele Barabucci:

On 12/10/23 14:11, Niels Thykier wrote:

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


maybe it is the combination of dh_installman + dh-exec?


    When  using executable debhelper config files, please be aware of
    the following:

    Otherwise,  the  output will be used exactly as‐is.  Notably,
    debhelper will **not expand  wildcards** or  strip  comments
    or strip whitespace in the output.


This surprises me a bit. util-linux currently uses both dh-exec and 
wildcards in `d/util-linux-locales.install` and it works as "expected" 
(but not as documented?):


https://salsa.debian.org/debian/util-linux/-/blob/f7d972e9d/debian/util-linux-locales.install

Doesn't this mean that `dh_install` expands the globs found in the 
output of the executable `foo.install`?


Regards,



It does; `dh_install` is a special snowflake of doing everything 
differently than anything else. The `dh_install` helper manually does 
the glob'ing rather than using the `filedoublearray` for glob expansion. 
 As a historical artefact, it never knew whether the `install` file 
executable and therefore the restriction never fully applied there.


This artefact has (also) been there since the introduction of executable 
debhelper config files.


I will accept this as a bug for dh_install not behaving as documented. I 
am probably going to end with ratifying the current behaviour rather 
than removing glob support (because removing glob support would require 
more code and break anyone relying on it even though it should not work).


For everything else, glob support should be done by the executable 
itself (possibly indirectly via dh-exec).


Best regards,
Niels

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Niels Thykier]

Gioele Barabucci:

On 12/10/23 14:11, Niels Thykier wrote:

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


Hi,

maybe it is the combination of dh_installman + dh-exec?

[...]

Regards,



Behaviour is as documented in `man 7 debhelper` under the "Executable 
debhelper config files":


"""
Executable debhelper config files


   When  using executable debhelper config files, please be aware of
   the following:

 * [...]

   Otherwise,  the  output will be used exactly as‐is.  Notably,
   debhelper will **not expand  wildcards** or  strip  comments
   or strip whitespace in the output.
"""
(emphasis mine)


As I see it, debhelper is working exactly as it is documented and 
therefore as it is expected to do.  This restriction of the executable 
config feature has been there from "day 1" of supporting executable 
files (from the days of debhelper/9) and is unlikely to change given the 
current architecture of debhelper.


Best regards,
Niels

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Niels Thykier]

Control: tags -1 moreinfo

Gioele Barabucci:

Package: debhelper
Version: 13.11.6
Severity: minor

Dear debhelper maintainer,

the line

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


[...]

Regards,



Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


Best regards,
Niels

Bug#1053668: diffoscope: Consider using `file -i` as fallback for unknown file output

[Niels Thykier]

Chris Lamb:

Niels Thykier wrote:


Digging a bit deeper, it turns out that `file -i` correctly classifies
the changelog as `text/plain; charset=utf-8`.  That is, `file` knows it
is text and I suspect `diffoscope` should try `file -i` as well when it
gets an unknown result from `file`.


By "unknown result" I assume you mean that diffoscope cannot match
the file type with any known comparator. :)  Indeed, diffoscope
doesn't recognise the bogus "Message Sequence Chart" so it falls
back to using a hexdump as you intuited.



Correct.


I've got some WIP code that will treat unknown file types as text if
they have a MIME type of text/plain. This avoids the use of hexdump
with the examples you sent over at least.



Sounds good. :)


Do you think I should be further limiting that conditional to a
whitelist of safe encodings, too? (eg. "utf-8" and "us-ascii", etc.)


Regards,



I am not sure what to do here.  Maybe you want to normalize the encoding 
first for more reliable diffs.  If one side is utf-8 and the other is 
utf-16 or something more exotic, normalized the encoding before the diff 
might produce more readable diffs as long as diffoscope somewhere 
denotes the encoding difference.  But honestly, I feel I should defer to 
your experience on this particular corner case.


Best regards,
Niels

Bug#1053668: diffoscope: Consider using `file -i` as fallback for unknown file output

[Niels Thykier]

Package: diffoscope
Version: 250
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net

Hi,

I noticed that `diffoscope` used `hexdump -C` based diffs for the 
debian/changelog in the `mscgen` package.


My first bet was that `file` would produce incorrect output and indeed, 
`file` classifies that changelog as a `Message Sequence Chart` rather 
than text.  This is now filed as 1053666.


Digging a bit deeper, it turns out that `file -i` correctly classifies 
the changelog as `text/plain; charset=utf-8`.  That is, `file` knows it 
is text and I suspect `diffoscope` should try `file -i` as well when it 
gets an unknown result from `file`.


This bug report obviously assumes that the `hexdump -C` like output is 
triggered because `diffoscope` uses `file` for determining how to 
analyze the changelog.  If it uses something else, then there is some 
other bug in play that makes `diffoscope` treat the `mscgen` changelog 
as a binary file.


Here are two samples files that `file` considers to be `Message Sequence 
Chart (chart)` and `text/plain; charset=us-ascii` with -i, in case it is 
useful for a test:


```
msc {
  a, b;
}
```
```
msc {
  c, d;
}
```



Best regards,
Niels

Bug#1053667: file: Misclassifies d/changelog of the mscgen package as a "Message Sequence Chart"

[Niels Thykier]

Package: file
Version: 1:5.45-2
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

Hi,

I get `Message Sequence Chart (chart)` when applying `file` to the 
changelog of the `mscgen` package.


$ file mscgen/debian/changelog 
mscgen/debian/changelog: Message Sequence Chart (chart)
$ head mscgen/debian/changelog 
mscgen (0.20-14) unstable; urgency=medium


  * Apply patch from Steve Langasek to avoid using negative
widths for text sizes in PNG files, which lead to crashes.
(Closes: #960405)
  * Add patch to give more height to PNG text.  The original
rendering no longer gave adequate space between lines or
the entity the text was a part of.
  * Remove -Wl,--as-needed as linker flag since it is now the
default.
 
For other Debian changelogs, `file` seems to have a much more reasonable 
output saying it is UTF-8 text.


"""
$ file debhelper/debian/changelog
debhelper/debian/changelog: Unicode text, UTF-8 text
"""

I suspect this is why `diffoscope` uses a `hexdump -C` based diff when 
doing delta's for the `mscgen` changelog.


Best regards,
Niels

-- System Information:
Versions of packages file depends on:
ii  libc6  2.37-12
ii  libmagic1  1:5.45-2

Bug#1053666: file: mscgen's examples are not classified as Message Sequence Charts

[Niels Thykier]

Package: file
Version: 1:5.45-2
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

Hi,

Another MSC related bug report for file.

It seems that `file` uses `msc {` to detect a Message Sequence Chart per 
the following mini test:


```
$ echo 'msc {' | file -
/dev/stdin: Message Sequence Chart (chart)
```

So it would seem reasonable that the mscgen's examples would be 
classified as a `Message Sequence Chart` as they contain this phrase:


```
$ grep 'msc {' examples/client_server.mscin
msc {
```

However, `file` considers them to be `ASCII` text:

```
$ file examples/*.mscin
examples/boxes_example.mscin:ASCII text
examples/client_server.mscin:ASCII text
examples/colour_sample.mscin:ASCII text
examples/msg_types.mscin:ASCII text
examples/simple_prog_desc.mscin: ASCII text
```

I suspect the "problem" is that the examples starts with comments 
covering the license of the example and some context about the example.



All examples here are from the `mscgen/0.20-14` Debian source package. I 
have not tried `file` on the installed examples. The installed examples 
has a #!-line, which could affect the outcome in a different direction.


-- System Information:
Versions of packages file depends on:
ii  libc6  2.37-12
ii  libmagic1  1:5.45-2

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Niels Thykier  writes:

Russ Allbery:



Ooo, this is a great framing of the problem.  I have a lot of thoughts
about this.  Unfortunately, I'm not sure if they're actionable thoughts
since my grand vision requires someone to sit down and do some serious
Policy restructuring and produce a radically different document.  But
maybe if I write them all down and enough people feel similarly, it
would be worth doing.  I would love to work on this, I am just afraid
that it is the sort of project that I would start and never finish and
thus never accomplish anything of use.



Indeed, it is definitely the thing I would personally prefer to
pre-align on before adventuring on something of this scale myself (were
I in your shoes), so I totally feel your concern about actionability.


I do to some extent want people to encourage me to work on this if they
think it would be awesome, since people being happy with it would be what
would make all the work worthwhile (although I will probably also need
help).  :)



Personally, I feel such a change would be for the better. +1 from here.


Interesting choice with the mixing. I was of the understanding that the
idea was one should try to avoid mixing documentation styles according
to Divio. Admittedly, I find it hard to fully stick to exactly one type
of style, so I would be happy if I had just overlooked the "advice on
mixing".


So, I have to admit that I have not read Divio in detail although I have
been pointed at it many times and have had the high-level concepts
explained to me.  I've read bits and pieces, but I'm not sure what it says
about mixing.



I think it was my reading of their Introduction section. It says:

"""
Each of them requires a distinct mode of writing. People working with 
software need these four different kinds of documentation at different 
times, in different circumstances - so software usually needs them all, 
and they should all be integrated into your documentation.


And documentation needs to be explicitly structured around them, and 
they all must be kept separate and distinct from each other.

"""

Which I interpreted as "don't mix" (particular the "must be kept 
separate and distinct").  But re-reading here it might just be that the 
policy should use "How to" as a baseline and clearly mark explainer 
paragraphs as "Here is the background" as something you can choose to 
dive into or easily skip if you are not interested (or have distinct 
subsections for how to vs. explainers, which I think you are proposing 
in the part that I snipped)


Anyway, as long as you are going into it with open eyes and it seems 
like you are!



[...]


As for the content: The "How-to" style would make sense for the target
audience.  I am less clear if all of these headlines makes up a "Policy"
as they sounds like something you could find in a "Debian Packaging 101"
guide.


I think that about a quarter of Policy currently is already how-to text.
For example, look at Policy 3.4:

https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions

This is a disguised how-to document on how to write a good package
description.  There's a ton of stuff in Policy like this.  What
distinguishes it from a Debian Packaging 101 guide is that the how-to goes
into *way* more depth than a 101 guide: edge cases, exceptions, advanced
bits of packaging, etc.



Sounds good to me.  For me it was mostly a question to ensure that 
Policy would not end up like "yet another new maintainers guide". You 
seem to have a clear vision here for how the Policy would set itself 
apart and I think you make a compelling argument.



The main problem from the perspective of helping the typical packager, is
that this is mixed in with oodles of advice that is irrelevant to anyone
except debhelper maintainers.  To take another short example, look at the
section on symbolic links:

https://www.debian.org/doc/debian-policy/ch-files.html#symbolic-links

Half of that section is a specification for the packaging helper, which
will fix symbolic links to follow those rules.  The rest is sort of a
how-to (mixed in with some basic shell command advice).



Indeed, I am not a fan of the those sections in our Policy!


Side question: Does Policy add anything on the specification for
`symbols` and `shlibs` files as a reference document that is not covered
by dpkg's documentation for these formats? I assume the "symbols guide"
(on /when/ to use symbols and when not too) would go in the previous
section.


Well, one can read the two side-by-side and see, and I'm biased as the
person who wrote it, but I think it does.

Policy duplicates dpkg documentation quite a lot, so this is a question
worth asking, but I do think Policy has a good answer.  The value that
Policy adds over the dpkg documentation generally falls into three
categories:

[...]


Again, compel

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Niels Thykier  writes:


I had a look at the introduction section of Policy to check who the
target audience is.  I cannot find an explicit mention of the target
audience. I suspect there is a conflict here on the content because we
have different audiences in mind for the Policy and the Policy does not
seem to be explicit here.



[...]


Ooo, this is a great framing of the problem.  I have a lot of thoughts
about this.  Unfortunately, I'm not sure if they're actionable thoughts
since my grand vision requires someone to sit down and do some serious
Policy restructuring and produce a radically different document.  But
maybe if I write them all down and enough people feel similarly, it would
be worth doing.  I would love to work on this, I am just afraid that it is
the sort of project that I would start and never finish and thus never
accomplish anything of use.



Indeed, it is definitely the thing I would personally prefer to 
pre-align on before adventuring on something of this scale myself (were 
I in your shoes), so I totally feel your concern about actionability.



I think that ideally Policy targets all three of your audiences, but not
at the same time, and not with the same priority.

I have a lot of problems with the current structure of Policy, to the
extent that it sometimes interferes with my motivation for working on it,
and one of the big ones is that it doesn't follow any structured design
pattern for documentation, such as Divio [1].


I had Divio in an earlier draft of my email - should have kept it! :D


[...]

I think my ideal structure of Policy would have three major parts.

First, there would be Policy for Debian packagers.  This would focus on
the things someone packaging for Debian needs to know, and would be
organized roughly around task.  Example sections here would be:

* Choosing an archive area
* Files on the file system (FHS, ownership, permissions, etc.)
* Writing a debian/control file
* Writing a changelog
* Writing a copyright file
* Packaging a shared library
* Packaging a system service
* Using maintainer scripts

In other words, this section would consist primarily of Divio how-to
guides, with some intermixed Divio explanations.  (Tutorials I think are
outside the scope of Policy and are better handled elsewhere, such as in
debhelper documentation.)

[...]


Interesting choice with the mixing. I was of the understanding that the 
idea was one should try to avoid mixing documentation styles according 
to Divio. Admittedly, I find it hard to fully stick to exactly one type 
of style, so I would be happy if I had just overlooked the "advice on 
mixing".


As for the content: The "How-to" style would make sense for the target 
audience.  I am less clear if all of these headlines makes up a "Policy" 
as they sounds like something you could find in a "Debian Packaging 101" 
guide.  That is a "risk" (or maybe exactly what you are going for), 
which would be fine with me and I would support the idea.


Nevertheless, I feel it has quite some potential to make Policy more 
accessible to new contributors and that alone is worth supporting in my 
book. Though I am hardly the target audience nor "paying the upkeep 
cost", so supporting it is basically gratis for me.





[...]

Second section would be Policy the reference manual for interfaces in the
distribution.  Sections here would be:

* Complete list of control fields and their meanings.
* Specifications for the .dsc and .changes files (which packagers mostly
   never need to care about, but tool maintainers do).
* The detailed reference documentation on all the ways maintainer scripts
   can be called.
* Specification for the symbols and shlibs files.

This is all Divio reference stuff.  Whenever we have a comprehensive
explanation of the details of something, it goes here, and then we
liberally link to the reference section from the packaging-focused how-to
section for more details.



Makes sense to me as well. I would indeed also need documentation somewhere.

Side question: Does Policy add anything on the specification for 
`symbols` and `shlibs` files as a reference document that is not covered 
by dpkg's documentation for these formats? I assume the "symbols guide" 
(on /when/ to use symbols and when not too) would go in the previous 
section.



Finally, there is the reference manual for toolchain maintainers.  My
position on this is that it's best-effort documentation and should
probably be a non-normative appendix where toolchain maintainers are
relatively free to just make changes without going through a very formal
process as long as those changes reflect reality.  This is, by nature,
going to be incomplete and possibly out of date, but I do think the
project should have *somewhere* outside of any specific package where
people can write down the details of, oh, the other options to
Rules-Requires-Root that we aren't currently u

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Bill Allombert  writes:

[...]  Quite a lot of Policy is of the general format "here's a bunch of
complex things you need to do, wait, never mind, just use debhelper, go
see its documentation for the configuration files you should use instead"
and some of the rest of Policy is "here's a bunch of complex things you
need to do but if you follow these instructions instead of using debhelper
your package will be buggy."  This is not ideal!

I think there's a lot of appeal of having a thorough specification for
what debhelper is supposed to be doing.  It would enable future
competition around better packaging helpers (and I do think debhelper will
not be the last word).  But I also want to be realistic about whether
we're really capable of maintaining that specification.

--
Russ Allbery (r...@debian.org)  



Indeed. I have had the same challenge with the Policy.

I had a look at the introduction section of Policy to check who the 
target audience is.  I cannot find an explicit mention of the target 
audience. I suspect there is a conflict here on the content because we 
have different audiences in mind for the Policy and the Policy does not 
seem to be explicit here.


If the target audience is package maintainers, then 100% of all debian 
contributors should read it. Then we need "simple and easy to 
understand" language and examples, because we want *everybody* to 
understand this.  I agree with Russ that long winded sections of "here 
is how you do this manually but really just use debhelper" is directly 
counter productive to this audience.


If it is cross-package integration, are we targeting the ones 
integrating or the ones providing the integration points?  If it is 
both, then for more complex topics, it would make sense to split the 
topic into two. One for consumer and one for the provider of the 
integration, because for the consumer it will probably boil down to 
"install path at $X in your deb and run tool $Y" and then the consumer 
can skip the provider section as "not relevant".


  There is a separate here in whether the Policy editors have the 
capacity to maintain the documentation for the provider side of the 
integration points for all the integrations.  I think this is where Russ 
is arguing that we do not that capacity.  If so, it would also make 
sense to explicitly cut *out* that side of from policy in the Scope 
section. Maybe along the lines of "The Policy does not document the 
provider side of integration points directly. Instead, we provide links 
to the external documentation where available.".



If the target audience is tool-chain maintainers, then only 5-10 people 
need to read the policy and the entire document + related process seems 
completely over-engineered.  But then, for the same reason, I suspect 
this is an unlikely target audience for the Policy.



Either way, I think the root problem is that we are not all agreeing on 
scope and audience for the Policy. Until resolved, we can argue forever 
about whether X belongs in Policy.


Best regards,
Niels


PS: I also have other things to say about the concrete topic, but I will 
leave that for a later mail. I think the point above is so important 
that it should not be diluted with other topics.

Bug#1036731: python3-debian: fails to parse some debian/control.in files

[Niels Thykier]

Control: reassign -1 devscripts

Hi,

The RTS parser can already cope with non-deb822 input. However, the 
caller has to opt-in to it and wrap-and-sort never that that.


I am doing a patch for this to have wrap-and-sort cope with invalid 
syntactical input.  It will come with degradation of features - notably, 
the package sorting will be disabled as otherwise we risk moving a 
paragraph out of a templated section (and if that templated section is a 
for-loop, you now get a completely different result).


To my knowledge, there is nothing for `python3-debian` to do at the 
moment. Reassigning to devscripts for doing the patch.


Best regards,
Niels

Bug#1050709: tar-ignore debian/source/options

[Niels Thykier]

Sean Whitton:

Hello Niels,

[...]

dgit will never let you accidentally perform an upload containing
something that's in the tree but not in git, and you can use
.git/info/exclude as a local way to ensure it's never in git.  So a
simple policy of always doing uploads with dgit might achieve what you
want, without introducing all these deltas between source packages, git,
local trees etc.?



Hi Sean

Appreciate the suggestion.

The suggestion assumes that I am using dgit or ready to migrate my 
workflow to use dgit, which I am not at this stage.


I was open to doing to making my package work better for people that use 
dgit if it has a "near zero cost" to my current packaging work flow. It 
is regular that other people upload debhelper and some of them use dgit.


The proposal of replacing `tar-ignore` with its expanded version minus 
`tar-ignore=.gitignore` sadly does not fit that "near zero cost" bill 
for me.  For now, I am afraid my packages will not be compatible with 
dgit until the feature interaction between dpkg-source -I/tar-ignore and 
dgit is resolved.



Best regards,
Niels

Bug#1051213: RFS: debianutils/5.12 [ITA] -- Miscellaneous utilities specific to Debian

[Niels Thykier]

Control: owner -1 !

Ileana Dumitrescu:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "debianutils":

[..]

Niels Thykier and I will be co-maintaining this package.



I got this. :)

Best regards,
Niels

Bug#1050806: O: debianutils -- Essential utilities specific to Debian

[Niels Thykier]

Ileana Dumitrescu:

Hi Niels,

@Ileana: Would you be fine with co-maintaining it with me? We can use 
the existing git repo (https://salsa.debian.org/debian/debianutils) as 
packaging repo and coordinate our changes via that.


That sounds good!

I have submitted a new version of debianutils to mentors to close the 
ITA along with some other updates [1]. Can you give me the necessary 
permissions for the salsa repo and future uploads?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051213

Best,



Hi Ileana

Thanks for preparing the changes.

I have sent you an invite for the salsa repo. Please accept and push 
your changes if you have them as individual changes. :) Otherwise, I can 
do an import of the source package (based on `gbp import-dsc`) as an 
alternative.


I will upload once you pushed the git changes or reported back to me 
that I should use import-dsc. :)




Best regards,
Niels

Bug#1050806: O: debianutils -- Essential utilities specific to Debian

[Niels Thykier]

Control: owner -1
Control: retitle -1 ITA: debianutils -- Essential utilities

On Tue, 29 Aug 2023 13:35:05 +0200 Bastian Germann  wrote:

Package: wnpp

After I have made a dog's breakfast of debianutils' postinst and fixed it,
I do not feel inclined to maintain that essential package any longer.
I cannot afford the response time that it takes when people's chroots break.
So I orphan debianutils.

So please consider adopting if you want to take the chance and have a good
knowledge of the tools contained in debianutils.





Hi,

I am also interested in maintaining the package, retitling it to an ITA 
because there are adopters.


@Ileana: Would you be fine with co-maintaining it with me? We can use 
the existing git repo (https://salsa.debian.org/debian/debianutils) as 
packaging repo and coordinate our changes via that.


Best regards,
Niels

Bug#1050709: tar-ignore debian/source/options

[Niels Thykier]

On Mon, 28 Aug 2023 13:53:22 +0100 Ian Jackson 
 wrote:

Package: dgit
Version: 11.3

debhelper (at least in sid) has a debian/source/options with;

  tar-ignore
  tar-ignore=debhelper/.idea

And it has a .gitignore.  This has the following effects:

 1. It defeats dgit's passing of a -I and -i options to dpkg-source,
so the dgit-generated source package does not contain .gitignore

 2. If one were to somehow manage to make a proper source package
that corresponds to the git tree, it wouldn't round trip
through dpkg-source.

So IMO there is no way to make a DFSG-compliant source package of
Debian's current debhelper package.

I was just assisting another DD contributor with this and other
problems; I was going to try to help sort out a mess by doing what
amounted to a sponsored upload.  However, this turned out to be
impossible.

I have done a non-dgit-based non-DFSG-compliant upload instead.

What should we do about this ?  Options (not mutually exclusive) could
include:

 * File a bug or MR against debhelper
 * Somehow ask that dpkg-source do something about this, but what ?
 * Have dgit detect this situation and at least explain it to the user
 * Have dgit generate a non-roundtrippable source package
   (probably very hard and also undesirable)

Ian.

[...]


Hi,

So this is a common pattern in my packages although it sometimes appears 
in d/s/local-options rather than d/s/options.


Basically, the issue is when you have something you want to have 
locally, not in git and also not in the archive.  In one my other 
packages, I have a "local" directory filled with local work items 
(including a full copy of the sudo deb package for testing purposes). 
Here the "local" directory is listed both in .gitignore and in 
"tar-ignore", because I do not want it in git nor in the archive when I 
do an upload.


To solve this, I add `tar-ignore=...` (for native packages) to 
debian/source/(local-)options.  However, if you add that option, you end 
up with the entire *.git* directory in the tarball.  To avoid that, I 
add the `tar-ignore` on its own to get the sane defaults back.


This then breaks dgit leading to this bug, which is kind of a catch-22 
if you want local specific things (IDE files or local prototype stuff) 
that you guarantee is excluded from git and dpkg-source automatically 
and also support dgit at the same time.


Best regards,
Niels

PS: Not sure if this problem is specific to native packages, which I 
happen to maintain a lot of (relative to other maintainers).


PPS: Another example is debputy/experimental. In there I also included 
some python related artefacts because the early drafts do not have a 
proper clean rule for all the "local only" tooling I use, such as python 
coverage.  The official builds do not use these things, so the clean 
rule should work fine, but I do not want a left over ".coverage" 
appearing in the source package as it is just cruft.

Bug#1042124: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Nilesh Patra:



On 25 August 2023 1:47:26 pm IST, Nilesh Patra  wrote:

On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum  wrote:

Source: eegdev
Version: 0.2-6
Severity: serious

In file included from conffile.lex.c:242:
../../lib/stdio.h:64:3: error: #error "Please include config.h first."
64 |  #error "Please include config.h first."
   |   ^


The lexed file conffile.lex.c seems to include some stuff before
config.h is included which is causing it to choke.

I'm not acquainted with lexers and not sure what causes this. I'd
appreciate any help.


Adding mentors list as well. If someone can help with this, that'd be great.

Best,
Nilesh



Hi,

I do not think the lexer has anything to do with this.

A quick look at the log suggests that the package is "rolling" its own 
"stdio.h" (note the "../../lib/stdio.h" in the error message).  Indeed, 
the full log has "mv stdio.h-t3 stdio.h" as well.


I believe that this is stdio.h is generated by the embedded gnulib copy 
and that is as far as I am willing to debug that rabbit hole. Based on 
the error, I assume gnulib's generated stdio.h requires the project 
specific "config.h" to be loaded first.


As for solving it, I would have a look at the "conffile.lex.c" file, see 
where it has its "#include" for stdio.h and then add an `include 
"config.h"` before that to see if it works (via a patch).


Hope that helps.

Best regards,
Niels

Bug#1042124: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Niels Thykier:

[...]

Hi,

[...]
I believe that this is stdio.h is generated by the embedded gnulib copy 
and that is as far as I am willing to debug that rabbit hole. Based on 
the error, I assume gnulib's generated stdio.h requires the project 
specific "config.h" to be loaded first.

[...]

Best regards,
Niels



Correction; the gnulib was probably not an "embedded copy". The file 
still seems to be generated via gnulib, so the rest of my argument would 
remain the same.

Bug#1049425: RM: libpam-blue -- RoQA; RC-buggy, not in stable, low popcon

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Additionally, it installs a file in /lib, so we either need to fix it to 
finish the /usr-merge transition or remove it.


Given the reasons in $SUBJECT, I am voting for removal.

Best regards,
Niels

Bug#1049406: debian-policy: Does Debian have native vs. non-native *binary* packages?

[Niels Thykier]

Package: debian-policy
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

Hi,

I re-read a bit on the policy definition of native vs. non-native 
packages and it occurred to me that the written word of the policy seems 
to be confusing to read at best.



The concept of a native package is introduced in chapter 4 "Source 
packages" and the following definition is given:


"""
Debian **source** packages are classified as native or non-native.

A native source package is one that does not distinguish between Debian 
packaging releases and upstream releases. A native source package 
contains a single tar file of source material, and the versioning does 
not have a Debian-specific component. Native packages are normally (but 
not exclusively) used for software that has no independent existence 
outside of Debian, such as software written specifically to be a Debian 
package.


[... more stuff about non-native packages ...]
"""

I put emphasis here on "Debian **source** packages", which implies that 
this definition do not apply to binary packages. I had a look in Chapter 
3 "Binary packages" and it does mention "Native Debian packages" but 
does not define the term.
  I assume the term in chapter 3 is a forward reference to chapter 4 
but it never explicitly states this. I feel it would aid the reader if 
it did have a explicit forward reference if that is what it is.
  Based on this assumption, I feel the full term should probably be 
along the lines of "binary packages built from a (non-)native source 
package". However, I admit that phrase is a bit obscene to use compared 
to "N(on-n)ative Debian packages" as it is a full sentence on its own. 
However, the shorter phrase used now may confuse readers into believing 
that "native binary packages" are a thing, which they do not seem to be 
according to chapter 4.



Assuming we agree so far, this has the consequences that:

 * The basename of the installed changelog name ("changelog" vs.
   "changelog.Debian") is decided based on the source package version
   and not the binary package version.
   - This is de facto what debhelper does because it does not know the
 version of the binary at the time debhelper installs the changelog
 (dh_installchangelog is run long before dh_gencontrol).
   - Not sure whether this affects lintian (I do not remember the code).

 * The remark in chapter 3 about date versioning for native packages is
   misplaced and should be in chapter 4 (the one about dashes being
   unsuitable for date separators in a native package). Because, a
   binary package built from a native source *can* have hyphens in its
   version.  Both according to the letter of the policy (the "native"
   trait only applies to the source package) but also in practice[1].

Assuming we do not agree on the above reading and "native binary 
packages" are a thing, then:


 * We have at least one instance of a non-native binary built from a
   native source that contains hyphens[1] with no open bugs of policy
   violations on this matter.

Maybe we should also review this from the angle of "Can a non-native 
source package produce binaries without a hyphen?" (e.g., replace "-" 
with "+") and still be policy complaint.  I would say "no", but tooling 
wise, I am certain it is possible.  Having a rule that all binaries 
built from a source must use the same "native-ness" of the source would 
solve this problem but would define java-common to be non-complaint.


However for the reasons stated above, we probably do not *want* to 
resolve this by mandating a binary is native based on its own version 
regardless of the source version/native-ness. This would lead debhelper 
to be non-compliant and in practice unable to become compliant out of 
the box.


Additionally, I hope we can improve the policy language around native 
vs. non-native and how it relates to binary packages.


Best regards,
Niels

[1]:
$ apt-cache show default-jre | grep -e ^Source: -e ^Version
Source: java-common (0.74)
Version: 2:1.17-74

The java-common source is a native package (version 0.74) but its binary 
default-jre is 2:1.17**-**74 and contains a hyphen.


This practice existed for over a decade now as I remember and no one 
complained. So the use of hyphens in binary versions are definitely not 
causing tooling issues and in my eyes makes this a "common practice" 
question rather than a "breaks stuff" question for whether it is allowed.


Feel free to open the on whether decade of use vs. it is only one 
package. Either way, the Policy is in my eyes not clear enough / aligned 
on this topic on what is allowed and what is not allowed.

Bug#1042567: pygame: Should Debian migrate to pygame-ce

[Niels Thykier]

Package: pygame
Severity: normal
X-Debbugs-Cc: ni...@thykier.net

Hi

It seems like the pygame community got split after an internal 
controversy: 
https://old.reddit.com/r/pygame/comments/1112q10/pygame_community_edition_announcement/


The question now is whether Debian to track the fork or the original or 
both.


A quick look at this upstream projects suggests that pygame-ce (the 
fork) seems to have run with the majority of the active contributors.


Either way, there is a newer version of pygame / pygame-ce, that I would 
like to see in Debian. So please upgrade (either way). :)


Best regards,
Niels

Bug#1042483: debhelper: dh_shlibdeps -l with undocumented absolute forcing

[Niels Thykier]

Package: debhelper
Version: 13.11.4
Severity: minor
X-Debbugs-Cc: ni...@thykier.net, guil...@debian.org

Refile of https://github.com/Debian/debhelper/issues/8 to the Debian 
BTS, where I am more likely to remember it exists.  CC'ing Guillem 
because he did the `dpkg-shlibdeps -l` transition and might shed some 
light on whether the absolute path behaviour (still?) makes sense.



--- 8< --- Original message --- 8< ---


It took me forever to sort out why I was getting "dpkg-shlibdeps: 
warning: cannot find library" for an internal library in my package, 
even as I was using the -l parameter to point to it.


I eventually realized that by calling dpkg-shlibdeps -l directly it 
would work fine. dh_shlibdeps wasn't passing along the -l as specified. 
The workaround was to use -- and then pass -l directly to dpkg-shlibdeps 
unchanged.


Looking into the code, dh_shlibdeps will prepend a slash to make the 
path absolute. I also found that this used to be documented, but it's 
been dropped from the man page.


This came up when I was using pdebuild, so maybe it's something related 
to the chroot? I really don't know the reason for the absolute forcing 
in the first place; it seems to work fine without.


Anyway, I'd at least restore the mention of relative paths being made 
absolute in the man page, or reevaluate the forcing altogether.


--- 8< --- End message --- 8< ---

Last time we touched the -l parameter (AFAICT) was in 
54bfb4207966f78b6412e84b12480e8a5c901cf6 (#717505) where Guillem Jover 
moved the code around and migrated to `dpkg-shlibdeps -l`.  The "force 
path to be absolute" was present back (prior to that commit).


There is no remark about whether the "force absolute path" still made 
sense with the transition to `dpkg-shlibdeps -l`, so I assume it did.


But this as far as I am willing to dig right now.

Best regards,
Niels

Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson

[Niels Thykier]

Jussi Pakkanen:

On Thu, 27 Jul 2023 at 17:45, Simon McVittie  wrote:


As far as I'm aware, we never want to include .pyc in Debian packages,
so I think debhelper's meson build system plugin should be turning this off
as a standard setting for all Debian packages (similar to the way it
sets --prefix=/usr as a standard setting for all Debian packages).

Do the Meson maintainers agree?


Obviously the defaults should do the correct thing. In fact until
yesterday that is what I thought the code does not do byte
compilation. We might even consider changing the default for this as I
would imagine all distros will hit the same issue.



If meson changes the default here upstream, then I would say that is 
preferable to changing debhelper.



Is there a way this can be done, without making packages FTBFS if debhelper
is backported to an older suite but Meson is not? -Dpython.bytecompile=-1
will cause `meson setup` to fail if Meson is an older version, and I'm not
aware of a way to say "set this option if supported, ignore if not" without
parsing `meson --version` and comparing it with a threshold.


Is there ever a case where debhelper would be backported byt Meson is
not? Now an expert but Meson sees a fair number of backports so I'd
imagine it to be the more up to date of the two packages.



If we can rely on meson in stable(-backports) having the feature, a 
simple Breaks in debhelper + unconditional use in the parameter is how I 
would go about it if we need to change debhelper



Further, debhelper updates would be gated on test failures, right? So
if someone did try to update it then there would be immediate errors?
This would be the simplest solution if it is acceptable.


The debhelper package does not have any tests covering the meson build 
system (or most of its other build systems).  In fact, debhelper just 
has a "handful" of tests for a dozen of its 50+ helpers.


It should not be so, but sadly it is.  Unless you mean "the archive 
breaking" as a test suite/failure (but that is hardly "gated"), then 
debhelper is going to disappoint you here.


Best regards,
Niels

Bug#1041642: dh_missing: Doesn't work if used in $(CURDIR)

[Niels Thykier]

Control: tags -1 wontfix

Daniel Leidert:

Package: debhelper
Version: 13.11.4
Severity: normal

I have a native package source from which I build multiple binary packages. The
files are organized as they would be on the target system with their full
destination path. As an example, the souirce directory contains:

./usr/share/applications/foo.desktop

[...]

This might be a cornercase, but I find it quite weird that it isn't working and
I could really use this. Is that a bug or a feature request?

Regards, Daniel

[...]



Hi Daniel

You have indeed hit a corner case and I do not think it makes sense to 
change dh_missing to support it.


You can trivially work around it by moving the "FS layout" into a 
subdirectory (e.g., "mkdir root && mv ... root/") and then use "root" as 
the --sourcedir for the dh_* tools that need --sourcedir.


As for having dh_missing support "$(CURDIR)", then most packages have a 
lost of "cruft" in "$(CURDIR)" that you would have to manually exclude - 
you see it already with your own cmd-line having to ignore debian + 
README.  There is one "exciting" thing here in that excludes are 
"global" - so the -X README.md ignores `README.md` *anywhere* it might 
occur, so you do not get warnings if you get install a `README.md` from 
somewhere (that is not the root). Probably benign in most cases but also 
surprising for most - and changing the -X semantics would be a pain.


For these (and other reasons), dh_missing is built around the concept of 
checking the output of "make install" rather than the source root. I do 
not see a good reason nor a compelling argument for changing that given 
the trivial work around for this one corner case, where might have been 
useful.


Accordingly, I have tagged the bug as wontfix.

Best regards,
Niels

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

[Niels Thykier]

Romain Francoise:

Package: debhelper
Version: 13.11.4
Severity: normal

I'm working on packaging a new upstream project which installs a number
of systemd units directly to /usr/lib/systemd/system and I noticed that
dh_installsystemd doesn't add the required maintscript stanzas to enable
these units.

If I patch the upstream build system to install the units under
/lib/systemd/system (which is the same location on a real system, but
not in the .deb) then everything works as expected.

Thanks.


Hi

This is #1031695, which was closed and archived (marking it hard for 
people to see this is a known item). My remarks from


 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695#124
 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695#147

still applies.

Please see #1031695 for details.  For the reasons provided in the 
#1031695 (see the links), I will now disengage from this bug and not 
interact further with this bug (it is not a "you"-thing, but a "me"-thing).


Best Regards,
Niels

Bug#1041150: devscripts: Demote fakeroot from Depends to Recommends or Suggests

[Niels Thykier]

Package: devscripts
Version: 2.23.5
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net

Hi

I believe that the `Depends` on `fakeroot` is too strong given recent 
development in Debian and I would like to see it demoted to either a 
Recommends or Suggests.


There are three cases, where `fakeroot` is declared as being used:

 * cvs-debuild
 * debclean
 * debuild

Personally, I think `cvs-debuild` is close to obsolete since "almost" no 
packages declare using CVS. According to trends.d.n, it is down to less 
than 10 (source: https://trends.debian.net/vcs_testing.csv) and given 
the low number, I do not see it as an argument for a strong dependency 
(this case is Suggests territory at best in my book).



As for `debclean`, it usage of fakeroot comes via debuild for invoking 
the `clean` target, so will cover it via `debuild`.



As for `debuild`, it historically passed `-rfakeroot` to 
dpkg-buildpackage.  However, `dpkg-buildpackage` auto-detects fakeroot 
itself as needed now and `debuild` have now removed the `-rfakeroot` because
it is no longer needed. Additionally, over 60% of all sources no longer 
requires (fake)root according to trends.d.o (source: 
https://trends.debian.net/rulesreqroot_testing-percent-stacked.png). 
That trend has only gone in one direction over time - less need for 
(fake)root.


Personally, I am a bit torn here. Personally, I want Suggests or lower. 
However, 40% is still a bit high for fakeroot to be an "unusual" 
case/dependency.
  An alternative argument is to say that `debuild` is not the tool 
requiring `fakeroot` (I think it did historically but that changed). It 
is `dpkg-buildpackage` that has the requirement and its package 
(`dpkg-dev`) already has a optional dependency on `fakeroot`. By that 
logic, we would remove the `fakeroot` dependency from devscripts. This 
argument also applies to `cvs-debuild` as far as I can tell.


For the above reasons, I feel it is time that devscripts stopped 
enforcing fakeroot to be present and demoting it at least to Recommends 
or possibly removed it entirely.


Best regards,
Niels

Bug#1039941: debhelper: intermittent dh_missing error

[Niels Thykier]

Control: tags -1 wontfix
Control: retitle -1 debhelper: Parallel d/rules not fully supported

Sven Joachim:

[...]

I think I am beginning to understand where the race condition is.  In
full builds of ncurses it is possible for 'make' to process the
install-arch and binary-indep targets in parallel, which can cause new
files to appear in debian/tmp after "dh_missing -i" has processed the
debian/.debhelper/generated/*/installed-by-* files, but before it
actually reads the contents of debian/tmp.  Those files will then be
falsely reported as not installed.

Probably such a situation is relatively unusual, and I guess dh_missing
has not been designed to handle it.  Will see how best to work around it
in ncurses.

Sven



Hi Sven

Thanks for the report and diagnosing the problem.

Indeed, debhelper was not never built for arbitrary parallelization of 
dh commands or interactions between the commands.  The `dh_missing` tool 
is a lot more susceptible to the problem as it tries to do a "global 
view" analysis



A proper fix in your case is to split the binary-X targets, inject a 
synchronization barrier and run dh_missing on the other side of it. I 
have no clue how to do that reliably in Make while keeping the target 
dependencies correct.



Unfortunately, there is not much I can do to fix this in debhelper as 
debhelper is 80% married to d/rules being a Makefile with arbitrary code 
execution injected "anywhere" and then 20% of features that need this 
not to be the case.

  Indeed, it is a bug/misfeature, but I do not see a way to solve it.

Best regards,
Niels

Bug#1036865: dpkg-dev: Overreaching Rules-Requires-Root namespace check

[Niels Thykier]

Guillem Jover:

Hi!



Hi,


[...]

Ugh, so from code staring and git log, it seems this has not worked since
the code got added. Which should also mean the debhelper namespace which
is documented in the spec does not work either. :/



I pulled out the debhelper keyword, so currently the debhelper namespace 
would be empty.  I do not remember what we wrote in the spec. If it 
lists a concrete debhelper keyword, then I feel that is a bug in the 
example from the spec (as the keyword is not supported).



I've prepared the attached patch which I think should be fixing this,
but will test and add some functional tests to check for this to make
sure and avoid regressions.



LGTM without having tested it.


I might look into whether to target stable releases too given that
it's a small fix (although no one else reported this until now, but
that might only mean people thought this was allowed…).

Thanks,
Guillem


I think no body has had a reason for using a non-dpkg namespaced keyword 
up till now. I retracted the debhelper one because it does not work well 
in practice.  I only discovered this because I wanted to introduce a R³ 
for debputy, where I feel it the usage would work in practice.


For the record, I have added said R³ keyword in debputy for the next 
release with a reference to this bug. I doubt it will create a lot of 
noise in the short term given debputy is "experimental-only" right now. 
It would have to be in a stable-backport before a stable update to dpkg 
would matter.
  And even then, the work around is for debputy to fallback to its 
internal assembly method or have the package degrade to "R³: 
binary-targets".


Best regards,
Niels

Bug#773385: Ping

[Niels Thykier]

Dima Kogan:

This really should work. It's maybe sorta ok for "apt-file list", but it
also affects "apt-file find". Look:

[...]

I.e. I asked it to tell me what package provides a file, and I had to
tell it which architecture to look at.

The whole point of apt-file is to look up the package name from a path,
and if I have to tell IT things like the architecture, it loses a lot of
its utility.

Thanks.



Hi Dima,

From my PoV, what you experience here with find is a complete different 
problem.


By default, apt-file uses the `APT::Architectures` configuration 
variable to determine which architectures to search for[1].  If APT's 
default is not correct here and you do not APT to see arm64, then please 
add the corrected `APT::Architectures` to `/etc/apt/apt-file.conf`.  If 
you feel that `-a` should have a different default, then please file a 
separate bug.
  Also, MRs or patches are welcome to improve the documentation if you 
want to contribute to making apt-file better for the next person! :)


I hope that solves your particular issue.

Thanks,
Niels

[1]: You can use `apt-config dump | grep Architectures` to see the 
default value that apt-file would get.

Bug#1036865: dpkg-dev: Overreaching Rules-Requires-Root namespace check

[Niels Thykier]

Package: dpkg
Version: 1.21.22
Severity: minor
X-Debbugs-Cc: ni...@thykier.net


I was playing around with doing a custom name space for 
Rules-Requires-Root, and then dpkg said it owned the namespace:


```
$ grep Rules-Requires-Root debian/control
Rules-Requires-Root: debputy/deb-assembly
$ dpkg-buildpackage -us -uc -nc -B -Pnoudeb
dpkg-buildpackage: error: Rules-Requires-Root field keyword 
"debputy/deb-assembly" is unknown in dpkg namespace

```

Personally, I was a bit surprised because I did not feel like dpkg has a 
claim on this namespace. It turns out that dpkg currently believes it 
owns *all* namespaces:


```
$ grep Rules-Requires-Root debian/control
Rules-Requires-Root: foo/bar
$ dpkg-buildpackage -us -uc -nc -B -Pnoudeb
dpkg-buildpackage: error: Rules-Requires-Root field keyword "foo/bar" is 
unknown in dpkg namespace

```

Please review the namespace check. Behaviour-wise there is a bug in it 
somewhere.


Best regards,
Niels

Bug#1036448: debhelper: please add helper for autoconf 2.71 autoupdate

[Niels Thykier]

Control: reassign -1 dh-autoreconf

The dh-autoreconf tool is maintained in a separate package; re-assigning.

Best regards,
Niels

Martin-Éric Racine:

Package: debhelper
Version: 13.11.4
Severity: wishlist

Possibly related to dh_autoreconf:

Since autoconf 2.71 has entered the archive, it often complains about outdated 
macros, asking for 'autoupdate' to be run. Example:

dh binary --builddirectory=build/
dh_update_autotools_config -O--builddirectory=build/
dh_autoreconf -O--builddirectory=build/
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:42: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:42: You should run autoupdate.
m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
configure.ac:42: the top level
configure.ac:48: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:48: You should run autoupdate.
./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
aclocal.m4:1899: XORG_COMPILER_BRAND is expanded from...
aclocal.m4:2018: XORG_COMPILER_FLAGS is expanded from...
aclocal.m4:2190: XORG_DEFAULT_OPTIONS is expanded from...
configure.ac:48: the top level
configure.ac:52: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:52: You should run autoupdate.
m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
configure.ac:52: the top level

Running 'autoupdate' indeed makes autoconf stop complaining, but it also 
results in dpkg forcing us to create a patch against autoconf.ac, which is IMHO 
the wrong approach.

Unless I'm mistaken, this is a case similar to updating config.guess and 
config.sub, so there should be a way to tell dh_autoreconf to run 'autoupdate' 
without making dkpg complain.

Martin-Éric

[...]

Bug#1031851: debhelper: makefile/dh_install should set prefix= and other standard variables

[Niels Thykier]

Control: tags -1 moreinfo

Gioele Barabucci:

Package: debhelper
Version: 13.11.4

Currently `dh_install` for makefile-based project sets the `DESTDIR` 
variable only.


[...]

A code search shows that setting `prefix=` and `sysconfdir=` is quite 
common in `d/rules` files:


https://codesearch.debian.net/search?q=%5B%5E-%5Dprefix%3D%2Fusr+path%3Adebian%2Frules=0=1



I find it curious that a number of these matches do not seem to apply to 
`make install` or `dh_auto_install`. Instead they are sometimes also 
used for `make` (e.g., the build phase rather than the install phase).


Just to set the expectations of how much benefit this change can result 
in as far as "reducing the number of cases with explicit prefix=/usr".


My "gut" feeling from scrolling over ~5 pages leaves me with a 40%/50% 
rate of cases where the package might benefit from it to the point where 
prefix=/usr would disappear (if/when people use dh_auto_install rather 
than "make install" - not all the "make install" lines I saw could 
easily be converted).


Given that debhelper sets `DESTDIR`, couldn't it also set `prefix` and 
all other common makefile variables, just like it does for 
autoconf-based projects (see 
)?


Regards,



It could. I think there are two important cases to consider:

 1) How many packages will this change break?

 2) How easy will it be for people to realize this change is what breaks
stuff and how to resolve it. Like can we come with a "one-size fits
all" answer for how to undo this change if it breaks a specific
package?

I think those two questions should be the counter-weight compared to the 
gain when evaluating whether we should apply this change and I would 
like to see the numbers/proposals for these to before saying whether we 
should move forward with this change.


Note: I am assuming this would require a compat bump. So for the 
answers, it is really about how painful will that compat bump be for the 
users of debhelper.


Best regards,
Niels

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Niels Thykier]

Michael Biebl:

Hello Niels, hello Sebastian



Hi Michael,



Am 24.03.23 um 16:28 schrieb Niels Thykier:

Sebastian Ramacher:

[...]

Any progress here? If this issue should be fixed for bookworm, time is
running short.

Cheers


I find that anytime I look at this bug my motivation to work on Debian 
instantly vanishes. In fact, I cannot even motivate myself to read the 
bug log to figure out what the consensus is. Accordingly, I will play 
the constitution 2.1.1 and step out of the way.
My attempt to raise this issue with debhelper and the release-team was 
to gather a consensus with how to deal with the affected packages.
A change to debhelper seemed liked the most straightforward approach to 
me.


I agree with all of this and I think you were both entitled and correct 
in raising the issue. I am still open to this being a bug in debhelper.


It was not meant as an attempt to force Niels into something he 
feels uncomfortable with, which he obviously does.

I apologize to Niels for that and hereby close this bug report.

Michael


Your reaction here does not match what I had expected from my email and 
I suspect my intentions were not perceived by you as I intended them. To 
start with the most important points:


You have done *nothing* to me that requires an apology from you.

You have *not* forced me to do something I am uncomfortable with.

As far as I am concerned, there was and is *no* conflict between
you and I.

We are good if you ask me. I am mostly sad that I made you think
otherwise, but that is on me.


Coming back to what I wanted to communicate: Starting with the context, 
the timing of my email came after two mails asking for an update on this 
bug that had not been answered by anyone. I.e., my email was a response 
to the requests for a update on the bug - both requests were in my view 
reasonable.
  As the named maintainer/uploader of debhelper, there is always an 
implicit assumption that I will be proactive in dealing with bugs, when 
there is no clear owner of the bug. Especially bugs that affect the 
upcoming release during the freeze. Given that I did not see a response 
and I could not easily identify a clear owner of the bug, I felt these 
emails hanged on me via the implicit assumption.


I wanted to make it very clear that I would *not* be able to live up to 
that assumption. If someone wanted this change, they would have to do it 
without involving me at any point. I was hoping that someone would take 
end to end ownership and deliver it without involving me. As opposed to 
a PR/patch that I would have to review - or leaving me to discuss with 
the RT what kind of change was acceptable this stage - or leaving me to 
reopen the discussion with the tech-ctte whether allowing services in 
/usr is acceptable as it would open up for file moves between /lib and 
/usr/lib, which they said they would not want when the original bug was 
filed (#995569).


  I would not have been able to do that and I doubt I will be able to do
  that any time soon.

But if someone wanted to do that. Great! It would have been a burden off 
my shoulder. On the flip-side, if no one else was willing to do the 
work, then I would not have to feel bad about not being able to do it 
either.  Either way would relieve me of the pressure of this bug.


Eventually, dh_installsystemd (et al.) will probably have to support 
/usr/lib. If someone fixes that now, great. If someone fixes later, great.


I do not mind the change. I mind the assumption that I will be doing it 
(in this or in future releases). Feel free to reopen this bug. As long 
as we all agree that for the timing being, *I* will *not* be interacting 
with the bug, do any design or review of the solution, or deal with any 
fallout of implementing the solution.
  Whoever owns up to dealing with all of that gets to deliver this 
feature. They get to do it without having to follow the NMU rules as far 
as I am concerned unless a co-maintainer steps up and takes ownership of 
this bug, because to me that is part of "stepping out of the way" when 
you are not volunteering to do the work.



In summary:

 * I do not feel you did anything wrong or owe me an apology.

 * I mind doing the work; not the change. If you (anyone) want
   this change and you commit to doing it. Please reopen the bug and go
   ahead as long as you do not "depend" on or "need" me for any part of
   it.

I hope my intentions were more clear this time.

Best regards,
Niels

Bug#1034026: podman-docker: missing /usr/share/user-tmpfiles.d/podman-docker.conf

[Niels Thykier]

Scott Edlund:
@nthykier do you think it's worth extending dh_installtmpfiles to 
include support for /usr/share/user-tmpfiles.d ?



[...]


Yes. Though it would have to be after the freeze (debhelper is covered 
by the toolchain freeze).


Feel free to file a wishlist bug for it.

Best regards,
Niels

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Niels Thykier]

Sebastian Ramacher:

[...]

Any progress here? If this issue should be fixed for bookworm, time is
running short.

Cheers


I find that anytime I look at this bug my motivation to work on Debian 
instantly vanishes. In fact, I cannot even motivate myself to read the 
bug log to figure out what the consensus is. Accordingly, I will play 
the constitution 2.1.1 and step out of the way.


If there are any recent debhelper contributors that want to claim this, 
then I will give preference to them and how they want to handle it.


Otherwise, if no debhelper contributor steps up, then I will waive the 
NMU process on this side of the release on the debhelper package to 
anyone, who ones to pick this up. Please keep the following in mind:


 1) Be adviced that you need to look at multiple helpers that interact
with the systemd services.  Notably, dh_installsystemd,
dh_installsystemduser and dh_installinit - all of which assumes
there is one and only one directly for these services.  Good luck

 2) I would that you push the changes to the salsa repo (it is
DD-writable by default, others will have to do a PR) but a nmudiff
CC'ed to this bug on top of the main branch in salsa will do.
- Please use the main branch, there are some translation changes
  since last upload, which should be a non-issue.
- If you are a DD, just push the changes to main and move on. Do not
  expect me to review a PR before you upload.

 3) I expect that you upload and handle any fall out. Fall out here
includes judging consensus, fix FTBFS, RC bugs or deal with
discussions including the tech-ctte or the release team about the
proposed solution, managing the unblock request (etc.).
- Assume I will not be involved in any of these steps.

 3) If you do change any translatable strings, please consider to notify
the translators.  At least pt and de translators recently updated
and I feel it would be a shame if they were not 100%. But not enough
that I expect I will invest in a follow up upload.

My apologies to the release team. Having been on the release team, I 
know this is probably not the message you wanted this close to the 
release. Sadly, it is the "best" I can do.


With that said and done, as far as bug is concerned, I am out!

Best regards,
Niels

Bug#1033409: nmu: dbgsym packages affected by fakeroot bug

[Niels Thykier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debhel...@packages.debian.org, hel...@subdivi.de

Hi,

I propose the following series of NMUs to close #1024261.  The list is 
based on the set of packages that Helmut found with this script with the 
following modifications:


 * binNMU version have been removed
 * architecture has been removed. I assume we will do ANY binNMUs for
   them to avoid M-A:same issues and it is easier to overshoot than
   clean out the packages that are not M-A:same

This would solve the dbgsym problems caused by fakeroot.  For the 
changelog entry, allegedly fakeroot fixed the problem by now and we can 
reference that. Alternatively, debhelper has worked around the fakeroot 
problem as well in 13.11.


This does not solve the non-dbgsym packages but at least we get the ball 
rolling on the part of the problem we have clearly identified and would 
enable us to close #1024261.


Best regards,
Nielsacm-dbgsym_6.0+20200416-1.1
alure-utils-dbgsym_1.2-9
ann-tools-dbgsym_1.1.2+doc-9
aprsdigi-dbgsym_3.10.0-5
argus-client-dbgsym_1:3.0.8.2-6.1
audacious-plugins-dbgsym_4.2-1
ax25mail-utils-dbgsym_0.15-1
colobot-dbgsym_0.2.0-2
connman-dbgsym_1.41-2
connman-vpn-dbgsym_1.41-2
conntrackd-dbgsym_1:1.4.7-1
conserver-server-dbgsym_8.2.7-2
courier-authdaemon-dbgsym_0.71.4-1
courier-authlib-dbgsym_0.71.4-1
courier-authlib-userdb-dbgsym_0.71.4-1
courier-base-dbgsym_1.0.16-3
courier-imap-dbgsym_5.0.13+1.0.16-3
courier-mlm-dbgsym_1.0.16-3
courier-mta-dbgsym_1.0.16-3
courier-pop-dbgsym_1.0.16-3
cutils-dbgsym_1.6-6
dablin-dbgsym_1.14.0-2
dolphin-owncloud-dbgsym_2.11.0.8354+dfsg-1
dvb-tools-dbgsym_1.22.1-5
fastforward-dbgsym_1:0.51-8
fido2-tools-dbgsym_1.12.0-2
freeipmi-ipmidetect-dbgsym_1.6.10-1
freeipmi-tools-dbgsym_1.6.10-1
fuse-dbgsym_2.9.9-6
geomview-dbgsym_1.9.5-4
giggle-dbgsym_0.7-5
globus-gatekeeper-dbgsym_11.4-2
gnome-applets-dbgsym_3.46.0-1
gnome-keyring-dbgsym_42.1-1
gnome-panel-dbgsym_3.46.0-1
gpsshogi-dbgsym_0.7.0-3.1
gspell-1-tests-dbgsym_1.12.0-1
gtklp-dbgsym_1.3.4-3
harp-dbgsym_1.16-1
hashcat-dbgsym_6.2.6+ds1-1
herbstluftwm-dbgsym_0.9.5-3
ibus-kkc-dbgsym_1.5.22-3
ibus-skk-dbgsym_1.4.3-2
ifcico-dbgsym_2.14tx8.10-27
ifgate-dbgsym_2.14tx8.10-27
invada-studio-plugins-ladspa-dbgsym_0.3.1-6
ipe-dbgsym_7.2.26+dfsg1-3
kbd-dbgsym_2.5.1-1
knockd-dbgsym_0.8-2
krb5-admin-server-dbgsym_1.20.1-1
krb5-auth-dialog-dbgsym_43.0-1
krb5-gss-samples-dbgsym_1.20.1-1
krb5-kdc-dbgsym_1.20.1-1
krb5-kdc-ldap-dbgsym_1.20.1-1
krb5-user-dbgsym_1.20.1-1
kup-backup-dbgsym_0.9.1-1
kyotocabinet-utils-dbgsym_1.2.79-2
lcdproc-dbgsym_0.5.9-6
lcdproc-extra-drivers-dbgsym_0.5.9-6
libbabl-0.1-0-dbgsym_1:0.1.98-1
libcoarrays-mpich-dev-dbgsym_2.10.1-1
libcoarrays-openmpi-dev-dbgsym_2.10.1-1
libdb1-compat-dbgsym_2.1.3-22
libdrm-tests-dbgsym_2.4.114-1
libfuse2-dbgsym_2.9.9-6
libiec61883-dev-dbgsym_1.2.0-6
libipe7.2.26-dbgsym_7.2.26+dfsg1-3
libkim-api2-dbgsym_2.3.0-1
libkim-api-dev-dbgsym_2.3.0-1
libleatherman1.12.1-dbgsym_1.12.1+dfsg-1.2
libopenmesh1-dbgsym_9.0-4
libopenmesh-apps-dbgsym_9.0-4
libopenmpi3-dbgsym_4.1.4-3
libopenms2.6.0-dbgsym_2.6.0+cleaned1-3
libowncloudsync0-dbgsym_2.11.0.8354+dfsg-1
libpdl-linearalgebra-perl-dbgsym_0.35-1
libplib1-dbgsym_1.8.5-14
libpmix2-dbgsym_4.2.2-1
libpmix-bin-dbgsym_4.2.2-1
libruli-bin-dbgsym_0.36-3
libsuperlu-dist8-dbgsym_8.1.2+dfsg1-1
libsuperlu-dist-dev-dbgsym_8.1.2+dfsg1-1
libtheora0-dbgsym_1.1.1+dfsg.1-16.1
libtheora-bin-dbgsym_1.1.1+dfsg.1-16.1
libv4l-0-dbgsym_1.22.1-5
libv4lconvert0-dbgsym_1.22.1-5
libxtrxll0-dbgsym_0.0.1+git20201202.1b6eddf-1
linuxptp-dbgsym_3.1.1-4
lldpd-dbgsym_1.0.16-1
login-dbgsym_1:4.13+dfsg1-1
lua-readline-dbgsym_3.2-1
lua-socket-dbgsym_3.1.0-1
miredo-dbgsym_1.2.6-7.1
mutt-dbgsym_2.2.9-1
myproxy-admin-dbgsym_6.2.14-2
myproxy-dbgsym_6.2.14-2
ndisc6-dbgsym_1.0.5-1
nethack-common-dbgsym_3.6.6-3
ntfs-3g-dbgsym_1:2022.10.3-1
ntfs-3g-dev-dbgsym_1:2022.10.3-1
oddjob-dbgsym_0.34.7-1
oddjob-mkhomedir-dbgsym_0.34.7-1
odr-dabmux-dbgsym_4.2.1-1
openmpi-bin-dbgsym_4.1.4-3
opensmtpd-dbgsym_6.8.0p2-4
orthanc-postgresql-dbgsym_4.0-7
osdsh-dbgsym_0.7.0-11
osmo-bsc-bs11-utils-dbgsym_1.9.0-3
osmo-bsc-ipaccess-utils-dbgsym_1.9.0-3
osmo-bsc-meas-utils-dbgsym_1.9.0-3
osmo-bts-dbgsym_1.5.0+dfsg1-2
osmo-ggsn-dbgsym_1.9.0-3
osmo-hlr-dbgsym_1.5.0+dfsg1-3
passwd-dbgsym_1:4.13+dfsg1-1
pdl-dbgsym_1:2.081-1
perl-tk-dbgsym_1:804.036-1
ploop-dbgsym_1.15-12
pmacct-dbgsym_1.7.7-1
postgresql-15-ogr-fdw-dbgsym_1.1.3-1
qflow-dbgsym_1.3.17+dfsg.1-3
r-cran-zip-dbgsym_2.2.2-1
roger-router-dbgsym_2.4.2-3
rxvt-unicode-dbgsym_9.30-2
scalapack-mpi-test-dbgsym_2.2.1-2
schroot-dbgsym_1.6.13-3
scitokens-cpp-dbgsym_0.7.3-1
shapelib-dbgsym_1.5.0-3
shotwell-dbgsym_0.30.17-1
sndio-tools-dbgsym_1.9.0-0.3
source-highlight-dbgsym_3.1.9-4.2
spice-vdagent-dbgsym_0.22.1-3
squid-dbgsym_5.7-1
squid-openssl-dbgsym_5.7-1
sqwebmail-dbgsym_6.0.5+1.0.16-3
sslh-dbgsym_1.20-1
sysrepo-dbgsym_2.0.53-6
topp-dbgsym_2.6.0+cleaned1-3
torcs-dbgsym_1.3.7+dfsg-5

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Niels Thykier]

Control: forcemerge 1031695 995569

Michael Biebl:

Package: debhelper
Version: 13.11.4
Severity: important
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

It appears we currently ship 35 packages in unstable installing 78
service files to /usr/lib/systemd/system which dh_installsystemd doesn't
handle:

[...]

The alternative is to update all those 35 packages and make sure they
install the files to /lib.


Michael


Sorry for being terse, I should be working on something else right now 
but prioritized a short message over nothing.


Duplicate of #995569. My concerns from back then still applies and I 
will not implement this feature until they are resolved. For the record, 
I do not feel the tech-ctte's resolution back then answered my question.


Additionally, we are in the bookworm freeze where toolchains are frozen 
and have been for a month now. I am also not going to implement this 
change for bookwork unless there is an agreement from the release team 
in place that this is the direction we want to go (I do not have time to 
look at that discussion right now either).


Thanks,
~Niels

Bug#1029645: ITP: debputy -- Manifest style debian package builder

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 
X-Debbugs-Cc: debian-de...@lists.debian.org, ni...@thykier.net

* Package name: debputy
  Version : 0.1.1
  Upstream Contact: Niels Thykier 
* URL : https://salsa.debian.org/debian/debputy/
* License : GPL-2+
  Programming Lang: Python
  Description : Manifest style debian package builder


Binary package being dh-debputy:
  Package builder that provides a declarative manifest for building
  debian packages.

  This version integrates with the debhelper sequencer dh and will
  replace several of debhelper's tools that are covered by debputy.

  The debputy package builder aims to reduce cognitive load for the
  packager and provide better introspection to better support to
  packagers, linters and the Debian janitor.


The early versions will integrate into the debhelper sequencer dh and 
will replace several of debhelper's tools that are covered by debputy. 
However, the goal is that debputy will be a standalone tool capable of 
packaging work from start to end.


In the early phase, I plan to keep debputy in experimental to allow for 
more aggressive prototyping.


Rationale:
==
My work on debputy is aimed at exploring an alternative packaging format 
that focuses on a single manifest (think Kubernetes helm charts or 
docker compose files).  A key goal is introspection and, for errors, a 
clear link to the part of the configuration that was involved or 
triggered the error.



Maintenance:

I am looking for people, who are interested in exploring this area with 
me and are:


  1) Interested in trying the prototype, or/and
  2) Interested in helping me design the manifest format, or/and
  3) Interested in helping me develop the tool, or/and
  4) Interested in integrating with the tool.
 - Whether third-party plug-in (a la dh add-ons) or linters/fixers

As some concrete suggestions for what a contributor might be helping me 
with. The list is not exhaustive and you are welcome to help regardless 
of whether your interest is mentioned above. :)


Trying out debputy:
===

There is a getting started guide at 
https://salsa.debian.org/debian/debputy/-/blob/main/GETTING-STARTED-WITH-dh-debputy.md.


If you do not use any overrides/hook targets, it is question of running:

 # (Remove --no-act to actually perform the change)
 $ debputy migrate-from-dh --no-act

And then add `dh-sequence-zz-debputy` to Build-Depends (the `zz-` is a 
hack for ordering debputy after other addons).


Key features:
-

Some high lighted features in debputy that are currently not available 
in other Debian packaging tools that might be interesting for you :)


 1) debputy supports setting static ownerships inside the debs without
relying on fakeroot.  This means that packages never need fakeroot
for the Debian packaging side (i.e., you should always be able to
use `Rules-Requires-Root: no` as long as the upstream build system
behaves).

This feature is mentioned in the GETTING-STARTED-WITH-dh-debputy.md
document, so you can see how to use it / try it out.

 2) If a binary package does not have a Multi-Arch field, debputy will
automatically deduce if it is safe to set "Multi-Arch" to "same".
The mechanics are based on rules by Helmut Grohne, who proposed this
feature on IRC.  In the rare cases, that debputy is wrong here,
you can explicitly set "Multi-Arch: no"

On the flip side, there are tons of features *not* supported by debputy 
at the moment.


Thanks,
~Niels

Bug#1028963: Surprise restriction of the qx_cmd() function in Dh_Lib.pm

[Niels Thykier]

Control: tags -1 wontfix
Control: retitle -1 Dh_Lib: qx_cmd does not support shell features

Gunnar Hjalmarsson:

Package: debhelper
Version: 13.11.1

Hello!

The fix of https://bugs.debian.org/1016354 resulted in a regression so 
Ubuntu's debhelper extension dh-translations stopped working.


This is the commit:

https://salsa.debian.org/debian/debhelper/-/commit/62a8608e

The qx_cmd() function has been used conveniently in dh_translations to 
grab the output from a few commands which make use of pipes. Now that 
doesn't work any longer. It was resolved for now by copying the qx_cmd() 
function as it looked like before commit 62a8608e into dh_translations. 
Please see the attached diff.


This raises the question if there is a need also for a 'cleaner' qx_cmd 
function. Maybe "complex_qx_cmd" (compare complex_doit).




The `qx_cmd` is specifically there for avoiding a shell.  It is 
unfortunate that it had an unintentional special case where 
`dh_translations` could "abuse" it and get a shell behaviour.


If you want a shell, you can just use perl's qx operator (`perldoc -f 
qx`), which is a "built-in", well documented and does not require any 
backwards compat tricks from dh-translations or debhelper.


Thanks,
~Niels

Bug#1028190: tzdata: Possible bug in postinst

[Niels Thykier]

Package: tzdata
Version: 2022g-1
Severity: normal
X-Debbugs-Cc: ni...@thykier.net

In the postinst, there is the following snippet:

> #! /bin/sh
> set -e
> [...]

# Update the time zone
echo $AREA/$ZONE > "$DPKG_ROOT/etc/timezone"
ln -nsf /usr/share/zoneinfo/$AREA/$ZONE "$DPKG_ROOT/etc/localtime.dpkg-new" 
&& \
mv -f "$DPKG_ROOT/etc/localtime.dpkg-new" "$DPKG_ROOT/etc/localtime"
which restorecon >/dev/null 2>&1 && restorecon 
"$DPKG_ROOT/etc/localtime"



I think there is a bug in the `which restorecon ...` construct that can 
cause termination of the postinst rather than conditional call to 
`restorecon`.


As far as I can tell, the construct will "fail" when restorecon is present:

```
which foo >/dev/null 2>&1 && foo ; echo $?
1
```


With `set -e`, this would trigger the postinst to fail and abort the 
installation.


I think this case calls for a `if ...; then .. fi` construct or a `! 
which ... && ...`.


I feel this ought to be an RC bug. However, given I found this with 
(manual) static analysis and no one else complained, I guess this case 
is basically never triggered.  That is why I have reported as non-RC.


Thanks,
~Niels

Bug#1028128: debconf: Please support /var/cache/debconf/tmp.ci being a tmpfs

[Niels Thykier]

Colin Watson:

[...]

What do you think about this patch?  [...]

>

diff --git a/dpkg-preconfigure b/dpkg-preconfigure
index e0db5b19..c1f24441 100755
--- a/dpkg-preconfigure
+++ b/dpkg-preconfigure
@@ -141,7 +141,7 @@ if (! $have_tty && $frontend->need_tty) {
  }
  
  my $tempdir='/var/cache/debconf/tmp.ci';

-remove_tree($tempdir, { safe => 1 });
+remove_tree($tempdir, { safe => 1, keep_root => 1 });
  make_path($tempdir);
  
  # Use the external package scanner for speed. It takes a list of debs

@@ -248,7 +248,7 @@ $frontend->shutdown;
  # Save state.
  Debconf::Db->save;
  
-remove_tree($tempdir, { safe => 1 });

+remove_tree($tempdir, { safe => 1, keep_root => 1 });
  
  =head1 AUTHOR
  


Looks good to me. :)

Thanks for considering
~Niels

Bug#1028128: debconf: Please support /var/cache/debconf/tmp.ci being a tmpfs

[Niels Thykier]

Package: debconf
Version: 1.5.81
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net


Hi,

Thanks for change to make dpkg-preconfigure no longer assume /tmp is 
mounted with `exec` (or without `noexec`).


When trying it out, I decided to make `/var/cache/debconf/tmp.ci` a 
tmpfs (with `exec` mounted) as a means to avoid unnecessary writes to 
the disk.  This results in the following warnings from dpkg-preconfigure:


```
[... apt output here ...]
Need to get 0 B/357 kB of archives.
After this operation, 11,3 kB disk space will be freed.
Do you want to continue? [Y/n]
cannot remove directory for /var/cache/debconf/tmp.ci: Device or 
resource busy at /usr/sbin/dpkg-preconfigure line 73.
cannot remove directory for /var/cache/debconf/tmp.ci: Device or 
resource busy at /usr/sbin/dpkg-preconfigure line 159.

(Reading database ... 126341 files and directories currently installed.)
[... dpkg log from here ...]
```

It does not seem to cause errors or problems, but I would prefer not 
having "warnings". Therefore, I was hoping dpkg-preconfigure would 
adopt/support this particular configuration as a supported 
(warning-free) method.


(Note, I appreciate it is close to the freeze and I do not mind waiting 
until after the release with the fix.  In particular if it avoids you 
having to "rush" things in your end)


Thanks,
~Niels

Bug#1026230: debhelper: Unable to successfully build in read-only source directory.

[Niels Thykier]

Garrett Kajmowicz:

[...]

The C1) case is something that could be useful for Debian itself.  There are
some tools that want to choose the location of the produced artefacts.  It has
been a low priority wish for me to have this solved "eventually".


I'm using multiple work-arounds for the project I am working on. The C1 work
by itself would still let me tidy some things up and so would be appreciated.



Good to know. I also suspect C1 is easier for us to implement in a short 
time frame.



For the C2) case, it is not that I cannot see possibilities in it. I am more
whether it outweighs the cost of doing it.

   => If we are going for C2, I would expect that you provide CI test
  cases to ensure the feature does not regress (at least for debhelper
  for the gitlab CI pipeline).  Otherwise, it is going to be a game of
  "whack-a-mole".


I have little experience with either gitlab or perl. Still, if you provide me a
few pointers I can certainly throw a few hours into developing some CI
tests for this.
  


It does not have to be perl.  A shell script that can setup a test 
package that is built with dh is sufficient inside gitlab CI is fine.


In case you have experience with GitHub CI, then it is a different 
syntax but otherwise the same concept.  As an example, the current 
debhelper CI snippet for testing changes is:


"""
tests-unstable:
  stage: test
  image: debian:unstable
  script:
- apt-get update
- apt-get build-dep -y .
- dpkg-buildpackage -us -uc -tc
"""

In theory, you would insert snippets in the "script:" part to setup the 
source package that debhelper is supposed to build (with the features 
you want to test), create the output directory, mark the source 
read-only somehow and then cd into followed by dpkg-buildpackage.


This would suffice as a single black box test. Probably we would need a 
battery of them, so you would wrap it in a script to try different test 
cases but that can be done in shell or whatever you are comfortable.



   => For C2, You may also have to do patches and tests for dh-autoreconf
  and dh-strip-nondeterminism as they are part of the default dh
  pipeline (and not maintained by me nor Guillem).


I can certainly take a stab at it. The required changes for both of these
appear to be straight-forward:  use the new parameter passed from
above (however architected) as-needed for the paths being processed.

Side note: patching ltmain.sh in-place strikes me as ... worrisome.



Actually, come to think of it, The dh-autoreconf tool's purpose is to 
*replace* (regenerate) the "configure" script from latest sources.  So 
this pretty much implies that the source directory have to be writeable 
if dh-autoreconf is to do anything.


So as long as it properly no-ops for non-autoconf packages, I think we 
should be fine here.



One possible solution to this is to have:

   1) dpkg-buildpackage gets two new parameters.  One for the artifact
  output directory and one for the writeable scratch directory.

   2) dpkg-buildpackage would export these directories as environment
  variables for the build process (debian/rules + debhelper).

   3) debhelper (and anything in debian/rules) would pick up these
  environment variables to write to the correct places.

   4) dpkg-buildpackage would pass relevant options to dpkg-genbuildinfo
  and dpkg-genchanges (etc.), so they are aware as well.


Should debuild itself be modified to support passing in these build
Parameters as well?
  


In theory, yes.  But really, all "*-buildpackage"-like wrapper tools 
should do that.


Though for starters, lets get support in dpkg-buildpackage first and 
then worry about patching the other tools.



@Guillem: What is your views on this?



Many of the required capabilities are already supported. For example,
the --builddirectory flag allows the building step to be placed in a
different directory.


While there are many options that package can use to tweak locations, they
are not aimed at the thing you are doing.  Notably the dh_* -P option is really
painful to use at scale (if you have multiple binary packages in the same
source package).


Huh. I assumed that these would be automatically use 
builddirectory/debian/
directory unless manually overridden.



No, the "builddirectory" is only for the "upstream" build system.


[...]


Okay. I'll await his response as well.


Hope that was useful.


It's fantastic.

Thank you!

- Garrett


Glad you are excited, though keep in mind that there are no guarantees 
at this point.  If (for whatever reason), dpkg cannot/will not support 
this change, then there is not a lot I can do in debhelper to solve 
this. (And also, we are volunteers, so we generally do not offer 
guarantees either even if we can/want to support a feature)


Thanks,
~Niels

Bug#1026459: RM: kvmtool -- RoQA; Orphaned, RC buggy, not in stable nor in testing

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

Please remove this package.  It has been orphaned for a year, has RC 
bugs preventing from being part of testing and did not make it into the 
current stable.


Thanks,
~Niels

Bug#1026458: RM: kytea -- RoQA; Orphaned, RC buggy, not in stable nor in testing

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

Please remove this package.  It has been orphaned for years, has RC bugs 
preventing from being part of testing and did not make it into the 
current stable.


Thanks,
~Niels

Bug#1026457: RM: debget -- RoQA; Orphaned, RC buggy, not in stable nor in testing

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

Please remove this package.  It has been orphaned for years, has RC bugs 
preventing from being part of testing and did not make it into the 
current stable.


Thanks,
~Niels

Bug#1026456: RM: z-push -- RoQA; Orphaned, RC buggy, not in stable nor in testing

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

Please remove this package.  It has been orphaned for years, has RC bugs 
preventing from being part of testing and did not make it into the 
current stable.


Thanks,
~Niels

Bug#1026454: RM: kopano-webapp -- RoQA; Orphaned, RC buggy, not in stable nor in testing

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

Please remove this package.  It has been orphaned for years, has RC bugs 
preventing from being part of testing and did not make it into the 
current stable.


Thanks,
~Niels

Bug#1026453: RM: eeshow/experimental -- RoQA; Orphaned, only in experimental and not updated for 4 years

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

This package is orphaned and has not been updated for 4 years.  As it is 
only in experimental, it should probably just be removed.


Thanks,
~Niels

Bug#1026452: RM: django-test-without-migrations -- RoQA; Orphaned, RC buggy, not in stable nor in testing

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ni...@thykier.net

Hi,

Please remove this package. It has been orphaned for 5 years, has RC 
bugs preventing from being part of testing and did not make it into the 
current stable.


Thanks,
~Niels