Hi again, On Mon, May 11, 2020 at 10:23:36PM +0200, Andreas Tille wrote: > On Mon, May 11, 2020 at 06:33:15PM +0200, Jun Aruga wrote: > > Many thanks for updating the spread sheet adding the Debian and > > Bio.tools status! > > You are welcome.
I've done some more updates meanwhile. > > I added the following 2 columns. It's great if we can fill it if we have a > > time. > > > > * Deb in Debian? arm64 > > * Deb in Debian? ppc64le > > I admit I'm not really motivated to fill these columns manually. I've > rather drafted a small script that you can run: > > > https://salsa.debian.org/blends-team/med/-/blob/master/covid-19_doc/bio_covid-19_dependencies_query > > The current result can be found here > > > https://salsa.debian.org/blends-team/med/-/blob/master/covid-19_doc/bio_covid-19_dependencies_result This is way better filled now 14 days later then my first reference to it. Some packages are just in Debian some more are waiting in new and some others are at least commited to Salsa to provide some metainformation and the possibility to link to on tasks pages. > > the HPC resources for COVID-19 analysis. > > > > I talked the motivation to people in nf-core project, and they are > > interested in it. > > Currently nf-core pipeline projects only support and have the amd64 > > based docker containers. > > I hope that the query result is helpful. I also checked bustools as > example that was pinned to amd64 architecture. Since I have not seen > any reason I simply uploaded for any architecture - lets see what we get > out of this. This seems to look good on all architectures. > > By the way, Steffen, > > Just keep in mind. "cat" is not the regular UNIX command's "cat", but > > "CAT", as Andreas mentioned it. > > But its a proof that my remark about some unfortunate choice of the name > that Steffen misunderstood the package request. This is now packaged as cat-bat (and in Debian new queue). When investigating into your list I was facing the following questions: umap ---- You mention in your document[1] for umap explicitly https://github.com/lmcinnes/umap However, I've found in Salsa another project with unfinished packaging https://bitbucket.org/hoffmanlab/umap This is really unfortunate and I filed issues cross-wise[2]. At least in Debian we should find distinct names and actually make sure that Jun's link is refering to the correct one of both obviously active projects vep --- I just want to make sure that the vep in Jun's list is refering to https://github.com/Ensembl/ensembl-vep guppy ----- When I tried to package pplacer I stumbled upon the fact that its using the "GPLed guppy". Since we discussed that guppy is closed software I was asking here: https://github.com/matsen/pplacer/issues/371 There is "another" guppy build by pplacer (once we might be able to build this OCaml software. Is it possible that the "guppy in nanopore workflows" is this guppy inside pplacer? Kind regards Andreas. [1] https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 [2] https://github.com/lmcinnes/umap/issues/439 and https://bitbucket.org/hoffmanlab/umap/issues/12/name-space-collision -- http://fam-tille.de
