Re: RFS: python3-typed-ast, hisat2

[Sascha Steinbiss]

Hi Michael,

I took a look at hisat2:

 - I would add:
  Copyright 1999, N. Jesper Larsson, all rights reserved.
   from ls.h to d/copyright
 - IMHO d/rules should have a ‘clean' override that removes the man pages built 
there
 - The watchfile doesn’t have any active entries? The following should work:
  opts=pasv \
  
ftp://ftp.ccb.jhu.edu/pub/infphilo/hisat2/downloads/hisat2-([0-9.]+)-source.zip
 - The package does not build reproducibly for me — likely because I have 
disorderfs enabled in my prebuilder setup, which is not the default. It might 
help wrapping the $(wildcard …) lines in the Makefile with $(sort …) etc. See 
https://reproducible-builds.org/docs/stable-inputs/.

and python3-typed-ast:

 - Lintian still warns about the (easy to fix):
  W: python3-typed-ast source: syntax-error-in-dep5-copyright line 25: 
Continuation line outside a paragraph (maybe line 24 should be " .”).
 - There are two license entries for ‘Files: *’ in d/copyright. From what I can 
see, only typed_ast/ast27.py and typed_ast/ast35.py are Python licensed, so it 
might be enough to set those two to License: Python, keeping the rest as Apache 
2.0?
 - Since the package seems to be quite generic, it may be better maintained 
with/in the DPMT [1]?
   What do you think?

Cheers and thanks for working on these
Sascha

[1] https://wiki.debian.org/Teams/PythonModulesTeam


> On 17 Aug 2016, at 16:56, Michael Crusoe  wrote:
> 
> Thanks!
> --
> Michael R. Crusoe
> Community Engineer & Co-founder
> Common Workflow Language project
> https://impactstory.org/u/-0002-2961-9670
> michael.cru...@gmail.com
> +40 720 781 765
> +1 480 627 9108



signature.asc
Description: Message signed with OpenPGP using GPGMail

CD-HIT binaries (Was: [GSoC] Help needed for verifying cd-hit test)

[Sascha Steinbiss]

Hi Andreas,

[...]
> Is there anybody who would
> expect to find a /usr/bin/cdhit executable in any scripts or should we
> rather rename to cd-hit to fit the upstream binary.

I remember that I had to patch upstream code a couple of times to change
the name of the CD-HIT/CD-HIT-EST binaries to match the Debian names
instead of upstream's ones. I'd need to update these then... it might
also help to keep both variants in, for instance the other one as a symlink?

Cheers
Sascga


-- 
 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. 

Re: trinityrnaseq in Git

[Sascha Steinbiss]

Hi Michael,

thanks! Just uploading a fixed version.

Cheers and have a nice weekend
Sascha

> On 5 Aug 2016, at 17:44, Michael Crusoe <michael.cru...@gmail.com> wrote:
> 
> Done, sorry about that!
> 
> [I forced pushed with your commit after mine]
> 
> On Fri, Aug 5, 2016 at 6:40 PM, Sascha Steinbiss <sa...@debian.org> wrote:
> Hi all,
> 
> I was going to look at the last GCC 6 FTBFS and trinityrnaseq looks like
> a good point to start. However, 2.2.0-dfsg-1 is already in unstable but
> still has UNRELEASED as distribution in Git... if there are any local
> changes left I would be happy if someone could push them :)
> 
> Cheers
> Sascha
> 
> 
> --
>  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.
> 
> 
> 
> 
> --
> Michael R. Crusoe
> Community Engineer & Co-founder
> Common Workflow Language project
> https://impactstory.org/u/-0002-2961-9670
> michael.cru...@gmail.com
> +40 720 781 765
> +1 480 627 9108



signature.asc
Description: Message signed with OpenPGP using GPGMail

trinityrnaseq in Git

[Sascha Steinbiss]

Hi all,

I was going to look at the last GCC 6 FTBFS and trinityrnaseq looks like
a good point to start. However, 2.2.0-dfsg-1 is already in unstable but
still has UNRELEASED as distribution in Git... if there are any local
changes left I would be happy if someone could push them :)

Cheers
Sascha


-- 
 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. 

Re: mummer patches

[Sascha Steinbiss]

Hi Fabian,

thanks for the patches!

> So I finally got round to submit my patches for MUMmer. One can be found
> in the repo, half of the other is attached to this mail. Unfortunately,
> the other half got lost in a code reindentation. Applying the changes
> requires refactoring src/tigr/sw_align.cc for the changes in the header.

Not really sure I understand what you mean... the patches in the repo's
series all apply without a problem and the one attached to your mail
doesn't seem to do a lot. Are you sure it is complete? Or where is the
other half one would be required to refactor?

> If someone has a lot of spare time on the weekend, feel free to go ahead.

Not that much spare time but I'd like to understand what I would be up
for ;)

Also, are the patches Debian-specific? Given that they don't seem to be
fixes but rather improve performance, I could imagine Stefan Kurtz
(MUMmer upstream) would probably appreciate receiving these patches as well.

Thanks
Sascha


-- 
 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. 

Re: Status of seqan

[Sascha Steinbiss]

Hi Andreas,

> 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 ;)

Cheers
Sascha

[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 
>> 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. 

Re: linuxbrew with homebrew/science - works!

[Sascha Steinbiss]

Hi all,

> It features an astonishing array of bioinformatics software and kind of
> saves what is left of my sanity to get our local HPC environment going.
> Our admins are "its in your home directory" fine with it.

Yes, I can see this is one of the main reasons for its popularity, and I
also use Homebrew on my work Mac since I don't have admin privileges there.

> I do not know what this means for Debian Med. It is a competition. And,
> with some early brain wash from the homebrew on the Mac I am now using
> on my desk, it also feels natural. Kind of nice is that the package
> names seem to be kept in sync with ours, e.g. I just noticed that STAR,
> our NGS aligner, is also called rna-star. And any such sync would be
> really nice to have so we can benefit from each other.

I think keeping package names in sync is indeed very thoughtful and a
good idea to do to reduce the amount of confusion and/or surprise to the
end user, who basicallu only has to use 'brew install' on one machine
and 'apt-get install' on the other.

Something I personally find interesting about Homebrew-science (but
others here may disagree) is that they apparently have a more relaxed
way of embracing upstream's way of distribution and building, which
seems to accelerate turnover time for packaging a lot. For example,
there is no requirement to build in a non-networked environment using
already packaged dependencies only. While I am aware of the security and
long-term maintainability considerations, this is difficult to beat for
the pure purpose of distribution and easy installability, and indeed I
have often seen their list of recipes contain new tools much earlier
than Debian.

Best
Sascha



-- 
 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. 

Re: Sorting our packages into Debian Med or Debian Science tasks

[Sascha Steinbiss]

Hi Andreas,

> I'm currently running an UDD query to detect not yet categorised
> packages[1] of ours and try to put them into tasks that might sound
> sensible.

Cool, I can also take a look later.

> I'm unsure whether we should add libhat-trie-dev to bio-dev
> task or some task in Debian Science or simply put it on the blacklist
> since its a predepency with no actual relevance for any task (be it
> in Debian Med or Debian Science).

In the case of hat-trie I'd say it's quite a generic data structure and
could probably transcend the bioinformatics field. Hence I'd be in
favour of the latter option.

Cheers
Sascha


-- 
 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. 

Re: GDPC Autopkgtes [GSOC]

[Sascha Steinbiss]

Hi Andreas,

[…]
>> I just pushed my changes to git, maybe it helps. Please note that gdpc is a 
>> graphical tool; not sure how you would want to do the testing here.
>> The current autopkgtests do not segfault anymore, but fail due to X not 
>> being set up in the testbed.
> 
> Any chance to try with Depends: xvfb ?

Using xvfb would work, still one would need to drive the testing logic (or even 
quit the GUI ;) via some scripting interface. For some inspiration, I once did 
some GUI autopkgtests for onioncircuits using Dogtail [1], very useful for GUI 
testing!

Cheers
Sascha

[1] 
https://anonscm.debian.org/cgit/pkg-privacy/packages/onioncircuits.git/tree/debian/tests


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: GDPC Autopkgtes [GSOC]

[Sascha Steinbiss]

Hi all,

>> I'll do report but i am looking at source code of gdpc and can't figure out
>> what is wrong i think something about methods is broken.
> 
> Usually injecting some printf("DEBUG %s(%i)", __FILE__, __LINE__)
> statements are pretty helpful to detect the location of the problem -
> for sure a debugger might help as well.

I have looked at the code as well and some changes in how mutexes are allocated 
helped to make gdpc start and run the examples mentioned in the README. It does 
crash every now and then, which may be connected to other locking issues I 
haven’t fully been able to track down. My suspicion is that it has to do with 
the move from the deprecated glib mutex functions to their new counterparts in 
debian/patches/41_glib_deprecated_funcs.patch.

I just pushed my changes to git, maybe it helps. Please note that gdpc is a 
graphical tool; not sure how you would want to do the testing here.
The current autopkgtests do not segfault anymore, but fail due to X not being 
set up in the testbed.

Cheers
Sascha




signature.asc
Description: Message signed with OpenPGP using GPGMail

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))

[Sascha Steinbiss]

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

>>
>> So anybody with some gcc-6 skills or those who want to ask on Debian
>> Mentors list for help which usually receives helpful responses quite
>> quickly is invited to work on our bugs.
>>
>> Kind regards
>>
>>   Andreas.
>>
>> On Wed, May 04, 2016 at 08:33:08AM +0200, Andreas Tille wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote:
>>>>
>>>>
>>>> Sure, I will see what I can do. How do you propose we as DMs
>>>> communicate
>>>> the changes -- just push a new branch in git and ping the list?
>>> Sascha, thanks for your good work on several bugs - without
>>> counting it
>>> was more than one per week.  If others might come up with this rate
>>> we
>>> could be quite safe for the release.  But its no time to relax and
>>> more
>>> bug fixers would be really great.  Specifically newcomers could
>>> gather
>>> some packaging skills by triaging bugs in existing packages.
>>>
>>> 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. 

Bug#831781: ITP: mash -- fast genome and metagenome distance estimation using MinHash

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@debian.org>

* Package name: mash
  Version : 1.1
  Upstream Author : Brian Ondov, Todd Treangen, Sergey Koren, and Adam 
Phillippy <adam.philli...@nih.gov>
* URL : https://mash.readthedocs.io
* License : BSD
  Programming Lang: C++
  Description : fast genome and metagenome distance estimation using MinHash

Mash uses MinHash locality-sensitive hashing to reduce large biosequences to
a representative sketch and rapidly estimate pairwise distances between
genomes or metagenomes. Mash sketch databases effectively delineate known
species boundaries, allow construction of approximate phylogenies, and can be
searched in seconds using assembled genomes or raw sequencing runs from
Illumina, Pacific Biosciences, and Oxford Nanopore.
For metagenomics, Mash scales to thousands of samples and can replicate Human
Microbiome Project and Global Ocean Survey results in a fraction of the time.

This package will be maintained within the Debian Med Packaging Team.

Re: A common test-data package for genome assemblers

[Sascha Steinbiss]

Hi all,

> I've had a couple packages that indicate the availability of data
> outside of the source distribution that can be used to try out the
> software (and make sure that it actually runs). I didn't think it was a
> good idea to bundle the data in with the actual package since it doesn't
> change between releases and would take up too much space on the archive
> if it was bundled with every upstream tarball.

+1, and also it would be nice to know that there is actually something
to assemble and one is not hitting corner cases with simulated reads
(i.e. generating not enough coverage trying to keep the size down).
For my autopkgtests that always required some fiddling.

> For example, at ,
> there are a few reduced datasets that can be used to run assemblies for
> PacBio and Nanopore sequencing data. Those files can also be used for
> tests of the sprai package, and possibly also for other long-read genome
> assemblers. There's also the option of packaging the Assemblathon data
> for this purpose, or using simulators to generate datasets for testing.
> 
> Does anyone have suggestions or thoughts on this?

I've previously used pbsim, wgsim, GenomeTools' simreads (packaged) or
Flux Simulator (not packaged) to generate very small read sets for
reasonably sized reference chromosomes, small enough to distribute with
the source tarballs of the packages to be tested or alternatively
generating them on-the-fly as part of the test run. For me these were
miniasm, rna-star and snpomatic.

I'd welcome a package containing known good test sets that would avoid
duplication. One could also generate separate sets for genomic reads,
RNA-seq reads, different sequencing platforms etc. What do you think?
For someone with little practical NGS experience to pick 'good' test
sets (like me) this will be a huge help for adding tests where upstream
doesn't provide test data.

Cheers
Sascha


-- 
 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. 

Re: Do you have popularity-contest set to yes?

[Sascha Steinbiss]

Hi Andreas,

> when looking at our tasks pages I'm noticing several package with 0
> installations reportet.

I looked at one of these that looks familiar to me and that I have been
tracking in my DDPO for quite a while (Artemis), and DDPO shows 16
installations. Could it be that the tasks pages show the numbers for
regularly used ('vote') or recently upgraded ('recent') installations
only? Looking at these numbers for Artemis they indeed are 0.

I guess that for bioinformatics packages using these as the visible
popcon counts on the tasks page might skew the numbers a bit.
I can imagine that one wouldn't use some of these tools every single day
(or even regularly)...

