Re: VirusSeeker: RepeatMasker missed in dependencies (Was: VirusSeeker - sorting the Downloads section)
> On Thu, May 07, 2020 at 11:24:00PM +0200, Étienne Mollier wrote: > > > > At some point, I wondered if it would be possible to get > > RepeatMasker into "non-free", and having VirusSeeker into > > "contrib" then, but I'm not sure that this is legally doable > > since VirusSeeker is GPL. Le Thu, May 07, 2020 at 11:39:18PM +0200, Andreas Tille a écrit : > > Hmmm, I do not remember but non-free is ugly for several technical > reasons (no autobuilders, no autopkgtests, no QA checks etc.) Thus > the first thing I do is contacting upstream to consider changing > their license. Would you mind doing so? If yes, I would consider > mentioning our COVID-19 sprint and that a free license would support > us in our fight against the pandemic. Hi all, +1 in principle, but I note that RepeatMasker has TRF (Tandem Repeat Finder) in its dependencies, which is also non-free... http://tandem.bu.edu/trf/trf.license.html Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: VirusSeeker: RepeatMasker missed in dependencies (Was: VirusSeeker - sorting the Downloads section)
Hi Étienne, On Thu, May 07, 2020 at 11:24:00PM +0200, Étienne Mollier wrote: > I've been quietly chiseling the packaging of virusseeker-virome, > but I missed the proper RepeatMasker dependency in the initial > list; Debian provides a few packages related to that software, > and I mistakenly thought it was available already. For > reference, it is the software available at: > > http://www.repeatmasker.org/RMDownload.html Thanks a lot for checking. > Unfortunately, I understand that it is licensed under OSL 2.1, > and that this license does not look DFSG compliant, nor seems > compatible with the GPL: > > > https://wiki.debian.org/DFSGLicenses#Open_Software_License_.28OSL.29_v1.1 > https://www.gnu.org/licenses/license-list.html#OSL > > At some point, I wondered if it would be possible to get > RepeatMasker into "non-free", and having VirusSeeker into > "contrib" then, but I'm not sure that this is legally doable > since VirusSeeker is GPL. > > Have you already met similar situation in the past ? > If so, how has it been dealt with ? Hmmm, I do not remember but non-free is ugly for several technical reasons (no autobuilders, no autopkgtests, no QA checks etc.) Thus the first thing I do is contacting upstream to consider changing their license. Would you mind doing so? If yes, I would consider mentioning our COVID-19 sprint and that a free license would support us in our fight against the pandemic. Kind regards Andreas. > mer...@debian.org, on 2020-04-10 07:40:42 +0300: > > 1. Replace hard-coded database paths with environment variables, say, > > VIRUSSEEKER_NCBI_NT. Then prior to running the VirusSeeker the user > > would need to download the databases and set these environment variables > > to their locations. > > > > 2. Make their paths configurable via a configuration file (under /etc, > > possibly) listing paths for the databases. After installing the Debian > > package, the user would have to edit this configuration file to point to > > the database locations. > > Hi Andrius, > > Thank you for your thoughts, even if I'm a bit late. Reading > through the script, even using environment variables, there is > a quite big share of hard-coded paths, so would probably attempt > to contact upstream in any case. > > Kind Regards, > -- > Étienne Mollier > Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d > Help find cures against the Covid-19 ! Give CPU cycles: > * Rosetta@home: https://boinc.bakerlab.org/rosetta/ > * Folding@home: https://foldingathome.org/ -- http://fam-tille.de
Re: Packaging libsis-jhdf5-java -- help needed
Hi again, Le 07/05/2020 à 16:26, Andreas Tille a écrit : > On Thu, May 07, 2020 at 09:43:11AM +0200, Andreas Tille wrote: >> I also >> think that observing autobuilders and possibly fix issues there in a >> subsequent upload with your additional changes could be a good idea. > > As expected there is some more work to do which escaped my sponsors > view: See bug #959955. :-) > > Kind regards > > Andreas. > I have just uploaded the new version 19.04.0+dfsg-2 of libsis-jhdf5-java to Salsa: to close bug #959955, I have changed the name of the .so that is generated to avoid name collisions. All tests from build-time and autopkgtest testsuite are passing. All the best, Pierre
VirusSeeker: RepeatMasker missed in dependencies (Was: VirusSeeker - sorting the Downloads section)
Hi Everyone, I've been quietly chiseling the packaging of virusseeker-virome, but I missed the proper RepeatMasker dependency in the initial list; Debian provides a few packages related to that software, and I mistakenly thought it was available already. For reference, it is the software available at: http://www.repeatmasker.org/RMDownload.html Unfortunately, I understand that it is licensed under OSL 2.1, and that this license does not look DFSG compliant, nor seems compatible with the GPL: https://wiki.debian.org/DFSGLicenses#Open_Software_License_.28OSL.29_v1.1 https://www.gnu.org/licenses/license-list.html#OSL At some point, I wondered if it would be possible to get RepeatMasker into "non-free", and having VirusSeeker into "contrib" then, but I'm not sure that this is legally doable since VirusSeeker is GPL. Have you already met similar situation in the past ? If so, how has it been dealt with ? mer...@debian.org, on 2020-04-10 07:40:42 +0300: > 1. Replace hard-coded database paths with environment variables, say, > VIRUSSEEKER_NCBI_NT. Then prior to running the VirusSeeker the user > would need to download the databases and set these environment variables > to their locations. > > 2. Make their paths configurable via a configuration file (under /etc, > possibly) listing paths for the databases. After installing the Debian > package, the user would have to edit this configuration file to point to > the database locations. Hi Andrius, Thank you for your thoughts, even if I'm a bit late. Reading through the script, even using environment variables, there is a quite big share of hard-coded paths, so would probably attempt to contact upstream in any case. Kind Regards, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: my plans about deep learning framework
Hi Mo, Mo Zhou, on 2020-05-07 14:15:15 +: > [[[ ROCm flavor of DL frameworks ]]] > > I still don't know how on earth can the ROCm software stack work with > the opensource `amdkfd` kernel driver (debian has already enabled that > driver for our kernel packages) instead of the proprietary version of > `amdkfd`. > > -- I'm willing to maintain the ROCm software stack as long as it is > able to work on a Debian system without non-free components. > There is a "ROCm Team" on salsa. > -- the answer to the above question is the only blocker for me to > make further progress about ROCm. I believe that I may be able to give a hand with this stack, although I'm still kind of green regarding Debian packaging. I don't expect it to be an easy task, but will see if I can help here. I just opened a request on Salsa to access the "AMD Yes! ROCm Team" group. Kind Regards, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: undefined vdb_mbed functions in ncbi-vdb2 library - ran out of ideas
Andreas Tille writes: > Just want to repeat that I currently have no spare cycles for this. Understood. > Do you want to express we should package ncbi-vdb Git HEAD rather than > a release tarball? No, I meant that the work in progress on salsa, based on an existing release tarball, just needs a little more tweaking. Sorry if that was unclear. > I also need to say that I'm afraid I do not understand > your second paragraph. Please compare (1) https://salsa.debian.org/med-team/ncbi-vdb/-/tree/upstream (2) https://salsa.debian.org/med-team/sra-sdk/-/tree/upstream (3) https://salsa.debian.org/med-team/sra-sdk/-/tree/bdf0081d3363e836e27474f0898a55f3ca7562f3 (2) should closely resemble (3), not (1). > I'd be super happy if you would find some time to turn your hints into > code in salsa. ;-) I'll try to find time this weekend. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: undefined vdb_mbed functions in ncbi-vdb2 library - ran out of ideas
Hi Aaron, On Thu, May 07, 2020 at 10:32:09AM -0400, Aaron M. Ucko wrote: > Andreas Tille writes: > > > H, I'm not sure whether vdb came with the original. I remember I > > had to patch some stuff (specifically droping the 'vbd_' prefix). But > > I do not remember and I have no spare cycles currently to dive into > > this. > > The git HEAD of ncbi-vdb looks mostly good to go at this point, and > AFAICT simply needs to account for the fact that sra-sdk needs both > interfaces/vfs/services-priv.h and libs/vfs/services-priv.h, neither of > which can substitute for the other. I'd suggest installing the latter > as services-priv-internal.h and patching sra-sdk's > tools/util/validate-names4.c accordingly. > > Meanwhile, it looks like sra-sdk's latest "2.10.4+dfsg" upstream tree > wound up as an accidental copy of ncbi-vdb. Just want to repeat that I currently have no spare cycles for this. Do you want to express we should package ncbi-vdb Git HEAD rather than a release tarball? I also need to say that I'm afraid I do not understand your second paragraph. I'd be super happy if you would find some time to turn your hints into code in salsa. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: license problem about nvidia's neural network library (cuDNN)
Hi Rebecca, I have completely forgot the threads I opened in the past. However, the cuDNN eula had been revised many times since the last discussion. The latest revision was made on Nov 2019. That means a re-evaluation is needed. On Thu, May 07, 2020 at 05:19:03PM +0100, Rebecca N. Palmer wrote: > Previous discussions: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862524 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887728 >
Re: license problem about nvidia's neural network library (cuDNN)
Previous discussions: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862524 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887728
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas, Le 07/05/2020 à 16:26, Andreas Tille a écrit : > On Thu, May 07, 2020 at 09:43:11AM +0200, Andreas Tille wrote: >> I also >> think that observing autobuilders and possibly fix issues there in a >> subsequent upload with your additional changes could be a good idea. > > As expected there is some more work to do which escaped my sponsors > view: See bug #959955. :-) > > Kind regards > > Andreas. > Wow, I had not seen that, thanks for showing me. I will prepare a new upload very soon to fix the issue. Best regards, Pierre
license problem about nvidia's neural network library (cuDNN)
Hello guys, I mentioned cudnn in the other mail about my "plans for deep learning frameworks". In this separate mail I'm talking about the licensing issue about cudnn, the most important CUDA library for neural networks. https://docs.nvidia.com/deeplearning/sdk/cudnn-sla/index.html Do you have any idea whether this can be uploaded to our non-free archive? I HATE NVIDIA. Reading that license makes me painful. I cannot understand whether on earth can we redistribute cuDNN through our non-free archive. Another solution which came up in my mind, for bypassing the license issue is to create a meta package `cudnn-installer` with postinst hooks that downloads and manually installs the library blobs.
Re: ncbi-igblast - compiles so much redundant general NCBI bits - wrong source tree?
Steffen Möller writes: > This ftp://ftp.ncbi.nih.gov/blast/executables/igblast/release/1.15.0/ is > where I got the source tree. It is not the case that igblast also occurs > elsewhere, say together with the regular NCBI tools, and I am not aware > of it. ncbi-blast+ and ncbi-igblast are both offshoots of the unpackaged NCBI C++ Toolkit, albeit with their own release cycles. I'd suggest building the helper libraries statically here, by changing --with-dll to --without-dll. (The default is somewhere in between, producing PIC static libraries, whereas you want PIE if anything.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
my plans about deep learning framework
Hi Science and Med Team, I maintain lots of packages related to deep learning and machine learning, but I think I'm reaching an upperbound. So I'm clearly stating my future plans about deep learning packages for Debian, lest potential contributors hesitate to step in and help. Med team has been added in the recipient list due to their increasing interest in deep/machine learning, and the coronavirus related works. [[[ DL frameworks ]]] My emergy only allows me to cover one modern deep learning framework -- pytorch. I'm very likely unable to help the tensorflow maintenance once bazel gets ready in our archive. I can keep maintaining some tensorflow dependencies since some of them are quite stable. -- I'll only maintain caffe and pytorch. Potential contributors should feel free to deal with any other DL frameworks. -- I can provide suggestions, but I'll not provide code. [[[ CUDA flavor of DL frameworks ]]] Currently I only have the plan to do the cpu version of pytorch (and caffe). The cuda version of caffe had been removed by me because I hate dealing with cuda related stuff in the debian archive. -- I'll not package the most important CUDA library -- cuDNN -- for deep learning frameworks. We need other volunteers for this. -- If someone is willing to maintain cuDNN, I can try to package the cuda version of pytorch [[[ ROCm flavor of DL frameworks ]]] I still don't know how on earth can the ROCm software stack work with the opensource `amdkfd` kernel driver (debian has already enabled that driver for our kernel packages) instead of the proprietary version of `amdkfd`. -- I'm willing to maintain the ROCm software stack as long as it is able to work on a Debian system without non-free components. There is a "ROCm Team" on salsa. -- the answer to the above question is the only blocker for me to make further progress about ROCm. [[[ upper layer applications ]]] -- I'll not maintain any upper layer applications built upon any deep learning framework. -- But I'll maintain ML-Policy to guide the maintenance of these packages. -- I may maintain some toy dataset packages for testing DL framework sanity e.g. src:dataset-fashion-mnist (already in testing and sid) --- These are all things I can do, and I'm not a monoplic maintainer. Volunteers are always welcome, and helps are always appreciated!
Re: undefined vdb_mbed functions in ncbi-vdb2 library - ran out of ideas
Andreas Tille writes: > H, I'm not sure whether vdb came with the original. I remember I > had to patch some stuff (specifically droping the 'vbd_' prefix). But > I do not remember and I have no spare cycles currently to dive into > this. The git HEAD of ncbi-vdb looks mostly good to go at this point, and AFAICT simply needs to account for the fact that sra-sdk needs both interfaces/vfs/services-priv.h and libs/vfs/services-priv.h, neither of which can substitute for the other. I'd suggest installing the latter as services-priv-internal.h and patching sra-sdk's tools/util/validate-names4.c accordingly. Meanwhile, it looks like sra-sdk's latest "2.10.4+dfsg" upstream tree wound up as an accidental copy of ncbi-vdb. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Packaging libsis-jhdf5-java -- help needed
On Thu, May 07, 2020 at 09:43:11AM +0200, Andreas Tille wrote: > I also > think that observing autobuilders and possibly fix issues there in a > subsequent upload with your additional changes could be a good idea. As expected there is some more work to do which escaped my sponsors view: See bug #959955. :-) Kind regards Andreas. -- http://fam-tille.de
Re: RFS: ncbi-entrez-direct
My thanks to both of you! Please feel free to copy me on future requests involving ncbi-entrez-direct, since I don't follow this list closely. (Likewise for ncbi-tools6, though that doesn't need much attention nowadays, and ncbi-blast+, though Olivier's also familiar with that package and has been doing a great job with it.) Meanwhile, I know newer upstream releases are available; I have local work in progress to catch up, and have rebased it on top of this upload. -- Aaron Andreas Tille writes: > Hi Pranav, > > package uploaded. Thanks a lot for your work, Andreas. > > On Wed, May 06, 2020 at 07:23:08PM +0530, Pranav Ballaney wrote: >> Hi, >> I've added autopkgtests to ncbi-entrez-direct. Since autopkgtests don't >> always run in an environment with an internet connection, most of the >> programs in this package can't be tested. I've added tests for all the >> programs that run locally. >> >> Please review and sponsor. >> https://salsa.debian.org/med-team/ncbi-entrez-direct >> >> Regards, >> Pranav
Re: Packaging libsis-jhdf5-java -- help needed
Hi Pierre, On Thu, May 07, 2020 at 08:16:07AM +0200, Pierre Gruet wrote: > Andreas, I have just seen you uploaded my commits of libsis-jhdf5-java > to unstable, thanks for that! > > I had not written to ask for it as I intended to do further changes > before the upload (the script h5ar in /usr/bin should be removed or > another jar should be compiled, as h5ar is not working as is). > But this is not a problem as the package you uploaded builds well, all > tests pass and the jar and jni are usable. I shall provide another > version soon, that fixes the /usr/bin/h5ar issue. Yes, I was wondering whether you plan additional changes but fixing the long standing RC bug seemed to be more important for the moment. I also think that observing autobuilders and possibly fix issues there in a subsequent upload with your additional changes could be a good idea. > Gilles, huge thanks again for your help, with your input I could solve > the remaining issues and, afterwards, improve debian/rules consequently. Thanks a lot to you both. Your work is really appreciated Andreas. -- http://fam-tille.de
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas and Gilles, Andreas, I have just seen you uploaded my commits of libsis-jhdf5-java to unstable, thanks for that! I had not written to ask for it as I intended to do further changes before the upload (the script h5ar in /usr/bin should be removed or another jar should be compiled, as h5ar is not working as is). But this is not a problem as the package you uploaded builds well, all tests pass and the jar and jni are usable. I shall provide another version soon, that fixes the /usr/bin/h5ar issue. Gilles, huge thanks again for your help, with your input I could solve the remaining issues and, afterwards, improve debian/rules consequently. All the best, Pierre
