Re: gengetopt - Is this a +dfsg case?
On Sat, Feb 22, 2014 at 01:37:13PM +0100, Dariusz Dwornikowski wrote:
> On 22 February 2014 12:42, Bart Martens <bartm@debian.org> wrote:
> > On Sat, Feb 22, 2014 at 11:58:39AM +0100, Dariusz Dwornikowski wrote:
> >> Hi,
> >>
> >> I am maintaining a great package - zmap. It depends, for building
> >> only, on gengetopt [1] to generate main.c stub for command line
> >> arguments handling. However gengetopt was removed from testing due to
> >> [2], it is only in unstable for now. This blocks new zmap versions
> >> going to testing. I already contacted the maintainer some time ago
> >> asking whether it would be fixed or he needs some help but he has not
> >> responded yet.
> >> [1] http://packages.qa.debian.org/g/gengetopt.html
> >> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708880
> >>
> >> My question is, how this situation should be handled, should these
> >> manuals be removed and package uploaded as dfsg ?
> >
> > I suggest to add a well-tested patch to the bug, and tag the bug "patch".
>
> Sorry, quite new to this. Patch what ? A source package, an orig
> tarball ? Along with the debian/ directory ? Should the patch remove
> the files and change the changelog to add dfsg tag ?
I meant a patch https://www.google.com/search?q=diff+patch containing all the
changes to the gengetopt source package https://wiki.debian.org/SourcePackage
you would apply if you would be the gengetopt package maintainer to fix the bug
holding back zmap. One possible set of changes would be what you described
("should these manuals be removed and package uploaded as dfsg"). Another
option would be to move the package to section non-free, but then zmap would
need to move to section contrib, and that's something you may not prefer.
Regards,
Bart Martens
Reply to: