Re: Please check packaging of new version of snakemake
Hi Andreas, On 17:58 09/01, Andreas Tille wrote: > Hi Kevin, > > I noticed that there is a new version of snakemake and I updated the Git > repository accordingly. Thanks, and sorry for not getting back to you till now. > Strangely enough I had to inject a hack to run the build time tests. Since > there is no such binary bin/snakemake any more inside the upstream tarball I > injected what's ending up inside the binary package via a quilt patch. This > seems to work but is so hackish that I would like to let another pair of > eyeballs having a look whether there might be a more appropriate solution. I've checked what you do, and AFAICT all is well. So long as the patch-introduced bin/snakemake is never installed, I think all is well. One note on the patch: that's an auto-generated binary you've patched in, which has a bunch of stuff hard-coded (versions etc). This will break with the next version, and be a real pain to keep the patch up to date. I've pushed a functionally equivalent but more general patch, which should be better. > Feel free to upload once you are happy with the package - any tests with real > data are welcome for sure. All seems well with a simple workflow of mine, so it *should* all work fine. Fingers crossed! Happy sprinting all! Cheers, K --- Kevin Murray signature.asc Description: PGP signature
Re: libzstd 1.1.2 contains embedded zlib fork
Hi all, On 16:50 13/01, Sascha Steinbiss wrote: > Hi Kevin, > > here on the Debian Med sprint Happy Sprint all! Shame I can't be there this year. > I was looking to update libzstd to the current upstream version 1.1.2. > Besides some minor changes to the patches I had to make, I also noticed that > it now includes an embedded copy of some zlib code, which -- according to the > inline comments -- was adapted to be ready to compile with the zlibwrapper. > It wasn’t clear to me whether this was really necessary; when these files are > removed from the affected Makefile (and some minor adjustments are made) the > build still finishes fine. That's been there since 1.1 I think, and is AFAICT example code for an alternative, non-packaged API that mimics the zlib API. It could be packaged under libzstd-dev:usr/share/doc/libzstd-dev/examples or something, like I've seen with a few development packages. Otherwise, I think nuking the sources or just removing them from the makefile is fine. Though from memory, anything compiled from these is not installed, so no action is probably also OK. > TBH I don’t feel I should upload this after consulting with you. I have > pushed my changes (tagged as UNRELEASED) and would be happy if you could take > a second look. AFAICT, running make in the package repo (i.e. unpatched upstream source) doesn't touch ./zlibWrapper, and none of the debian packages seem to have any trace of these sources. So I'm not sure, but I think any action (including doing nothing) should be fine, as these sources are inconsequential to any output, compiled or otherwise. What does the DFSG say about sources that are not compiled? They're in d/copyright anyway, IIRC FTPMASTER bounced me last update for this exact issue, and I added them. Happy hacking all! Cheers, K --- Kevin Murray signature.asc Description: PGP signature
Re: [Debian-med-packaging] Bug#841560: Could anybody please check the issue in python-skbio
Hi all, AFAICT I think I should have fixed the issues in skbio. I've filed an ROM bug, and updated to latest upstream. Could I please get an upload and see if the test failure goes away? Cheers, Kevin --- Kevin Murray
Re: [Debian-med-packaging] Bug#841560: Bug#841560: Could anybody please check the issue in python-skbio
Hi Andreas, On 19:15 15/11, Kevin Murray wrote: > I will also (but haven't yet) see if I can get it to build against libssw. Well that turned out to be far easier than I expected. I've pushed a patch that uses libssw from debian. So let's see if this fixes the build. And we also need to remove the old binary pkgs from the archive, I think (or whatever the reason is for the package being stuck in sid). Cheers, K --- Kevin Murray
Re: [Debian-med-packaging] Bug#841560: Could anybody please check the issue in python-skbio
Hi Andreas, On 08:49 15/11, Andreas Tille wrote: > could anybody check the issue in the skbio test suite? I've packaged the latest upstream, and uploaded. Let's see if this fixes the build. I will also (but haven't yet) see if I can get it to build against libssw. There are also old binary packages preventing a testing transition, which I'm not sure how to deal with. Cheers, K --- Kevin Murray
Re: Status of seqan2
Hi Andreas, On 16:55 06/08, Andreas Tille wrote: > Hi Kevin, > > On Sat, Aug 06, 2016 at 07:49:27PM +1000, Kevin Murray wrote: > > It appears I have got SeqAn to build. Looks as though they changed the name > > of > > one of their seqan-specific cmake options. I fixed d/rules and the build > > appears to succeed. However the only machine I currently have access to that > > has sufficient RAM & disk space is running Ubuntu 14.04, and therefore the > > lintian is way out of date. So I can't comment as to the correctness and > > cleanliness of the package, but I've pushed my change. > > It builds for me as well. Lintian claims some JS without source in >util/py_lib/seqan/dox/tpl/lib/ > I'll see what I can do about this. I raised this with upstream in [1]. They seem to think that it is required for building the docs. Perhaps we can consult w/ upstream and see if we can convince them to use non-minified sources. I see little need for their docs to use size-optimised JS, at least within debian. There are also some compiled Flash objects (*.swf). Cheers, K [1]: https://github.com/seqan/seqan/issues/1820 --- Kevin Murray 0xA4B4EE6A
Re: Status of seqan2
Hi Andreas, It appears I have got SeqAn to build. Looks as though they changed the name of one of their seqan-specific cmake options. I fixed d/rules and the build appears to succeed. However the only machine I currently have access to that has sufficient RAM & disk space is running Ubuntu 14.04, and therefore the lintian is way out of date. So I can't comment as to the correctness and cleanliness of the package, but I've pushed my change. Hope that helps, Cheers, K --- Kevin Murray 0xA4B4EE6A
Re: Status of seqan2
Hi Andreas, My apologies, this week is very busy. I've pulled the repo, and will try getting it to build. I'll push any commits I make immediately. It may still be worth asking debian-mentors, as A), I might not find a solution, and B), I might not get time to experiment with this fully. Sorry for my lack of responses/work on this. CHeers, K On 22:10 04/08, Andreas Tille wrote: > Hi folks, > > the fact that nobody raised an idea might mean I should ask on > debian-mentors for cmake help, right? > > Kind regards > > Andreas. > > On Wed, Aug 03, 2016 at 10:22:25PM +0200, Andreas Tille wrote: > > Hi Sascha, > > > > On Wed, Aug 03, 2016 at 05:15:15PM +0100, Sascha Steinbiss wrote: > > > > is it correct to assume that packaging seqan2 version 2.2 instead of 2.1 > > > > is the right way to go and should I help doing so? > > > > > > Well, if I could make a wish, then I would say 2.2 for sure! I have a > > > half-ready package for the free fast BLAST replacement Lambda [1] and > > > upstream states that current releases will 'work with the last official > > > SeqAn release' so I guess that would be 2.2. It would be great to get to > > > finish this ;) > > > > OK, I tried and the Git repository now contains SeqAn2 2.2 - but the > > build process does not start properly. Anybody with cmake knowledge > > might hopefully be able to help ... > > > > Kind regards > > > >Andreas. > > > > > [1] https://github.com/seqan/lambda > > > > > > > On Tue, Aug 02, 2016 at 09:10:27AM +0200, Andreas Tille wrote: > > > >> On Thu, Jul 21, 2016 at 12:52:54PM +1000, Kevin Murray wrote: > > > >>> > > > >>> There were many complex merge conflicts between master and upstream. > > > >>> It was > > > >>> actually a lot easier to resolve than I expected. It's now ready for > > > >>> review. > > > >>> However, it would be great if someone could take a close look at the > > > >>> package, > > > >>> particularly to ensure that the source is exactly what upstream > > > >>> provides (I've > > > >>> tried to check this with git, and I think I got it right, but more > > > >>> experienced > > > >>> eyes may differ). > > > >> > > > >> When trying to compare Upstream with the Git archive I stumbled upon > > > >> the > > > >> first question: Any reason to stick to version 2.1.0 if 2.2.0 is out? > > > >> May be the question is naive, but if we have trouble managing a single > > > >> seqan version (we failed to fix bugs for a long time) and now agreed > > > >> upon the need for two versions - old 1.4.2 (see my other mail) and 2.x > > > >> series, does the status of the Git repository mean you intend to > > > >> package > > > >> 2.1 and 2.2 separately? > > > >> > > > >>>>> Shall we start with a "simple" libseqan2-dev package with the > > > >>>>> latest upstream > > > >>>>> version (2.2.0)? I'll see if I can build on Michael's work in the > > > >>>>> seqan2 > > > >>>>> package. > > > >>>> > > > >>>> Yes, please keep it as simple as possible (but not simpler :-P ). > > > >>> > > > >>> Working on this now. There are already a couple of errors, so we'll > > > >>> see how I > > > >>> go. I'll try to push early and often, so don't assume that the repo > > > >>> is in a > > > >>> working state :). > > > >> > > > >> No visible commit since > > > >> > > > >> commit 003f498e234ecc31229f6ba624c9d1afc6618d0d > > > >> Author: Kevin Murray <s...@kdmurray.id.au> > > > >> Date: Thu Jul 21 17:54:39 2016 +1000 > > > >> > > > >> Did you pushed regularly? Please git pull - I've fixed Vcs fields. > > > >> > > > >> Kind regards > > > >> > > > >> Andreas. > > > >> > > > >> -- > > > >> http://fam-tille.de > > > >> > > > >> > > > > > > > > > > > > > -- > > > The Wellcome Trust Sanger Institute is operated by Genome Research > > > Limited, a charity registered in England with number 1021457 and a > > > company registered in England with number 2742969, whose registered > > > office is 215 Euston Road, London, NW1 2BE. > > > > > > > > > > -- > > http://fam-tille.de > > > > > > -- > http://fam-tille.de > --- Kevin Murray 0xA4B4EE6A
Re: Seqan2 (Was: Thanks to Gert and Sascha - other please keep on fixing bugs)
Hi Andreas, (Sorry, our mails seem to have crossed in the ether!) On 15:12 22/07, Andreas Tille wrote: > Hi Sascha, > > On Fri, Jul 22, 2016 at 01:40:40PM +0100, Sascha Steinbiss wrote: > > > > > > - refers to v1.4, AFAIK version 2.0 is already in the archive, so this > > > one should probably me closed. > > > > I don't think it is [1]. Anyway, AFAICS SeqAn 2.0 is intended to go into > > a separate package seqan2 instead? Some of the recent mails here on this > > list seem to indicate that? > > The seqan repo in Git has 2.0 already merged into master but not > > uploaded yet. Can anybody clarify please? > > My *personal* and *totally* uneducated opinion about seqan is that we > should *not* try to maintain two versions of seqan - specifically not an > old an currently RC buggy version. Thus it would be better to keep the > name seqan also for version 2.x. > And for my similarly personal and uneducated opinion: I'd love this to be true, but it could be a little optimistic. See below. > > If there is going to be a new repo for seqan2 because of API changes I > > think it might be worth fixing the GCC6 FTBFS in the 'old' (1.4) seqan > > package to make sure that important tools depending on 1.4 (such as > > bowtie, tophat, ...) stay in testing. > > What do you think? > > Seqan API has changed in minor 1.x versions as well and we managed to > patch the said tools. I'm simply hoping we can follow this strategy > also for seqan 2.x. Thus my suggestion to upload seqan 2.x as fast as > possible to experimental and see what we can do for the dependencies. > > Please note: I'm not deeply involved in all the internals and my > opinion might be at best naive, maybe totally wrong. However, it seems > that we do not have the power to maintain seqan 1.4 over a long time > (several releases). > >From my somewhat limited experience, the 1.x -> 2.x changes are quite fundamental. Like introducing entirely ways of doing certain things, e.g. any sequence file IO. I think that you're correct for trivial uses or changes that are easily handled with sed (and we should patch away to our hearts' content). But I am almost certain that there will be packages where much manual work is required as API changes are non trivial. There are also these facts to consider: a), seqan 1.x is on it's final minor release, and shouldn't be needing much updating at least from upstream. and b), upstream tool developers will *eventually* have to move to 2.x of their own accord and having the folks who wrote the tools do the API transition is better for all concerned. All in all, I think that having seqan 1.x in Stretch makes sense. Certainly, we should deprecate it, and be proactive encouraging upstreams to migrate to 2.x, but the burden of fixing a few GCC 6 FTBFS sounds a lot less to me than patching a bunch of tools that are stuck with the 1.x API. All $0.02's welcome, I'm hardly an expert in any of this. (Particularly ping @mr-c) Cheers, K --- Kevin Murray 0xA4B4EE6A
Re: Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))
Hi Sascha, On 13:40 22/07, Sascha Steinbiss wrote: > Hi all, > > [...] > > #811841 seqan: FTBFS with GCC 6: no match for > > > > - refers to v1.4, AFAIK version 2.0 is already in the archive, so this > > one should probably me closed. > > I don't think it is [1]. Anyway, AFAICS SeqAn 2.0 is intended to go into > a separate package seqan2 instead? Some of the recent mails here on this > list seem to indicate that? > The seqan repo in Git has 2.0 already merged into master but not > uploaded yet. Can anybody clarify please? > > If there is going to be a new repo for seqan2 because of API changes I > think it might be worth fixing the GCC6 FTBFS in the 'old' (1.4) seqan > package to make sure that important tools depending on 1.4 (such as > bowtie, tophat, ...) stay in testing. > What do you think? > > Thanks > Sascha > > [1] https://packages.debian.org/source/unstable/seqan Andreas/Michael may remember differently, but from memory we will have: - SeqAn 1.x in src:seqan -> seqan-dev (only, no apps) - SeqAn 2.x in src:seqan2 -> libseqan2-dev and seqan-apps (and one day -doc) So yes, I agree with you. Seqan 1.x (i.e. src:seqan) should be made to build correctly and not get booted from testing (and git should be reverted such that it contains only 1.x). Especially while the likes of bowtie & tophat rely upon them. (Though for smaller tools, providing patches to get them to build with seqan 2.x shouldn't be monumentally difficult and should be qulte upstream-able). Cheers, K --- Kevin Murray 0xA4B4EE6A
Re: Doc package in seqan remains empty
Hi Guys, On 18:39 22/01, Michael Crusoe wrote: > I'll email the team; am trying to build a partnership with them for other > reasons. > > Vin, 22 ian. 2016, 16:45, Andreas Tille <andr...@an3as.eu> a scris: > > > Hi Kevin, > > > > I worked a bit on seqan and injected the latest upstream version > > (2.0.1). I have no idea whether the seqan-doc package that was injected > > by you worked in 2.0.0 but now it remains empty. I also admit I have no > > idea how to create the docs (either in dox or manual or both?). > > Doh! I was actually working on this on the plane yesterday. The doc build kind of works once the dependencies are fulfilled. I have a (apparently stalled) request to add the packages I have made to the DPMT. > > Could anybody with upstream contact please clarify? > > > > I also noticed that if we want to deal with the docs need to care for > > several *.js files without source. > > I propose a couple of options: 1: We can drop the docs package, upload 2.0.1 with just libseqan-dev and get a modern seqan into Debian now. Then deal with the docs at a later date (once DPMT uploads packages etc). 2: Just keep the python deps under Debian Med and make a seqan-docs-dev package containing their custom python module and associated javascript. This would get the docs in sooner, but seems a bit of a kludge to me (and goes against the DPMT's request to maintain the python deps in their team, which I think we can all agree is where they belong). You may have figured I would prefer option 1 above for now. I can help with this next week. Cheers, Kevin -- who is at last on the same continent as you guys --- Kevin Murray 0xA4B4EE6A
Re: Debmed sprint ?
Hi all, On 13:56 04/11, Andreas Tille wrote: > Hi Olivier, > > On Wed, Nov 04, 2015 at 01:52:26PM +0100, Olivier Sallou wrote: > > I unfortunately won't be part of the sprint this year :-( > > I happens when our holidays start, and I already have planned stuff with > > my kids at this date. > > I guess we need at least two new sprint members to replace you ;-) but > as always family has preference before volunteer work. > Speaking of new sprint members, I'm hoping to attend. Haven't booked tickets but am 90% sure I'll be there. Cheers, K --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A
Re: Seqan moved from svn to Git
Hi Andreas, Sorry, it seems your email got lost in my inbox. On 15:33 08/09, Andreas Tille wrote: > Hi, > > I do also have access to some larger Jessie machine but here the build > failed quite quickly: > > ... > -- Configuring tests/cuda > CMake Error at util/cmake/SeqAnBuildSystem.cmake:395 (cmake_parse_arguments): > Unknown CMake command "cmake_parse_arguments". > Call Stack (most recent call first): > tests/cuda/CMakeLists.txt:26 (seqan_setup_cuda_vars) > > > -- Configuring incomplete, errors occurred! > See also > "/tmp/buildd/seqan-2.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log". > dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr > -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None returned exit code 1 > debian/rules:19: recipe for target 'build' failed > ... > > > As far as I understand > >manual/source/BuildManual/UsingFindSeqAnCMakeModule.rst > > and > >util/cmake/SeqAnBuildSystem.cmake > > SEQAN_HAS_CUDA should be autodetected. > > Any idea? > I'm re-building this in pbuilder, and will keep you posted. On a separate note, what do you think of the idea of having a different binary package for each of the seqan applications, as opposed to one big seqan-apps. Cheers, K --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A
Easy to fix bug-popping
Andreas, On 09:54 29/07, Andreas Tille wrote: snip BTW, about my pace: I'm more and more realising that it does not scale if I do the large amount of bug fixing in the Debian Med team[1]. Since I'm currenly at home (this time will end next week) I fixed more than one bug per day. We have *lots* of easy to fix targets. If a newcomer would try to fix two bugs per month he would make it into the bugs statistics[1] after one years. I bet there are more than 24 easy targets at belonging to the Debian Med team[2]. Sorry for hijacking the thread. I'm keen to get a bit further involved in Debian in general, and Debian Med in specific. Is there some list you have of easy to fix bugs which you would like assistance with? As a PhD student I don't have heaps of time, but enough to fix a bug or two a month ;). Cheers, Kevin --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A -- 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/20150729082416.gl2...@klaptop.kdmurray.id.au
Re: Seqan moved from svn to Git
Hi Andreas, I have a couple of large Debian Jessie machines, will give it a go there. Cheers, Kevin On 10:43 09/07, Andreas Tille wrote: Hi Michael (and others who would like to help with seqan upgrade), as promised some time ago I now migrated seqan SVN repository to Git with some loss of old tags and a bit broken Jessie branch - but I think we should focus on the future and not on the past. When doing so I spotted and fixed a git-svn issue I need to report and I do not want to spent more time in old code history. It would be great if somebody with a powerfull machine could give it a try (I hope next week I'll have access to a speedy Debian machine as well). We should try to get version 2.0.0 out for experimental first and try to rebuild seqan dependencies against this (which usually creates trouble for all upgrades since consumers of seqan follow the habit to use aged code copies and stick to these). Any help would be welcome 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/20150709084324.gh1...@an3as.eu --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A -- 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/20150709115725.ga2...@klaptop.kdmurray.id.au
Bug#791395: ITP: wgsim -- Simulate whole-genome sequencing data
package: wnpp Severity: wishlist Owner: 'Kevin Murray' s...@kdmurray.id.au *Package Name : wgsim Version : 0.3.1-r13 Upstream Author : Heng Li *URL : https://github.com/lh3/wgsim *License : MIT *Description : wgsim simulates sequencing reads from a reference genome. Wgsim is a small tool for simulating sequence reads from a reference genome. It is able to simulate diploid genomes with SNPs and insertion/deletion (INDEL) polymorphisms, and simulate reads with uniform substitution sequencing errors. It does not generate INDEL sequencing errors, but this can be partly compensated by simulating INDEL polymorphisms. --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A -- 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/20150704095723.gb2...@klaptop.kdmurray.id.au
Re: Scythe in Debian Med Git
Hi Andreas, On 08:18 11/05, Andreas Tille wrote: Hi Kevin, please note that I'm forwarding my answer to the list. I would always advise to send questions like yours to the list since it enhances your chances to get an answer more quickly. Please always remember that Debian Med is a team and not a single person. Apologies, I absent-mindedly replied to you personally again. I'll endeavour to group-reply in future. snip I've added a get-orig-source rule to d/rules, which wgets a tarball using the github API. This tarball is specific to the git SHA hash of upstream's current master, which defined version 0.994 (i.e., will always download the same content, even if upstream's master changes). I hope this is acceptable. As a temporary solution until upstream might be convinced to do proper releases this is OK. It also serves for others as documentation how we obtained the tarball. OK, I'll leave it as is until Vince gets back to me about tagging a released version. snip To the package itself: I did a couple of minor changes and commited these. It would have been more work to describe what you should do than doing it quickly myself. Please check the log thoroughly. There is one remaining issue: You are creating the manpage at build time but the result is quite poor regarding line spacing etc. It also adds a ruby build-dependency. Could you please preprocess the manpage and commit it right to the debian/ dir after checking that the syntax is OK? OK, I have made a new and improved d/scythe.1 and removed the ronn-based system (including from build-depends, and d/rules). Is it worth doing something similar with the README.html which we now generate, to avoid a build-dep on python-markdown? Cheers, Kevin --- Kevin Murray GPG pubkey: http://www.kdmurray.id.au/static/A4B4EE6A.asc FPR: 656C 0632 1EAB 2C3F 3837 9767 17C2 8EB1 A4B4 EE6A -- 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/20150511072633.ga2...@klaptop.kdmurray.id.au