Cheers
Sascha

(And yes, I have popcon reporting enabled on all my machines :))


-- 
 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. 

rate4site 3.0.0-3 changes

[Sascha Steinbiss]

Hi Tanya,

while fixing RC bug #811824 [1] I noticed a changelog entry for
rate4site 3.0.0-3 by you marked as UNRELEASED. A quick search in the
team mailing list didn't turn up anything related to it. I could take a
look later if you want and upload (if you think it's ready -- it looks
OK to me).
If you are still working on it, no problem either :)

Cheers
Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811824


-- 
 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. 

Re: Request for discussion: Is our Sprint more of a Mini-DebConf? What to have next?

[Sascha Steinbiss]

Dear Steffen,

sorry for my late reply -- I have been busy last week with both work and
RL and also had to think a little about your suggestions.

[...]
>> FYI as a side note: I have reached out to informatics people here at
>> Sanger during the regular campus-wide Informatics Group Meetings by
>> giving a brief talk about Debian Med and the history of the sprints and
>> also trying to get an idea of who would support such an event in-house.
>> In the discussion afterwards indeed some upstream developers agreed that
>> this would be a good idea and would benefit the institute. However,
>> there was little initiative from any particular group to approach me
>> afterwards and find out how to make it work together; it was merely
>> suggested to contact the Genome Campus conference centre (which might be
>> on the more expensive side compared to our previous venues).
>> I can try to poke some people to bring the topic back to the table.
>
> Fantastic campus, fantastic people, just that carp-loaded bit of water does
> not really qualify. 

I completely agree with your view, and also I agree that water from
above doesn't count either ;)

> Why don't you start a second theme and have it during the summer, one
> that could more easily then start migrating abroad. It could for
> instance be "attached to upstream" both in the sense of data 
> providers and possibly a conference for those traveling from far?

TBH I am not really comfortable being the driver behind the 'second
theme' meetings you are proposing. If I understand your proposal
correctly, you are envisioning these to be mainly about potential
applications, and how these may benefit the local upstreams as well as
the rest of the biomedical and genomics research community. I agree that
this is a good idea and that having an event on campus can be a great
opportunity for networking and community engagement in this regard.
However, I would also like to state that I do not see myself as the best
person to come up with concrete topics, plans and things to address as
I, simply put, may not have the necessary visions for future research or
application development that you definitely have. I am also not very
involved in the data to be processed, nor would I consider the research
side of these applications to be something I would like to get more into.

> Also "automate big clinical chemical data" (ABCCD) comes to mind :o)

Maybe it does to you ;) But I have absolutely no exposure to clinical
research at all so I'm afraid I can't comment on how much of a 'hot
topic' that may be.

[...]
>> If the number of participants supports this, maybe some pre-allocated
>> time for custom break-out sessions, to allow for some in-depth mentoring
>> or bug squashing without missing group discussions or talks?
>> What do you think?
> Most of us seem to be professional bioinformaticians. If we want to do
> bug squashing we can basically do that any time via skype and github.

While this may be true in some (most?) instances, my experience was that
the previous Debian Med meetings have always helped me a lot to learn
certain things through direct interaction with people who have been
doing the task at hand for a long time. In that regard IMHO nothing
beats face-to-face meetings, and I felt this was confirmed when working
with one of the participants at the meeting in Copenhagen earlier this year.

What I originally meant, and would probably make me most happy would be
to see enough variety in these meetings to suit both groups: those who
attend these meetings for high-level discussions and moving the research
community forward using Debian as one tool among many, as well as those
who are more interested in getting their hands dirty with the
Debian-specific bits, as one would probably have in a more traditional
sprint.
As you might have guessed, I would consider myself well within the
latter group.

> I sense particular value in learning whom to actively contact for help when
> something is difficult to track down if this is not upstream. It would be
> very nice for all the infrastructure bits, though, especially for the CI
> additions that you in particular I have seen to contribute much for.

I'm not sure I understand what you mean here. I agree that close
upstream connections are good, but I don't get the exact situation you
may be thinking of.

> What if what you referred to as "bug squashing" we apply on data 
> processing, i.e. workflows for best biological insights? Particularly
> for a large data site like yours it may be very nice to have
> something intertwining Debian with CWL for education, documentation
> and production.

As already said, I agree in principle but do not feel like someone who
is involved enough on the level of 'biological insights' to be of much
help here.
Please don't get me wrong -- I would be more than happy working to make
a Debian Med meeting possible here on Campus. I have discussed a
potential procedure with my colleagues here, and their take is 

Re: Request for discussion: Is our Sprint more of a Mini-DebConf? What to have next?

[Sascha Steinbiss]

Hi Steffen and all,

> I was peeking into the one or other scientific collaboration of mine to
> invite them to our next Debian Med sprint. But I could not really tell
> much about it, yet. Besides deciding where to convene next (which to my
> recollection is decided by someone saying loudly that he/she wants to
> host us ... hello?) 

FYI as a side note: I have reached out to informatics people here at
Sanger during the regular campus-wide Informatics Group Meetings by
giving a brief talk about Debian Med and the history of the sprints and
also trying to get an idea of who would support such an event in-house.
In the discussion afterwards indeed some upstream developers agreed that
this would be a good idea and would benefit the institute. However,
there was little initiative from any particular group to approach me
afterwards and find out how to make it work together; it was merely
suggested to contact the Genome Campus conference centre (which might be
on the more expensive side compared to our previous venues).
I can try to poke some people to bring the topic back to the table.

> we should possibly also lean back a bit and decide if we want to
> change the one or other thing. This could start with the name. In my
> perception what we are having is not so much a problem-focused
> Sprint.

Yes, I agree in principle.

> So, what do you all think?  Would it help to officially come up with 
> some extended Sprint format? What would you change? Nothing? More
> talks? More time?

If the number of participants supports this, maybe some pre-allocated
time for custom break-out sessions, to allow for some in-depth mentoring
or bug squashing without missing group discussions or talks?
What do you think?

> Should there possibly a second Debian Med meeting on another
> continent than Europe? 

Sure, if there is enough interest -- especially for newcomers from
overseas :) For now there have only been a handful of people traveling
that far. Not sure if more would come if there was an event closer to them.
However, I myself would probably only be able to make it if the travel
costs are moderate as my employer won't cover that.

> With the same focus? Or more medical?

Personally I probably wouldn't be too interested in medical or research
applications as I tend to focus more on the technical/infrastructure
aspect. But that's just me, YMMV. I can imagine that it might make sense
to attract the non-core-Debian crowd as well.


Best regards
Sascha


-- 
 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. 

Re: NETTAB 2016 abstract deadline extended to June 30th

[Sascha Steinbiss]

Hi all,

>> Solicited topics
>> http://www.igst.it/nettab/2016/submissions/topics/
>> 
>> I think a presentation on what Debian (Med) has to offer the 
>> community would be well received and I would be happy to co-author 
>> or advise such an abstract.
>> 
>> I plan to submit something there (not Debian related) , if
>> accepted, it would be nice to meet there  ;-)
> We should think of writing up all those latest developments. I like
> the Nettab, the hackathon, sprints, codefest paper had its origin
> right there.

I would be happy to help by contributing/fleshing out a manuscript in my
spare time once there is a skeleton 'story' to tell. It is highly
unlikely that I would be able to travel to Rome for the conference though.

[...]
>> We would need collaboration between five COST countries (basically 
>> Europe),  financial support averages EUR 130 000 per year for a 
>> four-year period (though it is all for meeting support, no salaries
>> or direct research support).
>> 
>> I think we need to be affiliated to research institute and
>> research programs  I don't think it would work for Debian.
> Oh, we are all employed somewhere. It would work. I am in  cHiPSeT 
> (http://chipset-cost.eu/, anybody finding me on that picture gets a
> free drink at our next Sprint).

Nr. 11 from the left -- spotted you within 5 seconds ;)

Cheers
Sascha


-- 
 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. 

Re: SSPACE (Was: RFS: ariba)

[Sascha Steinbiss]

Hi all,

[...[
>>> In any case I've updated and pushed what I found on my local disc to Git
>>> ...
>>
>> Yes, I have noticed. Great, thanks! A nice starting point.
> 
> Yup.  I would not mind if somebody else would take over (as always ;-)). 

I have finished SSPACE in git yesterday and it should be ready for upload.
Any comments on whether we should probably call the package
'sspace-basic' in case SSPACE-standard ever gets freed...?

Cheers
Sascha


-- 
 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. 

Bug#826682: ITP: sspace -- scaffolding pre-assembled contigs after extension

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sas...@steinbiss.name>

* Package name: sspace
  Version : 2.1.1
  Upstream Author : Marten Boetzer and Walter Pirovano
* URL : https://github.com/nsoranzo/sspace_basic
* License : GPL-2
  Programming Lang: Perl
  Description : scaffolding pre-assembled contigs after extension

SSAKE-based Scaffolding of Pre-Assembled Contigs after Extension (SSPACE) 
is a tool able to extend and scaffold pre-assembled biological contig
sequences using one or more mate pairs or paired-end libraries, or even a 
combination.

This is the free 'basic' version of SSPACE. The non-free 'standard' version is
available directly from Baseclear.

This package will be maintained by the Debian Med Packaging Team.

Help with CMake linking Debian's LLVM libs

[Sascha Steinbiss]

Hi,

I am trying to make SPAdes 3.8.0 [1] (just entered unstable) build with
Debian's packaged LLVM libraries instead of using the version bundled by
upstream. I have made the necessary CMake changes [2] in a separate git
branch [3] but run into a problem that seems to stem from within the
LLVM code itself. At least I can't directly see a relation to the SPAdes
code... but then again I'm better at C than C++ ;)

I was wondering if anyone could probably provide some assistance? Here's
what I get:

$ ./debian/rules build
[...]
In file included from
/vagrant/spades/src/modules/pipeline/config_struct.cpp:20:0:
/usr/lib/llvm-3.6/include/llvm/Support/YAMLTraits.h: In instantiation of
'typename std::enable_if::type llvm::yaml::yamlize(llvm::yaml::IO&, T&, bool) [with T =
std::map; typename
std::enable_if::type = void]':
/usr/lib/llvm-3.6/include/llvm/Support/YAMLTraits.h:579:14:   required
from 'void llvm::yaml::IO::processKey(const char*, T&, bool) [with T =
std::map]'
/usr/lib/llvm-3.6/include/llvm/Support/YAMLTraits.h:528:5:   required
from 'typename std::enable_if<(!
llvm::yaml::has_SequenceTraits::value), void>::type
llvm::yaml::IO::mapOptional(const char*, T&) [with T = std::map; typename std::enable_if<(!
llvm::yaml::has_SequenceTraits::value), void>::type = void]'
/vagrant/spades/src/modules/pipeline/config_struct.cpp:41:79:   required
from here
/usr/lib/llvm-3.6/include/llvm/Support/YAMLTraits.h:663:42: error:
invalid application of 'sizeof' to incomplete type
'llvm::yaml::MissingTrait >'
   char missing_yaml_trait_for_type[sizeof(MissingTrait)];

Does anyone see something obvious that I may have missed?
Thanks in advance!

Cheers
Sascha

[1] https://packages.qa.debian.org/s/spades.html
[2]
https://anonscm.debian.org/cgit/debian-med/spades.git/commit/?h=debian_llvm=94b326151eba4671dc266ac0d2198596a9363c43
[3] https://anonscm.debian.org/cgit/debian-med/spades.git/log/?h=debian_llvm


-- 
 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. 

Re: solution for testing migration for arch:all package with missing i386 deps

[Sascha Steinbiss]

Hi Afif,

thanks. I have sent an email and they have put in a hint to force it in; now 
it’s in testing. Thanks for the help!

Cheers
Sascha

> On 4 Jun 2016, at 07:05, Afif Elghraoui  wrote:
> 
> 
> 
> على الخميس  2 حزيران 2016 ‫09:47، كتب Afif Elghraoui:
>> Here is the thread where I negotiated for circlator:
>> 
>> This took longer because I had to explain why bwa, spades, and pysam
>> could not be built for i386.
>> 
>> And I had to ask for exceptions again (on 5/29) recently for pbh5tools
>> and smrtanalysis. That message does not appear in their list archives
>> (yet?) for some reason,
> 
> Here's that second link, for the record.
>  I didn't
> notice that the month of May had two pages of archives...
> 
>> but that process was very quick since the
>> reasons were already explained before.
>> 
> 
> regards
> Afif
> 
> -- 
> Afif Elghraoui | عفيف الغراوي
> http://afif.ghraoui.name
> 

plasmidSPAdes tests fail for 3.8.0

[Sascha Steinbiss]

Dear SPAdes developer team,

while updating the Debian packaging for SPAdes, which also includes adding 
build-time and installed tests for each tool, I noticed that the plasmidSPAdes 
tests (plasmidspades.test —test) do not succeed. This consistently happened for 
the Linux version (tested on Debian stretch) and on Mac OS X (version 10.11.5). 
I have attached the log file for one of them to this email.

The resulting error is:

== Error ==  TEST FAILED: 
/home/vagrant/SPAdes-3.8.0-Linux/spades_test/contigs.fasta does not contain 
contigs!

and indeed the file has size zero.

