Re: Which columns should we start working on?
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.
>
> 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.
>> 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.
>
>> 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
.
>
>> 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.
>
>> 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.
>
>> 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.
>
>>> * 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.
Yup. Thanks.
>> 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.)
Thank you.
>
>> 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].
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.
More thanks!
Steffen
Reply to: