Re: Regarding a New Project idea for Debian Med
Hi Prakhar, How is your effort going? Or did you give up? Pj. On Wed, May 19, 2010 at 10:56:52PM +0530, prakhar gaur wrote: > We want to have a Linux distribution based on Debian, dedicated > for Bioinformatics research which would be useful for researchers > and students. In India, high end hardware systems are at a > premium, hence we want the distribution, to have low memory > footprint. A variety of methods will be used to optimize the > performance of the bioinformatics programs. -- 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/20100627071820.ga17...@thebird.nl
Re: State of the embassy-* packages in Squeeze.
I am going to ask on the EMBOSS mailing list. Pj. -- 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/20100812212121.ga3...@thebird.nl
Re: State of the embassy-* packages in Squeeze.
I have an interest here, as I am mapping EMBOSS with BioLib - and versioning plays a role. Appears to me that supporting Embassy has less of an interest with the core EMBOSS team. EMBOSS is changing - that is what counts. If anyone cares to keep Embassy it would make sense to package it with an earlier version. Only way to guarantee some stability. I would not try option 3, unless you are heroic. Who is using Embassy now? I have seen complaints about the size of the repository, but would it not make sense to create Embassy-with-EMBOSS-6.2? And an updated EMBOSS-6.3? Or is this against policy? With nixos this would not be a problem. Nix transparently supports different versions of dependencies. Pj. On Wed, Aug 11, 2010 at 07:52:31AM +0200, Andreas Tille wrote: > On Tue, Aug 10, 2010 at 11:16:31PM -0400, Julien Cristau wrote: > > On Wed, Aug 11, 2010 at 08:55:32 +0900, Charles Plessy wrote: > > > > > To put the emboss and embassy packages in consistency in Squeeze, here are > > > possible solutions: > > > > > > - Remove the embassy-* packages from testing. > > > - Upload emboss 6.2 to testing-proposed-updates. > > > - Upgrade embassy-* packages with the latest upstream version, that > > > builds > > >against emboss 6.3, and let emboss 6.3 in testing. > > > > > 1 would be ok with me, 2 would not, and 3 would depend on the timeframe > > and on the amount of changes it represents. > > As well as Charles I have a strong preference for option 3. > > > (Other release team members > > may have other opinions though.) > > That means we should wait for the opinion of other release team members? > I'm just asking because this remark leaves us unclear in what direction > we should proceed. > > 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/20100811055231.ga24...@an3as.eu > -- 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/20100812211740.ga2...@thebird.nl
Re: State of the embassy-* packages in Squeeze.
On Fri, Aug 13, 2010 at 08:14:11AM +0900, Charles Plessy wrote: > What I am asking in option 3 is to ship EMBOSS 6.3.1 in Squeeze. Would it be > disruptive for your work with BioLib? I am a bit shocked to read that you > consider that option 3 (distributing EMBOSS 6.3.1 in Squeeze) is > ???heroic???. I > use it and follow the upstream mailing list; there is no indication that it > introduces regressions. The bugs I have reported as a user and as a packager > in > earlier versions are fixed in 6.3.1. No, no! There is a misunderstanding. Please ship EMBOSS-latest. BioLib uses the actual checkout of the CVS tree of EMBOSS, so I am even further ahead. As I understood the problem is that Embassy does not properly work against 6.3.1 - and should therefore either be dropped, or shipped with a working 6.2. Right? I meant to say that supporting Embassy, if that is not coming from the EMBOSS team itself, would be heroic. That is what I am asking on the EMBOSS-list - whether they intend to keep Embassy up to date, or not. BioLib does not use Embassy tools. Sorry for the misunderstanding. Pj. -- 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/20100813055513.ga4...@thebird.nl
Re: Debian Med Bioinformatics Sprint in Lübeck : post-install
I also enjoyed the conf. One result is a further collaboration on EMBOSS bindings to Perl, Python, Ruby and the JVM. > Cool - but what is rq? I can't find it in SVN nor on our tasks page. Brilliant tool for parallelized running of programs. Like Gridengine, or Torque, but *much* simpler to set up as it only requires one shared dir (not even ssh!). Wil run programs/scripts on a single multi-core, in a cluster, and in the cloud. I use it every day and have become part of 'upstream'. It is on Alioth in pkg-escience/rq-ruby1.8.git repo. I much prefer git over SVN. It is ready for upload, I think. > > * Pjotr's call to arms for better marketing, seconded by about everyone > > A, so Pjotr is our first marketing officier in the Debian Med team? > That would be really cool! I think with Tony they could really form a > strike force. :-) In fact we have started with the BMC paper, and an upcoming book chapter. I think, apart from the natural packaging, the only really useful thing would be a Bioinformatics page on the Wiki. Which should include a short Howto for newbie packagers. As simple as possible, without all the choices and options. Debian packaging is presented in a too complicated way (to scientists, forgive the irony). That is killing. I am recording my learning steps, when I have time I may turn it into a Howto. But don't hold your breath. Thanks Steffen, Andreas and others. I found it inspiring to see people taking software deployment so seriously. Its importance is usually underestimated. It is important for science, and serious progress! Pj. -- 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/20110202092627.gb23...@thebird.nl
PAML
The PAML description says now: Description: Phylogenetic Analysis by Maximum Likelihood (PAML) PAML is a package of programs for phylogenetic analyses of DNA or protein sequences using maximum likelihood. . PAML is not good for tree making. It may be used to estimate parameters and test hypotheses to study the evolutionary process, when you have reconstructed trees using other programs such as PAUP*, PHYLIP, MOLPHY, PhyML, RaxML, etc. The second paragraphi, even though on PAML's website, is not completely accurate. I don't think it belongs in the general package description. If every package said what it is not... Pj. -- 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/20111002122952.ga19...@thebird.nl
MrBayes-3.2pre(svn r465)
Hi, I updated the MrBayes package for the upcoming 3.2 release. The mb build system migrated to autoconf and friends. The Debian package sits in git+ssh://pjotr-gu...@alioth.debian.org//srv/home/users/pjotr-guest/mrbayes.git On i386 it builds without sse, which may be wanted, but I think the Debian policy is to stick with compiler defaults. 64-bits sse is default. The MPI version now works properly. The old package used an invocation script, which is broken. Pj. -- 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/20111019125612.ga16...@thebird.nl
Bio Med with git
I did not want to mess with the SVN repo, so I used git. When I used the info on: http://debian-med.alioth.debian.org/docs/policy.html#git-tips the script /git/debian-med/setup-repository packagename "Description of the package" creates a repository on alioth, in my home dir, not on git.debian.org. I suppose it has to be moved by you, or something? I do favor git over subversion, but I also realise the Bio Med team makes good use of a single SVN repository. I did not want to overwrite the existing mrbayes package. Would it have been OK to create mrbayes3.2pre on the trunk? Or should it be an SVN branch? I think it is easier to review my work on the SVN trunk. Pj. -- 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/20111019130505.gb16...@thebird.nl
EU Codefest (Bio) Italy July 2012
We are organising a 2 day codefest near Bergamo: http://www.open-bio.org/wiki/EU_Codefest_2012 Registration http://tecnoparco.org/codefest It will be fun! Debian packagers can work together, and get others involved. If you don't come, please pass this on to anyone interested in hooking up with Bio-* programmers. Three main topics will be worked on during the CodeFest: NGS and high performance parsers for OpenBio projects. RDF and semantic web for bioinformatics. Bioinformatics pipelines definition, execution and distribution. other tracks are welcome! Pj. -- 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/20120610073526.ga32...@thebird.nl
Re: guix-based installation of pigx-rnaseq - works
On Tue, Feb 23, 2021 at 09:28:48PM +0100, Steffen Möller wrote: > Hello, > > sudo apt-get install guix > guix install pigx-rnaseq :) > indeed installs the pigx-rnaseq library with its R dependencies. It > installs it all in /gnu, which is somewhat inconvenient, as in "my root > partition complained", and it takes painstakingly long, but it works. > > The system finds STAR and other executables in the regular system path, > only pigx-rnaseq was installed: > > $ guix package -l > Generation 1 Feb 23 2021 18:27:42 (current) > pigx-rnaseq 0.0.10 out > /gnu/store/nlknrjmm2knbr8i5m5qj94788arfb14n-pigx-rnaseq-0.0.10 > > The full install "pigx" I have not tried, yet. Will do. > > We keep mentioning conda also the time, while guix is somewhat left > aside, but https://guix.gnu.org/packages/ is truly impressive. Somewhat > annoying, if we ever decide to also reference guix packages in > d/u/metadata, then there are only versioned web pages like > https://guix.gnu.org/de/packages/bc-1.07.1/, so we would only have > moving targets point to. > > But otherwise, Debian's guix package has formidably done its job. It is > about time we get the conda packages into a similar state, just maybe > the / partition should be spared by default, but then again, it was only > 6.5GB. > > I had tried in vain to create a dockerfile with this setup which gets a > permission error in the moment that the installation of the packages starts: > > FROM debian:unstable > ENV TERM=xterm > RUN apt-get update -qq > RUN apt-get install -y guix > #RUN (/usr/bin/guix-daemon --build-users-group=_guixbuild & ) && guix > install pigx-rnaseq > #RUN (/usr/bin/guix-daemon & ) && guix install pigx-rnaseq # too big to fail > RUN (/usr/bin/guix-daemon & ) && guix install vim # still takes long and > fails The guix-daemon needs full privileges by default, but it does not need to run inside a container. Just build a docker or guix container and you'll get a minimal dependency tree inside the container. I wrote some stuff up here: https://github.com/pjotrp/guix-notes/blob/master/CONTAINERS.org mostly because I don't trust my memory ;) > Should this trigger any idea among those reading this - some RTFM plus a > small pointer would be much appreciated. Note that Guix is a rolling distribution. It can do that because versions do not interfere with each other. You can have an unlimited number of glibcs, pythons etc. The reason it installs software in /gnu/store is because of reproducibility. All paths are hard coded in binaries and libs. There is no search path to look up libs, for example. Install a package once and you'll get identical paths between machines, containers etc. I love Debian, but Guix packages and containers are the cats whiskers! It is brilliant to have them both. I have no need for conda. Pj.
Re: vcflib does not install scripts - missing bgziptabix
The vcflib installer drops the R scripts https://github.com/vcflib/vcflib/blob/master/CMakeLists.txt#L189 not sure you'd want those? Pj. On Sun, May 23, 2021 at 03:47:02PM +0200, Michael R. Crusoe wrote: >Thanks for catching this, Steffen! >A bug report would be appreciated, so we don't lose track of this. >-- >Michael R. Crusoe > >On Sun, May 23, 2021, 14:51 Steffen Möller <[1]steffen_moel...@gmx.de> >wrote: > > Hello, > cudaSV needs bgziptabix to be happy, which is how I became aware fo > all > the scripts in > Med/libvcflib$ ls scripts/ > bed2region plotXPEHH.R vcfindelproximity > vcfnulldotslashdot vcfregionreduce_and_cut > bgziptabix vcf2bed.py vcfindels > vcfplotaltdiscrepancy.r vcfregionreduce_pipe > plotBfst.R vcf2sqlite.pyvcfjoincalls > vcfplotaltdiscrepancy.sh vcfregionreduce_uncompressed > plotHaplotypes.R vcfbiallelic vcfmultiallelic > vcfplotsitediscrepancy.r vcfremovenonATGC > plotHapLrt.R vcfclearid vcfmultiway > vcfplottstv.sh vcfsnps > plotPfst.R vcfclearinfo vcfmultiwayscripts > vcfprintaltdiscrepancy.r vcfsort > plot_roc.r vcfcomplex vcfnobiallelicsnps > vcfprintaltdiscrepancy.sh vcf_strip_extra_headers > plotSmoothed.R vcffirstheader vcfnoindels > vcfqualfilter vcfvarstats > plotWCfst.R vcfgtcompare.sh vcfnosnps > vcfregionreduce > Med/libvcflib$ du -sh scripts/ > 399Kscripts/ > being plain missing in libvcflib1 . Should there be a libvcflib-bin > package? These scripts are expected to install together with vcflib, > so > maybe having them recommended is a good idea? The vcftools package > is > something independent. > debian/rules removes *.R files, so someone on this list knows more > about > it all than me, please give some directions. > Best, > Steffen > > References > >1. mailto:steffen_moel...@gmx.de
Re: vcflib does not install scripts - missing bgziptabix
Dear Steffen, I am looking at https://packages.debian.org/sid/amd64/libvcflib-tools/filelist and the R scripts are there. I think it is strange that many tools get installed in /usr/lib/vcflib/bin/ though. Is this policy? The man pages cover them all. wdyt? Pj. On Sun, May 23, 2021 at 05:02:01PM +0200, Pjotr Prins wrote: > The vcflib installer drops the R scripts > > https://github.com/vcflib/vcflib/blob/master/CMakeLists.txt#L189 > > not sure you'd want those? > > Pj. > > On Sun, May 23, 2021 at 03:47:02PM +0200, Michael R. Crusoe wrote: > >Thanks for catching this, Steffen! > >A bug report would be appreciated, so we don't lose track of this. > >-- > >Michael R. Crusoe > > > >On Sun, May 23, 2021, 14:51 Steffen Möller <[1]steffen_moel...@gmx.de> > >wrote: > > > > Hello, > > cudaSV needs bgziptabix to be happy, which is how I became aware fo > > all > > the scripts in > > Med/libvcflib$ ls scripts/ > > bed2region plotXPEHH.R vcfindelproximity > > vcfnulldotslashdot vcfregionreduce_and_cut > > bgziptabix vcf2bed.py vcfindels > > vcfplotaltdiscrepancy.r vcfregionreduce_pipe > > plotBfst.R vcf2sqlite.pyvcfjoincalls > > vcfplotaltdiscrepancy.sh vcfregionreduce_uncompressed > > plotHaplotypes.R vcfbiallelic vcfmultiallelic > > vcfplotsitediscrepancy.r vcfremovenonATGC > > plotHapLrt.R vcfclearid vcfmultiway > > vcfplottstv.sh vcfsnps > > plotPfst.R vcfclearinfo vcfmultiwayscripts > > vcfprintaltdiscrepancy.r vcfsort > > plot_roc.r vcfcomplex vcfnobiallelicsnps > > vcfprintaltdiscrepancy.sh vcf_strip_extra_headers > > plotSmoothed.R vcffirstheader vcfnoindels > > vcfqualfilter vcfvarstats > > plotWCfst.R vcfgtcompare.sh vcfnosnps > > vcfregionreduce > > Med/libvcflib$ du -sh scripts/ > > 399Kscripts/ > > being plain missing in libvcflib1 . Should there be a libvcflib-bin > > package? These scripts are expected to install together with vcflib, > > so > > maybe having them recommended is a good idea? The vcftools package > > is > > something independent. > > debian/rules removes *.R files, so someone on this list knows more > > about > > it all than me, please give some directions. > > Best, > > Steffen > > > > References > > > >1. mailto:steffen_moel...@gmx.de >
Re: vcflib does not install scripts - missing bgziptabix
Isn't namespace pollution something that comes up when you have a conflict? What is the chance of vcfallelicprimitives getting into a conflict? It would have to be another VCF toolkit ;) On Tue, May 25, 2021 at 07:41:46PM +0200, Steffen Möller wrote: > Dear Pjotr, > > Am 25.05.21 um 19:18 schrieb Pjotr Prins: > > I am looking at > > > > https://packages.debian.org/sid/amd64/libvcflib-tools/filelist > > > > and the R scripts are there. I think it is strange that many tools get > > installed in /usr/lib/vcflib/bin/ though. Is this policy? The man > > pages cover them all. > > > > wdyt? > > Thank you for spotting them. My hunch is that Michael wanted to avoid > name clashess - the vcftools package for instance also has vcf-sort, > just with a hypthen and there may be others forthcoming who then all > fight for their position in /usr/bin. > > The policy is to hide away those executables that are meant for > "internal use". So, I tend to think that this move was a bit too much on > the side of caution. > > So, I think that we should come up with yet another package, called > "vcflib" that drags in libvcflib-tools as an architecture-dependend > dependency and that ships the scripts in /usr/bin. For the moment I am > not sure about what to do about the binaries hidden away. I prefer > shipping them in /usr/bin but it is Michael's package and I would want > him to greenlight this first. > > Best, > Steffen > > > > > On Sun, May 23, 2021 at 05:02:01PM +0200, Pjotr Prins wrote: > >> The vcflib installer drops the R scripts > >> > >> https://github.com/vcflib/vcflib/blob/master/CMakeLists.txt#L189 > >> > >> not sure you'd want those? > >> > >> Pj. > >> > >> On Sun, May 23, 2021 at 03:47:02PM +0200, Michael R. Crusoe wrote: > >>>Thanks for catching this, Steffen! > >>>A bug report would be appreciated, so we don't lose track of this. > >>>-- > >>>Michael R. Crusoe > >>> > >>>On Sun, May 23, 2021, 14:51 Steffen Möller <[1]steffen_moel...@gmx.de> > >>>wrote: > >>> > >>> Hello, > >>> cudaSV needs bgziptabix to be happy, which is how I became aware fo > >>> all > >>> the scripts in > >>> Med/libvcflib$ ls scripts/ > >>> bed2region plotXPEHH.R vcfindelproximity > >>> vcfnulldotslashdot vcfregionreduce_and_cut > >>> bgziptabix vcf2bed.py vcfindels > >>> vcfplotaltdiscrepancy.r vcfregionreduce_pipe > >>> plotBfst.R vcf2sqlite.pyvcfjoincalls > >>> vcfplotaltdiscrepancy.sh vcfregionreduce_uncompressed > >>> plotHaplotypes.R vcfbiallelic vcfmultiallelic > >>> vcfplotsitediscrepancy.r vcfremovenonATGC > >>> plotHapLrt.R vcfclearid vcfmultiway > >>> vcfplottstv.sh vcfsnps > >>> plotPfst.R vcfclearinfo vcfmultiwayscripts > >>> vcfprintaltdiscrepancy.r vcfsort > >>> plot_roc.r vcfcomplex vcfnobiallelicsnps > >>> vcfprintaltdiscrepancy.sh vcf_strip_extra_headers > >>> plotSmoothed.R vcffirstheader vcfnoindels > >>> vcfqualfilter vcfvarstats > >>> plotWCfst.R vcfgtcompare.sh vcfnosnps > >>> vcfregionreduce > >>> Med/libvcflib$ du -sh scripts/ > >>> 399Kscripts/ > >>> being plain missing in libvcflib1 . Should there be a libvcflib-bin > >>> package? These scripts are expected to install together with vcflib, > >>> so > >>> maybe having them recommended is a good idea? The vcftools package > >>> is > >>> something independent. > >>> debian/rules removes *.R files, so someone on this list knows more > >>> about > >>> it all than me, please give some directions. > >>> Best, > >>> Steffen > >>> > >>> References > >>> > >>>1. mailto:steffen_moel...@gmx.de >
Re: Should sambamba be uploaded at this stage?
Hi Nilesh, Sambamba co-author here. On Wed, Jul 21, 2021 at 02:47:17AM +0530, Nilesh Patra wrote: > Hi, > > It came to my notice that sambamba does not list copyright holders, > and copyrgiht holders of several files are missing. > > I wonder if this is a RC bug, since I've seen a few of these earlier, > for example #823865 > > I fixed the copyright stuff, but along with that I did a bunch of other > changes: I'll add those fixes upstream. > - Repacked shunit2, since it makes no sense to vendor an embedded copy > - Added autopkgtests > - Minor changed to d/watch, d/salsa-ci.yml > - Added d/gbp.conf > - Fixed an override > > All changes on salsa > > Also, I see here[1] that sambamba builds only on amd64 and arm64 because > of missing B-D - so should supported arches in d/control be changed to > only these two? Yes, please. I know we aim for all architectures, but no one runs sambamba on less that 64 bits, so we have not supported that. > Similar changes in "Architecture" field in d/tests/control > > I do not have more time to spend with this package, so if @Andreas, > @Etienne, someone else could > revert/add/edit a few changes and sponsor me an upload, I'd really > appreciate that provided this is an RC bug (which I think it is) > > [1]: https://buildd.debian.org/status/package.php?p=sambamba > > Nilesh Tell me what I can do upstream. Pj.
Re: Should sambamba be uploaded at this stage?
On Wed, Jul 21, 2021 at 12:23:44PM +0200, Steffen Möller wrote: > > Yes, please. I know we aim for all architectures, but no one runs > sambamba on less that 64 bits, so we have not supported that. > >all other 64bit platforms would be fine? Like PPC64, mips64el, sparc64, >and riscv64? These are just unofficial platforms >([1]https://wiki.debian.org/SupportedArchitectures) but I suggest not >to exclude them. Untested, but may work. The BAM format is little-endian, so that may be an issue on some. > Tell me what I can do upstream. > >Praise the package on your home page with a badge once your are happy >with it :) > [3]https://badges.debian.net/badges/debian/unstable/sambamba/version.svg there is a badge already!
sambamba and freebayes new releases
Dear all, We release sambamba and freebayes with updated meson build systems. It should work for Debian. If not I am happy to troubleshoot. Pj.
vcflib new release
thanks Andreas! I also bumped vcflib https://github.com/vcflib/vcflib/releases/tag/v1.0.3 It should build as before. On Fri, Jan 21, 2022 at 12:17:00PM +0100, Andreas Tille wrote: > Am Fri, Jan 21, 2022 at 11:45:48AM +0100 schrieb Pjotr Prins: > > We release sambamba and freebayes with updated meson build systems. It > > should work for Debian. If not I am happy to troubleshoot. > > $ apt policy sambamba > sambamba: > Installed: (none) > Candidate: 0.8.2+dfsg-1 > Version table: > 0.8.2+dfsg-1 501 > 501 http://deb.debian.org/debian testing/main amd64 Packages > 50 http://deb.debian.org/debian unstable/main amd64 Packages > > $ $ dput freebayes_1.3.6-1_source.changes > Uploading freebayes using ftp to ftp-master (host: ftp.upload.debian.org; > directory: /pub/UploadQueue/) > running allowed-distribution: check whether a local profile permits uploads > to the target distribution > running protected-distribution: warn before uploading to distributions where > a special policy applies > running checksum: verify checksums before uploading > running suite-mismatch: check the target distribution for common errors > running gpg: check GnuPG signatures before the upload > signfile dsc freebayes_1.3.6-1.dsc ti...@debian.org > > fixup_buildinfo freebayes_1.3.6-1.dsc freebayes_1.3.6-1_amd64.buildinfo > signfile buildinfo freebayes_1.3.6-1_amd64.buildinfo ti...@debian.org > > fixup_changes dsc freebayes_1.3.6-1.dsc freebayes_1.3.6-1_source.changes > fixup_changes buildinfo freebayes_1.3.6-1_amd64.buildinfo > freebayes_1.3.6-1_source.changes > signfile changes freebayes_1.3.6-1_source.changes ti...@debian.org > > Successfully signed dsc, buildinfo, changes files > Uploading freebayes_1.3.6-1.dsc > Uploading freebayes_1.3.6.orig.tar.gz > Uploading freebayes_1.3.6-1.debian.tar.xz > Uploading freebayes_1.3.6-1_amd64.buildinfo > Uploading freebayes_1.3.6-1_source.changes > > > So sambamba seems to be the latest version in testing and freebayes > should follow soon. > > Thanks a lot for pinging here which is really welcome > >Andreas. > > -- > http://fam-tille.de >
tabixpp
I just bumped with an htslib fix: https://github.com/vcflib/tabixpp/releases/tag/v1.1.1 If there is a problem ping me. Pj.
