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