I have skipped tests for plasmidSPAdes for now but wanted to let you know about 
the issue.

Many thanks and best regards
Sascha




spades.log
Description: Binary data

python-csb should now be reproducible

[Sascha Steinbiss]

Hi all,

I think I have made python-csb reproducible, after making some changes to 
epydoc which are not yet accepted by the maintainer but already in the r-b 
custom repo. Could someone please upload so it can run on their Jenkins 
builders?

Thanks
Sascha

Re: SSPACE-basic GitHub repository

[Sascha Steinbiss]

Dear Nicola,

first of all many thanks for the quick reply.

> thanks for contacting me about the SSPACE-basic repository. The
> repository contains a copy of the "basic" version of SSPACE, which was
> released by Baseclear years ago under the GPL (v2 or later) and then
> discontinued.

This is very nice to hear; I didn't know that but it does indeed explain
this separate version and license.

> Then they removed all traces of this version from their
> website

Does that mean they do not support SSPACE-basic _at all_ any more? That
is, do you know if they still handle, for example, bug reports?
'Discontinued' seems to suggest that...

> SSPACE standard is a completely different version (at least license-wise).

Got it.

> The first commit of the repository
> https://github.com/nsoranzo/sspace_basic/commit/652d24aa74a3b45774db43b3483e71e40572a553
> contains an exact copy of the files I downloaded at the time from
> http://www.baseclear.com/download.php?file_id=1038 , the other commits
> are patches from me.

If Baseclear have discontinued SSPACE-basic, I was wondering if you
would be OK with being our upstream contact for SSPACE-basic? That means
that we would possibly forward bug reports, patches, etc. from Debian to
you if they address the SSPACE-basic software itself.

> I'd very happy if you package SSPACE-basic and I'd happy to accept
> patches to make the software more "packageable" if needed.

I will look into it as soon as I find some time, and contact you with
suggestions or patches if required. From what I can see without delving
too much into packaging, we won't be able to include the PDF manuals
without the source they were created from (LaTeX, Word, ...) also
included in the repository. This is a Debian policy; if these are not
available we'd have to exclude them from the packaged version.
An alternative is to just make plain text versions (copy?) and to
include them in the repository. This would need to be done on your side
as well though.

Thanks again for your cooperation :) Always happy to hear such welcome
news and to see good software freed!

Best regards
Sascha


> -- 
> Nicola Soranzo, Ph.D.
> Data Infrastructure & Algorithms group
> The Genome Analysis Centre (TGAC)
> Norwich Research Park, Norwich, NR4 7UH, UK
> http://www.tgac.ac.uk/sequencing-informatics/
> 
> On 04/06/16 16:49, Sascha Steinbiss wrote:
>> Dear Dr. Soranzo,
>>
>> I am writing you on behalf of the Debian Med team, a group within the
>> Debian project with the objective to package free software with
>> relevance in biology and medicine for official Debian.
>>
>> I noticed that you provide a GitHub repository with the SSPACE basic
>> source code [1], under the GPLv2 [2]. This version of SSPACE would in
>> principle be possible to be packaged for Debian, as inclusion into the
>> main archive requires such a free license, allowing for free
>> redistribution.
>> I was wondering how the version that you provide relates to the
>> non-free version (SSPACE standard) provided by Baseclear [3]. Is the
>> one that you provide a different or reduced-functionality version
>> compared to theirs? Most importantly, Baseclear make no mention of any
>> kind of free license — on the contrary, they require users to contact
>> them to obtain the software and also handle commercial users
>> separately, a notion that the GPL does not have.
>>
>> I would be glad if you could clarify how this GPL-licensed version
>> came to be? We would be very thankful if this was a version that the
>> original authors of SSPACE released under a free license, and would be
>> happy to package it for Debian.
>>
>> Many thanks
>> Sascha Steinbiss
>>
>> [1] https://github.com/nsoranzo/sspace_basic
>> [2] https://github.com/nsoranzo/sspace_basic/blob/master/COPYING
>> [3] http://www.baseclear.com/genomics/bioinformatics/basetools/SSPACE
> 


-- 
 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. 

SSPACE-basic GitHub repository

[Sascha Steinbiss]

Dear Dr. Soranzo,

I am writing you on behalf of the Debian Med team, a group within the Debian 
project with the objective to package free software with relevance in biology 
and medicine for official Debian. 

I noticed that you provide a GitHub repository with the SSPACE basic source 
code [1], under the GPLv2 [2]. This version of SSPACE would in principle be 
possible to be packaged for Debian, as inclusion into the main archive requires 
such a free license, allowing for free redistribution.
I was wondering how the version that you provide relates to the non-free 
version (SSPACE standard) provided by Baseclear [3]. Is the one that you 
provide a different or reduced-functionality version compared to theirs? Most 
importantly, Baseclear make no mention of any kind of free license — on the 
contrary, they require users to contact them to obtain the software and also 
handle commercial users separately, a notion that the GPL does not have. 

I would be glad if you could clarify how this GPL-licensed version came to be? 
We would be very thankful if this was a version that the original authors of 
SSPACE released under a free license, and would be happy to package it for 
Debian.

Many thanks
Sascha Steinbiss

[1] https://github.com/nsoranzo/sspace_basic 
[2] https://github.com/nsoranzo/sspace_basic/blob/master/COPYING
[3] http://www.baseclear.com/genomics/bioinformatics/basetools/SSPACE

python-cobra and rdp-readseq now reproducible

[Sascha Steinbiss]

Hi,

BTW, the two packages in the subject are now reproducible as well, could
someone please take a look? Changes are in git and SVN, respectively.

Cheers
Sascha


-- 
 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. 

Re: solution for testing migration for arch:all package with missing i386 deps

[Sascha Steinbiss]

Hi Andreas,

> On Thu, Jun 02, 2016 at 11:45:10AM +0100, Sascha Steinbiss wrote:
>> I remember you had recently raised a discussion about circlator not
>> being able to migrate to testing because of dependencies missing for
>> i386. It now looks like ariba is stuck in the same situation [1]. It is
>> also quite likely that this is probably going to be a common problem for
>> any Python/Perl/... tool that depends on something like bwa, bowtie2 or
>> spades, for example. This is a combination which I could imagine
>> wouldn't be too uncommon, at least in our group.
>>
>> In the ML thread, Ansgar mentioned a manual override that would get the
>> transition going in such cases [2] but I haven't been able to find out
>> how this was finally resolved for circlator -- could you probably point
>> me in the right direction?
> 
> I've not checked circulator but IMHO a possible workaround would be to
> "fake" an "Architectur: any" package and put the tool that is needed
> also inside Build-Depends so the autobuilders do not even try to create
> a package for this.  Not nice but the advantage would be that we can
> control this on our own.  

True, thanks for the suggestion.

> But I admit I'd prefer a "proper" solution in any case. 

Indeed. As circlator seems to have made it to testing white still being
arch:all [1], I'd still be curious how to achieve the same for ariba.
And I'm also interested to know whether whatever solution was found will
stick after the next upload...

Best wishes
Sascha

[1]
https://anonscm.debian.org/cgit/debian-med/circlator.git/tree/debian/control



-- 
 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. 

Re: SSPACE (Was: RFS: ariba)

[Sascha Steinbiss]

Hi Andreas,

>>> OK.  I've uploaded ariba to new.
>>
>> Thanks! Let's hope I will be able to upload updates by myself when it
>> hits the archive ;)
> 
> :-)
> Otherwise I'd add upload permissions for you ...

Well, this was probably the fastest NEW accept I ever witnessed :) So
yes, I would like upload permissions please.

>>> I personally can not tell how important SSPACE and GapFiller might
>>> be but may be we should send another "please free your software mail"
>>> ...
>>
>> Maybe we should... unless the repo you linked above is indeed 'the free
>> SSPACE version'. I noticed it said 'SSPACE basic' while the Baseclear
>> link below read 'SSPACE standard' -- so maybe there's a functionality
>> delta between the free and non-free versions that makes all the difference.
> 
> In any case I've updated and pushed what I found on my local disc to Git
> ...

Yes, I have noticed. Great, thanks! A nice starting point.

Cheers
Sascha


-- 
 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. 

solution for testing migration for arch:all package with missing i386 deps

[Sascha Steinbiss]

Hi Afif,

I remember you had recently raised a discussion about circlator not
being able to migrate to testing because of dependencies missing for
i386. It now looks like ariba is stuck in the same situation [1]. It is
also quite likely that this is probably going to be a common problem for
any Python/Perl/... tool that depends on something like bwa, bowtie2 or
spades, for example. This is a combination which I could imagine
wouldn't be too uncommon, at least in our group.

In the ML thread, Ansgar mentioned a manual override that would get the
transition going in such cases [2] but I haven't been able to find out
how this was finally resolved for circlator -- could you probably point
me in the right direction?

Thanks,
Sascha

[1] https://qa.debian.org/excuses.php?package=ariba
[2] https://lists.debian.org/debian-devel/2016/03/msg00415.html


-- 
 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. 

Re: SSPACE (Was: RFS: ariba)

[Sascha Steinbiss]

Hi Andreas,

>>> WARNING: sspace not found in path. Looked for
>>> SSPACE_Basic_v2.0.pl. But it is optional so will be skipped
>>> during assembly
>> 
>> Yes, I have talked to ARIBA upstream (we're conveniently sharing
>> the same office) and this is fine to skip; it's not really clear
>> whether using it leads to significant improvement of the results.
> 
> OK.  I've uploaded ariba to new.

Thanks! Let's hope I will be able to upload updates by myself when it
hits the archive ;)

>>> I noticed that there is sspace 2.1.1 at
>>> 
>>> https://github.com/nsoranzo/sspace_basic/releases
>>> 
>>> which claims to be GPL
>> 
>> After a quick talk with Martin I'd be careful to check that license
>> and the repo's owner's affiliation with the SSPACE authors... from
>> what we know SSPACE (owned by Baseclear) has never been free.
>> That's why it was made optional in ARIBA in the first place, along
>> with GapFiller (also not free, same situation).
> 
> I personally can not tell how important SSPACE and GapFiller might
> be but may be we should send another "please free your software mail"
> ...

Maybe we should... unless the repo you linked above is indeed 'the free
SSPACE version'. I noticed it said 'SSPACE basic' while the Baseclear
link below read 'SSPACE standard' -- so maybe there's a functionality
delta between the free and non-free versions that makes all the difference.

>>> I wonder how important sspace would be for ariba packaging and 
>>> whether I should have a take at 2.1.1 with my current local
>>> files.
>> 
>> As I said, it's not important and skipping it is fine and it has
>> been discussed with ARIBA's upstream. If you want you can take a
>> shot at SSPACE basic from that GitHub repo, but if it was me
>> packaging it I would probably try to confirm the license as GPL
>> with the original authors (Boetzer and Pirovano).
> 
> H, since you are obviously pretty well informed could you assume
> it would be you who intends to package the Github version and ask
> upstream perhaps a better informed question than I could do?

I can see to it, but have other things on my agenda atm. It's on my list
now though :)

Best wishes
Sascha


-- 
 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. 

Re: RFS: ariba

[Sascha Steinbiss]

Duh, missed the link [1]

[1] https://anonscm.debian.org/cgit/debian-med/ariba.git

S.


> On 31 May 2016, at 23:02, Sascha Steinbiss <sas...@steinbiss.name> wrote:
> 
> Hi all,
> 
> ARIBA [1] is ready for sponsoring if anyone can spare some time. It is 
> lintian clean, has automatically generated manpages, build time unit tests 
> and autopkgtests, and builds reproducibly.
> 
> Cheers
> Sascha

Re: java.util.Properties writer and reproducibility

[Sascha Steinbiss]

Hi Emmanuel,

many thanks for your reply.

> I confirmed that I encountered this issue with the property files
> generated by Ant... and I fixed it last week [1] ;) I haven't uploaded
> it yet though.

Excellent, that was a problem solved quickly :) Thanks you so much.

> You are right to be concerned about the entries ordering of
> java.util.Properties, fortunately Ant uses a subclass that preserves the
> ordering [2].

Good to know that Ant is patched now. Do you think other tools from the Apache 
Java ecosystem might also be affected by this behaviour and need to be looked 
at/patched individually?

Bes wishes
Sascha

plast now reproducible

[Sascha Steinbiss]

Hi all,

see subject, changes are in Git. I have also done some minor fixes (Vcs-*, 
hardening, …).

Cheers,
Sascha

java.util.Properties writer and

[Sascha Steinbiss]

Hi Emmanuel, 

sorry for contacting you out of the blue, but I have noticed your kind help for 
the Debian Med and Reproducible Builds teams before, so I was just going to try 
my luck again ;) 
I am currently trying to make king [1] reproducible, which is currently not 
built reproducibly because of timestamps in property files written by ant [2] 
and subsequently packaged into the distributed jar. Apparently these files are 
written using java.util.Properties store() method, which automatically inserts 
this timestamp with no chance of overriding it:

  'Next, a comment line is always written, consisting of an ASCII # character, 
the current date and time (as if produced by the toString method 
  of Date for the current time), and a line separator as generated by the 
Writer.'

Of course I could simply set the timestamps to a specific value after building 
but I feel this might be a systematic issue best tackled upstream. There are 
also some related issue entries in the Reproducible Builds documentation 
(concerning other files, e.g. Maven related) for which I suspect that they are 
different manifestations of this same problem.
In addition to the timestamp issue, I am a bit concerned about the order of 
these properties being written to the file: if the properties are stored in a 
hash table (as the API documentation seems to suggest) then I am not sure that 
the order of output is deterministic. At least the method documentation makes 
no claim about sortedness.

I was wondering whether you have encountered this issue before and in general 
what your thoughts are. If this behaviour is defined in the API, do you think 
there is any chance of tackling this upstream?

Many thanks, and best wishes
Sascha

[1] https://tracker.debian.org/pkg/king
[2] https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/king.html
[3] https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html

Re: cain and soapdenovo2 now reproducible

[Sascha Steinbiss]

Hi Andreas,

thanks for the uploads.

> On Sat, May 28, 2016 at 12:08:04AM +0100, Sascha Steinbiss wrote:
>> new batch of newly reproducible packages: cain and soapdenovo2. I have also 
>> migrated soapdenovo2 to git and will retire the SVN repo a soon as the 
>> package is in unstable.
> 
> Both are uploaded, some small changes for soapdenovo2 added (please git
> pull) and you can now clean up SVN.

Hmm, it seems to gone from SVN already?

> I also noticed some commits to cain on my local disk and tried to merge
> and push.

OK. For cain, I did not bump the Standards-Version as I didn’t want to 
introduce a new -doc package for the documentation as I didn’t want to have it 
sitting in NEW just for reproducibility. Separate -doc packages for 
documentation as recommended by 3.9.7 — but then again it’s only a 
recommendation ;)

Cheers
Sascha

cain and soapdenovo2 now reproducible

[Sascha Steinbiss]

Hi all,

new batch of newly reproducible packages: cain and soapdenovo2. I have also 
migrated soapdenovo2 to git and will retire the SVN repo a soon as the package 
is in unstable.

Cheers
Sascha

Bug#825529: ITP: ariba -- Antibiotic Resistance Identification By Assembly

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sas...@steinbiss.name>

* Package name: ariba
  Version : 1.0.0
  Upstream Author : Martin Hunt <m...@sanger.ac.uk>
* URL : https://github.com/sanger-pathogens/ariba
* License : GPL3
  Programming Lang: Python
  Description : Antibiotic Resistance Identification By Assembly

ARIBA is a tool that identifies antibiotic resistance genes in biosequence 
reads 
by running local sequence assemblies.
The input is a FASTA file of reference genes and paired sequencing reads. ARIBA
reports which of the reference genes were found, plus detailed information on
the quality of the assemblies and any variants between the sequencing reads
and the reference genes.

This package will be maintained under the umbrella of the Debian Med Packaging 
Team.

Re: toppred and bowtie now reproducible

[Sascha Steinbiss]

Hi Andreas,

>>> I've uploaded toppred.
>>
>> Great, thanks!
> 
> Hope your DD application will proceed so we can stop thanking each
> other. ;-)

I'm also DAM approved now, so all that's left is account creation :)

[...]
>> I have changed the corresponding patch in SVN to just set these to
>> these suggested fixed values. Many thanks for your hint.
>
> Its uploaded as in SVN.  BTW, according to my criterion "use Git once
> the source tarball was repackaged" which is the case here since we are
> removing the seqan code copy, we should move this package to Git sooner
> or later - latest with the next new upstream version.

Sure. I can also keep in mind to move packages with repacked upstream
tarballs to Git once I touch them.

>> After another run in my local r-b pipeline, I can confirm that the
>> package is still reproducible. So I guess we can go with the new version.
> 
> Very cool that somebody of the team has a local r-b pipeline.  While I
> agree that this effort is really important I did not minded to install
> it here.  So its very good to know that somebody else is caring.

I'll try to look at the rest of the non-reproducible ones whenever I
have some spare time.

Cheers
Sascha


-- 
 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. 

Re: toppred and bowtie now reproducible

[Sascha Steinbiss]

Hi Andreas,

> I've uploaded toppred.

Great, thanks!

> I've looked at bowtie and I have a question:  In the reproducible.patch
> you set some varying variables to fixed (basically empty) values in the
> Makefile.  In addition you are also commenting the variables inside the
> code which might also hide other information like build options etc.  I
> wonder whether the latter is needed.  There might be users who are
> interested in those settings like Build Options and other things.

Point taken. This is what I meant the other day when mentioning in an
email about removing information from the output.

> I assume that the Build Options are fixed for a reproducible build,
> aren't they?

They should be, according to
https://tests.reproducible-builds.org/index_variations.html. C*FLAGS,
LDFLAGS and friends should stay the same.

> So what about
> 
> -DBUILD_HOST="\"Debian-reproducible\""
> 
> and inject
> 
> dpkg-parsechangelog --show-field Date
> 
> into -DBUILD_TIME.  I also wonder whether the string
> 
> gcc -v 2>&1 | tail -1 | sed 's/ *(.*//'
> 
> should be generic enough to solve the reproducible issue by beeing
> informative enough for the user.
> 
> What do you think?

You are right, maybe upstream has included them for a reason. I have
changed the corresponding patch in SVN to just set these to these
suggested fixed values. Many thanks for your hint.
After another run in my local r-b pipeline, I can confirm that the
package is still reproducible. So I guess we can go with the new version.

Best
Sascha

P.S. Just for consistency, I will also adjust the output of bowtie2
accordingly in a later upload.


-- 
 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. 

toppred and bowtie now reproducible

[Sascha Steinbiss]

Hi all,

I’ve made toppred and bowtie reproducible and also did the usual housekeeping 
(hardening, autopkgtests, …). In git and svn, respectively.

Cheers
Sascha

Debian Med reproducibility overview

[Sascha Steinbiss]

Hi all,

FYI: The R-b team now has a list of reproducibility statistics for the
packages maintained by the Debian Med team:


https://tests.reproducible-builds.org/unstable/amd64/pkg_set_maint_debian-med.html

Looking quite good for now, only 50 packages currently unreproducible!

Cheers
Sascha


-- 
 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. 

Re: SMALT, Bowtie2 and rna-star now reproducible

[Sascha Steinbiss]

Hi Afif,

> You should be receiving rights to these packages soon so you can handle
> the uploads.

Excellent, thanks!

Have a nice weekend,
Sascha

> 
> Thanks and regards
> Afif
> 
> على السبت 21 أيار 2016 ‫14:15، كتب Sascha Steinbiss:
>> Update: rna-star is now reproducible too, see Git.
>> 
>> Cheers
>> Sascha
>> 
>>> On 21 May 2016, at 19:21, Sascha Steinbiss <sa...@tetrinetsucht.de> wrote:
>>> 
>>> Hi all,
>>> 
>>> SMALT and Bowtie2 are now reproducible as well (in Git and Svn, 
>>> respectively).
>>> Please note that I needed to make some changes to Bowtie that change its 
>>> output — in particular, build hostname, time and compiler are no longer 
>>> recorded at compile time and hence can not be printed in the output of 
>>> ‘bowtie2 --version’. I don’t think that changes a lot, but if anyone 
>>> considers this a problem, I’d be happy to just set them to arbitrary values.
>>> 
>>> Cheers
>>> Sascha
>> 
>> 
> 

Re: SMALT, Bowtie2 and rna-star now reproducible

[Sascha Steinbiss]

Update: rna-star is now reproducible too, see Git.

Cheers
Sascha

> On 21 May 2016, at 19:21, Sascha Steinbiss <sa...@tetrinetsucht.de> wrote:
> 
> Hi all,
> 
> SMALT and Bowtie2 are now reproducible as well (in Git and Svn, respectively).
> Please note that I needed to make some changes to Bowtie that change its 
> output — in particular, build hostname, time and compiler are no longer 
> recorded at compile time and hence can not be printed in the output of 
> ‘bowtie2 --version’. I don’t think that changes a lot, but if anyone 
> considers this a problem, I’d be happy to just set them to arbitrary values.
> 
> Cheers
> Sascha

SMALT and Bowtie2 now reproducible

[Sascha Steinbiss]

Hi all,

SMALT and Bowtie2 are now reproducible as well (in Git and Svn, respectively).
Please note that I needed to make some changes to Bowtie that change its output 
— in particular, build hostname, time and compiler are no longer recorded at 
compile time and hence can not be printed in the output of ‘bowtie2 --version’. 
I don’t think that changes a lot, but if anyone considers this a problem, I’d 
be happy to just set them to arbitrary values.

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

T-coffee and wise now reproducible

[Sascha Steinbiss]

Dear all,

I have made t-coffee and wise reproducible in git, and also did some of the 
usual housekeeping. If anyone could take a look, please…? Thanks in advance.

Cheers
Sascha

Re: RFS: ray (now builds reproducibly)

[Sascha Steinbiss]

Hi Andreas,

> On 18 May 2016, at 23:29, Andreas Tille <andr...@an3as.eu> wrote:
> 
> I'll take it.  Greetings from CWL hackathon in Paris, Andreas.

Thanks for the upload! All the best wishes to Herve, Michael & Co as well :)

Cheers
Sascha

> 
> On Wed, May 18, 2016 at 11:20:08PM +0100, Sascha Steinbiss wrote:
>> Hi all,
>> 
>> I have just adjusted ray’s build system in git to make it build reproducibly 
>> (and also fixed some more hardening stuff). So if someone wants to do a team 
>> upload…
>> 
>> Cheers
>> Sascha
> 
> 
> 
> -- 
> http://fam-tille.de
> 

RFS: ray (now builds reproducibly)

[Sascha Steinbiss]

Hi all,

I have just adjusted ray’s build system in git to make it build reproducibly 
(and also fixed some more hardening stuff). So if someone wants to do a team 
upload…

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iva_1.0.5-1_amd64.changes ACCEPTED into unstable, unstable

[Sascha Steinbiss]

Hi Andreas,

> Done.  Thanks for your work on this 

Many thanks to you as well :)

> and hope your DD application will be
> finalised soon.

Yes, I hope so too. Only needs FD and DAM approval now...

Cheers
Sascha

