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
