Re: Bio-Linux 9
On 6/22/18 9:23 PM, Andreas Tille wrote: > On Fri, Jun 22, 2018 at 05:53:40PM +0200, Steffen Möller wrote: >> @all, anybody who minds if I remove all software from our red list that >> has stale URLs? Hexamer came to mind. Ohters just needs an update of >> their URL like GenoGrapher and yet again others should possibly be >> removed because there is no real interest? > I'd be **really** happy if somebody would check that list, remove and > fix what needs to be removed or corrected. There is no point in simply > assembling a list of software which is outdated and will possibly never > be packaged. And if we just remove that red section? After all, we do have ITPs for what red is meant to express. So, I would rather have red as an indication of a delta to conda - or to bio-linux to stay in the thread. To digress a bit - to care for single packages is a bit from the past. It is a requirement, but nothing that a distribution can sell. We should find ways to truly present tasks on our tasks page. And this means that we present small workflows. The message to transport is "anybody using our distribution has everything needed to assemble and annotate a whole genome and the method section of your paper should say '...'." To digress a bit more, quite some of us are employed for the bioinformatics support of a certain routine. And this routine changes all the time because of new versions of tools (technical), new tools (more than just technical) and new flavours of data (almost biological). So, for these fully-employed bioinformaticians the "official" workflow is more like a template for what they are after. This is why I am so much after the RRIDs to be added to our packages - there will be abstractions from current established workflows towards an interaction of RRIDs and there will be suggestions to substitute RRIDs with each other. The main question for me are a) do we know what workflows we are supporting b) do we have all b1) the man power to keep all these packages updated b2) the contacts into the community to decide for the right packages Sorry for tall that text. So, I propose to * remove all from current red packages * reinterpret it as - packages other distros have that are of interest for us - packages that we should have because these are at the cutting edge of a workflow we support [once we have decided for workflows] Best, Steffen
(Bug #890784) Autopkgtest for readseq
Hi Andreas, I have just pushed some changes to readseq, including an autopkgtest and a patch to fix upstream tests. There is a bug: a conversion to ASN.1 format works improperly, and it is not trivial to fix. I would have done so if the program was not so old. That is why I have just disabled a "Test of NCBI ASN.1 conversions" and put an explanatory message. Please, check my commits! With regards, Liubov
Re: Autopkgtest fails if kmer is built with sbuild, but doesn't—with dpkg-buildpackage
Dear Andreas, On Wed, 20 Jun 2018 at 22:10 Andreas Tille wrote: > On Wed, Jun 20, 2018 at 12:13:04AM +0200, Liubov Chuprikova wrote: > > > I am worried that I will not be able to identify the offending piece of > > code. Could you suggest how to proceed here? > > I'd recommend to discuss the issue on debian-ment...@lists.debian.org. > Thank you for your guidance! I have written about the issue. Hope, someone will be able to help! __ Liubov
Re: (Bug #890784) Autopkgtest for readseq
Dear Liubov, On Sat, Jun 23, 2018 at 03:01:27PM +0200, Liubov Chuprikova wrote: > I have just pushed some changes to readseq, including an autopkgtest and a > patch to fix upstream tests. There is a bug: a conversion to ASN.1 format > works improperly, and it is not trivial to fix. I would have done so if the > program was not so old. That is why I have just disabled a "Test of NCBI > ASN.1 conversions" and put an explanatory message. I think that's a sensible approach. Uploaded. Thanks for your work on this Andreas. -- http://fam-tille.de
Digressions (Re: Bio-Linux 9)
Le Sat, Jun 23, 2018 at 11:45:04AM +0200, Steffen Möller a écrit : > > And if we just remove that red section? After all, we do have ITPs for > what red is meant to express. So, I would rather have red as an indication > of a delta to conda - or to bio-linux to stay in the thread. Hi Steffen, I think that it is a good idea. The red section is somehow a relic from the past because our growth made it unmaintainable, because the Debian Med developer community is broader and collectively we have a good intuition of what should be packaged next, and as you wrote later in your email, because the added value in Debian is in integration, which translates to the keyword "workflow" in Debian Med. > To digress a bit - to care for single packages is a bit from the past. It > is a requirement, but nothing that a distribution can sell. Very much agreed. I see how bioconda is slowly overtaking us, just by providing an essential feature: the ability to install software via a package manager without having to ask a busy sysadmin to run a sudo apt install command. But most of our packages do not have pre/post-inst/rm scripts, and their contents could be dropped seamlessly in the appropriate XDG directories of local users, had we the tool. And we have a fairly comprehensive (but not exhaustive) collections of versions available in snaphsot.debian.org, with an increasing coverage of autpkgtests that would allow to doublecheck that mixing packages from previous releases would still work. Altogether, we have an excellent base for providing whole workflows to local users, we just need some people to do it, and I have the impression that it requires to be able to spend full-time attention to the project at the beginning, which is hard for everybody who already have routine tasks generated by their main contribution to Debian Med... Oh well, I hope I will eventually manage to join a Debian Med sprint :) Have a nice Sunday, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
