On 25.03.20 11:36, Andreas Tille wrote:
[@Charles, please read below]
On Tue, Mar 24, 2020 at 11:07:38PM +0100, Steffen Möller wrote:
Wrt package lists I know you need this for the blends structure.
Well, not for the structure. We need to mention packaging tasks
and links to useful software could be put on our todo list. The
tool I currently prefer is the blends structure (until we have
something more practical).
A single package is neat to see packaged, but we need to complete a
workflow and test that workflow intensively. I suggest we agree on a set
of workflows we want to bring to Debian and then we do that. Non-free,
experimental, preferably main - but Debian, in a way that official
images of docker/amazon can find and install it.
have these lists, What I have is a small list of lists:
https://github.com/nanoporetech/ - the nanopore is a prime tool for
Hmmm, that github directory lists several tools but none with this
description neither the name nanopore. I've found a software named
nanopore on Github here:
Which one do you mean?
The is the official repository of the creator of the Nanopore. I want
them all, but we should start with the easy ones and the ones and the
ones required from workflows the we decide to bring to Debian.
I just looked at is
https://github.com/nanoporetech/qcat/blob/master/Dockerfile . This
starts with an Ubuntu image and compiles the package on the fly. Conda
is not mentioned in that repository but is has it
https://anaconda.org/bioconda/qcat . My preferred package name would be
That's also a directory. I've got a previous hint to
which is close to ready for uploading (should be listed on the covid-19
task soon). What else besided chip-seq would be most relevant.
I suggest we take the workflow of interest, say
and look at the packages loaded from Conda. For the epitope prediction
- python=2.7.15 #dont upgrade, FRED2 needs python 2.7 for now
- multiqc=1.6 #cant upgrade due to Python2 fix
Seems like we need to give FRED2 a bit of a technical push. And that is
exactly how Debian is helping.
I am not sure about the amont of energy I want to continue to invest
into bcbio at the very moment, I must admit.
I'll re-check your list.
Postpone that until the package is found relevant also for another workflow.
and there is another RNAseq library that is _almost_ there, i.e. we have
all the packages, but
describes issues about getting the css files into the R packages to have
nicer reports, without which the tests of pigx-rnaseq fail.
I can have a look. It needs multiqc which in turn has a non-free
dependency. I might try to follow the hint that we simply drop
Highcharts and document in README.Debian that the functionality is
restricted. This might help the dependencies of multiqc. What do you
think about this?
library, i.e. I introduced a privacy violation. The package may then go
to non-free or so but I am fine with that - biology first. For me. And
bcbio already is in contrib because of a dependency on vienna-rna (which
is one of those "almost free" licenses).
runs into the missing bits of the popular r-cran-locfit package.
Charles, are you reading here? We really need to push this issue
This happens in deseq2.
It is not on me to decide what workflow should be followed up. I suggest
to collect a series of options and the community should somehow
distribute the work.