> On Wed, May 11, 2016 at 04:41:52PM +0100, Sascha Steinbiss wrote:
>> Hi all,
>>
>> could I please get DM permissions for this please? There might be new
>> upstream releases in the making soon...
>>
>> Thanks
>> Sascha
>>
>> On 10/05/2016 17:04, Debian FTP Masters wrote:
>>>
>>>
>>> Accepted:
>>>
>>> Format: 1.8
>>> Date: Thu, 05 May 2016 09:32:57 +
>>> Source: iva
>>> Binary: iva
>>> Architecture: source amd64
>>> Version: 1.0.5-1
>>> Distribution: unstable
>>> Urgency: low
>>> Maintainer: Debian Med Packaging Team 
>>> <debian-med-packag...@lists.alioth.debian.org>
>>> Changed-By: Sascha Steinbiss <sas...@steinbiss.name>
>>> Description:
>>>  iva- iterative virus sequence assembler
>>> Closes: 772547
>>> Changes:
>>>  iva (1.0.5-1) unstable; urgency=low
>>>  .
>>>* Initial release (Closes: #772547)
>>> Checksums-Sha1:
>>>  26e0c01d1d5c68fa97542a8ef55c3b507f06bc6c 2098 iva_1.0.5-1.dsc
>>>  b2d23dd778f192efdda6d971e209bef4dd4d9167 8762199 iva_1.0.5.orig.tar.gz
>>>  85dbd6fc778dfdb400ad87856504cf6b8e1eccfc 5412 iva_1.0.5-1.debian.tar.xz
>>>  ae922a4cc9856ee8905a8de4a5f017334da45a8a 8576960 iva_1.0.5-1_amd64.deb
>>> Checksums-Sha256:
>>>  510d6f3016d00108d42504f3cce737faf7b50976afb11005ec3d3b5c1169d0cd 2098 
>>> iva_1.0.5-1.dsc
>>>  05ad4a24fb30047aaefc13fa4f7f29246e0cbea7835a0acd83c11cf44da10a3c 8762199 
>>> iva_1.0.5.orig.tar.gz
>>>  2348da190d10b40dad09dd1ccb5cf530682958352349e2ce7a45899954d3a047 5412 
>>> iva_1.0.5-1.debian.tar.xz
>>>  c5638437eb12199b68c97ffa8f30fe58c6400525f40a3e0c02e5a8a54a667657 8576960 
>>> iva_1.0.5-1_amd64.deb
>>> Files:
>>>  cd1c997f818767020a29f5b18ebad305 2098 science optional iva_1.0.5-1.dsc
>>>  43fce4144519ec9854b4ec967962cbd7 8762199 science optional 
>>> iva_1.0.5.orig.tar.gz
>>>  3160305f586bb04c262a547d870eb803 5412 science optional 
>>> iva_1.0.5-1.debian.tar.xz
>>>  823dbe60cdbccc9449a0b989ebaca847 8576960 science optional 
>>> iva_1.0.5-1_amd64.deb
>>>
>>>
>>>
>>> Thank you for your contribution to Debian.
>>>
>>
> 
> 
> 
> 


-- 
 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. 

Re: iva_1.0.5-1_amd64.changes ACCEPTED into unstable, unstable

[Sascha Steinbiss]

Hi all,

could I please get DM permissions for this please? There might be new
upstream releases in the making soon...

Thanks
Sascha

On 10/05/2016 17:04, Debian FTP Masters wrote:
> 
> 
> Accepted:
> 
> Format: 1.8
> Date: Thu, 05 May 2016 09:32:57 +
> Source: iva
> Binary: iva
> Architecture: source amd64
> Version: 1.0.5-1
> Distribution: unstable
> Urgency: low
> Maintainer: Debian Med Packaging Team 
> <debian-med-packag...@lists.alioth.debian.org>
> Changed-By: Sascha Steinbiss <sas...@steinbiss.name>
> Description:
>  iva- iterative virus sequence assembler
> Closes: 772547
> Changes:
>  iva (1.0.5-1) unstable; urgency=low
>  .
>* Initial release (Closes: #772547)
> Checksums-Sha1:
>  26e0c01d1d5c68fa97542a8ef55c3b507f06bc6c 2098 iva_1.0.5-1.dsc
>  b2d23dd778f192efdda6d971e209bef4dd4d9167 8762199 iva_1.0.5.orig.tar.gz
>  85dbd6fc778dfdb400ad87856504cf6b8e1eccfc 5412 iva_1.0.5-1.debian.tar.xz
>  ae922a4cc9856ee8905a8de4a5f017334da45a8a 8576960 iva_1.0.5-1_amd64.deb
> Checksums-Sha256:
>  510d6f3016d00108d42504f3cce737faf7b50976afb11005ec3d3b5c1169d0cd 2098 
> iva_1.0.5-1.dsc
>  05ad4a24fb30047aaefc13fa4f7f29246e0cbea7835a0acd83c11cf44da10a3c 8762199 
> iva_1.0.5.orig.tar.gz
>  2348da190d10b40dad09dd1ccb5cf530682958352349e2ce7a45899954d3a047 5412 
> iva_1.0.5-1.debian.tar.xz
>  c5638437eb12199b68c97ffa8f30fe58c6400525f40a3e0c02e5a8a54a667657 8576960 
> iva_1.0.5-1_amd64.deb
> Files:
>  cd1c997f818767020a29f5b18ebad305 2098 science optional iva_1.0.5-1.dsc
>  43fce4144519ec9854b4ec967962cbd7 8762199 science optional 
> iva_1.0.5.orig.tar.gz
>  3160305f586bb04c262a547d870eb803 5412 science optional 
> iva_1.0.5-1.debian.tar.xz
>  823dbe60cdbccc9449a0b989ebaca847 8576960 science optional 
> iva_1.0.5-1_amd64.deb
> 
> 
> 
> Thank you for your contribution to Debian.
> 



signature.asc
Description: OpenPGP digital signature

Re: mypy_0.4-1_source.changes REJECTED

[Sascha Steinbiss]

Hi Michael,

> FYI, I responded to the activity poll for me Debian Developer
> application on April 25th but I haven't heard any reply.

Maybe FD haven't processed your reply yet, or there's no AM free at the
moment? As my application has been AM approved a week ago, I guess there should
be one free soon ;)

Cheers
Sascha

> On Fri, May 6, 2016 at 2:19 PM, Debian FTP Masters
>  > wrote:
> 
> 
> 
>ACL dm: not allowed to upload source package 'mypy'
> 
>===
> 
>Please feel free to respond to this email if you don't understand why
>your files were rejected, or if you upload new files which address our
>concerns.
> 
> 
> 
> 
> --
> Michael R. Crusoe  michael.cru...@gmail.com
> 
> Community Engineer Common Workflow Language project
> _https://impactstory.org/u/-0002-2961-9670_   +32 (0) 2 808 25 52
>+1 480 627 9108


signature.asc
Description: Message signed with OpenPGP using GPGMail

Fwd: Re: [Pkg-javascript-devel] New home for datatables.js?

[Sascha Steinbiss]

FYI, I have just transferred datatables.js to the Javascript team.

Cheers
Sascha

 Forwarded Message 
Subject: Re: [Pkg-javascript-devel] New home for datatables.js?
Date: Fri, 6 May 2016 09:20:05 +0100
From: Sascha Steinbiss <sas...@steinbiss.name>
To: Jonas Smedegaard <d...@jones.dk>
CC: pkg-javascript-de...@lists.alioth.debian.org

Hi Jonas,

many thanks for the approval.

[...]
>> I just sent a join request via Alioth.
> 
> Approved.  Welcome aboard!

:)

> If you haven't already, yhen subscribe to our mailinglist and read our 
> mini Policy and other pages starting at 
> https://wiki.debian.org/Javascript

I'm already on the list and have also read (and followed) the policy
when packaging DataTables.

I will now move the git repo over to pkg-javascript, adjust the existing
git hooks according to the setup-repository script and transfer
maintainership over to pkg-javascript-devel from Debian Med with the
next upload.

Thanks again
Sascha






-- 
 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. 

Re: RFS: iva

[Sascha Steinbiss]

Hi Andreas,

> I'll take it.

Great, thanks for the upload!

Cheers
Sascha

> 
> On Thu, May 05, 2016 at 10:58:53AM +0100, Sascha Steinbiss wrote:
>> Hi all,
>> 
>> I have found the time to finish packaging of IVA [1]. Could anyone take
>> a look please?
>> It is lintian clean (with two overridden warnings due to timestamped
>> gzips distributed by upstream as reference data) and has build time unit
>> tests as well as an autopkgtest that succeeds. It also builds reproducibly.
>> 
>> Cheers
>> Sascha
>> 
>> [1] https://anonscm.debian.org/cgit/debian-med/iva.git
>> 
>> -- 
>> Dr Sascha Steinbiss
>> Senior Bioinformatician
>> Parasite Genomics
>> Wellcome Trust Sanger Institute
>> Genome Campus, Hinxton,
>> Cambridge, CB10 1SA, UK
>> 
>> 
>> -- 
>> 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
> 

RFS: iva

[Sascha Steinbiss]

Hi all,

I have found the time to finish packaging of IVA [1]. Could anyone take
a look please?
It is lintian clean (with two overridden warnings due to timestamped
gzips distributed by upstream as reference data) and has build time unit
tests as well as an autopkgtest that succeeds. It also builds reproducibly.

Cheers
Sascha

[1] https://anonscm.debian.org/cgit/debian-med/iva.git

-- 
Dr Sascha Steinbiss
Senior Bioinformatician
Parasite Genomics
Wellcome Trust Sanger Institute
Genome Campus, Hinxton,
Cambridge, CB10 1SA, UK


-- 
 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. 

Re: Strengthening team by fixing other members bugs

[Sascha Steinbiss]

Hi Andreas,

[...]
> It would be great if everybody who considers a member of the Debian Med
> team (even if not very active until now) would try to fix one bug per
> week.

Sure, I will see what I can do. How do you propose we as DMs communicate
the changes -- just push a new branch in git and ping the list?

Cheers
Sascha


-- 
 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. 

Re: RFS: augustus -- gene prediction in eukaryotic genomes

[Sascha Steinbiss]

Hi Afif,

thanks for your quick review & reply!

[…]
> where the cd $(CURDIR) lines are unnecessary-- every line in the Make
> recipe is called in a fresh shell that will already be in the top-level
> directory.

True. Changed this to the more idiomatic $(MAKE) -C  syntax anyway.

> Also, you could override dh_installchangelogs to tell debhelper about
> the upstream changelog if it isn't detected automatically.

Done.

> If the build order doesn't matter, these recursive make invocations can
> also be made into separate rules and set as prerequisites of the build.
> But that would only help if you're using dh --parallel and probably is
> not important.

Right. Probably not a major gamechanger in terms of build time, but it’s indeed 
more elegant and I have adjusted the rules file granularity to do this now.

> I'm sorry if you knew these things already and just preferred to do it
> the way you did, but I just want to make sure. I can change make these
> changes if you'd like. Just let me know.

No worries, I’ve just pushed the changes. Feel free to change whatever else 
catches your eye.
Thanks for the helpful hints.

Cheers,
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

RFS: augustus -- gene prediction in eukaryotic genomes

[Sascha Steinbiss]

Hi all,

I have prepared a version of AUGUSTUS in git. It builds three binary packages:

 - augustus, with the main binaries
 - augustus-data, containing pre-built species parameters for the most common 
organisms,
 - augustus-doc, which contains documentation such as manual-style READMEs and 
HTML tutorials.

The package causes no ‘legitimate' Lintian errors or warnings, only two 
(overridden) warnings concerning timestamped tarballs in the packages, which 
however were already included by upstream. I have also added autopkgtests for 
example gene finding with and without hints, and for simple retraining + gene 
finding. The package also builds reproducibly on amd64.

I also wrote man pages for the included executables. Upstream also contributed 
two man pages for tools whose function was not immediately clear to me; they 
will in turn include all man pages in their tarball starting from the next 
release.

Could anyone probably take a look, please? I’d be happy to address any 
remaining issues.

Cheers,
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Proposal to start link time optimisation for Debian Med packages

[Sascha Steinbiss]

Hi Steffen,

[…]
> * minimal impact on regular packaging - maintainers should not need to
> worry unless they do want to learn about it. To be achieved by changes
> to debhelper and the sharing of our packaging in our source code
> repositories.
> 
> * LTO flags should be optionally excluded from the build process
> 
> * announcement of this optimisation on our task pages

Agreed. Probably any related options could be exposed in 
DEB_BUILD_MAINT_OPTIONS, similarly to how hardening is handled?

> The promotion of this enhancement I consider to be exceptionally
> important, especially so if we can tie this up with the continuous
> integration testing and some benchmarking. For all the folks that wait
> over some NGS data set to be aligned etc, a 20% reduction of compute
> time may mean that they see results a working day earlier. 

Indeed I am really curious about the level of improvement one can get. 
In GenomeTools we did some experiments compiling the whole code base in
one big concatenated source file (an 'amalgamation') to allow the compiler
to optimise, inline etc. as much as possible. I'd consider this an approach 
with even more optimisation potential than LTO. Looking at the run time of
demanding tasks (ESA generation, etc) we were IIRC only able to achieve ~10%
of run time improvement using this level of optimisation. YMMV.

[…]
> Ok, so, let us see where this thread carries us and then we may also
> know about how many first helping hands and candidate packages we have.

I would be happy to try enabling LTO on some packages once we have
agreed on a mechanism to do it (if it's more than just adding something
to $LDFLAGS). Some of the later replies in the debian-devel thread about
valgrind errors sound a bit scary though. It would probably be best to use
candidate packages with good test coverage first.

Best,
Sascha

Re: Artemis: fix for #808851

[Sascha Steinbiss]

Hi Afif,

>> Did I miss something? I have everything to run Artemis (‘java -jar 
>> /usr/bin/art’ indeed runs Artemis) but the jar wrapper part doesn’t seem to 
>> work for me.
>> 
> 
> That's strange. It works for me on jessie. I will take a look, but it
> seems as though you don't have jarwrapper installed (but javahelper
> should have added it as a dependency of artemis).

I actually do have it installed. That was one of the first things I checked, 
sorry for not having mentioned it in my previous email ;)

> There was a misunderstanding on my part regarding jarwrapper. it doesn't
> create a script; it just handles executable jar files, but the end
> result is the same. You should be able to execute /usr/bin/art directly.

After a reboot (for me: vagrant reload) it works now, I can run /usr/bin/art 
directly. Probably a new binfmt handler is only available after reboot?
Anyway, I would consider this fixed now. Sorry for raising additional fuss over 
the jar issue.

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Artemis: fix for #808851

[Sascha Steinbiss]

Hi Afif,

> > I noticed that Artemis was removed from testing a while ago, and
> > one reason was bug #808851. You apparently started to fix it
> > (thanks!) but haven't seen an upload for a fixed version, so as I
> > had some time to spare this morning I looked at it. I just pushed
> > the last remaining changes needed to fix the FTBFS to git and would
> > be glad if you could take a look and upload if it’s OK with you.
> >
> 
> Wow, thank you for doing that. It's been a thorn in my side for a long
> time.

Sure, no problem. I just noticed after fixing it that you requested help for 
the fix. Anyway, here you go :)

> 
> > Quick question: You seem to have linked the .jars to /usr/bin,
> > which may confuse typical users who may want to call ‘art’ or ‘act’
> > from the command line, e.g. to give additional command line
> > parameters (database support, for example). Is there a special
> > reason for doing it this way? Artemis’ upstream tarball includes
> > the ‘act’ and ‘art’ scripts users may be familiar with.
> 
> The link is picked up by jarwrapper, which turns it into a script that
> sets the appropriate classpath and call's the jar file's main class.
> When I looked at the upstream-provided scripts, it seemed to me like
> they did basically the same thing. If we want to use them, we'd have
> to patch them to set the classpath as it would be set from the package
> installation. Would you prefer that?

I don’t really mind. I was just asking because when I wanted to test my newly 
built version of the updated package I noticed I couldn’t run Artemis:

[vagrant@vagrant-debian:~] $ sudo dpkg -i /vagrant/artemis_16.0.0+dfsg-5_all.deb
Selecting previously unselected package artemis.
(Reading database ... 130551 files and directories currently installed.)
Preparing to unpack .../artemis_16.0.0+dfsg-5_all.deb ...
Unpacking artemis (16.0.0+dfsg-5) ...
Setting up artemis (16.0.0+dfsg-5) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for mime-support (3.59) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
[vagrant@vagrant-debian:~] $ art
run-detectors: unable to find an interpreter for /usr/bin/art
[vagrant@vagrant-debian:~] $ which art
/usr/bin/art

Did I miss something? I have everything to run Artemis (‘java -jar 
/usr/bin/art’ indeed runs Artemis) but the jar wrapper part doesn’t seem to 
work for me.

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Artemis: fix for #808851

[Sascha Steinbiss]

Hi Afif,

I noticed that Artemis was removed from testing a while ago, and one reason was 
bug #808851. You apparently started to fix it (thanks!) but haven't seen an 
upload for a fixed version, so as I had some time to spare this morning I 
looked at it. I just pushed the last remaining changes needed to fix the FTBFS 
to git and would be glad if you could take a look and upload if it’s OK with 
you.

Quick question: You seem to have linked the .jars to /usr/bin, which may 
confuse typical users who may want to call ‘art’ or ‘act’ from the command 
line, e.g. to give additional command line parameters (database support, for 
example).
Is there a special reason for doing it this way? Artemis’ upstream tarball 
includes the ‘act’ and ‘art’ scripts users may be familiar with.

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Request for Sponsoring: spaced

[Sascha Steinbiss]

Hi Fabian,

> I have prepared a package for spaced (words). The remaining issues are
> due to upstream not releasing proper source tarballs (binaries are
> included and no versioning). 

Just a comment about this after taking a quick look: You can directly
exclude a binary from the orig tarball before import by listing the
binary in the 'Files-Excluded:' section of your debian/copyright.
With a few adaptations in your watchfile [1] it is then removed during
the download via uscan so you don't have to use an additional patch to
remove it.

Not sure you were aware of this but it's pretty useful.

Cheers,
Sascha

[1]
opts=repacksuffix=+dfsg,dversionmangle=s/\+(debian|dfsg|ds|deb)(\.\d+)?$//,repack,compression=xz


-- 
 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. 

Re: How to convert gb to gbk to get proper input for mauvealigner?

[Sascha Steinbiss]

Hi Andreas and Afif,

>> a colleague of mine relaised that mauvealigner seems to need gbk files
>> when running under Linux (while under Win also gb file is working).  This
>> happens when using
>>
>>java -Xmx6g -cp /usr/share/java/Mauve.jar 
>> org.gel.mauve.contigs.ContigOrderer -output OUTPUTDIR -ref REFERENCE.gbk 
>> -draft DRAFT.contigs.fasta
>>
>> While under win also REFERENCE.gb is OK this leads to an error under
>> (the Debian packaged!) mauvealigner (I forgot to ask what version is
>> used under Win - may be there is a difference as well).
> 
> As far as I know, gb and gbk are interchangeable extensions for the
> genbank format. 

I am not aware of a systematic difference betweek 'gb' and 'gbk' files
either.

> The genbank format may or may not include the actual
> sequence data. If you're passing a genbank file to Mauve, it should be
> including the sequence data.

This is also the most obvious source of problems I could think of. If
one of the files only has the annotation (feature table) and no
sequence, this might result in an error.
What is the exact wording of the error message?

Cheers
Sascha

P.S. To order contigs along a reference one might also try ABACAS, which
only needs a FASTA sequence as the reference if I am not mistaken.


-- 
 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. 

SILVA replacement pHMMs for Barrnap

[Sascha Steinbiss]

Dear Torsten,

I hope you are doing well. I was wondering whether you have had a chance
to look at my reply to Barrnap issue #13 [1] yet. As discussed last year
I have looked into building new profile HMMs from public sources to
replace the current ones built from SILVA alignments. I had to remove
these from the Debian package for Barrnap up to now for licensing reasons.

I would be happy to learn whether you would consider these to be
acceptable for use with Barrnap, or to receive any other feedback you
might have.

Thanks,
Sascha

[1] https://github.com/tseemann/barrnap/issues/13


-- 
 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. 

Re: Worth packaging bio_assembly_refinement?

[Sascha Steinbiss]

Hi Afif,

first of all thanks for looking at Circlator, which was on my list as well :)

>> I'm looking into packaging Circlator, which depends on the Sanger
>> program bio_assembly_refinement. Looking into it, I'm wondering whether
>> this is a tool that will just get folded into circlator eventually. Do
>> you think it's worth packaging it separately?
> 
> I should add that the alternative would be to bundle it into the
> circlator package as a multi-orig tarball. The question is better
> rephrased as whether it's worth packaging bio_assembly_refinement
> /separately/.

Yes, I noticed the dependency on bio_assembly_refinement as well and I was’t 
sure what part of it is really needed, since it’s description sounded a bit 
similar to Circlator itself. I didn’t have the time yet to look into it in more 
detail yet.
I have cc’d Martin Hunt, the Circlator author, and Nishadi de Silva, the 
bio_assembly_refinement author, on this email and they might be able to say 
more.

Many thanks,
Sascha

Re: [MoM] Outreachy 2016 application

[Sascha Steinbiss]

Hi Anna,

let’s see if I can help out to the best of my knowledge:

> First of all Sascha, thanks so much for your comments -- I managed to do the 
> setup for schroot backend! Actually, I wonder why does the documentation 
> suggest 'debci setup' for lxc if it doesn't work, but I guess this is the 
> question for Debian mentors team.

I guess so too. I haven’t used the documentation you mentioned before, it may 
be out of date?

> One more (not urgent) question here. I tried to run
> 'adt-run --user debci --output-dir /tmp/output-dir SOURCEPACKAGE --- schroot 
> debci-unstable-amd64'
> and I got an error all the times:
> "gpg: no default secret key: secret key not available
> gpg: signing failed: secret key not available
> adt-run [02:26:18]: ERROR: unexpected error: apt-ftparchive or signature 
> failed, code 2"
> 
> I manually generated gpg key, I checked it with gpg --list-key, I tried to 
> add its ID to  ~/.gnupg/gpg.conf but nothing helped. Eventually I executed 
> the command with sudo and it worked. Is 'sudo' really necessary or may I fix 
> it somehow?

I always call my LXC-based adt-run using sudo but the GPG issue may be 
unrelated. It’s difficult to say more without the context of the error. Did you 
create the keys as root?

> Dear all, I have a bunch of questions and I would appreciate your help!
> Here they are:
> 
> 1. Do I understand correctly that for creating a test I have to create 
> debian/tests folder, put bash script in it and to create debian/tests/control 
> file. Are there any other actions required?

The script does not necessarily need to be a bash script, it can be anything 
executable as long as its dependencies, e.g. interpreter, are declared in 
debian/tests/control. 
But otherwise, you got it. Just make sure you define all the dependencies for 
the test and pick the correct set of restrictions. For instance, if the tests 
write to stderr without that being an error (logging, for example) you need to 
specify ‘allow-stderr’. If the test needs to start services (e.g. dbus etc) for 
the test to run, you will also set an isolation level of at least ‘container’. 
Good that you chose LXC because that isolation level wouldn’t work with a 
simple chroot.
See https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html for 
detailed descriptions of the restrictions.

> 2. As far as I understand, from the test script I can call the tools being 
> tested as if they are installed in /usr/bin/ or as if they have an alias in 
> the system. Is it right?

Exactly. The idea of the autopkgtest is to test the package as it would look 
like in the installed state.

> 3. In test scripts I notices some relative paths (like "for f in test/*.sh"). 
> Do we always assume that the tests are executed from the exact directory? Is 
> it "debian”?

The working directory of each test is guaranteed to be the root of the source 
package, which will have been unpacked but not built. See 
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html for more 
information.

> 4. Do I always need to rebuild the package if I want to change the test 
> script? Is there a faster way to check changes?

If all you are changing is the test script, it should be enough to just build a 
new source package (all, please correct me if I’m wrong).

