transitive bug issue, how to manage this ?
Hi, all mobyle related packages (mobyle, mobyle-programs,..) are marked for Jessie auto removal. It says there is a transitive bug impacting it: "Version 1.5.3+dfsg-1 of mobyle is marked for autoremoval from testing on 2015-01-05. It depends (transitively) on and maven, affected by RC bug(s) and 770608 You should try to prevent the removal from testing by fixing these bugs." This is not a mobyle issue but a dependency issue. So there is nothing I can do directly BUT, mobyle depends on python packages and apache2 only, so I do not see where maven (for Java) appears here... I tried a recursive search in deps and did not found any maven dep. Does anyone know how to manage such case? Thanks Olivier
Re: Please help: failed build of plastimatch 1.5.16+dfsg-2 for several architectures
Gregory Sharp wrote: This is very helpful. Exactly the advice I was seeking! Slowly the process is starting to make sense. I have requested the binNMU for insighttoolkit. (Strangely I didn't get a return email from reportbug. Maybe it is in the queue. Or maybe I made a mistake. We'll see...) Once the binNMU is successful, it seems a "give-back" on plastimatch is needed. Seems like the binNMU has finally worked, the build log [1] looks much better now. :-) There are still problems on 2 platforms, but they seem unrelated: 1. On arm64 it's "BD-Uninstallable", which is because of a chain of uninstallables: gccxml -> cableswig -> libinsighttoolkit3-dev -> plastimatch. There's probably nothing we can/have to do about it. 2. On hurd-i386 there's a plastimatch-related compilation problem with a constant "MAX_PATH" that is missing on that platform. Looks like plastimatch has been failing on that platform all along because of this problem. I'm not sure, but since those problems seem to be unrelated, I think that bug #769975 should probably be closed now. What do you think? Cheers, Martin [1] https://buildd.debian.org/status/package.php?p=plastimatch -- 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/547a1191.40...@steghoefer.eu
Re: Licensing terms for data derived from ARB/SILVA data
Hi Andreas, >>> what aout putting barnap into main and barrnap-additional-data >>> into non-free? >> >> Do you mean having barrnap depend on or suggest barrnap-additional-data >> in that case? > > Only *suggests* would be possible to keep barrnap in main. I see -- makes sense. >> The problem is that the non-free HMMs are not really "additional", as >> barrnap would not work without them at all. Hence it would not make >> sense to install one without the other. >> >> In theory, one could split the HMMs into a free and a non-free set, and >> then patch barrnap to read its HMMs from multiple sources. > > What do you mean by "multiple sources"? The files of the different > packages can perfectly end up in the same directory. Well, I need to explain how barrnap reads its input HMMs then. There is currently one .hmm file for each kingdom: euk(aryote), bac(terial), arc(haea) and mito(chondrial). These four files are currently distributed with barnap in the upstream tarball. Each of these files contains multiple HMM definitions (in HMMER3 format), some of which are taken from Rfam (free) and some of which are built from the non-free SILVA alignments (the 23S and 28S rRNAs, to be exact). When barrnap is called, the '--kingdom' parameter takes either 'euk', 'bac', 'arc' or 'mito', hence specifying the prefix of the .hmm file to use in the search. So if the .hmm files are split into two separate ones, e.g. euk.hmm and euk_nonfree.hmm, one would need to patch barrnap to actually call nhmmer with both files, if they exist. >> However, if someone does not have non-free enabled, they will silently >> miss all the results only available with the non-free HMM set. I can >> imagine that would confuse the majority of users, who would want to rely >> on the output of barrnap as it is. > > I can not comment on this since I'm no end user. That's just what I can imagine as a potential negative consequence -- the end-user might see the missing results as a flaw in barrnap itself. If I was the upstream author, I would not be too happy about this in this case. Best Sascha -- 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/5479efae.3000...@steinbiss.name
Re: Licensing terms for data derived from ARB/SILVA data
On 29/11/14 15:03, Andreas Tille wrote: > Hi, Hi Andreas, > what aout putting barnap into main and barrnap-additional-data > into non-free? Do you mean having barrnap depend on or suggest barrnap-additional-data in that case? The problem is that the non-free HMMs are not really "additional", as barrnap would not work without them at all. Hence it would not make sense to install one without the other. In theory, one could split the HMMs into a free and a non-free set, and then patch barrnap to read its HMMs from multiple sources. The free HMMs could then go into the barrnap package in main, and the non-free ones into a separate data package in non-free. However, if someone does not have non-free enabled, they will silently miss all the results only available with the non-free HMM set. I can imagine that would confuse the majority of users, who would want to rely on the output of barrnap as it is. > Greetings from Hanoi > Andreas. Thanks and enjoy your vacation :) Sascha > On Sat, Nov 29, 2014 at 01:14:20PM +, Sascha Steinbiss wrote: >> Hi Olivier and all, >> >> thanks for the feedback. I have just adapted the barrnap package to go >> into the non-free area and added the respective licenses to d/copyright. >> If there are no other suggestions, I would consider the package to be >> ready for upload then. >> I will also reply to Frank Gloeckner and inform Torsten Seemann about >> the results of the enquiry later. >> >> Thanks >> Sascha >> >> On 29/11/14 11:49, olivier.sal...@codeless.fr wrote: >>> On 11/29/2014 12:29 PM, Sascha Steinbiss wrote: Hi all, >> But we would like to ask you to clearly indicate that the profiles are >> only free for non-commercial usage, commercial users need a licence. >> The easiest approach is to add a reference to the SILVA terms of >> license assigned to the software/profile. > Argghh! this will prevent from being in free section. And I suppose > those profiles are mandary for software usage ? To ensure that the Debian version and the upstream version produce the same results, yes, they are necessary. I guess there are two choices now: 1. Put barrnap in non-free. What consequences would that have for a 'regular' academic user -- they would have to enable non-free on a default install, right? >>> Yeap, they need to add non-free to apt sources 2. Use an alternative set of pHMMs in the Debian version of barrnap, only including those which are built from Rfam alignments only (Rfam has a free license (CC0)). However, that would strongly limit the functionality of barrnap as whole rRNA families could end up being missing from the output of the dfsg compliant version. I guess to have a usable barrnap version, 1. is the only viable solution. Any comments? >>> I agree Thanks Sascha >>> >>> >> >> >> -- >> 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/5479c6ac.2080...@steinbiss.name >> >> > -- 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/5479e7c5.1050...@steinbiss.name
Re: Licensing terms for data derived from ARB/SILVA data
On Sat, Nov 29, 2014 at 03:35:33PM +, Sascha Steinbiss wrote: > On 29/11/14 15:03, Andreas Tille wrote: > > Hi, > > Hi Andreas, > > > what aout putting barnap into main and barrnap-additional-data > > into non-free? > > Do you mean having barrnap depend on or suggest barrnap-additional-data > in that case? Only *suggests* would be possible to keep barrnap in main. > The problem is that the non-free HMMs are not really "additional", as > barrnap would not work without them at all. Hence it would not make > sense to install one without the other. > > In theory, one could split the HMMs into a free and a non-free set, and > then patch barrnap to read its HMMs from multiple sources. What do you mean by "multiple sources"? The files of the different packages can perfectly end up in the same directory. > The free HMMs > could then go into the barrnap package in main, and the non-free ones > into a separate data package in non-free. Yes, this as my idea. > However, if someone does not have non-free enabled, they will silently > miss all the results only available with the non-free HMM set. I can > imagine that would confuse the majority of users, who would want to rely > on the output of barrnap as it is. I can not comment on this since I'm no end user. > > Greetings from Hanoi > > Andreas. > > Thanks and enjoy your vacation :) Thanks - and going offline again 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/20141129154931.gb3...@an3as.eu
Re: Licensing terms for data derived from ARB/SILVA data
Hi, what aout putting barnap into main and barrnap-additional-data into non-free? Packages in non-free do not gain the same QA means which we do nit need for the non-free data. Greetings from Hanoi Andreas. On Sat, Nov 29, 2014 at 01:14:20PM +, Sascha Steinbiss wrote: > Hi Olivier and all, > > thanks for the feedback. I have just adapted the barrnap package to go > into the non-free area and added the respective licenses to d/copyright. > If there are no other suggestions, I would consider the package to be > ready for upload then. > I will also reply to Frank Gloeckner and inform Torsten Seemann about > the results of the enquiry later. > > Thanks > Sascha > > On 29/11/14 11:49, olivier.sal...@codeless.fr wrote: > > On 11/29/2014 12:29 PM, Sascha Steinbiss wrote: > >> Hi all, > >> > But we would like to ask you to clearly indicate that the profiles are > only free for non-commercial usage, commercial users need a licence. > The easiest approach is to add a reference to the SILVA terms of > license assigned to the software/profile. > >>> Argghh! this will prevent from being in free section. And I suppose > >>> those profiles are mandary for software usage ? > >> To ensure that the Debian version and the upstream version produce the > >> same results, yes, they are necessary. I guess there are two choices now: > >> > >> 1. Put barrnap in non-free. What consequences would that have for a > >>'regular' academic user -- they would have to enable non-free on a > >>default install, right? > > Yeap, they need to add non-free to apt sources > >> > >> 2. Use an alternative set of pHMMs in the Debian version of barrnap, > >>only including those which are built from Rfam alignments only (Rfam > >>has a free license (CC0)). However, that would strongly limit the > >>functionality of barrnap as whole rRNA families could end up > >>being missing from the output of the dfsg compliant version. > >> > >> I guess to have a usable barrnap version, 1. is the only viable > >> solution. Any comments? > > I agree > >> Thanks > >> Sascha > > > > > > > -- > 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/5479c6ac.2080...@steinbiss.name > > -- 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/20141129150358.ga3...@an3as.eu
Re: Licensing terms for data derived from ARB/SILVA data
Hi Olivier and all, thanks for the feedback. I have just adapted the barrnap package to go into the non-free area and added the respective licenses to d/copyright. If there are no other suggestions, I would consider the package to be ready for upload then. I will also reply to Frank Gloeckner and inform Torsten Seemann about the results of the enquiry later. Thanks Sascha On 29/11/14 11:49, olivier.sal...@codeless.fr wrote: > On 11/29/2014 12:29 PM, Sascha Steinbiss wrote: >> Hi all, >> But we would like to ask you to clearly indicate that the profiles are only free for non-commercial usage, commercial users need a licence. The easiest approach is to add a reference to the SILVA terms of license assigned to the software/profile. >>> Argghh! this will prevent from being in free section. And I suppose >>> those profiles are mandary for software usage ? >> To ensure that the Debian version and the upstream version produce the >> same results, yes, they are necessary. I guess there are two choices now: >> >> 1. Put barrnap in non-free. What consequences would that have for a >>'regular' academic user -- they would have to enable non-free on a >>default install, right? > Yeap, they need to add non-free to apt sources >> >> 2. Use an alternative set of pHMMs in the Debian version of barrnap, >>only including those which are built from Rfam alignments only (Rfam >>has a free license (CC0)). However, that would strongly limit the >>functionality of barrnap as whole rRNA families could end up >>being missing from the output of the dfsg compliant version. >> >> I guess to have a usable barrnap version, 1. is the only viable >> solution. Any comments? > I agree >> Thanks >> Sascha > > -- 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/5479c6ac.2080...@steinbiss.name
Re: Licensing terms for data derived from ARB/SILVA data
On 11/29/2014 12:29 PM, Sascha Steinbiss wrote: > Hi all, > >>> But we would like to ask you to clearly indicate that the profiles are >>> only free for non-commercial usage, commercial users need a licence. >>> The easiest approach is to add a reference to the SILVA terms of >>> license assigned to the software/profile. >> Argghh! this will prevent from being in free section. And I suppose >> those profiles are mandary for software usage ? > To ensure that the Debian version and the upstream version produce the > same results, yes, they are necessary. I guess there are two choices now: > > 1. Put barrnap in non-free. What consequences would that have for a >'regular' academic user -- they would have to enable non-free on a >default install, right? Yeap, they need to add non-free to apt sources > > 2. Use an alternative set of pHMMs in the Debian version of barrnap, >only including those which are built from Rfam alignments only (Rfam >has a free license (CC0)). However, that would strongly limit the >functionality of barrnap as whole rRNA families could end up >being missing from the output of the dfsg compliant version. > > I guess to have a usable barrnap version, 1. is the only viable > solution. Any comments? I agree > Thanks > Sascha -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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/5479b2c0.20...@codeless.fr
ncbi blast+ compilation error
Hi Aaron, I have updated patches to the new version of blast+, however I have a compilation error. Do you have an idea of what should be added ? Thanks Olivier Extract: undefined reference to symbol kBlastMinorVersion missing symbol DSO missing from command line at ld step for blast_app seems app required algo/blast/core
Re: Licensing terms for data derived from ARB/SILVA data
Hi all, >> But we would like to ask you to clearly indicate that the profiles are >> only free for non-commercial usage, commercial users need a licence. >> The easiest approach is to add a reference to the SILVA terms of >> license assigned to the software/profile. > Argghh! this will prevent from being in free section. And I suppose > those profiles are mandary for software usage ? To ensure that the Debian version and the upstream version produce the same results, yes, they are necessary. I guess there are two choices now: 1. Put barrnap in non-free. What consequences would that have for a 'regular' academic user -- they would have to enable non-free on a default install, right? 2. Use an alternative set of pHMMs in the Debian version of barrnap, only including those which are built from Rfam alignments only (Rfam has a free license (CC0)). However, that would strongly limit the functionality of barrnap as whole rRNA families could end up being missing from the output of the dfsg compliant version. I guess to have a usable barrnap version, 1. is the only viable solution. Any comments? Thanks Sascha -- 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/5479ae12.2030...@steinbiss.name
Re: Licensing terms for data derived from ARB/SILVA data
On 11/28/2014 04:48 PM, Frank Oliver Glöckner wrote: > Dear Sascha Steinbiss, > thanks for the information. > We discussed it and in general we agree that the HMM profiles derived > from LSURef_115_tax_silva_full_align_trunc.fasta can be distributed. > But we would like to ask you to clearly indicate that the profiles are > only free for non-commercial usage, commercial users need a licence. > The easiest approach is to add a reference to the SILVA terms of > license assigned to the software/profile. Argghh! this will prevent from being in free section. And I suppose those profiles are mandary for software usage ? > > Have a nice weekend > > Frank Oliver Glöckner > > Am 26.11.2014 20:28, schrieb Sascha Steinbiss: >> On 26/11/2014 17:56, Frank Oliver Glöckner wrote: >>> >Dear Sascha Steinbeiss, >> Dear Prof. Gloeckner, >> >> thanks for your prompt reply. >> >>> >Before we can answer your question may I ask you to provide us with >>> some >>> >more information about the: >>> >1. name of the tool >> The software in question is barrnap >> (http://www.vicbioinformatics.com/software.barrnap.shtml) written by >> Torsten Seemann. >> >>> >2. functionality of the tool, e.g. does it just detect rRNAs, and/or >>> >does it classify sequences? >> The main functionality is to detect rRNAs and to output their locations >> in an input sequence as GFF3 features. As far as classification goes, it >> does distinguish between the individual rRNAs for a given kingdom >> (5S,23S,16S for bacteria; 5S,5.8S,28S,18S for eukaryotes, etc.) but does >> not taxonomically classify them as being close to a particular >> species. You can see example output on the web page given above. >> >> It is basically a wrapper around nhmmer searching for a relatively >> general rRNA pHMM, meant for de novo annotation. >> >>> >All the best >>> >Frank Oliver Glöckner >> Best wishes from a former 'Nordlicht' (I think we met once when I still >> was at the ZBH Hamburg) >> Sascha Steinbiss >> >>> > >>> >Am 26.11.2014 12:34, schrieb Sascha Steinbiss: >>Dear ARB/SILVA team, >> >>I am writing to inquire about a special case regarding your data >>licensing terms. >>I am involved with the Debian Med project >>(https://www.debian.org/devel/debian-med/), whose goal it is to provide >>software from the medical and bioinformatics fields to users of the >>Debian Linux distribution. Currently I am working on packaging a piece >>of free (GPL) software for prediction of rRNA genes in sequences. This >>software requires (and would be bundled with) a set of nucleotide >>profile HMMs (built with HMMER) based on several individual data >>sources. One of the data sources used to build these HMMs was the file >>LSURef_115_tax_silva_full_align_trunc.fasta, available from your >>database. >>Since your licensing terms >>(http://www.arb-silva.de/silva-license-information/) are not clear about >>how derivatives of your data are to be licensed, I would like to ask >>whether it would be OK for us to package and redistribute these HMMs >>under a free license, for both academic and non-academic users. I wish >>to make it clear here that the original file >>LSURef_115_tax_silva_full_align_trunc.fasta will NOT be included in the >>package, only HMMs built from it (and other free sources). >> >>I am looking forward to your response. >> >>Best regards >>Sascha Steinbiss > > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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/54798abd.7090...@codeless.fr
