Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270810 > unrolled thread

Bug#1121014: dhcpcd-base: Manager forgets iface cmdline opts on CARRIER event

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1121014: dhcpcd-base: Manager forgets iface cmdline opts on CARRIER event Daniel Gröber <dxld@darkboxed.org> - 2025-11-19 16:10 +0100
    Bug#1121014: dhcpcd-base: Manager forgets iface cmdline opts on CARRIER event Daniel Gröber <dxld@darkboxed.org> - 2025-11-20 17:40 +0100
    Bug#1121014: dhcpcd-base: Manager forgets iface cmdline opts on CARRIER event Daniel Gröber <dxld@darkboxed.org> - 2025-11-21 10:50 +0100

#1270810 — Bug#1121014: dhcpcd-base: Manager forgets iface cmdline opts on CARRIER event

[Multipart message — attachments visible in raw view] — view raw

Package: dhcpcd-base
Version: 1:10.1.0-11
Severity: important
Forwarded: https://github.com/NetworkConfiguration/dhcpcd/pull/548
X-Debbugs-Cc: dxld@darkboxed.org

Dear Maintainer,

While working on dhcpcd<>ifupdown integration I found that interface
UP/DOWN events (cable re-plugging) can clear options that were passed when
asking the global manager (dhcpcd.service) to start the interface
initially.

This doesn't happen when using per-iface (as used by ifupdown=0.8.44) or
per-iface-per-af.

The attached patch fixes the issue and has more detailed rationale.

My preferred design for future-proof ifupdown<>dhcpcd.service
interoperability relies on this not being broken, I will be uploading an
NMU (1:10.3.0-1.1) to DELAYED/5 soon so my pending ifupdown=0.9 upload will
not regress or have to hack around this.

Thanks,
--Daniel

FYI: Find nomenclature and discussion in
https://lists.debian.org/debian-devel/2025/10/msg00201.html

[toc] | [next] | [standalone]

#1270957

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 19, 2025 at 08:43:19PM +0200, Martin-Éric Racine wrote:
> > My preferred design for future-proof ifupdown<>dhcpcd.service
> > interoperability relies on this not being broken, I will be uploading an
> > NMU (1:10.3.0-1.1) to DELAYED/5 soon so my pending ifupdown=0.9 upload will
> > not regress or have to hack around this.
> 
> No. I really don't wanna introduce any Debian-specific diff to the
> upstream code.

Martin, taking care of stable users is part of your responsibilities as
Debian maintainer -- this necessarily includes patch managment as Debian
policy require fixes bound for stable to be made in unstable first:

  https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#stable-update

> 5.5.1. Special case: uploads to the stable and oldstable distributions
>
> The bug you want to fix in stable must be fixed in unstable already

Consequently a blanket refusal not to take patches is not an acceptable
response.

Please provide technical justification.

Thanks,
--Daniel

[toc] | [prev] | [next] | [standalone]

#1271034

[Multipart message — attachments visible in raw view] — view raw

Martin,

On Fri, Nov 21, 2025 at 11:34:42AM +0200, Martin-Éric Racine wrote:
> See https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
> 
> You did not attach your patch to a bug well ahead of time, leave
> plenty of time for the maintainer to react discuss whether he agrees,
> or contacted him separately if he didn't react. You immediately
> uploaded your changes.

You're confusing uploading to DELAYED/5 with uploading to unstable. This
gives you five days to react, well three and a bit now:

  https://ftp-master.debian.org/deferred.html

  https://www.debian.org/doc/manuals/developers-reference/pkgs.html#delayed-uploads

--Daniel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web