> 5. In the artfastqgenerator package I saw the following: "cp -a 
> /usr/share/doc/artfastqgenerator/examples/*" Does it mean that these examples 
> are provided by from upstream and they will be placed in that directory while 
> package installation?

Thats’s what I expect, yes.

> 6. Tests for axe-demultiplexer change my font and background colors to blue 
> and black respectively. Is something wrong with my system settings or is it 
> an expected behaviour?
> 7. I ran test for eigensoft package (which checks that it prints usage info). 
> It is marked as PASS, but stdout clearly says that it has an error: "error: 
> eigenstrat do not print usage information". What's the matter? Why does it 
> fail and why isn't this failure detected? (I guess the matter is in exit code 
> -- it is alway equal to zero). Again, are my system settings incorrect or is 
> it a common behaviour?

No idea about these, these seem to be quite package specific.

> 8. I'm looking for the test data for bwa. How do I check the licence for a 
> dataset? May I use the test data from the other package? (Say bowtie2 -- it 
> has test data inside). May I put the data in debian/tests or do I need to use 
> some other location?

I wouldn’t put larger (say >1MB) test data into the debian/tests directory, but 
rather create a bwa-test package containing the data and make it a dependency 
of the test. Can anyone perhaps comment on this idea?
IMHO you can use test data from other packages, but keep in min

Re: Packages for Stable-backports

[Sascha Steinbiss]

Hi Afif,

> I'm planning to backport several packages for the current stable release
> (probably after next week). I wanted to list them here in case there are
> any objections or things I should be aware of. They are:
> 
> barrnap
> fastaq
> roary
> tantan
> spades

Sure, that would be great. For Roary, however, please keep in mind that there 
are some dependencies that aren’t in stable yet (libtest-files-perl and 
libfile-grep-perl). 

Thanks,
Sascha

Re: RFS: reapr

[Sascha Steinbiss]

Hi Michael,

> Sascha, care to share your reproducibility test setup?

Sure, but it’s nothing too flashy and basically just the recommended reference 
setup. With cowbuilder installed and my pbuilderrc 
(https://github.com/satta/dotfiles/blob/master/pbuilder/.pbuilderrc) just 
follow the instructions at:

  https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Usage_example

to create a cowbuilder base with the modified toolchain, then clone

  https://anonscm.debian.org/git/reproducible/misc.git

(I don’t have a default distribution set in my .pbuilderrc so I had to patch 
rebuild.sh with the attached patch).

Then, copy the package files + orig tarball for the package you want to test 
into the misc/prebuilder directory.
From there, then do:

  ./rebuild.sh -c -b /var/cache/pbuilder/base-reproducible.cow 

and watch for the big ‘reproducible’ banner. If there’s none, then look at the 
output in the log directory, particularly the diffoscope HTML — this is 
basically just what Debian’s reproducibility reports give you. Very useful to 
check whether your package will build reproducibly for Debian (only for amd64 
in my case but I can live with that ;))

Cheers
Sascha




default_dist.patch
Description: Binary data

biosquid fix for #815883, please review & upload

[Sascha Steinbiss]

Hi all,

I have prepared a fix for #815883 in SVN and also updated the package to 
current standards. Could someone sponsor a team upload please?

Thanks,
Sascha

Re: RFS: reapr

[Sascha Steinbiss]

Hey,

> [...]
>> and builds reproducibly.
> 
> Actually, I just noticed it doesn't! I do get slightly different
> binaries (though no timestamps involved) and I can't track it down
> further for now. 

OK, it was just a ccache issue in my reproducibility testing setup. The package 
is fine!

Cheers
S.

Re: RFS: reapr

[Sascha Steinbiss]

Hi again,

[...]
> and builds reproducibly.

Actually, I just noticed it doesn't! I do get slightly different
binaries (though no timestamps involved) and I can't track it down
further for now. I'll try to get in touch with the r-b team later.
However, I don't consider this an upload blocker at the moment.

Cheers
Sascha


-- 
 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. 

RFS: reapr

[Sascha Steinbiss]

Hi all,

with all required dependencies in place now and with a proper test case
I think REAPR is ready for upload. Code is in git, could anyone take a
look please?
The package has no lintian errors/warnings, has build time tests as well
as autopkgtests, and builds reproducibly.

Many thanks,
Sascha


-- 
 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. 

Re: [MoM] Outreachy 2016 application

[Sascha Steinbiss]

Hi Anna and Andreas,

[…]
>> I got the following error: "Error: container adt-sid-amd64 is not defined"
>> 
>> This  discussion
>> looks relevant, but the executed command here is slightly different.
>> 
>> Do you have any ideas how to fix this issue? What am I doing wrong?
> 
> H, good question.  Its a long time ago thyt I used adt-run and I
> need to refresh my mind myself.  I would need some more time to check
> myself which I do not have currently.  I'd recommend you stick to a
> shell script that runs in your *local* machine for the moment.
> 
> Or may be somebody else here on the list can help?  

I think that 'debci setup’ only prepares a schroot environment to use as a 
testbed, so you need to use:
  
  $ adt-run --user debci foobar.changes --- schroot debci-sid-amd64

where I’m not completely sure about the name of the environment, it may be 
different for you.

LXC uses a different container format and you need to use a different command 
for building. For LXC I had to use ’act-build-lxc’, e.g.

  $ sudo adt-build-lxc debian sid

will build you a LXC container for sid.

> If not and you
> want to get this up and running before I'm back from vacation you have
> very good chances to ask this question on the mailing list
>   debian-ment...@lists.debian.org
> Just do not hesitate to ask there.

Seconded. They are usually quite responsive :)

Cheers,
Sascha

Re: detecting the presence of new files / licenses / copyrights

[Sascha Steinbiss]

Hi,

> http://sources.debian.net/src/amtterm/1.4-1/debian/rules/?hl=4#L4
> 
> Has anyone used this technique in practice?

Not yet, but it looks useful in case things change. Unfortunately doesn’t help 
with getting the licenses in to begin with...

Thanks for the pointer,
Sascha

PBSIM code repository on Google Code

[Sascha Steinbiss]

Dear Dr Hamada,

I'm writing you on behalf of the Debian Med team that has the objective
to package all free software in the field of biology and medicine for
official Debian.

I have prepared a Debian package for your tool PBSIM [1] which is hosted
on Google Code. Unfortunately, this service has recently shut down and
has only preserved all projects in a read-only archive [2]. This means
that it is not possible any more for you to release new versions,
incorporate patches from contributors etc. on this hosting platform. I
was wondering if you are intending to maintain PBSIM in the future, and
if so, if you could consider migrating the code to GitHub? Google Code
offers an easy mechanism to do this [3].

Many thanks,
Sascha Steinbiss

[1] https://code.google.com/archive/p/pbsim/
[2] https://code.google.com/archive/about
[3] https://code.google.com/export-to-github/export?project=pbsim


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#813385: ITP: reapr -- universal tool for genome assembly evaluation

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: reapr
  Version : 1.0.18 
  Upstream Author : Martin Hunt <martin.h...@sanger.ac.uk> 
* URL : http://www.sanger.ac.uk/science/tools/reapr 
* License : GPL
  Programming Lang: C++, Perl
  Description : universal tool for genome assembly evaluation

REAPR is a tool that evaluates the accuracy of a genome assembly using mapped
paired end reads, without the use of a reference genome for comparison. It can
be used in any stage of an assembly pipeline to automatically break incorrect
scaffolds and flag other errors in an assembly for manual inspection. It
reports mis-assemblies and other warnings, and produces a new broken assembly
based on the error calls.
The software requires as input an assembly in FASTA format and paired reads
mapped to the assembly in a BAM file. Mapping information such as the fragment
coverage and insert size distribution is analysed to locate mis-assemblies.
REAPR works best using mapped read pairs from a large insert library (at least
1000bp). Additionally, if a short insert Illumina library is also available,
REAPR can combine this with the large insert library in order to score each
base of the assembly.

This package will be maintained under the umbrella of the Debian Med Packaging
Team.

Bug#812426: ITP: miniasm -- ultrafast de novo assembler for long noisy DNA sequencing reads

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: miniasm
  Version : 0.2
  Upstream Author : Heng Li <l...@me.com>
* URL : https://github.com/lh3/miniasm
* License : MIT
  Programming Lang: C
  Description : ultrafast de novo assembler for long noisy DNA sequencing 
reads

Miniasm is an experimental very fast OLC-based de novo sequence assembler
for noisy long reads. It takes all-vs-all read self-mappings (typically by
minimap) as input and outputs an assembly graph in the GFA format.
Different from mainstream assemblers, miniasm does not have a consensus step.
It simply concatenates pieces of read sequences to generate the final unitig
sequences. Thus the per-base error rate is similar to the raw input reads.

This software will be maintained by the Debian Med Packaging team.

Bug#810600: ITP: minimap -- tool to find approximate mapping positions between long sequences

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: minimap
  Version : 0.2 
  Upstream Author : Heng Li <l...@me.com>
* URL : https://github.com/lh3/minimap
* License : MIT
  Programming Lang: C
  Description : tool to find approximate mapping positions between long 
sequences

Minimap is an experimental tool to efficiently find multiple approximate
mapping positions between two sets of long sequences, such as between
reads and reference genomes, between genomes and between long noisy reads.
Minimap does not generate alignments as of now and because of this, it is
usually tens of times faster than mainstream aligners. 
It does not replace mainstream aligners, but it can be useful to simply
and quickly identify long approximate matches at moderate divergence among
a huge collection of sequences. For this task, it is much faster than most
existing tools.

This software will be maintained by the Debian Med Packaging team.

Re: libtabixpp test fixes ready for upload

[Sascha Steinbiss]

Hi Andreas,

> Uploaded and upload permissions granted for your next package revision.
> Thanks for your work on this

Thanks for the quick action and the upload permissions.

Cheers
Sascha

RFS: Roary ready for upload

[Sascha Steinbiss]

Dear team,

with all Perl dependencies now out of NEW and a crucial bug (#808552) now 
fixed, Roary is ready for upload in my opinion. Runs its Perl test suite 
successfully, is lintian clean, and builds reproducibly.

Thanks,
Sascha

libtabixpp test fixes ready for upload

[Sascha Steinbiss]

Hi team,

I have fixed autopkgtests in libtabixpp and also moved around dependencies a 
bit. Could someone upload please?

Many thanks, 
Sascha

Bug#808495: ITP: roary -- high speed stand alone pan genome pipeline

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: roary
  Version : 3.5.7
  Upstream Author : Andrew J. Page <ro...@sanger.ac.uk>
* URL : http://sanger-pathogens.github.io/Roary/
* License : GPL-3+
  Programming Lang: Perl
  Description : high speed stand alone pan genome pipeline

Roary is a high speed stand alone pan genome pipeline, which takes annotated
assemblies in GFF3 format (as produced, for instance, by Prokka) and calculates
the pan genome. Using a standard desktop PC, it can analyse datasets with
thousands of samples, something which is computationally infeasible with
existing methods, without compromising the quality of the results. 128 samples
can be analysed in under 1 hour using 1 GB of RAM and a single processor.
To perform this analysis using existing methods would take weeks and hundreds
of GB of RAM. Roary is not intended for meta-genomics or for comparing
extremely diverse sets of genomes.

This package will be maintained under the umbrella of the Debian Med
Packaging Team.

Bug#807977: ITP: libtabixpp -- C++ wrapper to tabix indexer

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: libtabixpp
  Version : 1.0.0 
  Upstream Author : Erik Garrison <erik.garri...@gmail.com>
* URL : https://github.com/ekg/tabixpp
* License : MIT
  Programming Lang: C++
  Description : C++ wrapper to tabix indexer

Tabix indexes files where some columns indicate sequence coordinates: name
(usually a chromosome), start and stop. The input data file must be position
sorted and compressed by bgzip. After indexing, tabix is able to quickly 
retrieve data lines by chromosomal coordinates.
This package provides a C++ wrapper to the tabix indexer.

This is packaged as a dependency for REAPR and will be maintained the Debian
Med packaging team.

RFS: snpomatic

[Sascha Steinbiss]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

I have prepared snpomatic as a dependency for REAPR (to come). I would
be happy if someone could take a look in git. Apart from the missing
watch file (no releases tagged by upstream) it is lintian clean and
builds reproducibly.
Looking forward to your comments!

Thanks
Sascha
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWbuRHAAoJEFVWo04Eo2ELkocQALaH1kmWoobAQPp8dax44OYK
JcYxJ8i8ifGx/3W61grguFCEYtWUx6YSpinXecljYS9QrtLt9gCk6tBxQV6bYAM2
0vSNKgFFlA9llzVeRc6JwCvTlScAKZvZR9Bmntb4ey5w1xNms5Z9skvqE0jxmz5t
lkSrz5NFeOawOywQz5WXkwa5CBwebozMNpPEObt7S1ikV0s478VCjdwwkana/Fe1
gxaB/1oOXb0JeV2Bm5e1nJEuuNfsaO9hIja6XRyOpVNS2po1BM7+lgX8wpfRYWWw
53d7X2UAdgrTXDZMBrLaj15llzpLJG4ASQgjPcBWPKy6Ho5qAJsKq82AYZokmjTk
L+Z9mHJ5z86nBOXTpYPh9lyb0xKepM8DScRoBGBhDkDXfuluIsxYUoIfnzBB749W
CDfpCkkkO9w2lCKzkKDaTAnxOGRSuuMYo7vqFPOb2iS0lLTXiLibfO8yjot/QxPU
HKn9EEeQsHC9o9P3jKFjj+dvPbs95QipYoOAZPOAnzfOX3pEuOzva4P43tCuPB69
RjjJzsLUoBeqQiVMnmvB8ZD8HTd5oZuxvTTkFPv3wxVGGF4y6B3C6WlvlKH7DOpd
VGFhdxeOS6xduvCMuFfKT/WXqcWJNtmfT5Iigwuro8soAwHB1Q73Ckt9miqebOMr
x61Aw6v0XDYnGxccy+BB
=QATK
-END PGP SIGNATURE-


-- 
 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. 

Re: RFS: snpomatic

[Sascha Steinbiss]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Andreas,

> thanks for working on it.  I hope upstream will follow your request
> to add proper versioning.

So do I, let's see how things develop.

> I uploaded to new but would like to mention the minor nitpicking
> that
> 
> debian/patches/fix_ungap
> 
> has lots of patch chunks that are just removing space which makes 
> reading to the real content of the patch a bit nasty.

True. In general I consider trailing whitespace something to be
removed wherever encountered, but if you reckon that people will be
re-reading the patch I am happy to oblige ;)

> I'd recommend removing these spacing-changing chunks in a next 
> version of the package.

Sure, no problem at all.

Thanks for the upload,
Sascha

> On Mon, Dec 14, 2015 at 03:46:16PM +, Sascha Steinbiss wrote: 
> Hi all,
> 
> I have prepared snpomatic as a dependency for REAPR (to come). I
> would be happy if someone could take a look in git. Apart from the
> missing watch file (no releases tagged by upstream) it is lintian
> clean and builds reproducibly. Looking forward to your comments!
> 
> Thanks Sascha
>> 
>> 
>> -- 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.
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWbvXuAAoJEFVWo04Eo2ELbYYQALM3K6ZK+kRe2DqI7uTbjo4B
xz+b9Hno86FeeZb49MGxO+9bag5NDjTrxdbtaEoiGlUA8RNORlyAoSxYTnl4SmOc
0kef6lPqGVAaBg2h+QdfvohVj26X7wbz0B1B19PHHLlWDSgl3REZnCIgOTITJMWe
ps73DqLuNO6TEOnlgZM7UFzo00lObHIGzT93XisLwEY090eLkG17qevQ6WujF0DU
eN+d5sA0/MKGxV+F419MrtBAxyevYE/UMXvg0d5JHYwkMOc7PDgo7Q0aMjhP1yZm
pjTrxpAi0rJWeKgeYRgvNEpy7ys2vpwwBNAIvNfQsi8BmEA07v5E0p+gzbw8LjAv
a9Qu32HyeutKMvpo6fYe0v3J2jftN3yEgfn4Y2xl5NCDx07xp0OfQq/wmo/orv2t
6LH5BTPzHdxa/GsGXn4D4sr0hsNeg+HplAUNoLzqfDfa5Qz6yQt+Qb8mR4fnxuaU
od67pcmOfBKpwNCBhNRG9M8Ue/81xeqn6cJurXON4Diuh7G3dQVHJKRdha3zZo2T
aPv/DIBhZHUgFOS+Dr3MeQ60o9mD1oiOdPACXCQjJmnYqf3Fq1LCdXeaDDzsLTcZ
HVXTkwhIuwAHVTxROYO3gSaiCW0C01HUJ+8U6Jmc5ZV6I+xrsFwz/ZhuxCXqUhj9
FKQZ5DTfWQalnbSLupc4
=ybaU
-END PGP SIGNATURE-


-- 
 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. 

License for tabixpp

[Sascha Steinbiss]

Dear Erik,

I'm writing you on behalf of the Debian Med team that has the objective to 
package all Free Software in the field of Biology and Medicine for official 
Debian.  

I am currently prepared a Debian package for your Tabix C++ wrapper tabixpp 
[1]. It is a requirement for other software using it and that I am looking to 
package. However, the tabixpp GitHub repository does not specify a license, 
which is necessary for being able to distribute the code in Debian.

I would also be very glad if you could also consider pull request #10 [2] (not 
by me, but it makes working with the source a bit more convenient).

Many thanks, and kind regards
Sascha

[1] https://github.com/ekg/tabixpp
[2] https://github.com/ekg/tabixpp/pull/10

Bug#807779: ITP: snpomatic -- fast, stringent short-read mapping software

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: snpomatic
  Version : 0.0.20151015 
  Upstream Author : Heinrich Magnus Manske <m...@sanger.ac.uk>
* URL : https://github.com/magnusmanske/snpomatic
* License : GPL-3+
  Programming Lang: C++
  Description : fast, stringent short-read mapping software

High throughput sequencing technologies generate large amounts of short reads.
Mapping these to a reference sequence consumes large amounts of processing
time and memory, and read mapping errors can lead to noisy or incorrect
alignments.
SNP-o-matic is a fast, stringent short-read mapping software. It supports a
multitude of output types and formats, for uses in filtering reads, alignments,
sequence-based genotyping calls, assisted reassembly of contigs etc.

This package, maintained by the Debian Med Packaging Team, is a dependency for
REAPR.

Bug#805693: ITP: codonw -- Correspondence Analysis of Codon Usage

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss <sa...@tetrinetsucht.de>

* Package name: codonw
  Version : 1.4.4
  Upstream Author : John Peden <jfp%23hanson-cod...@yahoo.com>
* URL : http://codonw.sourceforge.net
* License : GPL2
  Programming Lang: C
  Description : Correspondence Analysis of Codon Usage

CodonW is a package for codon usage analysis. It was designed to simplify
Multivariate Analysis (MVA) of codon usage. The MVA method employed in 
CodonW is correspondence analysis (COA) (the most popular MVA method for
codon usage analysis). CodonW can generate a COA for codon usage, relative
synonymous codon usage or amino acid usage. Additional analyses of codon
usage include investigation of optimal codons, codon and dinucleotide bias,
and/or base composition. CodonW analyses sequences encoded by genetic codes
other than the universal code.

This package will be maintained in the Debian Med Packaging Team.

Re: Debmed sprint ?

[Sascha Steinbiss]

Hi all,

>> Any news regarding next sprint?
>> Copenhagen neighbourhood had been suggested, but are a location and date
>> fixed?
>>
>> I d like to look at tickets soon enough to find cheap prices
> 
> See here
> 
> https://wiki.debian.org/Sprints/2016/DebianMed2016

I have just looked at the hotel availability [1] but it looks like all
single rooms are already booked for that time period ('Udsolgt')?

Cheers
Sascha

[1]
http://www.sinatur.dk/book-et-ophold/alle-hoteller#{%22language%22:%22da-DK%22,%22hotelCode%22:%22FRD%22,%22hotelRegion%22:%22null%22,%22arrivalDate%22:%222016-02-04%22,%22stay%22:3,%22time%22:%220%22,%22customer%22:null,%22ScenarioType%22:%22NoSeat%22,%22roomCount%22:1,%22visibleRatePlans%22:null,%22visibleSeats%22:null,%22activeRate%22:%22%22,%22promoCode%22:%22%22,%22rooms%22:[{%22guests%22:[1,0,0,0,0,0],%22roomCode%22:%22DVF%22,%22ratePlan%22:%22BAR4FRD%22}],%22currentRoom%22:0,%22currency%22:%22DKK%22,%22currentStep%22:3}


-- 
 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. 

RFS: kmc 2.2-1 is ready

[Sascha Steinbiss]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

I have updated kmc to the most recent version. Lintian clean in my sid
pbuilder. Can someone take a look and upload, please?
I would also be happy to get DM permissions, if possible :)

Thanks,
Sascha
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3IP/AAoJEFVWo04Eo2EL1tYQAIqAGv/j7NPD7IzLD2idojXU
QZ8UAQzKXWbSjcSjSR9u7AZkB3oGwy/giNz/O3oX3SQi0u8SbBYiJtp9+7q7GKW7
T1KG/ZhYefgzLvz5fi1wsxjjsp+if4slc9Pl5yPgR8KKnyKkwBSF4k5Gyi9G7ZQ+
CoHeLECXJOS79H9mtxsBkOOh1MYX5sZcgdJ1Rh2FXz4RvVqthraVrR6iraoe5WME
rfI+o0ZAm9PF0CqX9oVZUtuc5EPOknKZ2DzNt2y4cj6IlHr/kofGLoMdPVs6yMj/
NkY/kTxuz5YQi+7D8CEhdeWaeibO4IYCQZ+ifrhBW2z7RR0FYQFVaazNtG64SFfk
b3ldbNDXiVhDbRLQTTZGvxb0vM6OLsklkLULqflhL3eEZOCJSje6v/+8B+NhwrqU
WiGkoEQq40KLBqoLbqWogiA17bdg8E+KHWei4dW4oe8tdI46wamrenxTDwj1Wurw
9sIsmhoCQN4q4F2z8tMXauZaRxVrlwEGFCxsDCSk4vVtHGsEU9wjAADQ3nRcNkSI
J7Lu3iTVwsy6hZOnJpc2usBh3Fuy4qkDCxA3unaSwmb3M++rrCfim9Au9NymMztq
bHviKfbeMtvDZcaG4LSHTfDCkBzwQjXQ31G4I364wbyfqEvjDFme/be4yq54yXNa
Dys1bY4kWPZMkm1JXjQW
=eSmj
-END PGP SIGNATURE-


-- 
 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. 

Re: DebianMed policy error

[Sascha Steinbiss]

Hi,

Btw, in the same paragraph, I think it should additionally be
'--svn-noautodch' instead of '--svn-no-autodch':

[vagrant@debian-8:~] $ svn-buildpackage --help | grep autodch
  --svn-noautodch  Don't add a new Debian changelog entry when done

Cheers
Sascha

On 12/08/2015 10:12, olivier sallou wrote:
 Hi,
 there is an error in DebianMed policy page [0]:
 
 *svn-buildpackage* |--svn-tag-only|
 |= --svn-only-tag|
 |
 |
 |[0] http://debian-med.alioth.debian.org/docs/policy.html|
 |
 |
 |Olivier|


-- 
 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. 


-- 
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/55cb1123.10...@tetrinetsucht.de

Re: Hint for newcomers: Please check developers dashboard

[Sascha Steinbiss]

Hi all,

 If you check your developers dashboard
 
   https://udd.debian.org/dmd/
 
 you can see all things you could do on packages you touched.
[…]

I’ve actually also found the QA overview very useful, e.g.

  https://qa.debian.org/developer.php?login=sas...@steinbiss.name

which also shows if there’s something to do, and also some more useful stats 
about your packages.

Cheers
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/aaeef2f8-578f-40c8-9ea1-c996bff5b...@tetrinetsucht.de

Bug#793907: ITP: tantan -- low complexity and tandem repeat masker for biosequences

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss sa...@tetrinetsucht.de

* Package name: tantan
  Version : 13
  Upstream Author : Martin Frith tan...@cbrc.jp
* URL : http://www.cbrc.jp/tantan/
* License : GPL
  Programming Lang: C
  Description : low complexity and tandem repeat masker for biosequences

tantan is a tool to mask simple regions (low complexity and short-period tandem
repeats) in DNA, RNA, and protein sequences. The aim of tantan is to prevent
false predictions when searching for homologous regions between two sequences.
Simple repeats often align strongly to each other, causing false homology
predictions.

This tool is very useful in conjunction with fast aligners like LAST.
See http://www.ncbi.nlm.nih.gov/pubmed/25172925 for a good use case
example.

The tantan package will be maintained by the Debian Med Packaging Team.


-- 
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/20150728192230.29965.57314.report...@jessie64.vagrantup.com

Bug#776710: ITP: barrnap-data-nonfree -- non-free pHMMs for barrnap

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss sa...@tetrinetsucht.de

* Package name: barrnap-data-nonfree
  Version : 0.5
  Upstream Author : Torsten Seemann torsten.seem...@monash.edu 
  URL : http://www.vicbioinformatics.com/software.barrnap.shtml
* License : SILVA
  Description : non-free pHMMs for barrnap

Profile Hidden Markov models (pHMMs) for use with Barrnap (BAsic Rapid
Ribosomal RNA Predictor), which are only free to use for academic users.
In particular, these are the 28S (euk) and 23S (arc, bac) rRNAs.

This package, suggested by the upcoming barrnap package, extends it to include
additional RNA models derived from data which is not freely available to all
users (academic only).


-- 
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/20150131142549.2951.12213.reportbug@renard

Re: DebianMed Sprint in St Malo precision

[Sascha Steinbiss]

Hi Olivier,

 By the way, do you think we should work out which rooms to book right
 now or is it enough just to let them know you are coming now, and group
 together into rooms when we arrive?
 Hi,
 sorry for late answer,
 you should book it right now.

Okay, so if they ask what kind of room I want exactly, I need to know if
someone wants to share a room! Any volunteers?

 You'd better call them if you get no answer.

I will.

Thanks
Sascha

 On 09/12/2014 09:48, olivier sallou wrote:
 Hi,
 sorry for the multiple emails but I want to precise that even if you are
 registered on the Sprint Wiki, you need to register yourself with the
 hotel to get a room.

 The Wiki is used for planification only, no room is booked automatically.

 Thanks

 Olivier

 


-- 
 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. 


-- 
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/5493ffe6.5060...@steinbiss.name

Re: unstable/experimental freeze policy

[Sascha Steinbiss]

On 15/12/2014 11:30, Andreas Tille wrote:
 Hi Sascha,

Hi Andreas,

[...]
 I think by waiting a certain time to see whether some QA tools have
 run once or twice which is probably in a one month time frame.

 Oh, I didn't know these tools also run on experimental. In this case I
 completely agree!
 
 Well, this is a misunderstanding.  The QA tools are running on testing
 and unstable and I would wait a bit to be sure that several runs will
 not show anything problematic.  If this is the case we could think about
 violating freeze policy and upload to unstable.

It seems there is a misunderstanding... if the QA tools only run on
testing and unstable, how will this tell me if my package update in
experimental is safe to upload to unstable?

I see that I can get build logs for experimental
(https://buildd.debian.org/status/package.php?p=genometoolssuite=experimental)
which is good as the new version of the package builds on all platforms
on which it was built before. But lintian
(https://lintian.debian.org/maintainer/debian-med-packag...@lists.alioth.debian.org.html#genometools)
has not picked up 1.5.4-1 yet and and debcheck does not have checks for
experimental
(https://qa.debian.org/debcheck.php?dist=experimentalpackage=genometools).

[...]
 So we can agree upon uploading mid January (latest at our sprint :-)).

Absolutely :)


 See you
  Andreas. 

See you there,
Sascha


-- 
 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. 


-- 
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/548ffe20.1070...@steinbiss.name

Re: DebianMed Sprint in St Malo precision

[Sascha Steinbiss]

Hi Olivier,

I have sent an email to the hotel last week to book a room but have not
yet received any reply... could it be that they have no network at all
right now?

By the way, do you think we should work out which rooms to book right
now or is it enough just to let them know you are coming now, and group
together into rooms when we arrive?

Thanks
Sascha

On 09/12/2014 09:48, olivier sallou wrote:
 Hi,
 sorry for the multiple emails but I want to precise that even if you are
 registered on the Sprint Wiki, you need to register yourself with the
 hotel to get a room.
 
 The Wiki is used for planification only, no room is booked automatically.
 
 Thanks
 
 Olivier


-- 
 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. 


-- 
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/5490001b.3000...@steinbiss.name

Re: unstable/experimental freeze policy

[Sascha Steinbiss]

Hi Andreas,

On 16/12/2014 10:08, Andreas Tille wrote:
 We need to make sure that the *release* has no bugs.  If you later
 upload to unstable and a bug occures you can fix the bug in unstable as
 usual.  But if you have upload to unstable an later a bug in testing is
 detected you run into trouble fixing this problem via unstable since
 there is just a higher version.

Ah, _now_ I get it. All makes sense now :)

Many thanks (and have hice holidays)
Sascha


-- 
 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. 


-- 
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/54900604.8050...@steinbiss.name

Re: unstable/experimental freeze policy

[Sascha Steinbiss]

Hi Andreas,
 I have just uploaded a new version of a package (new GenomeTools
 upstream version) to experimental
[...]
 do you see much in the way of uploading this package to unstable as well?
 
 You always need to outweight policy with sane reasons / common sense.
 If you think GenomeTools and its dependencies will pretty surely not
 feature any RC bug we will probably not need to keep new versions out of
 unstable.  But how can you surely know this?

Well, I cannot prove it... but as there is currently only one package
depending on it and I'm both its upstream author and maintainer, I think
I'm fairly sure ;)

 I think by waiting a certain time to see whether some QA tools have
 run once or twice which is probably in a one month time frame.

Oh, I didn't know these tools also run on experimental. In this case I
completely agree!

 So if you are sure the Debian import Freeze for Ubuntu will be Feb
 2015 it might be the best compromise to upload GenomeTools (and its
 dependencies) in mid January which should be sufficient to a) reach
 Ubuntu and b) uncover any RC bugs in testing.

Absolutely! The Ubuntu import freeze for vivid is on Feb 19th
(https://wiki.ubuntu.com/VividVervet/ReleaseSchedule) so mid January
definitely sounds good.

Thanks and best regards,
Sascha


-- 
 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. 


-- 
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/548eb176.9020...@steinbiss.name

unstable/experimental freeze policy

[Sascha Steinbiss]

Hi all,

I have a question regarding the jessie freeze policy. In the policy
document (https://release.debian.org/jessie/freeze_policy.html) it says
that one should keep disruptive changes out of unstable and continue
making use of experimental for changes that are not suitable for jessie.

I have just uploaded a new version of a package (new GenomeTools
upstream version) to experimental, fixing many original upstream bugs
and introducing new features. It is a dependency for another package and
contains a library. As this new release contains a fix for a bug which
has been quite common for a while and a major source of tickets in the
upstream issue tracker, I would really like to make sure that

 a) current unstable users get the new version, and

 b) Ubuntu picks up the new version until their Debian import
freeze in Feb 2015 (they import from unstable),

do you see much in the way of uploading this package to unstable as well?

Note that I am not asking for an unblock to get it into testing -- there
are no RC bugs, and new upstream versions do not seem to be liked much
for unblocks anyway. Unstable only will be perfectly fine for me.

Maybe I could get some opinions...

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/548c24b3.6020...@steinbiss.name