Re: Please check new version of tophat
Hi Dominique, On Sun, Oct 05, 2014 at 09:12:13PM -0400, Dominique Belhachemi wrote: On Sun, Oct 5, 2014 at 7:59 PM, Charles Plessy ple...@debian.org wrote: Le Sun, Oct 05, 2014 at 01:21:57PM -0400, Dominique Belhachemi a écrit : Based on the changelog I would say that you can skip the 2.0.13 release. TopHat 2.0.13 release 10/2/2014 Version 2.0.13 is a maintenance release with the following changes: removed SAMtools as an external dependency in order to avoid incompatibility issues with recent and future changes of SAMtools and its code library (an older, stable SAMtools version is now packaged with TopHat) fixed a few code compatibility issues when compiling on OSX 10.9 Even if the discussion went further one remark: I think this is not the correct attitude. If upstream had reasons to do a new release and is shipping a copy of an older samtools version we should at least find out the reasons for this since it might also mean that 2.0.12 is broken. Do we have some connection to upstream to sort this out in a sensible matter? I followed the 'Testing the installation' instructions on http://ccb.jhu.edu/software/tophat/tutorial.shtml . wget http://ccb.jhu.edu/software/tophat/downloads/test_data.tar.gz tar zxvf test_data.tar.gz cd test_data tophat -r 20 test_ref reads_1.fq reads_2.fq I am immediately running into the version parser issue. [2014-10-05 20:51:46] Beginning TopHat run (v2.0.12) --- [2014-10-05 20:51:46] Checking for Bowtie Bowtie version: 2.2.3.0 [2014-10-05 20:51:46] Checking for Samtools ... After a quickdirty patch ... --- /usr/bin/tophat2014-09-25 02:29:36.0 -0400 +++ /usr/bin/tophat.patch2014-10-05 20:45:55.900444000 -0400 @@ -1537,10 +1537,10 @@ samtools_out = proc.communicate()[1] ... I am getting the same results as with samtools 0.1.19: tophat -r 20 test_ref reads_1.fq reads_2.fq [2014-10-05 20:55:06] Beginning TopHat run (v2.0.12) --- [2014-10-05 20:55:06] Checking for Bowtie Bowtie version: 2.2.3.0 ... --- [2014-10-05 20:55:07] A summary of the alignment counts can be found in ./tophat_out/align_summary.txt Any idea where to find upstreams test suite? We definitely should contact upstream and we also should ship a test suite. If there is no such thing as an upstream official development test suite we should probably provide the test you did above (including the test data) to enable autopkgtesting. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006072835.gd10...@an3as.eu
Re: Updating the fis-gtm package to V6.2-000
Hi Bhaskar, On Thu, 2 Oct 2014, Bhaskar, K.S wrote: [KSB] Those *openssl* files are versions of the reference implementation of the plugin compiled with #include, #if, etc. configured to call call OpenSSL. They are not actually linked to OpenSSL or other libraries - linking happens dynamically. Oh, come on, why should it matter whether you are linking at compile time or at run time? In both cases the result is a combined binary. kbhaskar@bhaskark:~$ ls -l /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/lib*crypt* /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_AES256CFB.so -r-xr-xr-x 1 root root 40056 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_BLOWFISHCFB.so lrwxrwxrwx 1 root root 33 Sep 18 15:45 kbhaskar@bhaskark:~$ Yes and when you look with ldd at libgtmcrypt_openssl* you see that libssl is needed. Most of the discussion of license interaction between copyleft and non-copyleft licenses at en.wikipedia.org/wiki/GNU_General_Public_License pertain to software used under non-copyleft licenses requesting services from (I deliberately avoid the use of linking to) software used under non-copyleft licenses. In this case, we have the reverse - a copyleft software (GT.M) requesting services from non-copyleft software (OpenSSL). Regardless, it appears that there are different schools of thought on this. Hmm, so why do you think that almost all GPL software that links to OpenSSL has a special OpenSSL exception? I am afraid such discussions have been made frequently ... * Include a statement in the README that says something like: As dynamic linking by the reference implementation of the plugin to software such as cryptographic libraries that are released under non-copyleft licenses is not considered to create a derivative work, there is no interaction between the license used for GT.M and those of cryptographic libraries. * Remove any claim of copyright from the reference implementation of the plugin (i.e., place the reference implementation in the public domain). * Remove the precompiled versions of the reference implementation of the plugin from the distribution and include only the source of the plugin (as I noted earlier, the GT.M binary distribution includes source code for the reference implementation of the plugin). Use the post-install script to compile the reference implementation of the plugin. Thorsten, please let me know what you think. I don't understand why you don't want to go the easy way? As you consider to remove the license in 2), why don't you just add the exception to your license text? Otherwise the last proposal would be fine. Thorsten
Re: Updating the fis-gtm package to V6.2-000
Thorsten -- I'll digest your comments in detail once I get out of conference calls and meetings, but the short answer to changing the license is that running anything through Legal will take more time than we have available. Regards -- Bhaskar On 10/06/2014 07:55 AM, Thorsten Alteholz wrote: Hi Bhaskar, On Thu, 2 Oct 2014, Bhaskar, K.S wrote: [KSB] Those *openssl* files are versions of the reference implementation of the plugin compiled with #include, #if, etc. configured to call call OpenSSL. They are not actually linked to OpenSSL or other libraries - linking happens dynamically. Oh, come on, why should it matter whether you are linking at compile time or at run time? In both cases the result is a combined binary. kbhaskar@bhaskark:~$ ls -l /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/lib*crypt* /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_AES256CFB.so -r-xr-xr-x 1 root root 40056 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_BLOWFISHCFB.so lrwxrwxrwx 1 root root33 Sep 18 15:45 kbhaskar@bhaskark:~$ Yes and when you look with ldd at libgtmcrypt_openssl* you see that libssl is needed. Most of the discussion of license interaction between copyleft and non-copyleft licenses at en.wikipedia.org/wiki/GNU_General_Public_License pertain to software used under non-copyleft licenses requesting services from (I deliberately avoid the use of linking to) software used under non-copyleft licenses. In this case, we have the reverse - a copyleft software (GT.M) requesting services from non-copyleft software (OpenSSL). Regardless, it appears that there are different schools of thought on this. Hmm, so why do you think that almost all GPL software that links to OpenSSL has a special OpenSSL exception? I am afraid such discussions have been made frequently ... * Include a statement in the README that says something like: As dynamic linking by the reference implementation of the plugin to software such as cryptographic libraries that are released under non-copyleft licenses is not considered to create a derivative work, there is no interaction between the license used for GT.M and those of cryptographic libraries. * Remove any claim of copyright from the reference implementation of the plugin (i.e., place the reference implementation in the public domain). * Remove the precompiled versions of the reference implementation of the plugin from the distribution and include only the source of the plugin (as I noted earlier, the GT.M binary distribution includes source code for the reference implementation of the plugin). Use the post-install script to compile the reference implementation of the plugin. Thorsten, please let me know what you think. I don't understand why you don't want to go the easy way? As you consider to remove the license in 2), why don't you just add the exception to your license text? Otherwise the last proposal would be fine. Thorsten -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543299c8.3060...@fisglobal.com
Re: Error while loading shared libraries
Hi Andreas it might be sensible if you commit your work to a repository to let others have a look. Otherwise its hard to do some speculation. You're right. I didn't committed my work before because the Git repository of fw4spl wasn't ready. But now it is, and I've just pushed my package on Alioth [1]. Best regards, Corentin [1] https://alioth.debian.org/anonscm/git/debian-med/fw4spl.git -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432ac5e.3000...@gmail.com
Re: Updating the fis-gtm package to V6.2-000
On 10/06/2014 07:55 AM, Thorsten Alteholz wrote: Hi Bhaskar, On Thu, 2 Oct 2014, Bhaskar, K.S wrote: [KSB] Those *openssl* files are versions of the reference implementation of the plugin compiled with #include, #if, etc. configured to call call OpenSSL. They are not actually linked to OpenSSL or other libraries - linking happens dynamically. [KSB2] …snip… * Include a statement in the README that says something like: As dynamic linking by the reference implementation of the plugin to software such as cryptographic libraries that are released under non-copyleft licenses is not considered to create a derivative work, there is no interaction between the license used for GT.M and those of cryptographic libraries. * Remove any claim of copyright from the reference implementation of the plugin (i.e., place the reference implementation in the public domain). * Remove the precompiled versions of the reference implementation of the plugin from the distribution and include only the source of the plugin (as I noted earlier, the GT.M binary distribution includes source code for the reference implementation of the plugin). Use the post-install script to compile the reference implementation of the plugin. Thorsten, please let me know what you think. I don't understand why you don't want to go the easy way? As you consider to remove the license in 2), why don't you just add the exception to your license text? Otherwise the last proposal would be fine. [KSB2] Adding a license exception to the COPYING file would probably require me to go through Legal and that may add delays that increase the risk of pushing us past the deadline. However, the reference implementation of the plugin is just a minuscule part of GT.M, and removing a claim of copyright specifically to the reference implementation of the plugin is something that we can do easily without requiring approval. Would removing the claim of copyright to the reference implementation of the plugin solve the issue? Thanks. Regards -- Bhaskar Thorsten -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432b145.1030...@fisglobal.com
Question about packaging a nonfree package ( no ITP yet )
Hi all, I have just created an ITP for a software package called gubbins (ITP: 764232). I am in direct contact with the upstream author of gubbins (sit next to him really). Gubbins has a dependency on a piece of software called Fastml. Fastml is not free. Actually is published under no license. It has copyright and a note saying that anyone wishing to make changes to the code needs to contact the author. For gubbins to work, Fastml needed to be changed. Gubbins upstream has contacted the author of Fastml. The author was happy for the code to be changed, but has stated that he doesn't wish the code to be published under any kind of free license (actually under any kind of licence). I was approaching the problem of packaging gubbins in the most sensible way I found. Package Fastml, then package gubbins and state Fastml as a gubbins dependency. I would have to maintain two more packages, but hey... Now the question is, what is the best way to go about this? Do I package Fastml as non-free? If so, can you point me to the debian policy and procedure on this? Should I package it in another way? Also, the idea is to keep Fastml as it is originally and patch the changes needed to it at build time. Do you see any problems with this? Are there more things I should be concerned about? Kind regards, Jorge
Re: Question about packaging a nonfree package ( no ITP yet )
Hi Jorge, On Mon, Oct 06, 2014 at 04:48:28PM +0100, Jorge Sebastião Soares wrote: I am in direct contact with the upstream author of gubbins (sit next to him really). Gubbins has a dependency on a piece of software called Fastml. Fastml is not free. Actually is published under no license. This sucks. It has copyright and a note saying that anyone wishing to make changes to the code needs to contact the author. For gubbins to work, Fastml needed to be changed. Gubbins upstream has contacted the author of Fastml. The author was happy for the code to be changed, but has stated that he doesn't wish the code to be published under any kind of free license (actually under any kind of licence). I was approaching the problem of packaging gubbins in the most sensible way I found. Package Fastml, then package gubbins and state Fastml as a gubbins dependency. I would have to maintain two more packages, but hey... Now the question is, what is the best way to go about this? As far as I know a package with no license at all is simply not redistributable ... since it is lacking the permission to be distributed (even in non-free). May be there are alternatives with the same functionality or we try to convince the author to pick at least any license (also for his own safety!) - preferably a free one. Just for the name similarity (*ML): We just managed to convince an author of some frequently used, long standing non-free license to pick a free one[1]. Kind regards Andreas. [1] https://wiki.debian.org/DebianMed/Meeting/Southport2012/ePetition_Phylip -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006161449.ga25...@an3as.eu
Re: Question about packaging a nonfree package ( no ITP yet )
Hi Andreas, Good hearing from you. On Mon, Oct 6, 2014 at 5:14 PM, Andreas Tille andr...@an3as.eu wrote: Hi Jorge, On Mon, Oct 06, 2014 at 04:48:28PM +0100, Jorge Sebastião Soares wrote: I am in direct contact with the upstream author of gubbins (sit next to him really). Gubbins has a dependency on a piece of software called Fastml. Fastml is not free. Actually is published under no license. This sucks. Doesn't it just... It has copyright and a note saying that anyone wishing to make changes to the code needs to contact the author. For gubbins to work, Fastml needed to be changed. Gubbins upstream has contacted the author of Fastml. The author was happy for the code to be changed, but has stated that he doesn't wish the code to be published under any kind of free license (actually under any kind of licence). I was approaching the problem of packaging gubbins in the most sensible way I found. Package Fastml, then package gubbins and state Fastml as a gubbins dependency. I would have to maintain two more packages, but hey... Now the question is, what is the best way to go about this? As far as I know a package with no license at all is simply not redistributable ... since it is lacking the permission to be distributed (even in non-free). I now see how much it sucks... May be there are alternatives with the same functionality or we try to convince the author to pick at least any license (also for his own safety!) - preferably a free one. I had a chat with gubbins upstream and I was told not to contact the Fastml author. :( Nonetheless I managed to convince gubbins upstream to ask the Fastml author about a license. Reply: He doesn't care about licenses at all. Let me have a chat around the office again tomorrow. See if we can get the guy to pick something. It could even be Expat. If he is afraid that big evil corporations will make money from his code releasing it as GPL#. (this was hinted in the conversation I had with gubbins upstream, but not sure this was what the Fastml author had in mind) Just for the name similarity (*ML): We just managed to convince an author of some frequently used, long standing non-free license to pick a free one[1]. Well done on the Phylip petition. I did sign it... I'm happy I did. Speak soon, Jorge
Re: Question about packaging a nonfree package ( no ITP yet )
Hi, On Mon, Oct 06, 2014 at 05:36:44PM +0100, Jorge Sebastião Soares wrote: Good hearing from you. :-) ditto As far as I know a package with no license at all is simply not redistributable ... since it is lacking the permission to be distributed (even in non-free). I now see how much it sucks... May be there are alternatives with the same functionality or we try to convince the author to pick at least any license (also for his own safety!) - preferably a free one. I had a chat with gubbins upstream and I was told not to contact the Fastml author. :( I admit I'm not a fan of I was told statements. Nobody should tell a grown up what he should do in free software aspects. Nonetheless I managed to convince gubbins upstream to ask the Fastml author about a license. Reply: He doesn't care about licenses at all. Let me have a chat around the office again tomorrow. See if we can get the guy to pick something. It could even be Expat. If he is afraid that big evil corporations will make money from his code releasing it as GPL#. (this was hinted in the conversation I had with gubbins upstream, but not sure this was what the Fastml author had in mind) You might like to see for Joe Felsenstein phylip on the Debian Med mailing list to seek for previous occurances of this argument. BTW, no license at all makes you even less safe against big evil corporation. Just for the name similarity (*ML): We just managed to convince an author of some frequently used, long standing non-free license to pick a free one[1]. Well done on the Phylip petition. I did sign it... I'm happy I did. Finally it would have worked even without the petition as far as I can say when the copyright owners realised that they made less not even a three digit number of $ income per year ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006181153.gb25...@an3as.eu
