Re: status on picard-tools and issue with libsnappy-java
On Wed, Aug 15, 2012 at 09:45:59AM +0200, olivier.sal...@codeless.fr wrote: > > > I tried something along this path and created > > > > git://git.debian.org/debian-med/snappy1.0.3-java.git > > > > However, when doing so I noticed that all downloadable versions > > snappy-java-1.0.3.[1-3].tar.gz are unfortunately NOT featuring our > > target class LoadSnappy. I wonder whether somebody could contact > > picard-tools upstream again what exact version they are using (and > > perhaps nagging again that finally using unmaintained code is definitely > > not a good idea - beeing angry about ABI changes or not.) > They refer to snappy 1.0.3-rc3 [0]. LoadSnappy is available there. I can find this file here but there is no such downloadable tarball (any more). Any hint, how to reasonably check out the source? And I would like to repeat: A project that relies on orphaned / deprecated upstream / unmaintained code is at least questionable and I wonder whether we should really support this. Kind regards Andreas. > [0] > http://code.google.com/p/snappy-java/source/browse/?name=snappy-java-1.0.3-rc3#hg%2Fsrc%2Fmain%2Fjava%2Forg%2Fxerial%2Fsnappy -- 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: http://lists.debian.org/20120815085643.gd6...@an3as.eu
Re: status on picard-tools and issue with libsnappy-java
On Wed, Aug 15, 2012 at 09:48:54AM +0200, olivier.sal...@codeless.fr wrote: > By the way, do you plan to package it and update picard-tools or do you > want I take this in charge. > I can do it if you want, it is only a matter of time. I tried to reduce your after-holiday stress by giving it a start. Lets see how far this will reach ... 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: http://lists.debian.org/20120815081647.gb6...@an3as.eu
Re: status on picard-tools and issue with libsnappy-java
Le 8/14/12 10:57 AM, Andreas Tille a écrit : > Hi, > > On Tue, Aug 14, 2012 at 09:06:46AM +0200, olivier.sal...@codeless.fr wrote: >> Le 8/13/12 1:35 PM, Andreas Tille a écrit : >>> On Mon, Aug 13, 2012 at 08:07:22PM +0900, Charles Plessy wrote: For libsnappy-java, since it still only has 10 Popcon users, of which I already contribute 2 or 3 points because I develop on multiple machines, we can also do something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 using an epoch, and b) request its removal from Wheezy. >>> Its dirty but probably solves the problem in a way that causes the least >>> work for us currently. However, I think the popcon count is anyway >>> "alarming" enough to assume that we might leave some unhappy users >>> behind. >> I'd rather like avoiding a removal. >> I'd still prefer packaging a v1.0.3 ( with an epoch) > I agree that this is also my prefered solution but if the package say > >libsnappy1.0.3-java > > should be maintained in addition to libsnappy-java ... but without an > epoch IMHO, because these are distinct packages without a common > history. Or am I missing something? > >> that conflicts with the current version > I do not see any reason for a conflict if the file names are different. > >> and a picard-tools that recomments 1.0.3. >> If 1.0.3 is not present, it does not matter, picard-tools will work. It >> is only "mandatory" for picard-tools building. > IMHO the only thing what we need to do in picard-tools is changing the > class dependencies from snappy.jar to snappy1.0.3.jar which should do > the trick. > > I tried something along this path and created > > git://git.debian.org/debian-med/snappy1.0.3-java.git > > However, when doing so I noticed that all downloadable versions > snappy-java-1.0.3.[1-3].tar.gz are unfortunately NOT featuring our > target class LoadSnappy. I wonder whether somebody could contact > picard-tools upstream again what exact version they are using (and > perhaps nagging again that finally using unmaintained code is definitely > not a good idea - beeing angry about ABI changes or not.) By the way, do you plan to package it and update picard-tools or do you want I take this in charge. I can do it if you want, it is only a matter of time. Thanks Olivier > > Kind regards > >Andreas. > > > -- > 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: http://lists.debian.org/502b5466.9040...@codeless.fr
Re: status on picard-tools and issue with libsnappy-java
Le 8/14/12 10:57 AM, Andreas Tille a écrit : > Hi, > > On Tue, Aug 14, 2012 at 09:06:46AM +0200, olivier.sal...@codeless.fr wrote: >> Le 8/13/12 1:35 PM, Andreas Tille a écrit : >>> On Mon, Aug 13, 2012 at 08:07:22PM +0900, Charles Plessy wrote: For libsnappy-java, since it still only has 10 Popcon users, of which I already contribute 2 or 3 points because I develop on multiple machines, we can also do something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 using an epoch, and b) request its removal from Wheezy. >>> Its dirty but probably solves the problem in a way that causes the least >>> work for us currently. However, I think the popcon count is anyway >>> "alarming" enough to assume that we might leave some unhappy users >>> behind. >> I'd rather like avoiding a removal. >> I'd still prefer packaging a v1.0.3 ( with an epoch) > I agree that this is also my prefered solution but if the package say > >libsnappy1.0.3-java > > should be maintained in addition to libsnappy-java ... but without an > epoch IMHO, because these are distinct packages without a common > history. Or am I missing something? Nope, you"re right. > >> that conflicts with the current version > I do not see any reason for a conflict if the file names are different. > >> and a picard-tools that recomments 1.0.3. >> If 1.0.3 is not present, it does not matter, picard-tools will work. It >> is only "mandatory" for picard-tools building. > IMHO the only thing what we need to do in picard-tools is changing the > class dependencies from snappy.jar to snappy1.0.3.jar which should do > the trick. > > I tried something along this path and created > > git://git.debian.org/debian-med/snappy1.0.3-java.git > > However, when doing so I noticed that all downloadable versions > snappy-java-1.0.3.[1-3].tar.gz are unfortunately NOT featuring our > target class LoadSnappy. I wonder whether somebody could contact > picard-tools upstream again what exact version they are using (and > perhaps nagging again that finally using unmaintained code is definitely > not a good idea - beeing angry about ABI changes or not.) They refer to snappy 1.0.3-rc3 [0]. LoadSnappy is available there. [0] http://code.google.com/p/snappy-java/source/browse/?name=snappy-java-1.0.3-rc3#hg%2Fsrc%2Fmain%2Fjava%2Forg%2Fxerial%2Fsnappy > > Kind regards > >Andreas. > > > -- > 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: http://lists.debian.org/502b53b7.2020...@codeless.fr
Re: status on picard-tools and issue with libsnappy-java
Hi, On Tue, Aug 14, 2012 at 09:06:46AM +0200, olivier.sal...@codeless.fr wrote: > > Le 8/13/12 1:35 PM, Andreas Tille a écrit : > > On Mon, Aug 13, 2012 at 08:07:22PM +0900, Charles Plessy wrote: > >> For libsnappy-java, since it still only has 10 Popcon users, of which I > >> already > >> contribute 2 or 3 points because I develop on multiple machines, we can > >> also do > >> something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 > >> using > >> an epoch, and b) request its removal from Wheezy. > > Its dirty but probably solves the problem in a way that causes the least > > work for us currently. However, I think the popcon count is anyway > > "alarming" enough to assume that we might leave some unhappy users > > behind. > I'd rather like avoiding a removal. > I'd still prefer packaging a v1.0.3 ( with an epoch) I agree that this is also my prefered solution but if the package say libsnappy1.0.3-java should be maintained in addition to libsnappy-java ... but without an epoch IMHO, because these are distinct packages without a common history. Or am I missing something? > that conflicts with the current version I do not see any reason for a conflict if the file names are different. > and a picard-tools that recomments 1.0.3. > If 1.0.3 is not present, it does not matter, picard-tools will work. It > is only "mandatory" for picard-tools building. IMHO the only thing what we need to do in picard-tools is changing the class dependencies from snappy.jar to snappy1.0.3.jar which should do the trick. I tried something along this path and created git://git.debian.org/debian-med/snappy1.0.3-java.git However, when doing so I noticed that all downloadable versions snappy-java-1.0.3.[1-3].tar.gz are unfortunately NOT featuring our target class LoadSnappy. I wonder whether somebody could contact picard-tools upstream again what exact version they are using (and perhaps nagging again that finally using unmaintained code is definitely not a good idea - beeing angry about ABI changes or not.) 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: http://lists.debian.org/20120814085713.gg6...@an3as.eu
Re: status on picard-tools and issue with libsnappy-java
Le 8/13/12 1:35 PM, Andreas Tille a écrit : > On Mon, Aug 13, 2012 at 08:07:22PM +0900, Charles Plessy wrote: >> For libsnappy-java, since it still only has 10 Popcon users, of which I >> already >> contribute 2 or 3 points because I develop on multiple machines, we can also >> do >> something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 >> using >> an epoch, and b) request its removal from Wheezy. > Its dirty but probably solves the problem in a way that causes the least > work for us currently. However, I think the popcon count is anyway > "alarming" enough to assume that we might leave some unhappy users > behind. I'd rather like avoiding a removal. I'd still prefer packaging a v1.0.3 ( with an epoch) that conflicts with the current version and a picard-tools that recomments 1.0.3. If 1.0.3 is not present, it does not matter, picard-tools will work. It is only "mandatory" for picard-tools building. Olivier > >> Note to the other readers: this is really something that usually should not >> be >> done. Please forget what you read ! > What did you wrote? Probably need to start reading from top because I > forgot what was written there. ;-) > >> What do you think ? > I have a slight preference for Oliviers suggestion and I'd be fine with > waiting once he is back from holidays. We should keep the dirtier > method (which was in some mail I need to reread because I forgot) in > mind if something might cause any problem. > > There might be a third way that also qualifies as dirty solution: As I > said we could inject LoadSnappy.java as patch and by doing so build the > package successfully. Then we could *Conflict* picard-tools with > libsnappy-java to make sure that the class is not found at execution > time. Could you please exlpain again the advantage of having libsnappy > for the picard-tools user? > > Kind regards > > Andreas. > > > -- > 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: http://lists.debian.org/5029f906.8030...@codeless.fr
Re: status on picard-tools and issue with libsnappy-java
Le Mon, Aug 13, 2012 at 01:35:43PM +0200, Andreas Tille a écrit : > > Could you please exlpain again the advantage of having libsnappy for the > picard-tools user? It accelerates some operations by compressing temporary data on the fly. The upstream website mentions a time reduction of 25 %. http://sourceforge.net/apps/mediawiki/picard/index.php?title=Using_Snappy_in_Picard Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813115114.ge4...@falafel.plessy.net
Re: status on picard-tools and issue with libsnappy-java
On Mon, Aug 13, 2012 at 08:07:22PM +0900, Charles Plessy wrote: > > For libsnappy-java, since it still only has 10 Popcon users, of which I > already > contribute 2 or 3 points because I develop on multiple machines, we can also > do > something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 using > an epoch, and b) request its removal from Wheezy. Its dirty but probably solves the problem in a way that causes the least work for us currently. However, I think the popcon count is anyway "alarming" enough to assume that we might leave some unhappy users behind. > Note to the other readers: this is really something that usually should not be > done. Please forget what you read ! What did you wrote? Probably need to start reading from top because I forgot what was written there. ;-) > What do you think ? I have a slight preference for Oliviers suggestion and I'd be fine with waiting once he is back from holidays. We should keep the dirtier method (which was in some mail I need to reread because I forgot) in mind if something might cause any problem. There might be a third way that also qualifies as dirty solution: As I said we could inject LoadSnappy.java as patch and by doing so build the package successfully. Then we could *Conflict* picard-tools with libsnappy-java to make sure that the class is not found at execution time. Could you please exlpain again the advantage of having libsnappy for the picard-tools user? 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: http://lists.debian.org/20120813113543.ge10...@an3as.eu
Re: status on picard-tools and issue with libsnappy-java
Le Mon, Aug 13, 2012 at 12:30:12PM +0200, olivier.sal...@codeless.fr a écrit : > > Too bad > We could indeed package a libsnappy1.0.3-java (with a conflict on > libsnappy-java, and a recommends on picard-tools) and make picard-tools > depend on this version. Hi Olivier and Andreas, first of all, many thanks for your work on this. For libsnappy-java, since it still only has 10 Popcon users, of which I already contribute 2 or 3 points because I develop on multiple machines, we can also do something very "dark side", that is a) downgrade libsnappy-java to 1.0.3 using an epoch, and b) request its removal from Wheezy. Note to the other readers: this is really something that usually should not be done. Please forget what you read ! What do you think ? -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813110722.gd4...@falafel.plessy.net
Re: status on picard-tools and issue with libsnappy-java
Le 8/13/12 11:08 AM, Andreas Tille a écrit : > On Mon, Aug 13, 2012 at 09:27:50AM +0200, olivier.sal...@codeless.fr wrote: >> I copy below the answer from upstream team. >> They will not go to latest snappy version. Seems it was quite difficult >> to integrate it and faced issues. >> >> The problem is snappy-java 1.0.4 breaks its API and is not compatible >> with version 1.0.3 used by picard-tools. > This is what we also learned (the hard way). > >> At runtime, picard-tools tries to detect snappy. If not present, it will >> be ok. However we still face the problem for Debian for compilation >> >> Message original >> Sujet: Re: [Samtools-help] support of snappy-1.0.4 >> Date : Thu, 09 Aug 2012 10:27:11 -0400 >> De : Alec Wysoker >> Pour : olivier.sallou >> Copie à :samtools-h...@lists.sourceforge.net >> >> ... >> >> Could you try one of the following alternatives to using latest snappy-java: >> >> * Use the same version Picard uses, i.e. 1.0.3-rc3 > It somehow came to my mind to package this older version. Finally we > started packaging libsnappy-java for the only purpose to support picard > ... and currently this purpose is not fullfilled. Too bad We could indeed package a libsnappy1.0.3-java (with a conflict on libsnappy-java, and a recommends on picard-tools) and make picard-tools depend on this version. I am on holiday for the moment and won't have much time to manage this. However, if adding such library (1.0.3) can fix the issue, I could do this in a few weeks. > >> * Omit snappy-java classes completely. >> net.sf.samtools.util.SnappyLoader is written so that if >> org.xerial.snappy.SnappyInputStream and >> org.xerial.snappy.SnappyOutputStream are not found on the classpath, >> then the code should work without using Snappy. > Hmmm, I do not know the advantage we would liked to reach and whether > this is acceptable. However, it seems to make sense to do not only a > check whether the class is available but also to verify the version if > there are incompatible versions known. I have no idea whether this is > possible - but if yes this would be a reasonable hint to upstream. Incompatible versions should also be detected as expected class will not be found. But this does not fix our compilation issue as snappy is still required for build (with correct version) > Kind regards > > Andreas. > > > -- > 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: http://lists.debian.org/5028d734.6090...@codeless.fr
Re: status on picard-tools and issue with libsnappy-java
On Mon, Aug 13, 2012 at 09:27:50AM +0200, olivier.sal...@codeless.fr wrote: > I copy below the answer from upstream team. > They will not go to latest snappy version. Seems it was quite difficult > to integrate it and faced issues. > > The problem is snappy-java 1.0.4 breaks its API and is not compatible > with version 1.0.3 used by picard-tools. This is what we also learned (the hard way). > At runtime, picard-tools tries to detect snappy. If not present, it will > be ok. However we still face the problem for Debian for compilation > > Message original > Sujet:Re: [Samtools-help] support of snappy-1.0.4 > Date :Thu, 09 Aug 2012 10:27:11 -0400 > De : Alec Wysoker > Pour :olivier.sallou > Copie à : samtools-h...@lists.sourceforge.net > > ... > > Could you try one of the following alternatives to using latest snappy-java: > > * Use the same version Picard uses, i.e. 1.0.3-rc3 It somehow came to my mind to package this older version. Finally we started packaging libsnappy-java for the only purpose to support picard ... and currently this purpose is not fullfilled. > * Omit snappy-java classes completely. > net.sf.samtools.util.SnappyLoader is written so that if > org.xerial.snappy.SnappyInputStream and > org.xerial.snappy.SnappyOutputStream are not found on the classpath, > then the code should work without using Snappy. Hmmm, I do not know the advantage we would liked to reach and whether this is acceptable. However, it seems to make sense to do not only a check whether the class is available but also to verify the version if there are incompatible versions known. I have no idea whether this is possible - but if yes this would be a reasonable hint to upstream. 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: http://lists.debian.org/20120813090803.gb10...@an3as.eu
status on picard-tools and issue with libsnappy-java
I copy below the answer from upstream team. They will not go to latest snappy version. Seems it was quite difficult to integrate it and faced issues. The problem is snappy-java 1.0.4 breaks its API and is not compatible with version 1.0.3 used by picard-tools. At runtime, picard-tools tries to detect snappy. If not present, it will be ok. However we still face the problem for Debian for compilation Olivier Message original Sujet: Re: [Samtools-help] support of snappy-1.0.4 Date : Thu, 09 Aug 2012 10:27:11 -0400 De :Alec Wysoker Pour : olivier.sallou Copie à : samtools-h...@lists.sourceforge.net Hi Olivier, I assume you are referring to Picard library rather than samtools, because I don't think samtools uses Snappy. I am reluctant to fiddle with Snappy or get a new version, because we had lots of problems when we released it, some of which did not happen on our configuration but only for other users, which made it difficult to test and debug. It took several iterations for this to settle down. Could you try one of the following alternatives to using latest snappy-java: * Use the same version Picard uses, i.e. 1.0.3-rc3 * Omit snappy-java classes completely. net.sf.samtools.util.SnappyLoader is written so that if org.xerial.snappy.SnappyInputStream and org.xerial.snappy.SnappyOutputStream are not found on the classpath, then the code should work without using Snappy. -Alec On 8/8/12 10:02 AM, olivier.sallou wrote: > Hi, > I am part of the DebianMed team, we package some programs for Debian. > When trying to compile sam-tools, we got an issue because current snappy > version is 1.0.4 and it is not compatible with previous ones. > > Indeed, LoadSnappy class is not present anymore, and has been replaced > by SnappyLoader (same name as one of your classes). > Furthermore, public method load is not present anymore. > > With hacks, I could get it compile, but I do not know if my hacks are > correct (if needed I can send you what I did). > > Do you plan to support new snappy version ? > > Thanks > > Olivier > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Samtools-help mailing list > samtools-h...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/samtools-help
