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 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
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014021456.ga25...@master.debian.org
Re: gengetopt - Is this a +dfsg case?
On Sat, Feb 22, 2014 at 11:58:39AM +0100, Dariusz Dwornikowski wrote: > My question is, how this situation should be handled, should these > manuals be removed and package uploaded as dfsg ? Or the best is to > wait for upstream to change the licence. If you don't need this package in testing you can wait. Otherwise, you can't. That's simple. -- WBR, wRAR signature.asc Description: Digital signature
Re: gengetopt - Is this a +dfsg case?
On 22 February 2014 12:42, Bart Martens 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 ? > >> Or the best is to wait for upstream to change the licence. > > Waiting is usually not the best approach. Heh ok. > >> >> I am asking out of curiosity, and to know how to handle such >> situations in the future, I do not want hijack the package from >> Alessio. > > How to handle such situations in the future depends on the situations. :-) In > this case I suggest ... see above. > > Regards, > > Bart Martens -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGnkundPLgMUyyim=9=ubwqdxqtbsjfc_3440kye2__rlrd...@mail.gmail.com
Re: gengetopt - Is this a +dfsg case?
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". > Or the best is to wait for upstream to change the licence. Waiting is usually not the best approach. > > I am asking out of curiosity, and to know how to handle such > situations in the future, I do not want hijack the package from > Alessio. How to handle such situations in the future depends on the situations. :-) In this case I suggest ... see above. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140222114258.gb3...@master.debian.org
gengetopt - Is this a +dfsg case?
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. My question is, how this situation should be handled, should these manuals be removed and package uploaded as dfsg ? Or the best is to wait for upstream to change the licence. I am asking out of curiosity, and to know how to handle such situations in the future, I do not want hijack the package from Alessio. [1] http://packages.qa.debian.org/g/gengetopt.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708880 -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cagnkund+q2swd_dxq_1prqz9y-ewstgyc2yr2qqah8xttrr...@mail.gmail.com
