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

Laszlo Kajan lkajan at rostlab.org
Tue Aug 7 16:54:49 UTC 2012


Dear Team, Andreas!

Please have a look and upload my updated, Userguide.pdf-less version of hmmer2, if you think it is all right.

You have to use the get-orig-source target (e.g. $ ./debian/rules) to get a repackaged (pdf-less) version of the upstream!

Thank you!

Best regards,

Laszlo

On 07/08/12 16:22, Laszlo Kajan wrote:
> 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
>>
> 
> _______________________________________________
> 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
> 



More information about the Debian-med-packaging mailing list