[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Which columns should we start working on?

Hi Steffen,

On Wed, Mar 24, 2021 at 03:53:41PM +0100, Steffen Möller wrote:
> Am 24.03.21 um 11:38 schrieb Andreas Tille:
> > Hi Steffen,
> >
> > thanks a lot for your verbose answer.  I admit I'm afraid that this
> > valuable information might get lost amongst random postings in our web
> > archive.  Is there any volunteer to create a Wiki pointing to the
> > spreadsheet in question (and may be the spreadsheet links back to that
> > Wiki)?
> I had mentioned the spreadsheat in ()s after the package name. But you
> can also search for the package name across sheets.

I mean this actual mail you wrote to the list should be in a more
prominent place to enable users finding it easily.

> > On Tue, Mar 23, 2021 at 10:13:48PM +0100, Steffen Möller wrote:
> >> down and what a quick success.
> >>
> >>       MEME (Others) - a classic
> >    https://salsa.debian.org/med-team/meme
> >    -> Main blocker is IMHO the non-free license.  I need to admit
> >       personally that I would be really happy if we could do way
> >       more on this front.  I'm frequently asked whether there are
> >       some non-coding tasks in Debian Med.  Here it is:  Contact
> >       upstream and log your activity in the Software Liberation
> >       Wiki[1]
> >    -> I've done some `routine-update -f` + polishing but there is
> >       some build error.  Probably/hopefully not hard to fix, I guess
> >       a newer gcc issue than upstream was testing with.
> It is non-free for now. This likely is why it is not in.  Right. Hm.

Nilesh has nicely written to upstream (thanks Nilesh!)  Lets see what
might happen.

> >>       bbtools (Others and bulk RNA-seq) - we may already have part of
> >> that in the distribution - I was/am a bit confused, still - is this
> >> redundant with bbmap?
> > Can you please clarify this question?  Others have no better option than
> > reading your mind. ;-)
> It is the same, so we just need to somehow make this easier for our users.
> bbmap we are shipping is https://sourceforge.net/projects/bbmap/ and in
> /usr/share it  comes with lots of shell scripts that start with "bb". I
> now saw on https://jgi.doe.gov/data-and-tools/bbtools/ that they are
> pointing to that bbmap repository.
> Ok - leave that to me ;) I think this can be fixed in d/control.

May be even some "Provides: bbtools" ?
Those scripts in /usr/share are just due to my lack of knowledge.
Please make things more sensible!
> >>    B) the "columns". These are representants of what software biologists
> >> are likely to need to go from raw data to a publication and nobody
> >> missing anything. My priorities here are
> >>
> >>       virus tab:
> >>         1st and foremost: artic fieldbioinformatics - this uses the
> >> nanopore to tell what ebola/sars strain you have - this may be as close
> >> to the pandemics as we can possibly get. Since I work at a University
> >> Hospital I think I am allowed to feel positively about finding someone
> >> to field-test our fieldtest package once this is completed.
> >> There is the original artic implementation and a reimplementation with
> >> the nextflow workflow. Whatever we get to first, I tend to think.
> >> Confusing? That is why we need the bio.tools folks - it is too much for
> >> our tasks list (and for bio.tools, still :-) ).
> > Yes, please lets clarify this.  For the packager its simply unclear
> > what to do when reading this.  The spreadsheet has
> >
> >     https://nf-co.re/artic and we have
> >     https://salsa.debian.org/med-team/fieldbioinformatics
> >
> > What is the relation and what should be the next step.
> https://nf-co.re/artic is the reimplementation of the artic fieldbioinformatics workflow with nextflow. And there should somewhere be the original to that reimplementation. Personally, I like the idea to implement as much as possible of what the nf-core community comes up with, so I would go for https://nf-co.re/artic
>  . 

I tried to document this here:
> >>       Single-Cell RNA-seq - all of them, preferably
> >>       bulk RNA-seq - BioConductor,  pigx-rnaseq - is mostly there
> > Are you taling about Column "W"?  I can not make a direct connection
> > between your text and the spreadsheet, sorry?  And if yes, what are
> > we missing?
> These are sheets.

Ahhhhhh, thanks for your patience - probably I'm a bit slow in

> >>       nanopore - it is the sequencing technology that is closest to us -
> >> I actually own half of one, Jun has a complete one :) It is used in the
> >> field to genotype viruses - today - it is too young to have a perfect
> >> pipeline for it, yet, I tend to think. And the device is used so very
> >> heterogeneiously. Things get updated very frequently everywhere and so
> >> this is more like a "let's see what is going to be used"-kind of
> >> situation for me at the moment.   
> > Here you are talking about the nanopore tab, right?
> Yes.
> What I typically do is to look at the methods section of papers and add
> tools that have been used for that paper. The blocker is guppy to have
> it all completely Open Source.

I remember we discussed this and someone has given reasons why there
is less hope.  We should try to ask upstream anyway.

> >> There are some tools that block many columns from being completed. To
> >> mention here in particular are the workflow engines, and here it is
> >> nextflow that seems like being a beast to package. So, yes, Nilesh,
> >> please, nextflow out of the way would be a big help.
> > I very weak start was done here:
> >
> >    https://salsa.debian.org/med-team/nextflow
> >
> > As I mentioned in d/changelog it seems capsule is a blocker.
> >  
> >>    A^B) the packages that have a direct application to virology/drug
> >> development and are mostly singular applications - look at what
> >> OpenPandemics' Forli lab and colleagues are giving us
> >> https://forlilab.org/ . My picks are
> >>
> >>     AutoDock-CrankPep (Docking/Structures) since oligopeptides are a
> >> common tool to fish for antibodies, so you want to have something to
> >> model that.
> >>
> >>   and sometimes it is "community forming" and "technical curiosity" that
> >> triggers me as for
> >>     cmdock (Docking/Structures)
> >>     autodock-gpu (Docking/Structures)
> >>   which would be seen by all the BOINC-people. But who would not go
> >> through their website and dream a bit.
> > Are these listed in the spreadsheet?  I guess if you give more direct
> > links (either to the spreadsheet or links to the upstream projects)
> > chances to get this packaged are higher. 
> Yes. The sheet is in ()s.

Thanks again for the explanation.  I really think we should iron
out this in an accompanying doc for the sheet.

> > See above: Please lets start with freeing this.  Its even mentioned
> > at the TODO section of the Software liberation page[1].
> Thanks!
> >> B) pyomo
> >    https://salsa.debian.org/science-team/pyomo
> >    https://salsa.debian.org/python-team/packages/pyomo
> >
> >    Which one?  Please sort out this to not confuse others.
> They are the same package. https://salsa.debian.org/science-team/pyomo
> was last changed by me,
> https://salsa.debian.org/python-team/packages/pyomo last changed by
> sandro who updated the maintainer address for a 3year old codebase. The
> one of the python-team should be removed.

Would you mind asking the Python team for removing this?  I do not have
admin permissions there.
Kind regards



Reply to: