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
Wiki)?
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.
> 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
https://salsa.debian.org/med-team/fieldbioinformatics
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:
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.
> > * 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
mail.)
> 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
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.
> 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
Andreas.
[1] https://wiki.debian.org/DebianMed/SoftwareLiberation
[2] https://salsa.debian.org/med-team/python-leidenalg
--
http://fam-tille.de
Reply to: