Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Giorgos Skafidas]

Package: dhcpcd5
Version: 7.1.0-2+b1
Severity: wishlist

Dear Maintainer,

please consider updating dhcpcd to its latest upstream version.

Also, perhaps the "5" in the package's name could be dropped.

Thank you for your efforts!

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/1 CPU thread)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dhcpcd5 depends on:
ii libc6 2.30-8
ii lsb-base 11.1.0

Versions of packages dhcpcd5 recommends:
pn openresolv | resolvconf <none>

Versions of packages dhcpcd5 suggests:
pn dhcpcd-gtk <none>

-- no debconf information

[Michael Biebl]

Control: block 810151 by -1

On Mon, 13 Jul 2020 10:15:11 +0300 Giorgos Skafidas
<gio...@skafidas.online> wrote:
> Package: dhcpcd5
> Version: 7.1.0-2+b1
> Severity: wishlist
>
> Dear Maintainer,
>
> please consider updating dhcpcd to its latest upstream version.
>
> Also, perhaps the "5" in the package's name could be dropped.
>
> Thank you for your efforts!

Related to that, in #810151 I was asked to add support for dhcpcd to
NetworkManager.
The NetworkManager dhcpcd plugin requires a minimum version of 9.3.3

From the NEWS file:

=============================================
NetworkManager-1.30
Overview of changes since NetworkManager-1.28
=============================================

...
* The dhcpcd plugin now requires a minimum version of dhcpcd-9.3.3 with
the --noconfigure option. Using an older version will cause dhcpcd to
exit with a status code of 1.


I was considering enabling dhcpcd support in NetworkManager since ISC
DHCP client seems to be on life support:
https://www.isc.org/blogs/dhcp-client-relay-eom/


But that would require dhcpcd to be properly maintained in Debian and I
don't see that happening atm.

Regards,
Michael

[Martin-Éric Racine]

Package: dhcpcd5
Followup-For: Bug #964947
X-Debbugs-Cc: sc...@sl.id.au,r...@marples.name,santi...@riseup.net,mp...@debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I have an NMU waiting on Mentors.

<https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>

All patches from the previous upload have been dropped since they were cherry-picked from upstream Git.

A patch against manual pages was created and forwarded upstream. It's already been acknowledged and merged in Git.

Configure's upstream default paths make Lintian bark, so I've kept the overrides in debian/rules for now. It might be worth working with upstream on making the defaults do what FHS and current packaging practices want.

It's also worth noting that the maintainer and upstream both have unpublished VCS commits on Salsa (most recent: Fri May 15 22:11:32 2020).

Best Regards,
Martin-Éric

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIXRAwACgkQrh+Cd8S0
17ZfWA//S70dCme79AVQCSN4piDEFSU2qT+6ZjBh2B49PhQJ6yx4xvDL5DBat3bh
mKI9j9SV+YfcQ8gvXxyN3uowoP9JAfKWpF3DTKO613uwLm2ytN39vWma9K0JmMu3
hTys0fDaVPx/M7rswRP8vP2OJAMHOij/zqbSH+vTw2LtYyS93r5RCxTmre6cVrZ5
wKfZboZKSnTgsb0CF6HrPez8PA2ZHMH2rLbuGGdbi1VwEFayQdXV4Ssope4NxzIG
Pqcu6EAElYzvkZ02vbZkKbHe8Bh85XhD/RWjRz4sX2mdQRxVdqViOiqzZtsj2Ttl
Mh4o//jY/esVkzslz4b7efVFNIMlSONHXOGabMaVyQ14WoOP+GVy5Gc7dmsz8FLR
dK1TAOLJDBjkeeM/hCRvNsI+q/Cp5WLrY7udolKHE1dnufdne9qnx/I55ZCLcS8q
IPb5INka1V9QUf8QETsScWHE/SVOIoo30S18u1x7nuq86eV+c26heP52sxmSUsHt
uUjlUybsGla6j574B7gTqBbipL8uF6p2E6o/yQJYdDQ5zpEHMv5TugNUBq9pefVN
2YvOUh+fzUL/hcLvQ/MdvjB+XxhrAONSRB127Cx4kU5xuCP1c5G9aZS83k0cXe1z
elr8cUFMJNHCD5TUQmZorgSg5azmsD7oFqEbQIsTBq0YdagoLT4=
=sVj9
-----END PGP SIGNATURE-----

[Michael Biebl]

Am 24.02.22 um 09:45 schrieb Martin-Éric Racine:
> And, sure enough, I forgot to tag Michael on my previous message.

You don't really have to tag me, tbh.

Fwiw, NetworkManager nowadays defaults to its internal dhcp client
implementation (based on sd-network), isc dhclient is only a fallback
(unless configured explicitly).
So dhcpcd5 being available in a newer version would be nice but is not a
pressing issue for NetworkManager itself.

See also man NetworkManager.conf

> dhcp
> This key sets up what DHCP client NetworkManager will use. Allowed values are dhclient, dhcpcd, and internal. The
> dhclient and dhcpcd options require the indicated clients to be installed. The internal option uses a built-in DHCP
> client which is not currently as featureful as the external clients.
>
> If this key is missing, it defaults to internal. If the chosen plugin is not available, clients are looked for in this
> order: dhclient, dhcpcd, internal.

Fwiw, this is the reason why isc-dhcp-client was first demoted to
Suggests in network-manager and has been dropped completely in 1.32.12-1.

Regards,
Michael

[Michael Biebl]

Am 24.02.22 um 10:25 schrieb Martin-Éric Racine:

> dhclient already only is a backup, and so would dhcpd be. Noted.
>
> Well, anyhow. The NMU is pending upload. It's up to NM maintainers
> whether they'll want to enable the dhcpcd backend or not, once the
> upload has been done.

If dhcpcd is properly maintained I do intend to enable support for it in NM.

It's just that my interest in dhcpcd5 is limited. E.g. I don't plan to
review or sponsor the upload (too much other stuff already).

In any case, thanks for your efforts, even if it should be one-time only.

Regards,
Michael

[Santiago R.R.]

On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R." <santi...@riseup.net> wrote:

>
>
>On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine" <martin-er...@iki.fi> wrote:
>>Package: dhcpcd5
>>Followup-For: Bug #964947
>>X-Debbugs-Cc: sc...@sl.id.au,r...@marples.name,santi...@riseup.net,mp...@debian.org
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA512
>>
>>I have an NMU waiting on Mentors.
>>
>><https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>
>>

