Re: Uninformative hyperlink in O: (package orphaning) bug reports
Hi all, On 07.07.19 14:47, Osamu Aoki wrote: > On Sat, Jun 29, 2019 at 10:07:19AM +0200, Tobias Frost wrote: >> On Thu, Jun 27, 2019 at 03:38:48PM -0400, Boyuan Yang wrote:[snip] >> This text comes from a template we use in the MIA-Team. >> You can find it here: >> https://salsa.debian.org/qa/qa/blob/master/mia/templates/wnpp-orphan.mia >> >>> However, https://www.debian.org/devel/wnpp/#howto-o provides almost zero >>> information for an enthusiast that want to adopt the package, i.e. there's >>> no >>> detailed instruction on how to actually upload a package for a person not >>> quite familiar with Debian's packaging workflow. >>> >>> I'd suggest some kind of rewording on the website given that this link has >>> been posted everywhere in different BTS bug reports. Including a link to >>> https://mentors.debian.net/intro-maintainers might be a good idea. Anyway >>> any >>> kind of improvement would be appreciated. >> >> A MR would be indeed very welcome! ;-) > > OK. I will do so to request to add the following for 4 files: > > If you are a prospective Debian maintainer, you are encouraged to take > this package.> We need a volunteer like you. Please note that > maintaining a package requires time and skills. Please look at > https://mentors.debian.net/intro-maintainers to understand existing > practices first. If you are new to Debian packaging, please read a > tutorial document such as > https://www.debian.org/doc/manuals/debmake-doc/index.en.html and also > study how other Debian maintainers package similar packages. I think this is still starting a little bit negative, maybe like this? If nobody adopts this package it will vanish from Debian. Do you care for this package being part of Debian? If so, have a look at https://mentors.debian.net/intro-maintainers to understand best practices of maintaining a package. If you are new to Debian packaging, please read the tutorial https://www.debian.org/doc/manuals/debmake-doc/index.en.html and also study how other Debian maintainers package similar packages. Bye Michael signature.asc Description: OpenPGP digital signature
Re: Cron, anacron, cronie, systemd-timers
Hi, On Sun, 7 Jul 2019 19:18:17 +0200, Christian Kastner wrote: >one of the cron maintainers here, and also the cronie maintainer. thanks for the swift answer. >> What is the issue that keeps cronie out of unstable? If it just a matter >> of personpower, or are there technical reasons? If it's just a matter of >> personpower, I'd like to help. > >It's mainly been personpower; however, that is improving. Any additional >help is welcome, of course. > >cronie was uploaded to experimental ages ago, but it's been rotting >there ever since. > >My goal for it was to patch is so that it is as compatible with our >vixie cron (which has quite a few extensions!), to make a transition >from cron to cronie as the main cron daemon as painless as possible. It is good to know where things are going. Would you mind if I created a wiki page with this road map laid out about where Debian's cron world is going? That would, though, only make sense if you could find the time to cross-read it and add omissions and point out factual errors. >Over the past couple of years, I've spent a considerable amount of >effort in converting the format to source format 3.0 (quilt), but I >never quite finished and got distracted with other stuff. Nevertheless, >I completed this conversion in February. I'll push it over the next few >days (I was just waiting for buster to be released before doing anything >drastic). \o/ It is good to know that there is considerable work going on, most of it being on the source code level, which is unfortunately something I cannot be helpful because I'm not a sufficiently good C programmer. I was not even aware that vixie cron and cronie share a common code base that makes such a migration feasible. >My current plan it to move from vixie cron 3.0pl1-134 directly to a >(patched) cronie as soon as possible, so that the default daemon can be >switched to cronie in time the next release. Great! That is good to know. Are you using a mailing list for this effort that I can subscribe to and see where I can be helpful? Or is this mainly a one-man show anyway? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Uninformative hyperlink in O: (package orphaning) bug reports
Hi again, On 09.07.19 09:17, Michael Kesper wrote: > I think this is still starting a little bit negative, maybe like this? > > If nobody adopts this package it will vanish from Debian. > Do you care for this package being part of Debian? ^^^ Maybe change this "package" to software, as I just realized that term is used a little bit too often here and users don't care about "packages" but about using software. > If so, have a look at https://mentors.debian.net/intro-maintainers to > understand best practices of maintaining a package. > If you are new to Debian packaging, please read the tutorial > https://www.debian.org/doc/manuals/debmake-doc/index.en.html and also > study how other Debian maintainers package similar packages. ^^^ Don't know exactly how to phrase that better. Bye Michael signature.asc Description: OpenPGP digital signature
Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)
Hi, On Tue, Jul 09, 2019 at 06:12:00AM +, Niels Thykier wrote: > Instead, I have been toying with the idea of treating d/control as > something we generate. While not entirely novel in itself, once you > start generating d/control, you can do interesting rewrites such as: I've started work in that direction with the debian-xcontrol package a few years ago. The debian/control file is an API that is difficult to extend because it lives at the boundary of an Internet service, so any change basically requires writing adapter code that translates API versions, and the control file is somewhat unversioned (Policy-Version exists, but is not used as a switch). Your proposal of generating some of the fields doesn't affect the API itself, as long as the fields are populated at the right time. We don't have a mechanism for updating the control file at build time, because any part of the build process that would be able to do so is after the part where the control file is consumed for the first time, so it would give an inconsistent view. The way it was generally done with xcontrol was to regenerate the control file and compare whether the generated file was equivalent to the existing one, and fail the build if not. This is a bit fragile, but it's the best we can do here without changing Policy. Your proposal effectively reinvents debian-xcontrol, which wasn't a roaring success because it was more annoying to use than just writing a few lines by hand. It's not a bad idea per se, but it will need more benefit to fly. Simon
Bug#931703: ITP: python-json-logger -- JSON library for Python logging framework
Package: wnpp Severity: wishlist Owner: Ondrej Koblizek * Package name: python-json-logger Version : 0.1.11 Upstream Author : Zakaria Zajac * URL : https://github.com/madzak/python-json-logger * License : BSD-2-Clause Programming Lang: Python Description : JSON library for Python logging framework This library is provided to allow standard Python logging to output log data as json objects. With JSON logs are more readable by machines and there is no need to create custom parsers for syslog type records. I plan to use this package in work. This package does not have unsatisfied dependecies. No other package with similar functionality found. I want maintain this package in DPMT. I have sponsor for first upload.
Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)
On Tue, 09 Jul 2019, Simon Richter wrote: > Your proposal of generating some of the fields doesn't affect the API > itself, as long as the fields are populated at the right time. We don't > have a mechanism for updating the control file at build time, because any > part of the build process that would be able to do so is after the part > where the control file is consumed for the first time, so it would give an > inconsistent view. On a somewhat related topic, I filed this wishlist bug a long time ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597340 The idea is to have implicit substvars at the end of every field so that you can extend the content of the field, and possibly introduce fields that are not present in the original source tree. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#931704: ITP: r-cran-rook -- web server interface for R
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: r-cran-rook Version : 1.1 * URL : https://cran.r-project.org/web/packages/Rook * License : GPL-2 Programming Lang: R Description : web server interface for R Group maintained on https://salsa.debian.org/r-pkg-team/r-cran-rook
Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]
Hello, On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote: > I would go even further and drop the (manual) NEW queue for binary-NEW > packages. > Is there a good reason why new binary packages need manual processing by > the FTP team? Couldn't this be fully automated? The three things the FTP team check[1] are worth doing again for binary-NEW packages. In order: there are often lots of new files in an upload that ends up in binary-NEW so there might be licensing issues; a new binary package means a new member of the binary package namespace; it's good to have a second pair of eyes look at your SONAME bump etc. [1] https://ftp-master.debian.org/REJECT-FAQ.html right at the top -- Sean Whitton signature.asc Description: PGP signature
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hello, On Tue 09 Jul 2019 at 12:16AM +02, Marco d'Itri wrote: > On Jul 07, Jonathan Wiltshire wrote: > >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? >> A: Yes (preferably with other changes, not just a version bump). > Is there any good reason why we still do not have an interface to allow > developers to self-service request a binNMU of a package? > It would solve this and other problems. My impression from talking to wanna-build people is that there are sufficiently many subtleties involved in correctly scheduling binNMUs that costly (in terms of buildd and human time) mistakes would be likely. Unless the interface only let you do very simple binNMU requests of single packages, in which case it might not be worth implementing. -- Sean Whitton signature.asc Description: PGP signature
Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]
On Tue, Jul 09, 2019 at 01:33:49PM +0100, Sean Whitton wrote: > Hello, > > On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote: > > > I would go even further and drop the (manual) NEW queue for binary-NEW > > packages. > > Is there a good reason why new binary packages need manual processing by > > the FTP team? Couldn't this be fully automated? > > The three things the FTP team check[1] are worth doing again for > binary-NEW packages. In order: there are often lots of new files in an > upload that ends up in binary-NEW so there might be licensing issues; a > new binary package means a new member of the binary package namespace; > it's good to have a second pair of eyes look at your SONAME bump etc. > > [1] https://ftp-master.debian.org/REJECT-FAQ.html right at the top > I've always wondered about this. Why is it, then, that binary-NEW still applies if there have been no source files added/removed? (A SONAME bump possibly being necessitated by some change that does not involve adding/removing/renaming source files.) Following on that, what about a package that does add/remove source files (perhaps many) without a SONAME bump or other change that results in a new binary package? It seems like reviewing the package name space on introduction of a new binary package and an additional review of a SONAME bump are good things and the binary-NEW criteria seem to fit. However, the "there might be new source files with licensing issues" does not seem to be a good fit for binary-NEW criteria. Not to say that it matters much in the context of binary-NEW. But if catching potential licensing issues associated with large source changes is in fact something which the FTP team wishes to be able to do, it probably warrants a different filter than "adds a new binary package to the archive" in order to be effective. Regards, -Roberto -- Roberto C. Sánchez
Re: Survey results: git packaging practices / repository format
Hello, On Mon 08 Jul 2019 at 10:37AM +10, Ben Finney wrote: > Russ Allbery writes: > >> Ben Finney writes: >> >> > It may be “bare debian” is meant to cover this; but I don't >> > recognise the comment “requires use of quilt and similar tools” >> > because I've never needed to use Quilt for this. >> >> How do you handle needed changes to the upstream source? > > * Use whatever VCS is published by upstream, to implement the change. > > * Preferably do this in a local fork, because: > > * Rebase the branch as necessary while the change is not yet merged > upstream. > > * Export that change as a series of patches. > > * Those patches become DEP-3 files in ‘debian/patches/’ of the Debian > package. > > So the VCS tools themselves, and the DEP-3 format, completely (?) > obviate the need for any human to touch Quilt. > >> Or do you just never make any changes to the upstream source? > > We are rarely that lucky! Changes to upstream are very often needed. > That's a good reason to maintain a local clone of the upstream VCS > repository. Okay, thanks for this, I think I understand better now. Do you expect some other Debian contributor doing an NMU to clone a copy of upstream's repo and follow a similar workflow, if they want to change the upstream source? Or what? -- Sean Whitton signature.asc Description: PGP signature
Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]
Hello, On Tue 09 Jul 2019 at 08:45AM -04, Roberto C. Sánchez wrote: > Why is it, then, that binary-NEW still applies if there have been no > source files added/removed? (A SONAME bump possibly being necessitated > by some change that does not involve adding/removing/renaming source > files.) For the addition to the binary package namespace to be reviewed. > Following on that, what about a package that does add/remove source > files (perhaps many) without a SONAME bump or other change that results > in a new binary package? Same again. > It seems like reviewing the package name space on introduction of a new > binary package and an additional review of a SONAME bump are good things > and the binary-NEW criteria seem to fit. However, the "there might be > new source files with licensing issues" does not seem to be a good fit > for binary-NEW criteria. Not to say that it matters much in the context > of binary-NEW. But if catching potential licensing issues associated > with large source changes is in fact something which the FTP team wishes > to be able to do, it probably warrants a different filter than "adds a > new binary package to the archive" in order to be effective. The FTP team can't check every single upload, so I guess that at some point someone decided that checking every binary-NEW upload was a sensible compromise. More sophisticated filtering on what gets checked would probably be a good idea, but that would need someone to implement it. -- Sean Whitton signature.asc Description: PGP signature
Re: Uninformative hyperlink in O: (package orphaning) bug reports
To everyone who is working on this problem, thank you :-) On Tue, Jul 09, 2019 at 10:38:14AM +0200, Michael Kesper wrote: > Hi again, > > On 09.07.19 09:17, Michael Kesper wrote: > > I think this is still starting a little bit negative, maybe like this? > > > > If nobody adopts this package it will vanish from Debian. > > Do you care for this package being part of Debian? >^^^ > Maybe change this "package" to software, as I just realized that term > is used a little bit too often here and users don't care about > "packages" but about using software. > The Case of the Disappearing Orphans: Motivations for maintaining to open source software. To be fair, doesn't the QA team (and random acts of kindness) often keep these packages alive? Maybe say something about that, and also how placement into a team provides better support for both the package/software and prospective contributor? Also, in the interest of keeping things positive, is it worth noting that Debian has "an almost magical ability to transform users into developers" (I read that in an article somewhere, years ago)? Thus, maybe package orphaning bug reports can become a more smooth path for situating new contributors into whatever context has the best chance of maximising their long-term motivation and future contributions? > > If so, have a look at https://mentors.debian.net/intro-maintainers to > > understand best practices of maintaining a package. > > If you are new to Debian packaging, please read the tutorial > > https://www.debian.org/doc/manuals/debmake-doc/index.en.html and also > > study how other Debian maintainers package similar packages. > ^^^ > Don't know exactly how to phrase that better. Hm, I'm not sure. Ideally it seems like it would be nice if we could provide a bit more streamlined procedure for "similar packages". Eg: 1. What language is the package implemented in? 2. Is there a team for that? ...URL for intake page for new members to a team, with hello-world packaging example (technical reference) and a link to the git repo of a complex package that is a well-documented high quality model of the team standards. The language-specific Hello-world example should use dh, unless the team generally doesn't (eg: IIRC the Haskell team, et al). The complex package would be a learn-by-example for things like overrides. Contributors will eventually learn how to search & find the resources they need, but I've seen a number of emails expressing how new contributors feel laughed at for not being able to find the relevant information and solutions. Thanks again to everyone who is working on this! Regards, Nicholas P.S. has anyone yet volunteered to help out with that sphinx document conversion project. signature.asc Description: PGP signature
Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)
On Tue, Jul 09, 2019 at 12:24:40PM +0200, Simon Richter wrote: > Your proposal of generating some of the fields doesn't affect the API > itself, as long as the fields are populated at the right time. We don't > have a mechanism for updating the control file at build time, because any > part of the build process that would be able to do so is after the part > where the control file is consumed for the first time, so it would give an > inconsistent view. I used to handle this back when I had the goal of making sure that e2fsprogs from the git repository could successfully build as far back as oldoldstable. The idea was that sometimes people would want to be able to get an updated version of e2fsprogs with all of the bug fixes; and while I'm not willing to manually extract large number of bug fixes and backport them to ancient distro versions of Debian and Ubuntu --- our backport process to Debian Obsolete^H^H^H^H^H^H^H^H Stable is *not* fun for me, as far as I'm concerned), I could at least make sure that modern versions of e2fsprogs could be trivially repackaged for ancient versions of Debian/Ubuntu. The way I did this was to make a default target in debian/rules called debian-files, which would create (or re-create) debian/control from a debian/control.in file. Then to build e2fsprogs on debian, one would first unpack the e2fsprogs' upstream tarfile distribution, or check it out from git, and then run: ./debian/rules dpkg-buildpackage The Debian source package would have the automagically generated debian/control file, so it was fully compatible with all of Debian's package tooling, but it would also have the debian/control.in file, which as far as *I* was concerned was the preferred form for modification. Cheers, - Ted
dev-ref: migration to Sphinx (was Re: Uninformative hyperlink in O: (package orphaning) bug reports)
On Tue, Jul 09, 2019 at 08:15:57AM +0200, Michael Kesper wrote: > > it to developers-reference. (FYI: I am trying to convert > > developers-reference to sphinx now and working on a branch. Any > > volunteer to help this is appreciated.) > Is that branch on salsa? yes, see "#931548 Migration to Sphinx" & thanks, help certainly very welcome! -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Dropping Release and Release.gpg support from APT
So,
we currently have code dealing with falling back from InRelease
to Release{,.gpg} and it's all a bit much IMO. Now that buster
has been released with an InRelease file, the time has IMO come for
us to drop support for the old stuff from APT!
Timeline suggestion
---
now add a warning to apt 1.9.x for repositories w/o InRelease, but
Release{,.gpg}
Aug/Sep turn the warning into an error, overridable with an option (?)
Q1 2020 remove the code
My idea being that we give this a cycle in the Ubuntu 18.10 stable
release before we drop it, so people are ready for it.
Why remove it?
--
* It's annoying UX to have repositories with Release files and the "Ign" lines
* Handling the fallback from InRelease to Release{,.gpg} involves some
abstractions
and logic and the less logic we have in security-relevant file fetching, the
better
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Error when running dh_dwz (actually an error when running dwz(1))
Dear -devel list, Looks like dh_dwz was recently added into debhelper and it is causing some FTBFS on one of my packages. It could be a bug of dwz itself but I'm looking for some help inside Debian first. Please try to build package marisa from its git packaging repo ( https://salsa.debian.org/input-method-team/marisa/commit/f5ff598466266b230d68c9db9f8e31281604b7a6 ). The following error will pop up when dwz is called: = [...] dh_dwz dwz: debian/ruby-marisa/usr/lib/x86_64-linux-gnu/ruby/2.5.0/marisa.so: Found compressed .debug_aranges section, not attempting dwz compression dh_dwz: dwz -q -- debian/ruby-marisa/usr/lib/x86_64-linux- gnu/ruby/2.5.0/marisa.so returned exit code 1 make: *** [debian/rules:30: binary] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 = I don't have much experience of dealing with debugging symbols so any hints would be appreciated. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#931738: ITP: libkainjow-mustache -- Mustache text templates for modern C++
Package: wnpp Severity: wishlist Owner: Kunal Mehta * Package name: libkainjow-mustache Version : 3.2.1 Upstream Author : Kevin Wojniak * URL : https://github.com/kainjow/Mustache * License : BSL-1.0 Programming Lang: C++ Description : Mustache text templates for modern C++ A header-only Mustache template implementation for C++11, with no additional dependencies. This is a new dependency for the latest version of libkiwix, replacing the unmaintained ctpp2 library.
Re: Dropping Release and Release.gpg support from APT
On Tue, Jul 09, 2019 at 08:53:04PM +0200, Julian Andres Klode wrote:
>So,
>
>we currently have code dealing with falling back from InRelease
>to Release{,.gpg} and it's all a bit much IMO. Now that buster
>has been released with an InRelease file, the time has IMO come for
>us to drop support for the old stuff from APT!
>
>Timeline suggestion
>---
>now add a warning to apt 1.9.x for repositories w/o InRelease, but
>Release{,.gpg}
>Aug/Sep turn the warning into an error, overridable with an option (?)
>Q1 2020 remove the code
>
>My idea being that we give this a cycle in the Ubuntu 18.10 stable
>release before we drop it, so people are ready for it.
>
>Why remove it?
>--
>* It's annoying UX to have repositories with Release files and the "Ign" lines
>* Handling the fallback from InRelease to Release{,.gpg} involves some
>abstractions
> and logic and the less logic we have in security-relevant file fetching, the
> better
Can we please slow this kind of change down? We normally look for a
full cycle in Debian stable before making breaking changes. Your
proposed schedule will potentially bite people using stable -
the deprecation warnings will have come and gone.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
Re: Error when running dh_dwz (actually an error when running dwz(1))
Hi Boyuan, > I don't have much experience of dealing with debugging symbols so any hints > would be appreciated. I would also be interested in this from my "Lintian hat" of: https://bugs.debian.org/931632#35 Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: Dropping Release and Release.gpg support from APT
On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> Timeline suggestion
> ---
> now add a warning to apt 1.9.x for repositories w/o InRelease, but
> Release{,.gpg}
> Aug/Sep turn the warning into an error, overridable with an option (?)
> Q1 2020 remove the code
I think this timeline is missing a few items:
File bugs/patches on dak, launchpad, reprepro and other repository
creation tools to drop producing Release{,.gpg} (including all the
ones used by derivatives and by prominent external apt repositories
and apt repository services).
Wait for all of those to be fixed.
Add the warnings.
Wait one Debian release cycle.
Change the warnings to errors.
Wait a bit more.
Remove the code.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: Uninformative hyperlink in O: (package orphaning) bug reports
On Tue, Jul 9, 2019 at 11:24 PM Nicholas D Steeves wrote: > To be fair, doesn't the QA team (and random acts of kindness) often > keep these packages alive? There is no specific team maintaining orphaned packages, other than the set of Debian contributors who are motivated to do that. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#931755: ITP: python-b2-sdk -- Python library to access B2 cloud storage.
Package: wnpp Severity: wishlist Owner: Ondrej Koblizek * Package name: python-b2-sdk Version : 1.0.0 Upstream Author : Backblaze, Inc. * URL : https://github.com/Backblaze/b2-sdk-python * License : MIT Programming Lang: Python Description : Python library to access B2 cloud storage. This repository contains a client library and a few handy utilities for easy access to all of the capabilities of B2 Cloud Storage. This package is a new dependency of the next version of package backblaze-b2. I plan maintain it in DPMT.
Using dh causes configure to be run twice?
In my attempt to convert e2fsprfogs's debian/rules to use dh, I'm running into yet another frustration with dh, which is that it insists on running the configure script twice. The problem is that dh is trying to use build-arch and build-indep: % dh build --no-act debian/rules build-arch debian/rules build-indep And build-arch and build-indep both want to run configure: % dh build-arch --no-act dh_testdir -a dh_update_autotools_config -a debian/rules override_dh_auto_configure debian/rules override_dh_auto_build create-stamp debian/debhelper-build-stamp % dh build-indep --no-act dh_testdir -i dh_update_autotools_config -i debian/rules override_dh_auto_configure debian/rules override_dh_auto_build create-stamp debian/debhelper-build-stamp This seems amazingly non-optimal. I tried to see how other packages work around this misfeature, and I see that openssh just hacks things to make the second dh_auto_configure a no-op: override_dh_auto_configure-arch: dh_auto_configure -Bdebian/build-deb -- $(confflags) ifeq ($(filter noudeb,$(DEB_BUILD_PROFILES)),) dh_auto_configure -Bdebian/build-udeb -- $(confflags_udeb) # Avoid libnsl linkage. Ugh. perl -pi -e 's/ +-lnsl//' debian/build-udeb/config.status cd debian/build-udeb && ./config.status endif override_dh_auto_configure-indep: RLY? That seems like an amazing hack. Is there no other way to work around what appears to be massive mis-design in dh? If the goal is to make moving to dh a mandate, and working on Debian to be fun, we desperately need better documentation on how to use dh for real-world packages, and not just simple, trivial packages :-( - Ted
