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

2022-03-14 Thread 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.  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
> > >  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 
> > @@ -61,6 +62,7 @@
> >2013 Christoph Egger 
> >2014 Salvatore Bonaccorso 
> >2015 Daniel Echeverry 
> > +   2022 Martin-Éric Racine 
> >  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 
   2013 Christoph Egger 
   2014 Salvatore Bonaccorso 
   2015 Daniel Echeverry 
   2022 Martin-Éric Racine 
License: BSD-2

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

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

2022-03-05 Thread Martin-Éric Racine 
On Sat, Mar 5, 2022 at 8:31 AM Martin-Éric Racine
 wrote:
>
> On Sat, Mar 5, 2022 at 7:09 AM Martin-Éric Racine
>  wrote:
> >
> > On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R.  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
> > > >  wrote:
> > > > >
> > > > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  
> > > > > wrote:
> > > > > >
> > > > > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > > > > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. 
> > > > > > > > >  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…
> > > > >
> > > > > 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.
> >
> > 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.
>
> Wait. I get what you meant. This ends up hard-coding the path on all
> arch. Not good.
>
> This being said, I'm not sure of how else to fix the broken --prefix
> propagation for --libdiir and --mandir. Finding and fixing the issue,
> and possibly submiting a patch to upstream, requires more autotool
> skills than I have.

Fixed. I found a kludge to poll dpkg for the target triplet.

This still doesn't resolve the issue of why --prefix doesn't correctly
propagate to --libdir and --mandir out of the box. Neither of these
should need to be manually specified if --prefix propagates.
Upstream's ./configure script probably is broken in some way.

Martin-Éric

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

2022-03-04 Thread Martin-Éric Racine 
On Sat, Mar 5, 2022 at 7:09 AM Martin-Éric Racine
 wrote:
>
> On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R.  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
> > >  wrote:
> > > >
> > > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  
> > > > wrote:
> > > > >
> > > > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > > > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. 
> > > > > > > >  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…
> > > >
> > > > 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.
>
> 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.

Wait. I get what you meant. This ends up hard-coding the path on all
arch. Not good.

This being said, I'm not sure of how else to fix the broken --prefix
propagation for --libdiir and --mandir. Finding and fixing the issue,
and possibly submiting a patch to upstream, requires more autotool
skills than I have.

Martin-Éric

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

2022-03-04 Thread Martin-Éric Racine 
On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R.  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
> >  wrote:
> > >
> > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  
> > > wrote:
> > > >
> > > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. 
> > > > > > >  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…
> > >
> > > 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.

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.

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.

> * Your entry in d/copyright still doesn't follow the same (weird)
>   indentation than previous contributors':
>
>  Files: *
>  Copyright: 2006-2018  Roy Marples 
> @@ -61,6 +62,7 @@
>2013 Christoph Egger 
>2014 Salvatore Bonaccorso 
>2015 Daniel Echeverry 
> +   2022 Martin-Éric Racine 
>  License: BSD-2

I used wrap-and-sort for that.

Martin-Éric

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

2022-03-04 Thread 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
>  wrote:
> >
> > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  wrote:
> > >
> > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> > > >  wrote:
> > > > >
> > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. 
> > > > > >  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…
> >
> > 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 
@@ -61,6 +62,7 @@
   2013 Christoph Egger 
   2014 Salvatore Bonaccorso 
   2015 Daniel Echeverry 
+   2022 Martin-Éric Racine 
 License: BSD-2
 

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

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

2022-03-02 Thread Santiago R.R. 



On March 2, 2022 6:10:32 PM GMT+01:00, "Martin-Éric Racine" 
 wrote:
>On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine
> wrote:
>>
>> On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  wrote:
>> >
>> > El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
>> > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
>> > >  wrote:
>> > > >
>> > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
>> > > >  wrote:
>> > > > >
>> > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. 
>> > > > >  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…
>>
>> 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

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

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

2022-03-02 Thread Martin-Éric Racine 
On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine
 wrote:
>
> On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  wrote:
> >
> > El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> > >  wrote:
> > > >
> > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > > >  wrote:
> > > > >
> > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. 
> > > > >  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…
>
> 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.

Martin-Éric

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

2022-02-28 Thread Martin-Éric Racine 
On Mon, Feb 28, 2022 at 5:44 PM Santiago R.R.  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

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

2022-02-28 Thread Martin-Éric Racine 
On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  wrote:
>
> El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > >  wrote:
> > > >
> > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  
> > > > 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…

Merely changing the binary name sounds perfectly reasonable to me.

Martin-Éric

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

2022-02-28 Thread 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
>  wrote:
> >
> > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  
> > > 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


signature.asc
Description: PGP signature

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

2022-02-28 Thread Santiago R.R. 
El 28/02/22 a las 16:26, Martin-Éric Racine escribió:
> On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  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  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."
> > > >  wrote:
> > > >  >>
> > > >  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> > > >  wrote:
> > > >  >>> Package: dhcpcd5
> > > >  >>> Followup-For: Bug #964947
> > > >  >>> X-Debbugs-Cc:
> > > > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> > > >  >>>
> > > > > I have an NMU waiting on Mentors.
> > > > >
> > > > > 
> > > > >
> > > > >> 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.

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


signature.asc
Description: PGP signature

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

2022-02-28 Thread Martin-Éric Racine 
On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
 wrote:
>
> On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
>  wrote:
> >
> > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  
> > 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.

Martin-Éric

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

2022-02-28 Thread Martin-Éric Racine 
On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
 wrote:
>
> On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  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.

Martin-Éric

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

2022-02-28 Thread Martin-Éric Racine 
On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  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  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."
> > >  wrote:
> > >  >>
> > >  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> > >  wrote:
> > >  >>> Package: dhcpcd5
> > >  >>> Followup-For: Bug #964947
> > >  >>> X-Debbugs-Cc:
> > > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> > >  >>>
> > > > I have an NMU waiting on Mentors.
> > > >
> > > > 
> > > >
> > > >> 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

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

2022-02-28 Thread 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  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."
> >  wrote:
> >  >>
> >  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> >  wrote:
> >  >>> Package: dhcpcd5
> >  >>> Followup-For: Bug #964947
> >  >>> X-Debbugs-Cc:
> > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> >  >>>
> > > I have an NMU waiting on Mentors.
> > >
> > > 
> > >
> > >> 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


signature.asc
Description: PGP signature

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

2022-02-26 Thread Martin-Éric Racine 
On Sat, Feb 26, 2022 at 12:06 PM Martin-Éric Racine
 wrote:
>
> On Sat, Feb 26, 2022 at 11:54 AM Roy Marples  wrote:
> > >> 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
>
> Sure enough, existing Build-Dep inherited from the current packaging
> did not pull libudev-dev. Added. Built and tested. Works well. Thanks
> for pointing that out.

Btw, it would be a good idea for BUILDING.md to mention which
libraries can optionally be used, such as libudev-dev in the above
case.

Ditto for configure to mention the package-specific options such as
where to find and include additional hooks. Right now, it only shows
generic instructions.

Martin-Éric

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

2022-02-26 Thread Martin-Éric Racine 
On Sat, Feb 26, 2022 at 11:54 AM Roy Marples  wrote:
>
> On 26/02/2022 07:53, Martin-Éric Racine wrote:
> > On Fri, Feb 25, 2022 at 3:52 PM Roy Marples  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.

Something like this?

allow-hotplug enp9s0 wlp12s0
iface enp9s0 inet manual
iface wlp12s0 inet manual
wpa-ssid 
wpa-psk 

That would probably work. The 'manual' method would let dhcpcd do its
job in the background.

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

Sure enough, existing Build-Dep inherited from the current packaging
did not pull libudev-dev. Added. Built and tested. Works well. Thanks
for pointing that out.

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

Noted.

Martin-Éric

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

2022-02-26 Thread Martin-Éric Racine 
On Fri, Feb 25, 2022 at 10:31 AM Roy Marples  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

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

2022-02-26 Thread Martin-Éric Racine 
On Sat, Feb 26, 2022 at 11:10 AM Roy Marples  wrote:
>
> 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?

See above messages.

Martin-Éric

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

2022-02-26 Thread Martin-Éric Racine 
On Sat, Feb 26, 2022 at 10:56 AM Roy Marples  wrote:
>
> 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.

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.

Martin-Éric

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

2022-02-26 Thread Martin-Éric Racine 
On Sat, Feb 26, 2022 at 9:53 AM Martin-Éric Racine
 wrote:
>
> On Fri, Feb 25, 2022 at 3:52 PM Roy Marples  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 
> wpa-psk 
> 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

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

2022-02-25 Thread Martin-Éric Racine 
On Fri, Feb 25, 2022 at 3:52 PM Roy Marples  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 
wpa-psk 
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 =

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

2022-02-25 Thread Martin-Éric Racine 
On Fri, Feb 25, 2022 at 10:31 AM Roy Marples  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."
>  wrote:
>  >>
>  >>
>  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
>  wrote:
>  >>> Package: dhcpcd5
>  >>> Followup-For: Bug #964947
>  >>> X-Debbugs-Cc:
> sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
>  >>>
> > I have an NMU waiting on Mentors.
> >
> > 
> >
> >> 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

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

2022-02-24 Thread Santiago R.R. 



On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R." 
 wrote:
>
>
>On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine" 
> wrote:
>>Package: dhcpcd5
>>Followup-For: Bug #964947
>>X-Debbugs-Cc: 
>>sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
>>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA512
>>
>>I have an NMU waiting on Mentors.
>>
>>
>>

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.

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

2022-02-24 Thread 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



OpenPGP_signature
Description: OpenPGP digital signature

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

2022-02-24 Thread Martin-Éric Racine 
On Thu, Feb 24, 2022 at 11:12 AM Michael Biebl  wrote:
> 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.

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.

Martin-Éric

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

2022-02-24 Thread 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


OpenPGP_signature
Description: OpenPGP digital signature

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

2022-02-24 Thread Martin-Éric Racine 
And, sure enough, I forgot to tag Michael on my previous message. Sorry.

On Thu, Feb 24, 2022 at 10:38 AM Martin-Éric Racine
 wrote:
>
> Package: dhcpcd5
> Followup-For: Bug #964947
> X-Debbugs-Cc: 
> sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> I have an NMU waiting on Mentors.
>
> 
>
> 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-

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

2022-02-24 Thread Martin-Éric Racine 
Package: dhcpcd5
Followup-For: Bug #964947
X-Debbugs-Cc: 
sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have an NMU waiting on Mentors.



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-

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

2022-02-19 Thread Michael Biebl 


Control: block 810151 by -1

On Mon, 13 Jul 2020 10:15:11 +0300 Giorgos Skafidas 
 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


OpenPGP_signature
Description: OpenPGP digital signature

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

2020-07-13 Thread 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  

Versions of packages dhcpcd5 suggests:
pn  dhcpcd-gtk  

-- no debconf information