Thanks for your work! I do not have too much free cycles, but I will do my best to review and upload it soon.

After that, I will take a look at its integration with ifupdown.

>>All patches from the previous upload have been dropped since they were cherry-picked from upstream Git.
>>
>>A patch against manual pages was created and forwarded upstream. It's already been acknowledged and merged in Git.
>>
>>Configure's upstream default paths make Lintian bark, so I've kept the overrides in debian/rules for now. It might be worth working with upstream on making the defaults do what FHS and current packaging practices want.
>>
>>It's also worth noting that the maintainer and upstream both have unpublished VCS commits on Salsa (most recent: Fri May 15 22:11:32 2020).
>>

Thank you for paying attention to that. Is there anything you can cherry-pick from them? (Haven't taken a look at your NMU yet, so maybe it is a silly question)

Cheers,

-- S

>>Best Regards,
>>Martin-Éric
>>
>>-----BEGIN PGP SIGNATURE-----
>>
>>iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIXRAwACgkQrh+Cd8S0
>>17ZfWA//S70dCme79AVQCSN4piDEFSU2qT+6ZjBh2B49PhQJ6yx4xvDL5DBat3bh
>>mKI9j9SV+YfcQ8gvXxyN3uowoP9JAfKWpF3DTKO613uwLm2ytN39vWma9K0JmMu3
>>hTys0fDaVPx/M7rswRP8vP2OJAMHOij/zqbSH+vTw2LtYyS93r5RCxTmre6cVrZ5
>>wKfZboZKSnTgsb0CF6HrPez8PA2ZHMH2rLbuGGdbi1VwEFayQdXV4Ssope4NxzIG
>>Pqcu6EAElYzvkZ02vbZkKbHe8Bh85XhD/RWjRz4sX2mdQRxVdqViOiqzZtsj2Ttl
>>Mh4o//jY/esVkzslz4b7efVFNIMlSONHXOGabMaVyQ14WoOP+GVy5Gc7dmsz8FLR
>>dK1TAOLJDBjkeeM/hCRvNsI+q/Cp5WLrY7udolKHE1dnufdne9qnx/I55ZCLcS8q
>>IPb5INka1V9QUf8QETsScWHE/SVOIoo30S18u1x7nuq86eV+c26heP52sxmSUsHt
>>uUjlUybsGla6j574B7gTqBbipL8uF6p2E6o/yQJYdDQ5zpEHMv5TugNUBq9pefVN
>>2YvOUh+fzUL/hcLvQ/MdvjB+XxhrAONSRB127Cx4kU5xuCP1c5G9aZS83k0cXe1z
>>elr8cUFMJNHCD5TUQmZorgSg5azmsD7oFqEbQIsTBq0YdagoLT4=
>>=sVj9
>>-----END PGP SIGNATURE-----

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

[Roy Marples]

On 24/02/2022 21:31, Santiago R.R. wrote:
>
>
> On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
<santi...@riseup.net> wrote:
>>
>>
>> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
<martin-er...@iki.fi> wrote:
>>> Package: dhcpcd5
>>> Followup-For: Bug #964947
>>> X-Debbugs-Cc:
sc...@sl.id.au,r...@marples.name,santi...@riseup.net,mp...@debian.org
>>>

> I have an NMU waiting on Mentors.
>
> <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>
>
>
>> Thanks for your work! I do not have too much free cycles, but I will do my best to review and upload it soon.
>
>> After that, I will take a look at its integration with ifupdown.

I will argue that integeration with ifupdown would not be a good thing, or at
least not the sole integration.

Since dhcpcd-5 it's been designed to run standalone monitoring interfaces as
they arrive and depart and reacting accordingly.
This operation is important on a multihomed system where wireless and wired for
example could be assigned the same IP address.

With dhcpcd-9 it has privilege separation and seccomp support making it the most
secure DHCP client available. As this spawns a few processes, it's much better
NOT to run per interface just to cut down on the number of processes required.
Turning this feature off (which I believe the Debian package does, not checked)
would be a bad thing.

> Configure's upstream default paths make Lintian bark, so I've kept the overrides in debian/rules for now. It might be worth working with upstream on making the defaults do what FHS and current packaging practices want.

The default upstream paths mirror that of a BSD system. I belive that is in
conflict with FHS.

> It's also worth noting that the maintainer and upstream both have unpublished VCS commits on Salsa (most recent: Fri May 15 22:11:32 2020).

My commits on Salsa are just me packaging dhcpcd.
Looking, someone else decided to redo the NTP hooks entirely for Debian.
My understanding is that the only thing the upstream hook doesn't do is timesyncd.

Roy

[Martin-Éric Racine]

On Fri, Feb 25, 2022 at 10:31 AM Roy Marples <r...@marples.name> wrote:
>
> On 24/02/2022 21:31, Santiago R.R. wrote:
> >
> >
> > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> <santi...@riseup.net> wrote:
> >>
> >>
> >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> <martin-er...@iki.fi> wrote:
> >>> Package: dhcpcd5
> >>> Followup-For: Bug #964947
> >>> X-Debbugs-Cc:
> sc...@sl.id.au,r...@marples.name,santi...@riseup.net,mp...@debian.org
> >>>
> > I have an NMU waiting on Mentors.
> >
> > <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>
> >
> >> Thanks for your work! I do not have too much free cycles, but I will do my best to review and upload it soon.
> >
> >> After that, I will take a look at its integration with ifupdown.
>
> I will argue that integeration with ifupdown would not be a good thing, or at
> least not the sole integration.
>
> Since dhcpcd-5 it's been designed to run standalone monitoring interfaces as
> they arrive and depart and reacting accordingly.
> This operation is important on a multihomed system where wireless and wired for
> example could be assigned the same IP address.

The key idea with ifupdown is to be able to pass options to a variety
of network configuration tools via a centralized
/etc/network/interfaces configuration. Nothing more.

Right now, my personal experiements with dhcpcd indicate that
something as simple as passing options to wpa_supplicant via dhcpcd's
configuration file is not an easy task. Ditto for enabling prefix
delegation to a second interface. Via ifupdown's
/etc/network/interfaces these follow a normalized syntax that is
completely independant of which tools perform the actual network
configuration under the hood.

> > Configure's upstream default paths make Lintian bark, so I've kept the overrides in debian/rules for now. It might be worth working with upstream on making the defaults do what FHS and current packaging practices want.
>
> The default upstream paths mirror that of a BSD system. I belive that is in
> conflict with FHS.

There's more. For instance, manual pages canonically go to
/usr/share/man/manX (or /usr/local/share/man/manX for locally-built
packages). dhcpcd's Configure defaults put these in /share/man/manX if
no prefix is passed to configure. Also hooks are currectly put in
${prefix}/libexec (which is the correct FHS location), but since they
are not executable and lack the Bourne shell shebang, Lintian barks.

> > It's also worth noting that the maintainer and upstream both have unpublished VCS commits on Salsa (most recent: Fri May 15 22:11:32 2020).
>
> My commits on Salsa are just me packaging dhcpcd.
> Looking, someone else decided to redo the NTP hooks entirely for Debian.
> My understanding is that the only thing the upstream hook doesn't do is timesyncd.

I wouldn't be surprised to find that Debian's own hooks are outdated
by now, except perhaps for timesyncd.

Martin-Éric

[Roy Marples]

On 25/02/2022 09:25, Martin-Éric Racine wrote:
> Right now, my personal experiements with dhcpcd indicate that
> something as simple as passing options to wpa_supplicant via dhcpcd's
> configuration file is not an easy task.

Why would you want to? They have separate domains of responsibility. One
configures the addressing and routes and other misc related stuff and the other
brings up the actual link to do this on.

dhcpcd's wpa_supplicant hook was written to solely support hotplugging a USB
wireless stick into a machine without any kind of hotplug support.
Since then I have added then -M flag to wpa_supplicant so it can do it by itself.

Now if you want to configure wpa_supplicant via dhcpcd for a specific wireless
network then the dhcpcd-ui project exists for that and relies on the
wpa_supplicant config being writable via the wpa_supplicant control socket.

> Ditto for enabling prefix
> delegation to a second interface.

Lets talk about this separately.
Please email me and I'll help you with your setup, no need to muddy an unrelated
debian bug report about it.

> Via ifupdown's
> /etc/network/interfaces these follow a normalized syntax that is
> completely independant of which tools perform the actual network
> configuration under the hood.

ifupdown is great for static configuration.
I would use it to configure links such as bonding, bridging, etc.
Anything dynamic, not so great.

For example having ifupdown start separate instances of a DHCP client per
interface is not only a waste of resources it also introduces undefined
behaviour because only one of these can bind to the unspecified address. The
only way around this is opening a socket for every address on the interface.
If you have a lot of interfaces or addresses dhcpcd would rapidly drain
available resources just to guarantee a defined behaviour.

I've supported dhcpcd running on a system with thousands of virtual interfaces
that arrive and depart to support a clients needs (I have no idea what he was
trying to achieve with this, it does sound crazy) and the above approach is not
tennable, so running a single dhcpcd instance across all interfaces is the only
viable solution.

dhcpcd works both ways, while I can't dictate how it should be used in Debian, I
will always encoruage the service approach rather than the per interface
approach, especially when other interfaces are in play such as prefix delegation.

>
>>> Configure's upstream default paths make Lintian bark, so I've kept the overrides in debian/rules for now. It might be worth working with upstream on making the defaults do what FHS and current packaging practices want.
>>
>> The default upstream paths mirror that of a BSD system. I belive that is in
>> conflict with FHS.
>
> There's more. For instance, manual pages canonically go to
> /usr/share/man/manX (or /usr/local/share/man/manX for locally-built
> packages). dhcpcd's Configure defaults put these in /share/man/manX if
> no prefix is passed to configure. Also hooks are currectly put in
> ${prefix}/libexec (which is the correct FHS location), but since they
> are not executable and lack the Bourne shell shebang, Lintian barks.

dhcpcd's configure default puts them into /usr/share/man/manX if nothing is
passed to configure. Maybe the Debian package is doing something differently?

The hooks that dhcpcd-run-hooks calls make zero sense being executed outside of
dhcpcd-run-hooks so being marked executable with a shell shebang also makes zero
sense.

Roy

[Martin-Éric Racine]

On Fri, Feb 25, 2022 at 3:52 PM Roy Marples <r...@marples.name> wrote:
>
> On 25/02/2022 09:25, Martin-Éric Racine wrote:
> > Right now, my personal experiements with dhcpcd indicate that
> > something as simple as passing options to wpa_supplicant via dhcpcd's
> > configuration file is not an easy task.
>
> Why would you want to? They have separate domains of responsibility. One
> configures the addressing and routes and other misc related stuff and the other
> brings up the actual link to do this on.

Because having the configuration data for all interfaces is
/etc/network/interfaces' whole point.

> dhcpcd's wpa_supplicant hook was written to solely support hotplugging a USB
> wireless stick into a machine without any kind of hotplug support.
> Since then I have added then -M flag to wpa_supplicant so it can do it by itself.

Which is a problem. dhcpcd and systemd currently compete for control
of the wireless device. systemd tries to rename it to follow
Predictable Network Interface Names at the same time as dhcpcd tries
to to connect it to a network. It results in configuration failing.
Also, unless I missed something, dhcpcd doesn't currently have the
built-in logic to understand whether a device is wireless (needs WPA)
or not (doesn't need anythign else than DHCP).

> Now if you want to configure wpa_supplicant via dhcpcd for a specific wireless
> network then the dhcpcd-ui project exists for that and relies on the
> wpa_supplicant config being writable via the wpa_supplicant control socket.

Nice idea for laptops, not so good idea for hosts that need to
repeatedly connect to the same AP and then perform otherws tasks such
as serve as a bridge for a LAN. For instance:

allow-hotplug enp9s0 wlp12s0
iface enp9s0 inet dhcp
iface enp9s0 inet6 auto
privext 2
dhcp 1
iface wlp12s0 inet dhcp
wpa-ssid <SSID>
wpa-psk <password>
iface wlp12s0 inet6 auto
privext 2
dhcp 1

This results in the host always getting a connection. If just routes
through whichever interface managed to get a DHCP configuration.

> > Ditto for enabling prefix
> > delegation to a second interface.
>
> Lets talk about this separately.
> Please email me and I'll help you with your setup, no need to muddy an unrelated
> debian bug report about it.

The point here was how not doing it in a flat file where all
interfaces can be centrally configured is a distraction. The one file
provides a centralized view and a uniform syntax.

> > Via ifupdown's
> > /etc/network/interfaces these follow a normalized syntax that is
> > completely independant of which tools perform the actual network
> > configuration under the hood.
>
> ifupdown is great for static configuration.
> I would use it to configure links such as bonding, bridging, etc.
> Anything dynamic, not so great.
>
> For example having ifupdown start separate instances of a DHCP client per
> interface is not only a waste of resources it also introduces undefined
> behaviour because only one of these can bind to the unspecified address. The
> only way around this is opening a socket for every address on the interface.
> If you have a lot of interfaces or addresses dhcpcd would rapidly drain
> available resources just to guarantee a defined behaviour.

The separate stanzas for inet and inet6 is something I've long
wondered about. dhclient's man page has the answer:

4 Use the DHCPv4 protocol to obtain an IPv4 address and
configuration parameters. This is the default and cannot be combined
with -6.

This is precisely why I want to replace dhclient with dhcpcd as the
default DHCP client. If an interface is marked in
/etc/network/interfaces as DHCP type, both IPv4 and IPv6 should be
attempted in a transparent way, and dhcpcd does that wonderfully.

> >>> Configure's upstream default paths make Lintian bark, so I've kept the overrides in debian/rules for now. It might be worth working with upstream on making the defaults do what FHS and current packaging practices want.
> >>
> >> The default upstream paths mirror that of a BSD system. I belive that is in
> >> conflict with FHS.
> >
> > There's more. For instance, manual pages canonically go to
> > /usr/share/man/manX (or /usr/local/share/man/manX for locally-built
> > packages). dhcpcd's Configure defaults put these in /share/man/manX if
> > no prefix is passed to configure. Also hooks are currectly put in
> > ${prefix}/libexec (which is the correct FHS location), but since they
> > are not executable and lack the Bourne shell shebang, Lintian barks.
>
> dhcpcd's configure default puts them into /usr/share/man/manX if nothing is
> passed to configure. Maybe the Debian package is doing something differently?
>
> The hooks that dhcpcd-run-hooks calls make zero sense being executed outside of
> dhcpcd-run-hooks so being marked executable with a shell shebang also makes zero
> sense.

Here's what I get on a build that uses the upstream configure defaults
as-is (i.e.overrides in debian/rules disabled):

SYSCONFDIR = /etc
SBINDIR = /usr/sbin
LIBDIR = /lib/i386-linux-gnu
LIBEXECDIR = /usr/libexec
DBDIR = /var/db/dhcpcd
RUNDIR = /run/dhcpcd
MANDIR = /share/man
DATADIR = /usr/share
HOOKSCRIPTS =
EGHOOKSCRIPTS = 50-yp.conf
STATUSARG =
PRIVSEPUSER = dhcpcd

E: dhcpcd5: non-standard-dir-in-var var/db/
E: dhcpcd5: non-standard-toplevel-dir share/
W: dhcpcd5-dbgsym: elf-error In program headers: Unable to find
program interpreter name
[usr/lib/debug/.build-id/df/5e855a885adce7a0063b55ff5f1e406f77cd48.debug]
W: dhcpcd5: executable-not-elf-or-script usr/libexec/dhcpcd-hooks/01-test
W: dhcpcd5: executable-not-elf-or-script usr/libexec/dhcpcd-hooks/20-resolv.conf
W: dhcpcd5: executable-not-elf-or-script usr/libexec/dhcpcd-hooks/30-hostname
W: dhcpcd5: file-in-unusual-dir share/man/man5/dhcpcd.conf.5
W: dhcpcd5: file-in-unusual-dir share/man/man8/dhcpcd-run-hooks.8
W: dhcpcd5: file-in-unusual-dir share/man/man8/dhcpcd.8
W: dhcpcd5: no-manual-page usr/sbin/dhcpcd

drwxr-xr-x root/root 0 2022-02-24 15:08 ./etc/
-rw-r--r-- root/root 1429 2022-02-24 15:08 ./etc/dhcpcd.conf
drwxr-xr-x root/root 0 2022-02-24 15:08 ./etc/init.d/
-rwxr-xr-x root/root 1905 2019-05-03 16:14 ./etc/init.d/dhcpcd
drwxr-xr-x root/root 0 2022-02-24 15:08 ./lib/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./lib/systemd/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./lib/systemd/system/
-rw-r--r-- root/root 191 2019-05-03 16:14
./lib/systemd/system/dhcpcd.service
drwxr-xr-x root/root 0 2022-02-24 15:08 ./share/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./share/man/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./share/man/man5/
-rw-r--r-- root/root 30106 2022-02-24 15:08 ./share/man/man5/dhcpcd.conf.5
drwxr-xr-x root/root 0 2022-02-24 15:08 ./share/man/man8/
-rw-r--r-- root/root 7091 2022-02-24 15:08
./share/man/man8/dhcpcd-run-hooks.8
-rw-r--r-- root/root 26559 2022-02-24 15:08 ./share/man/man8/dhcpcd.8
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/lib/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/lib/dhcpcd/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/lib/dhcpcd/dhcpcd-hooks/
-rw-r--r-- root/root 2496 2019-05-03 16:14
./usr/lib/dhcpcd/dhcpcd-hooks/60-ntp-common.conf
-rw-r--r-- root/root 380 2019-05-03 16:14
./usr/lib/dhcpcd/dhcpcd-hooks/62-chrony.conf
-rw-r--r-- root/root 466 2019-05-03 16:14
./usr/lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
-rw-r--r-- root/root 546 2019-05-03 16:14
./usr/lib/dhcpcd/dhcpcd-hooks/66-ntp.conf
-rw-r--r-- root/root 549 2019-05-03 16:14
./usr/lib/dhcpcd/dhcpcd-hooks/68-openntpd.conf
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/libexec/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/libexec/dhcpcd-hooks/
-rwxr-xr-x root/root 734 2022-02-24 15:08
./usr/libexec/dhcpcd-hooks/01-test
-rwxr-xr-x root/root 6164 2022-02-24 15:08
./usr/libexec/dhcpcd-hooks/20-resolv.conf
-rwxr-xr-x root/root 3762 2022-02-24 15:08
./usr/libexec/dhcpcd-hooks/30-hostname
-rwxr-xr-x root/root 8163 2022-02-24 15:08 ./usr/libexec/dhcpcd-run-hooks
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/sbin/
-rwxr-xr-x root/root 404904 2022-02-24 15:08 ./usr/sbin/dhcpcd
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/share/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/share/dhcpcd/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/share/dhcpcd/hooks/
-rw-r--r-- root/root 2832 2022-02-24 15:08
./usr/share/dhcpcd/hooks/10-wpa_supplicant
-rw-r--r-- root/root 885 2022-02-24 15:08
./usr/share/dhcpcd/hooks/15-timezone
-rw-r--r-- root/root 814 2022-02-24 15:08
./usr/share/dhcpcd/hooks/29-lookup-hostname
-rw-r--r-- root/root 1163 2022-02-24 15:08
./usr/share/dhcpcd/hooks/50-yp.conf
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/share/doc/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./usr/share/doc/dhcpcd5/
-rw-r--r-- root/root 2619 2022-02-24 15:08
./usr/share/doc/dhcpcd5/changelog.Debian.gz
-rw-r--r-- root/root 7966 2022-02-24 09:34
./usr/share/doc/dhcpcd5/copyright
drwxr-xr-x root/root 0 2022-02-24 15:08 ./var/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./var/db/
drwxr-xr-x root/root 0 2022-02-24 15:08 ./var/db/dhcpcd/

Martin-Éric

[Roy Marples]

On 26/02/2022 08:22, Martin-Éric Racine wrote:
> I forgot to include the actual configure stanza that gets issued. Here
> it is, straight from the build log:
>
> dh_auto_configure
> ./configure --build=i686-linux-gnu --prefix=/usr
> --includedir=\${prefix}/include --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> --disable-option-checking --disable-silent-rules
> --libdir=\${prefix}/lib/i386-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking
> configure args: --build=i686-linux-gnu --prefix=/usr
> --includedir=${prefix}/include --mandir=${prefix}/share/man
> --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> --disable-option-checking --disable-silent-rules
> --libdir=${prefix}/lib/i386-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking
> ./configure: WARNING: unknown option --disable-option-checking

So it's very assumptive that configure is a shell script and sets the variable
${prefix} to what --prefix is AND evaluates each assignment so it can work out
the variable prefix.

This behaviour is not documented by autoconf as far as I can see.

If you do --mandir=/usr/share/man or don't set it all all then dhcpcd's
configure gets the results you want.

Roy

[Roy Marples]

On 26/02/2022 09:04, Martin-Éric Racine wrote:
>> So it's very assumptive that configure is a shell script and sets the variable
>> ${prefix} to what --prefix is AND evaluates each assignment so it can work out
>> the variable prefix.
>>
>> This behaviour is not documented by autoconf as far as I can see.
>>
>> If you do --mandir=/usr/share/man or don't set it all all then dhcpcd's
>> configure gets the results you want.
>

> Not setting it at all results in the manual pages getting incorrectly
> installed in /share/man/manX/ as shown in the previous e-mail. This is
> a bug. It should inherit prefix, but it somehow doesn't.
>
> Explicitly setting --mandir=/usr/share/man obviously works, but should
> not be needed if prefix was correctly inherited.

$ ./configure --prefix=/tmp/foo
...
SYSCONFDIR = /tmp/foo/etc
SBINDIR = /tmp/foo/sbin
LIBDIR = /tmp/foo/lib
LIBEXECDIR = /tmp/foo/libexec
DBDIR = /var/db/dhcpcd
RUNDIR = /var/run/dhcpcd
MANDIR = /tmp/foo/share/man
DATADIR = /tmp/foo/share
HOOKSCRIPTS = 50-ntp.conf
EGHOOKSCRIPTS = 50-ypbind
STATUSARG =
PRIVSEPUSER = _dhcpcd

How is this broken?

Roy

[Roy Marples]

On 26/02/2022 09:14, Martin-Éric Racine wrote:

> See above messages.

No, that's not good enough.

I have demonstrated that the prefix option and explicity setting the mandir
option work fine. I have also asked for autoconf documentation regarding the
expected behaviour about evaluating the prefix variable to which you have not
provided anything.

dhcpcd's configure is not autoconf and relying on undocumented internal
behaviour for autoconf it not the right way to do things.

Roy

[Martin-Éric Racine]

On Fri, Feb 25, 2022 at 10:31 AM Roy Marples <r...@marples.name> wrote:
> Looking, someone else decided to redo the NTP hooks entirely for Debian.
> My understanding is that the only thing the upstream hook doesn't do is timesyncd.

On Debian, systemd Recommends systemd-timesyncd or time-daemon.

Packages currently providing time-daemon:

chrony - Versatile implementation of the Network Time Protocol
ntp - Network Time Protocol daemon and utility programs
ntpsec - Network Time Protocol daemon and utility programs
openntpd - OpenBSD NTP daemon
systemd-timesyncd - minimalistic service to synchronize local time
with NTP servers

Nonetheless dhcpcd's configure script tests for whatever NTP service
is currently running on the build host and enables matching hooks.
Works well for building host-specific binaries, but is obviously not
flexible enough for a software distribution to anticipate for any of
the above options being installed on a target host pulling dhcpcd
packages from a repository.

Martin-Éric

[Roy Marples]

On 26/02/2022 07:53, Martin-Éric Racine wrote:
> On Fri, Feb 25, 2022 at 3:52 PM Roy Marples <r...@marples.name> wrote:
>>
>> On 25/02/2022 09:25, Martin-Éric Racine wrote:
>>> Right now, my personal experiements with dhcpcd indicate that
>>> something as simple as passing options to wpa_supplicant via dhcpcd's
>>> configuration file is not an easy task.
>>
>> Why would you want to? They have separate domains of responsibility. One
>> configures the addressing and routes and other misc related stuff and the other
>> brings up the actual link to do this on.
>
> Because having the configuration data for all interfaces is
> /etc/network/interfaces' whole point.

Then get /etc/network/interfaces to control wpa_supplicant and don't abuse the
dhcpcd hook.

>
>> dhcpcd's wpa_supplicant hook was written to solely support hotplugging a USB
>> wireless stick into a machine without any kind of hotplug support.
>> Since then I have added then -M flag to wpa_supplicant so it can do it by itself.
>
> Which is a problem. dhcpcd and systemd currently compete for control
> of the wireless device. systemd tries to rename it to follow
> Predictable Network Interface Names at the same time as dhcpcd tries
> to to connect it to a network. It results in configuration failing.

Oh please.
This issue was 9 solved years ago when I wrote a udev plugin for dhcpcd that
forces dhcpcd to only "use" the interface when udev says the name has settled.
https://github.com/NetworkConfiguration/dhcpcd/commit/12bbc8cb5c7507be15a7e0af4140c3d81125c46c

A quick test using a Debian VM I have shows it still works fine.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if.c#L538
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if-linux.c#L1016

However, it looks like this isn't pacakged with Debian

Now, if it doesn't work go file a bug with udev.

> Also, unless I missed something, dhcpcd doesn't currently have the
> built-in logic to understand whether a device is wireless (needs WPA)
> or not (doesn't need anythign else than DHCP).

You have missed something.
dhcpcd can set a profile per SSID so in dhcpcd.conf you could do this

profile AP1
static ipaddress=192.168.1.100/16

profile AP2
static ipaddress=10.100.32.1/8

In the hook scripts you also have ${if_wireless} to examine.

>
>> Now if you want to configure wpa_supplicant via dhcpcd for a specific wireless
>> network then the dhcpcd-ui project exists for that and relies on the
>> wpa_supplicant config being writable via the wpa_supplicant control socket.
>
> Nice idea for laptops, not so good idea for hosts that need to
> repeatedly connect to the same AP and then perform otherws tasks such
> as serve as a bridge for a LAN. For instance:
>
> allow-hotplug enp9s0 wlp12s0
> iface enp9s0 inet dhcp
> iface enp9s0 inet6 auto
> privext 2
> dhcp 1
> iface wlp12s0 inet dhcp
> wpa-ssid <SSID>
> wpa-psk <password>
> iface wlp12s0 inet6 auto
> privext 2
> dhcp 1
>
> This results in the host always getting a connection. If just routes
> through whichever interface managed to get a DHCP configuration.

I fail to see why this is a problem for what I described.
All dhcpcd-ui does is set a password for the network. That works fine with
bridging because you can add an interface to a bridge regardless of the actual
link being configured correctly or not.

>>> Via ifupdown's
>>> /etc/network/interfaces these follow a normalized syntax that is
>>> completely independant of which tools perform the actual network
>>> configuration under the hood.
>>
>> ifupdown is great for static configuration.
>> I would use it to configure links such as bonding, bridging, etc.
>> Anything dynamic, not so great.
>>
>> For example having ifupdown start separate instances of a DHCP client per
>> interface is not only a waste of resources it also introduces undefined
>> behaviour because only one of these can bind to the unspecified address. The
>> only way around this is opening a socket for every address on the interface.
>> If you have a lot of interfaces or addresses dhcpcd would rapidly drain
>> available resources just to guarantee a defined behaviour.
>
> The separate stanzas for inet and inet6 is something I've long
> wondered about. dhclient's man page has the answer:
>
> 4 Use the DHCPv4 protocol to obtain an IPv4 address and
> configuration parameters. This is the default and cannot be combined
> with -6.
>
> This is precisely why I want to replace dhclient with dhcpcd as the
> default DHCP client. If an interface is marked in
> /etc/network/interfaces as DHCP type, both IPv4 and IPv6 should be
> attempted in a transparent way, and dhcpcd does that wonderfully.

My comment about wasting resources still stands as it applies to both IPv4 and IPv6.

Try starting dhcpcd built with privsep on a specific interface and then examine
the process list and what network addresses are being listened to.
Then redo this without specifying any interface and look at the same data.
You will see that this is a lot less resource.

The fact dhclient only works in ipv4 more or ipv6 mode isn't related to that.

Roy

[Santiago R.R.]

(Removing some people from CC to avoid polluting their mailboxes)

El 25/02/22 a las 11:25, Martin-Éric Racine escribió:

> On Fri, Feb 25, 2022 at 10:31 AM Roy Marples <r...@marples.name> wrote:
> >
> > On 24/02/2022 21:31, Santiago R.R. wrote:
> > >
> > > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> > <santi...@riseup.net> wrote:
> > >>
> > >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> > <martin-er...@iki.fi> wrote:
> > >>> Package: dhcpcd5
> > >>> Followup-For: Bug #964947
> > >>> X-Debbugs-Cc:
> > sc...@sl.id.au,r...@marples.name,santi...@riseup.net,mp...@debian.org
> > >>>
> > > I have an NMU waiting on Mentors.
> > >
> > > <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>
> > >
> > >> Thanks for your work! I do not have too much free cycles, but I will do my best to review and upload it soon.

...

I forgot to say I hope Scott is doing well. I hope his lack of activity
is just a lack of available time.


Martin-Éric, thank you again for preparing this NMU. Here you have some
comments/questions:

* You are moving stuff to /usr. Do you have any reason for making this
change in this NMU?
While I think it is a good thing, this is not documented in
d/changelog, and I think an NMU should focus on the reason for doing it
(the newest upstream release in this case).
From the developers reference (5.11.1.): "...Fixing cosmetic issues or
changing the packaging style in NMUs is discouraged."

This also concerns the minor bump version number in d/watch.

* Could you please fix the indentation of the your new entry in d/copyright?

* Part of the changes you are including had already been done in the VCS
by Scott. There is no rule about this, but *I* would give credit to
him. Maybe I would have cherry-picked the relevant changes needed for
packaging this new upstream release, and use `gdp dch`. This is up to
you.

* Could you please tell me how have you tested it?

(I will answer Roy's messages in another mail)

Cheers!

-- Santiago

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. <santi...@riseup.net> wrote:
>
> (Removing some people from CC to avoid polluting their mailboxes)
>
> El 25/02/22 a las 11:25, Martin-Éric Racine escribió:
> > On Fri, Feb 25, 2022 at 10:31 AM Roy Marples <r...@marples.name> wrote:
> > >
> > > On 24/02/2022 21:31, Santiago R.R. wrote:
> > > >
> > > > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> > > <santi...@riseup.net> wrote:
> > > >>
> > > >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> > > <martin-er...@iki.fi> wrote:
> > > >>> Package: dhcpcd5
> > > >>> Followup-For: Bug #964947
> > > >>> X-Debbugs-Cc:
> > > sc...@sl.id.au,r...@marples.name,santi...@riseup.net,mp...@debian.org
> > > >>>
> > > > I have an NMU waiting on Mentors.
> > > >
> > > > <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>
> > > >
> > > >> Thanks for your work! I do not have too much free cycles, but I will do my best to review and upload it soon.
> ...
>
> I forgot to say I hope Scott is doing well. I hope his lack of activity
> is just a lack of available time.

The last upload was made in May 2019 i.e. oldstable.

Bug #964947 requesting the packaging of current version was filed in
July 2020. That's nearly 2 years ago. It remains unanswered by Scott
despite recent activity on the bug. My packaging therefore assumes
that Scott is MIA and focuses on bringing the package closer to what's
expected for contemporary usage.

> * You are moving stuff to /usr. Do you have any reason for making this
> change in this NMU?
> While I think it is a good thing, this is not documented in
> d/changelog, and I think an NMU should focus on the reason for doing it
> (the newest upstream release in this case).
> From the developers reference (5.11.1.): "...Fixing cosmetic issues or
> changing the packaging style in NMUs is discouraged."

I try to keep the delta with upstream defaults as small as possible.
Upstream uses /usr. The only thing that doesn't work as expected is
that upstream's configure script fails at putting the prefix for
manual pages.

As a side-issue, Lintian incorrectly reports the upstream default for
its lease database (/var/db) as non-standard. See Bug#1006482. Because
of this, I've kept the directory unchanged for now.

If Debian followed FHS by the book, we would probably want the DHCP
client to sit in /sbin since it's needed to bring up the network and
/usr may be mounted later during bootup. Since Debian doesn't mount
/usr separately, using upstream defaults works as-is.

> This also concerns the minor bump version number in d/watch.

It was a low-hanging fruit and verified to work.

> * Could you please fix the indentation of the your new entry in d/copyright?

IMHO, the whole file's indentation needs to be fixed. I had troubles
aligning my addition, because the file currently uses TAB+2SPACES.
There really should be a linting tool for that.

> * Part of the changes you are including had already been done in the VCS
> by Scott. There is no rule about this, but *I* would give credit to
> him. Maybe I would have cherry-picked the relevant changes needed for
> packaging this new upstream release, and use `gdp dch`. This is up to
> you.

I have not checked what's in VCS since no upload has taken place since
2019 and no reaction to bugs has take place since then either.

> * Could you please tell me how have you tested it?

For the past week, it's been the DHCP client on an host that matches
upstream assumptions: hotpluggable Ethernet or USB WiFi dongles. The
host in question has Ethernet, and I've randomly used a variety of USB
dongles to test WiFi support. Configuring wpa_supplicant manually
via/etc/wpa_supplicant/wpa_supplicant.conf rather than passing the
SSID and PSK key via /etc/network/interfaces required a lot of
googling but works as expected. This initially didn't work as
expected, because the package was not compiled with libudev and
upstream's BUILDING.md makes no mention of what libraries may be used
to enable some features. That's how I ended up adding the Build-Dep.

Martin-Éric

[Santiago R.R.]

El 28/02/22 a las 16:26, Martin-Éric Racine escribió:

Sorry, just to be sure of understanding, are you reverting the move to
/usr? If yes, please tell me when you have a new version to review.
Otherwise, please document it in d/changelog.

>
> If Debian followed FHS by the book, we would probably want the DHCP
> client to sit in /sbin since it's needed to bring up the network and
> /usr may be mounted later during bootup. Since Debian doesn't mount
> /usr separately, using upstream defaults works as-is.
>
> > This also concerns the minor bump version number in d/watch.
>
> It was a low-hanging fruit and verified to work.

Yes, I can acknowledge that. But again, I have some doubts that's the
changes that should be expected in an NMU.

>
> > * Could you please fix the indentation of the your new entry in d/copyright?
>
> IMHO, the whole file's indentation needs to be fixed. I had troubles
> aligning my addition, because the file currently uses TAB+2SPACES.
> There really should be a linting tool for that.

Idem.

>
> > * Part of the changes you are including had already been done in the VCS
> > by Scott. There is no rule about this, but *I* would give credit to
> > him. Maybe I would have cherry-picked the relevant changes needed for
> > packaging this new upstream release, and use `gdp dch`. This is up to
> > you.
>
> I have not checked what's in VCS since no upload has taken place since
> 2019 and no reaction to bugs has take place since then either.
>
> > * Could you please tell me how have you tested it?
>
> For the past week, it's been the DHCP client on an host that matches
> upstream assumptions: hotpluggable Ethernet or USB WiFi dongles. The
> host in question has Ethernet, and I've randomly used a variety of USB
> dongles to test WiFi support. Configuring wpa_supplicant manually
> via/etc/wpa_supplicant/wpa_supplicant.conf rather than passing the
> SSID and PSK key via /etc/network/interfaces required a lot of
> googling but works as expected. This initially didn't work as
> expected, because the package was not compiled with libudev and
> upstream's BUILDING.md makes no mention of what libraries may be used
> to enable some features. That's how I ended up adding the Build-Dep.

Great, thank you!

-- Santiago

[Santiago R.R.]

El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> <martin-er...@iki.fi> wrote:

> >
> > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > <martin-er...@iki.fi> wrote:
> > >
> > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. <santi...@riseup.net> wrote:
> > > > * Could you please fix the indentation of the your new entry in d/copyright?
> > >
> > > IMHO, the whole file's indentation needs to be fixed. I had troubles
> > > aligning my addition, because the file currently uses TAB+2SPACES.
> > > There really should be a linting tool for that.
> >

> > Actually, it seems that wrap-and-sort can be used for d/copyright too.
> > I somehow was under the impression that it's only used for d/control.
> > I'm extremely tempted to run it on the whole package.
>
> Reading back on Bug #964947, I notice that the request was for both
> packaging current upstream and dropping the 5 out of the package name.
> I would tend to agree. The 5 really only was meant as an upstream
> branch tag. The source and binary really should be called 'dhcpcd'
> since it essentially is a fork of the abandoned source of the same
> name.

Changing the source name means creating (or reintroducing) a different
debian package. Just in case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218

Changing the binary name only means it would have to pass by NEW…

-- Santiago

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 5:44 PM Santiago R.R. <santi...@riseup.net> wrote:
>
> El 28/02/22 a las 16:26, Martin-Éric Racine escribió:

> > > * You are moving stuff to /usr. Do you have any reason for making this
> > > change in this NMU?
> > > While I think it is a good thing, this is not documented in
> > > d/changelog, and I think an NMU should focus on the reason for doing it
> > > (the newest upstream release in this case).
> > > From the developers reference (5.11.1.): "...Fixing cosmetic issues or
> > > changing the packaging style in NMUs is discouraged."
> >
> > I try to keep the delta with upstream defaults as small as possible.
> > Upstream uses /usr. The only thing that doesn't work as expected is
> > that upstream's configure script fails at putting the prefix for
> > manual pages.
> >
> > As a side-issue, Lintian incorrectly reports the upstream default for
> > its lease database (/var/db) as non-standard. See Bug#1006482. Because
> > of this, I've kept the directory unchanged for now.
>
> Sorry, just to be sure of understanding, are you reverting the move to
> /usr? If yes, please tell me when you have a new version to review.
> Otherwise, please document it in d/changelog.

Read again. Prefix is currently to upstream default at /usr. The DHCP
lease database would be in /var/db/dhcpcd, but Lintian considers
/var/db as non-standard even though it is FHS. Bug filed against
Lintian accordingly and the lease database remains in /var/lib until
Lintian has been fixed.

> > > * Could you please fix the indentation of the your new entry in d/copyright?
> >
> > IMHO, the whole file's indentation needs to be fixed. I had troubles
> > aligning my addition, because the file currently uses TAB+2SPACES.
> > There really should be a linting tool for that.
>
> Idem.

Either I run wrap-and-sort on the source tree, or I make no attempt to
fix the formatting of d/copyright.

Martin-Éric

[Santiago R.R.]

On March 2, 2022 6:10:32 PM GMT+01:00, "Martin-Éric Racine" <martin-er...@iki.fi> wrote:
>On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine
><martin-er...@iki.fi> wrote:

>> Merely changing the binary name sounds perfectly reasonable to me.
>
>Please note that I have re-uploaded the package to Mentors. The log
>file is more explicit about cosmetic changes and about ./configure
>caveats.
>

Thank you. And sorry for the radio silence, I got busier than expected the last couple of days. I hope I can process it by Friday.

Cheers,

Santiago

[Santiago R.R.]

El 02/03/22 a las 19:10, Martin-Éric Racine escribió:
> On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine

> > Merely changing the binary name sounds perfectly reasonable to me.
>
> Please note that I have re-uploaded the package to Mentors. The log
> file is more explicit about cosmetic changes and about ./configure
> caveats.

* Are you sure about this in debian/rules?

+ --libdir=/usr/lib/i386-linux-gnu \

At a first glance, I suppose that would break multiarch support.


* I still don't feel fully comfortable with the cosmetic changes,
specially with wrap-and-sort, for *this* NMU. According to my
interpretation of developers-references, we should avoid that.
Scott is still listed as Maintainer, even if the package hasn't been
updated for a long time (hello MIA Team!). At the same time, I
appreciate your work and I think the changes you are making should
arrive into the debian archive sooner or later.

Since I doubt, may I ask the MIA Team if it is OK to include cosmetic
changes in an NMU for package that hasn't been orphaned?


* Your entry in d/copyright still doesn't follow the same (weird)
indentation than previous contributors':

Files: *
Copyright: 2006-2018 Roy Marples <r...@marples.name>
@@ -61,6 +62,7 @@
2013 Christoph Egger <chri...@debian.org>
2014 Salvatore Bonaccorso <car...@debian.org>
2015 Daniel Echeverry <epsi...@gmail.com>
+ 2022 Martin-Éric Racine <martin-er...@iki.fi>
License: BSD-2


Cheers,

-- Santiago

[Santiago R.R.]

Sorry for the delayed answer!

El 05/03/22 a las 07:09, Martin-Éric Racine escribió:

> On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R. <santi...@riseup.net> wrote:
> >
> > El 02/03/22 a las 19:10, Martin-Éric Racine escribió:
> > > On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine
> > > <martin-er...@iki.fi> wrote:

[...]

> > > Please note that I have re-uploaded the package to Mentors. The log
> > > file is more explicit about cosmetic changes and about ./configure
> > > caveats.
> >
> > * Are you sure about this in debian/rules?
> >
> > + --libdir=/usr/lib/i386-linux-gnu \
> >
> > At a first glance, I suppose that would break multiarch support.
>

> Without it, the udev backend goes in /lib, instead of /usr/lib like
> the rest of the package. It's in the changelog: --prefix somehow
> doesn't propagate as it should for --libdir and --mandir.

>
> > * I still don't feel fully comfortable with the cosmetic changes,
> > specially with wrap-and-sort, for *this* NMU. According to my
> > interpretation of developers-references, we should avoid that.
> > Scott is still listed as Maintainer, even if the package hasn't been
> > updated for a long time (hello MIA Team!). At the same time, I
> > appreciate your work and I think the changes you are making should
> > arrive into the debian archive sooner or later.
> >
> > Since I doubt, may I ask the MIA Team if it is OK to include cosmetic
> > changes in an NMU for package that hasn't been orphaned?
>

> I definitely went a step beyond NMU because, asides from not having
> tracked upstream, the package is seriously outdated and not up to
> current best practices. As a ground rule, a package that hasn't
> changed since oldstable definitely is up for a brush-up of its
> packaging to bring it up to current Policy, even if no new upstream
> has come. None of that has happened for this and a number of other
> packages.

If you want to go even further, it would be great if you think about an
ITS ;-)

>
> I feel that this (and several more) packages should be investigated by
> the MIA Team. The sheer amount of packages in the Debian archive that
> haven't been updated since oldstable (or that barely received a random
> cherry-picked patch from upstream Git applied by the security team) is
> alarming. Debian's archive is rotting, and that's not a good sign,
> considering how many distributions build their UI on top of Debian
> packages.
>

I cannot talk for the MIA Team, but I am sure they do as best as they
can. And maybe they need some help to spot those packages that urgently
need love.

> > * Your entry in d/copyright still doesn't follow the same (weird)
> > indentation than previous contributors':
> >
> > Files: *
> > Copyright: 2006-2018 Roy Marples <r...@marples.name>
> > @@ -61,6 +62,7 @@
> > 2013 Christoph Egger <chri...@debian.org>
> > 2014 Salvatore Bonaccorso <car...@debian.org>
> > 2015 Daniel Echeverry <epsi...@gmail.com>
> > + 2022 Martin-Éric Racine <martin-er...@iki.fi>
> > License: BSD-2
>

> I used wrap-and-sort for that.
>

So maybe wrap-and-sort is not clever enough. Expanding the tabs, this is
how I see it on my machine:

Files: debian/*
Copyright: 2010-2013 Roy Marples <r...@marples.name>

2013 Christoph Egger <chri...@debian.org>
2014 Salvatore Bonaccorso <car...@debian.org>
2015 Daniel Echeverry <epsi...@gmail.com>