On Sat, Mar 5, 2022 at 7:09 AM Martin-Éric Racine <martin-eric.rac...@iki.fi> wrote: > > On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R. <santiag...@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-eric.rac...@iki.fi> wrote: > > > > > > > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R. <santiag...@riseup.net> > > > > 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 > > > > > > <martin-eric.rac...@iki.fi> wrote: > > > > > > > > > > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine > > > > > > > <martin-eric.rac...@iki.fi> wrote: > > > > > > > > > > > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. > > > > > > > > <santiag...@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… > > > > > > > > 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
