gengetopt - Is this a +dfsg case?

2014-02-22 Thread Dariusz Dwornikowski
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

Re: gengetopt - Is this a +dfsg case?

2014-02-22 Thread Bart Martens
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

Re: gengetopt - Is this a +dfsg case?

2014-02-22 Thread Dariusz Dwornikowski
On 22 February 2014 12:42, Bart Martens ba...@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.

Re: gengetopt - Is this a +dfsg case?

2014-02-22 Thread Andrey Rahmatullin
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

Re: gengetopt - Is this a +dfsg case?

2014-02-22 Thread Bart Martens
On Sat, Feb 22, 2014 at 01:37:13PM +0100, Dariusz Dwornikowski wrote: On 22 February 2014 12:42, Bart Martens ba...@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