[Debian-med-packaging] hmmer2_2.3.2-6_amd64.changes REJECTED

[Laszlo Kajan]

Ok, I like what Steffen writes, so this is what I will do:

* Repack hmmer2 /without/ Userguide.pdf and (ask for) upload again - I need this relatively soon.

* Consider repacking hmmer (version 3) from the svn repo. This is not urgent for me right now, so this will be delayed, someone else may pick
this up.

What will FTP masters do with hmmer (version 3) now? It is in main, but does not comply with the DFSG...

Best regards,

Laszlo

On 07/08/12 16:13, Steffen Möller wrote:
> On 08/07/2012 02:05 PM, Laszlo Kajan wrote:
>> Hello Andreas and team!
>>
>> So ok, both hmmer2 and hmmer (3.0, in main) have this problem. Apparently this slipped through before, but not now.
>>
>> There are sources for Userguide.pdf in [1].
>>
>> My understanding of the policy [2] is that in case the source package contains Userguide.pdf without sources, the source pack can not be in
>> main. Is this correct?
> Can you truly build the userguide from there? Then it would be pretty
> cool if you could put some extra effort in the generation of the source
> tree and get the source directly from svn.
> 
>> I am going to email [3] and ask for the inclusion of the Userguide.pdf source in the tarball they distribute.
> Good luck. I would just take it from svn ...
>>
>> But for now, what should I do?:
>>
>> * Repack the source of hmmer and hmmer2 without Userguide.pdf?
> hmmer2 is mostly historic now, anyway. So I would just let it go
> without. Anybody truly interested in it should dive into the source.
> Been there. For hmmer3, I suggest to go for the svn.
>> [1] https://svn.janelia.org/eddylab/eddys/src/hmmer
>> [2] http://www.debian.org/doc/debian-policy/ch-archive.html
>> [3] hmmer at janelia.hhmi.org
>>
>> On 28/07/12 16:48, Andreas Tille wrote:
>>> On Sat, Jul 28, 2012 at 03:42:55PM +0200, Steffen Möller wrote:
>>>> Back at the time I had not know that we can have
>>>> free and non-free stuff mixed with the same source package.
>>> Hmmm, are you sure?  IMHO it is just the source that should not contain
>>> any non-free stuff.  How can a source containing only free stuff
>>> generate a non-free binary?  Any links?
> non-free-ness is about compliance with DFSG. The software license is
> only a part of what freeness is about. If we cannot modify bits because
> we do not have the tools, then the package is not free as in DFSG either.
> 
> One easy example are the virtual binaries I had done for BOINC to help
> with dependencies for CUDA gpu programming. It depends on nvidia stuff
> that is non-free, rendering the binary contrib.
> 
> Cheers,
> 
> Steffen
> 
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>