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:
https://salsa.debian.org/med-team/fieldbioinformatics/-/commit/8d46dfc1601546376bac0cd30c954301c99a5670
> >> 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
understanding.
> >> 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
Andreas.
--
http://fam-tille.de
Reply to: