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

Re: Which columns should we start working on?

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

On Tue, Mar 23, 2021 at 10:13:48PM +0100, Steffen Möller wrote:
> down and what a quick success.
>       MEME (Others) - a classic

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

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

What is the relation and what should be the next step.
>       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?

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

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


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. 
> > * What do you think of the "package of the week plan" that Andreas proposed?
> I admit to have forgotten about it. But how many people do we then want
> to work at the same package. Andreas did a good job with the
> videoconferences such that we got to know each other. So, I suggest to
> keep the Excel sheet as a synchronisation tools - we write the name of
Sorry to nitpick here:  We are not talking about that non-free software
tool to work on spreadsheets.  I wished people take more care on our
list and use the generic term spreadsheet.  Thank you.

> ours somewhere in the package line so we know who is active on it. And
> whoever wants extra input then just says so.
> scanpy I think would have been on my list from last months and I am very
> happy to see this addressed.

I did a bit more on it (and just pushed python-leidenalg to Salsa which
is another dependency).  I'll coordinate with Robbi to continue with
this.  (Thanks for answering the question about naming in your other
> My next picks would be for A) MEME

See above: Please lets start with freeing this.  Its even mentioned
at the TODO section of the Software liberation page[1].

> B) pyomo


   Which one?  Please sort out this to not confuse others.

> A^B) autodock-gpu - can we
> have three packages of the week?

No we can't.  Please throw a coin and lets continue with the next
one later. ;-)

> I need another few days on non-Debian-issues, I am afraid.

Thanks a lot for this start anyway


[1] https://wiki.debian.org/DebianMed/SoftwareLiberation 
[2] https://salsa.debian.org/med-team/python-leidenalg


Reply to: