Re: sra-sdk: drop B-D on markdown

[Charles Plessy]

Le Sat, Jul 06, 2024 at 03:54:21PM +0200, Pierre Gruet a écrit :
> 
> As this B-D has alternatives (markdown | libtext-markdown-perl | discount),
> we should just remove markdown from the alternatives to prevent sra-sdk and
> its rdeps from being removed.

Actually, I wonder if the whole line can just be reomved... I do not see
anything in the package that uses the markdown command to build
documentation.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Re: package bcftools dependencies for gff2gff.py and guess-ploidy.py cause bcftools to have 10x as many dependencies

[Charles Plessy]

By the way, Giulio's Gmail rejects my messages, so maybe somebody can
bounce the news to him ?

Le Tue, Jun 25, 2024 at 08:40:46AM +0900, Charles Plessy a écrit :
> Hi all,
> 
> I just uploaded bcftools with the Python dependencies moved to Recomends
> because:
> 
>  - they will still be installed by default,
>  - Bioconda also does not provide them,
>  - I was the one who uploaded the update introducing these dependencies.
> 
> I can revert the change if there are objections.
> 
> Thanks Giulio for the feedback!
> 
> Charles
> 
> -- 
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Debian Med packaging team http://www.debian.org/devel/debian-med
> Tooting from home  https://framapiaf.org/@charles_plessy
> - You  do not have  my permission  to use  this email  to train  an AI -

Re: package bcftools dependencies for gff2gff.py and guess-ploidy.py cause bcftools to have 10x as many dependencies

[Charles Plessy]

Hi all,

I just uploaded bcftools with the Python dependencies moved to Recomends
because:

 - they will still be installed by default,
 - Bioconda also does not provide them,
 - I was the one who uploaded the update introducing these dependencies.

I can revert the change if there are objections.

Thanks Giulio for the feedback!

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Charles Plessy]

Le Fri, Mar 29, 2024 at 07:21:27AM +0100, Andreas Tille a écrit :
>  
> For the moment it would be easy to make sure at least new r-bioc-*
> packages are restricted to the said architectures by adding this to
> dh-r.

I fully agree.

By the way the next Bioconductor is scheduled for May 1st, shortly after
the R 4.4 release.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Charles Plessy]

Hi Andreas,

I agree that we can remove EMBOSS in all 32-bit platforms.  I think that
a large fraction of the scientific field has no appetite to do any extra
volunteer work to such as accepting our patches to support scientific
computations on 32-bit systems in 15 years...

Have a nice day,

Charles

Re: Nextflow - have just used it on our HPC cluster and liked it

[Charles Plessy]

Hi Steffen and everybody,

I also use Nextflow at work, and indeed, it makes it very easy to run a
pipeline many times.  Also, Nextflow is a single Java executable, which
makes it easy to deploy anywhere Java is already installed.

You probably also saw the nf-core repository of modules and pipelines.
I like the way they are organised and find them empowering.  The
community is very nice too.

BUT

With my Debian background it is very hard for me to adapt to the conda /
biocona / quay / galaxy ecosystem.  I just can not figure out who is
responsible for what, no idea how long the whole thing will be
supported, where is the source code used to build the the packages into
Docker images in to Singularity images, etc.  Not to mention that the
whole paradigm behind "one tool, one minimal image" deprives me from all
the Unix tools that I use to enjoy on in a Debian context.  In bioconda
you have no idea whether sed is from GNU of from busybox unless you try
it or dig for a package recipe in GitHub...

NOT TO MENTION THAT

Everybody expects that these images will stay forever and for free at
the URL where they are, while I have not seen any evidence of an
organisation promising that it will really happen for at least a
decade...  Without these images and the receipes to create them
(remember the singularity <- docker <- conda <- GitHub fragmentation),
the hope that these pipelines provide reproducibility in the long term
is wishful thiking.

SO

Against the stream of minimising image size to the bone while processing
terabytes of sequencing data, I thing that Debian Med images with all of
our packages installed would be a useful alternative in many cases.

I am already doing something along the lines on our HPC cluster to turn
our packages into environment modules (lmod).

https://github.com/oist/BioinfoUgrp/blob/master/DebianMedModules.md#creation-of-a-new-singularity-image

The size of the images is a bit less than 8 GiB, and I make a new image
at each point release.  Would there be some interest to make such images
in a more official way ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Re: [Debian-med-packaging] Bug#1009118: python3-biopython: incompatible with muscle >= 5

[Charles Plessy]

Hello everybody,

I have read the Muscle5 paper and it is a totally different program than
Muscle3.

https://pubmed.ncbi.nlm.nih.gov/36379955/

Reintroducing muscle3 as a separate package might be useful not only to
Biopython, but also to the people who need it in pipelines, etc.

Have a nice day,

Charles

CWL media type and file extension now in /etc/mime.types

[Charles Plessy]

Hello everybody,

I just updated the media-types package in Sid, which brings (among other
changes) the application/cwl media type (and its json variant) in the
`/etc/mime.types` file.

If a backport would be useful to some purposes, please let me know.

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Freexian-funding for what keeps nagging us?

[Charles Plessy]

Le Wed, Apr 06, 2022 at 11:52:28PM +0200, Steffen Möller a écrit :
> 
> https://freexian-team.pages.debian.net/project-funding/

Hi Steffen and everybody,

maybe it would be useful to produce and distribute one small Singularity
container per debian-med package ?

I know that biocontainers are popular but...

 1) their contents are heterogenous and unpredictable.  In particular,
 some contain GNU sed, and other only contain busybox sed.  This makes
 writing shell scripts a real pain.

 2) I am not confident that they are all DFSG-free, in particular
 regarding non-commercial use clauses.

 3) Some of them lag behind upstream versions, and as a Debian developer
 it is far easier for me to update a Debian package than update a
 biocontainer.

 4) Maybe we can innovate a way to circumvent the need for "mulled"
 containers, by taking advantage that most of our packages can run
 perfectly on identical Stable roots ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: RFR: last-align

[Charles Plessy]

Le Thu, Aug 05, 2021 at 10:22:08PM +0200, Andreas Tille a écrit :
> 
> May be it makes sense to propagate the 2to3 patch upstream (but I'm
> to lazy to do this, sorry).

Last month I exchanged emails with Martin (the upstream developer) about
this and he answered me that he made sure that his scripts were
compatible with both Python 2 and 3.  So the only effect of applying the
patch upstream would be to to drop compatibility with Python 2.

The reason he keeps support for Python 2 is that it is still the default
on Mac OS and on some shared workstations used by scientists.  I think
we can wait that Apple wakes up and the old workstations shut down.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: ArrayExpressHTS ran into removed fastx-toolkit

[Charles Plessy]

Le Tue, Jul 27, 2021 at 12:02:00PM +0200, Steffen Möller a écrit :
> 
> fastx-toolkit https://tracker.debian.org/pkg/fastx-toolkit ran into a
> bug in one of its dependencies and was removed for that reason.
> ArrayExpressHTS still depends on fasta_formatter from that library.

Hi Steffen,

I had a quick look (git grep) at the source code of ArrayExpressHTS and
although it has an option to indicate the path to fasta_formatter, it
appears to never use it.

As a control, you can git grep other external tools (samtools, mmseq,
...) and you will see that, in contrary to the search with
fasta_formatter, it returns lines of code that do construct a shell
command using the path to the tool.

So if I am not mistaken, maybe we can just drop its dependancy ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Request for discussion - what should bio.tools et al. do for us?

[Charles Plessy]

[In brief, can Debian Med members have easy write access to the metadata
in bio.tools for the software they reference and we package, and can we
use that to strengthen out ties ?]

Le Wed, Jun 16, 2021 at 07:38:37PM +0200, Steffen Möller a écrit :
> 
> I had joined the bio.tools folks this afternoon for a pre-meeting of an
> EU project to give the registries a boost. I was asked what Debian would
> want from them.

Hi Steffen,

I just looked for my favourite tool, LAST, in bio.tools and in Debian:

https://bio.tools/last

https://packages.debian.org/sid/last-align

https://tracker.debian.org/pkg/last-align

First, it would be great to cross-reference each other.  But what is the
canonical URL for our upstream/metadata files ?

The sources.debian.net server allows to find it easily for the package
in Sid, but during freezes there may be a more up-to-date one in
experimental…

https://sources.debian.org/src/last-align/sid/debian/upstream/metadata/

The Salsa URL allows to update the metadata without uploading the
package (that was my original intention), but is not easily discoverable
once there are packages outside Debian Med.

https://salsa.debian.org/med-team/last-align/-/blob/master/debian/upstream/metadata

In the past I attempted to expose the data on a server that I called
"Umegaya" but I failed to maintain it in the long run.  There is also
the UDD if I remember well, but I can not find anymore how external
people can get information from it.

Once bio.tools can discover which softare that they reference is
packaged by us, it would be great if they can link to us.

Then, we also have the opportunity of sharing metadata.  For example in
LAST, it is outdated (homepage changed).  Getting it fixed automatically
would be a dream.  On the other hand, we could imagine that if Debian
Med members could easily update bio.tools metadata, maybe our
routine-update script could pull it for the packages that have a
Registry bio.tools entry in upstream/metadata ?

Finally, having an opportunity to advertise ourselves and our
specificities.  At work we had a discussion on whether we can become
a green campus by 2030.  Electricity production on our island is close
to 100% fossile fuel.  I really like our effort made on packages like
last-align to squeeze out computing power by having multiple
cpu-optimised binaries chosen transparently.  This is something other
platforms do not offer.  Other example, while LAST's biocontainer has
the coreutils installed, other ones have only busybox.  Although we
do not distribute containers by ourselves, it would be good to have a
place to advertise that if one uses a minimal image plus apt install our
packages, they can be sure that scripts with grep -P or sort -V are not
going to fail :)

And of course we have our strong checks on licenses, that make us unique
(and me sometimes furious in the past during NEW processings):
everything we distribute is Free, while in other projects the
prossibility to be forbidden to use in commercial proojects is always
lurking (for instance with UCSC genome tools source files or MEME source
files being included and underdocumented).

Have a nice day !

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

The laboratory where I work, in Okinawa, recruits a bioinformatics programmer.

[Charles Plessy]

Hello everybody,

The research laboratory where I work, at the Okinawa Institute of
Science and Technology (OIST, Japan), recruits a bioinformatics
programmer.

https://www.oist.jp/careers/bioinformatics-programmer-research-assistant-plankton-genomics-genomics-and-regulatory

It is a junior position of research assistant; one of the main tasks
will be to deploy and develop bioinformatics pipelines.  Our main
workflows use Nextflow and Singularity to run bioconda-packaged
software, but of course there is at least me in the team who always
eager to leverage Debian Med wherever possible.  So another Debian Med
contributor would certainely not feel lonely.  On the hardware side, our
HPC cluster has a couple hundreds nodes with 128-core AMD processors,
512 Gb memory, with many many terabytes of storage.  We have a strong
commitment to open and reproducible research.

Our research projects revolve around marine biology, and our institute
is located on a subtropical island that is ideal for connecting with the
sea on both professionnal and recreational ways...  This said, the
topics of the other research units at OIST cover fields in a broad area
ranging from mathematical and natural sciences to robotics and
behaviour, which makes OIST a great place for people who have
pluridisciplinary interests.

Have a nice Day !

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: "Entry: NA" in debian/upstream/metadata

[Charles Plessy]

Le Wed, Mar 03, 2021 at 08:08:08PM +0100, Andreas Tille a écrit :
> On Wed, Mar 03, 2021 at 06:58:12PM +0100, Steffen Möller wrote:
> > So, "NA" indeed means like "hey, I checked but this was not found". This
> > information should not be lost.
> > 
> > An empty entry, as if from a template, does not have the same meaning.
> > If NA (which is how R expects it  and I found it likely to be easier to
> > parse) or N/A - I would not be bother to do all these changes and would
> > just leave it. Indeed, on the Excel sheet I am using N/A.
> 
> I definitely bother / veto agains renaming the now implemented 'NA' to
> simply 'N/A' since there is no advantage at all.  However, I can follow
> the argument of Andrius that and empty string "" (not just nothing as in
> our empty boilerplate) could serve the given purpose.

Hi all,

how about YAML's null value for entries for which it was confirmed that
the information does not exist ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Organising Debian Med Sprint starting on Thursday

[Charles Plessy]

Le Tue, Feb 16, 2021 at 06:06:18PM +0100, Andreas Tille a écrit :
> 
> I explicitly like to mention Charles Plessy and Afif Elghraoui who both
> seem to have drifted away a bit from the team to do other tasks.

Thanks a lot Andreas :)

The new mailcap and media-types need more attention before the release
("%s" escaping is in a messy state).  After that I hope it becomes more
low-maintenance!

Enjoy the sprint !

Charles

PS: created a med-bio Singularity image from our stable release at work
and autogenerated environment modules for each packages.  Very handy
when we do not need the very latest version of a tool.

https://github.com/oist/BioinfoUgrp/blob/master/DebianMedModules.md#misc-commands

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: bedtools 2.29.2+dfsg-6

[Charles Plessy]

Le Sun, Jan 17, 2021 at 01:20:10PM +0100, Étienne Mollier a écrit :
> 
> I noticed current bedtools 2.29.2+dfsg-5 fails to migrate to
> testing, so I pushed a fix[1].  Since this is transition freeze,
> I'm not 100% sure if it should be pushed, current Testing
> version is 2.29.2+dfsg-3, and there are a few reverse
> dependencies.

Hi Étienne,

As the changes do not request action on bedtools's reverse-dependencies,
it is not a transition, so you can go ahead !

https://release.debian.org/bullseye/freeze_policy.html#transition

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

How to handle patches during a routine update ?

[Charles Plessy]

Hello everybody,

I did not realise how rusty my skills became...

At the moment my main problem is how to handle patch updates.

My specific question here is: after I run routine-update, the process is
paused with the following message:

W: There is fuzz in some patches.
   Please use another terminal to inspect patches and press RET here once 
ready

I do not know what I am supposed to do to be ready: edit the files ?
Edit the patches ?

With your precious help, I will not only update this package but also
update the information in our team policy :)

https://med-team.pages.debian.net/policy/#handling-patches

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Please do not mass-degrade Recommends to Suggests in med-bio

[Charles Plessy]

Le Thu, Jul 16, 2020 at 02:57:21PM +0200, Andreas Tille a écrit :
> 
> would love if we simply keep some task that is mainly offering
> "everything" until we have some better solution.

Hi all,

I agree: I find such tasks particularly useful when generating
multi-purpose containers.  In my case I use med-cloud to avoid graphical
programs, but the more bioinformatics it installs, the better it is.
This keeps Dockerfiles very simple :)

Have a nice day,

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

What is the best way to refresh a 2to3 patch ?

[Charles Plessy]

Hello everybody,

I was trying to update LAST (fortunately I saw I will not have to do so
anymore), but struggled for half an hour on the 2to3 patch...

I fixed it partly by hand, and partly with "quilt refresh".  But when I
inspected the patch, I realised that this approach just makes it bitrot:
the parts newly written upstream are simply not going to be covered.

Could routine-update update these patches automagicallly ?

(By the way if quilt is not the state of the art anymore, please let me
know. It took me plenty of time to find on the Internet the magic `for
where in ./ ../ ../../ ../../../ ../../../../ ../../../../../` command
that would make `.quiltrc` work; not sure why I did not paste it
to the group policy at the time...)

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: VirusSeeker: RepeatMasker missed in dependencies (Was: VirusSeeker - sorting the Downloads section)

[Charles Plessy]

> On Thu, May 07, 2020 at 11:24:00PM +0200, Étienne Mollier wrote:
> > 
> > At some point, I wondered if it would be possible to get
> > RepeatMasker into "non-free", and having VirusSeeker into
> > "contrib" then, but I'm not sure that this is legally doable
> > since VirusSeeker is GPL.

Le Thu, May 07, 2020 at 11:39:18PM +0200, Andreas Tille a écrit :
> 
> Hmmm, I do not remember but non-free is ugly for several technical
> reasons (no autobuilders, no autopkgtests, no QA checks etc.)  Thus
> the first thing I do is contacting upstream to consider changing
> their license.  Would you mind doing so?  If yes, I would consider
> mentioning our COVID-19 sprint and that a free license would support
> us in our fight against the pandemic.

Hi all,

+1 in principle, but I note that RepeatMasker has TRF (Tandem Repeat
Finder) in its dependencies, which is also non-free...

http://tandem.bu.edu/trf/trf.license.html

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Help for asking upstreams about free licenses urgently needed (Was: Help: Seeking source code of guppy base caller)

[Charles Plessy]

Le Tue, May 05, 2020 at 11:18:51PM +0200, Andreas Tille a écrit :
> 
>   apt install environment-modules  

Yes, but we are under CentOS...

This said, I use Debian Med increasingly with Singularity.  I made an
image where I `apt install med-cloud` and use it to make environment
modules that export specifically the binaries of some packages, for
instance bedtools, etc.  The tedious part is to stitch the CentOS path
to the image: at the moment I need to generate one script per command.
I wonder if there would be a way to automate some steps...

Cheers,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Help for asking upstreams about free licenses urgently needed (Was: Help: Seeking source code of guppy base caller)

[Charles Plessy]

> On Mon, May 04, 2020 at 10:37:22AM +0900, Charles Plessy wrote:
> > 
> >  - Upgrades are not drop-in replacements for each other and a laboratory
> >typycally needs to install several versions side-to-side.

Le Tue, May 05, 2020 at 06:52:43AM +0200, Andreas Tille a écrit :
> I wonder how users of that software are dealing with this.

In our case we use the environment modules system (modules.sourceforge.net).

Have a nice day,

-- 
Charles

Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team

[Charles Plessy]

Le Mon, Apr 27, 2020 at 11:52:22AM +0200, Andreas Tille a écrit :
> 
>https://salsa.debian.org/med-team/resfinder/
> 
> Both versions *.pl and *.py remain in source and it took me a long
> time to get an answer from upstream / our users what is really used
> and what should be packaged.  See also README.Debian.

Hi Andreas,

thanks a lot for this interesting example.

I think that it supports my point of view, because the resfinder.pl and
resfinder.py are not drop-in replacements for each other.  In
particular, they do not support the same set of command-line arguments.
In that sense, the Python version looks like a version 2 of the Perl
command, without full backwards compatibility.

Let's imagine now that we would have renamed `resfinder.pl` to just
`resfinder` and that on a package upgrade, we would replace it by
a renamed `resfinder.py`.  We would just break our users scripts.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Help for asking upstreams about free licenses urgently needed (Was: Help: Seeking source code of guppy base caller)

[Charles Plessy]

Hi Andreas and everybody,

I am a regular user of Guppy.  We use it to transform ("basecall") raw
signal output from the sequencers manufactured by Oxford Nanopore
Technologies (ONT) to nucleic acid sequence files in the FASTQ format
accepted by many of the tools that we package in Debian Med.

I think that even if ONT would free Guppy, packaging it would be
a significant challlenge.

 - Guppy is a moving target, and whichever version we would distribute
   in Stable is unlikely to satisfy the users a year later.

 - Upgrades are not drop-in replacements for each other and a laboratory
   typycally needs to install several versions side-to-side.

 - In many cases, a GPU is needed to have Guppy end its computation in
   a reasonable time.  But Debian does not have an infrastructure to
   test GPU computations.

 - As far as I know, Guppy is developed on amd64 and arm64 only.  We
   can therefore expect the usual portability issues.

 - The conversion from raw to FASTQ is done by neural network algorithms
   for which we do not have access to the training data, and therefore
   the freedom to modify Guppy would be limited to the sugar around the
   core algorithms.

In that sense, I think that if we want to distribute a basecaller in
Debian, we should better pick an alternative that is already free.  Some
of them are reported to perform as well as Guppy.  But which one to
pick, and how about long-term mainteance ?

Altogether, I think that we will best serve our users by making sure
that Free basecallers are easy to install on Debian, providing the
standard tools for downstream analysis (we are quite good at this), and
adding value by supporting bioinformatics workflow systems.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team

[Charles Plessy]

> Andreas Tille wrote:
> 
> > I admit I *personally* *really* hate this since I think I perfectly
> > subscribe all those good reasons to not add language extensions. 

Le Fri, Apr 24, 2020 at 06:13:45PM +0100, Chris Lamb a écrit :
> 
> I share your dislike. Please file a separate wishlist bug for this — I
> would certainly entertain arguments to add logic to Lintian in order
> to spare this boilerplate within the Med team.

Hi all,

we already have https://bugs.debian.org/190753

A lot of time has passed, and most of the Policy delegates and Technical
Committee members have changed.  Maybe we can solve the problem by
finally relaxing the policy to allow us to do exactly what we are doing
now: ignoring the call to rename programs when the main outcome is to
break our users scripts, our upstreams documentations, and sometimes our
own packages.

"Reproducible research" is now mainstream and I feel so frustrated that
Debian is the only distribution in the world that insists on
deliberately becoming incompatible, by changing programs names
arbitrarly.

The goal of this policy was to make it easier to rewrite a program from
one language to another language while keeping a compatible interface.
We now have more than 15 years of experience on that matter with
scientific software and my conclusion is: it never happens.

Have a nice week-end

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: https://github.com/nf-core/covid19 - nextflow pipeline

[Charles Plessy]

Hi Andreas,

Le Wed, Mar 25, 2020 at 11:36:27AM +0100, Andreas Tille a écrit :
> > 
> > https://github.com/nanoporetech/ - the nanopore is a prime tool for
> > covid-19
> 
> 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:

The Nanopore tools evolve fast, and most of them are not under a Free
license, but the following might be useful:

To convert old formats to new ones:
https://github.com/nanoporetech/ont_fast5_api

To demultiplex "barcoded" sequence reads:
https://github.com/nanoporetech/qcat

> > Also, this
> > runs into the missing bits of the popular r-cran-locfit package.
> 
> Charles, are you reading here?  We really need to push this issue
> forward.

I thought that the problem was solved since the package landed in
unstable and testing ?

https://packages.debian.org/sid/r-cran-locfit

Have a nice Sunday,

Charles

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: [Debian-med-packaging] How are bed files created? (Was: trinculo_0.96+dfsg-1_amd64.changes REJECTED)

[Charles Plessy]

Le Fri, Apr 10, 2020 at 06:07:57AM +0200, Matthias Klumpp a écrit :
> 
> Hmm, if those bed files can easily converted into their textual
> representation (which presumably is their preferred form of
> modification) just adding a hint that this is possible is probably
> enough for Debian.

Hi Matthias and everybody,

for scientific data, the "preferred form of modification" is a rather
misleading concept.  The pedigree files in PLINK are telling which gene
variants are found in which person, and therefore modifying them does
not make much sense.

Also, in general, text representations are not necessarly the preferred
form for modification of scientific data, because it .  For instance,
with the "BAM" format, some tools can operate directly on binary
streams. Other example, some data (like DNA sequenes produced by Oxford
Nanopore sequencers) is in HDF5, which in theory might be serialised in
text format with third-party tools, but in practice will always be
handled in binary form.

I think that what was important to show here is that these files are
example data in a standard format, and not a deliberate obsfucation of
functional parts of the software (like binary blobs in the kernel,
minified Javascript, etc).

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: How are bed files created? (Was: trinculo_0.96+dfsg-1_amd64.changes REJECTED)

[Charles Plessy]

Le Thu, Apr 09, 2020 at 06:21:17PM +0200, Liubov Chuprikova a écrit :
> 
> plink1 --bfile examples/genotypes --recode --tab --out genotypes --noweb
> 
> and back to binary, here three files will be created: *.bed, *.fam, *.bim
> (those are in examples folder):
> 
> plink1 --file genotypes --make-bed --out genotypes --noweb
> 
> So, the binary can be excluded and replaced by a flat version of the file.

Hi all,

indeed, this "bed" file is in binary format; I just found its
description on the plink website:

http://zzz.bwh.harvard.edu/plink/binary.shtml

By the way, it is unfortunate that the ".bed" file extension for "binary
PED files" is also used by the – much more frequently encountered –
"Browser Extensible Data" files that describe features in coordinate
windows on reference DNA sequence files.  (I do not know which one came
first…)  But at the URL above there is a description of the magic number
to identify binary PED files.  Would there be anybody interested in
submitting an entry to the file or the sharedmimeinfo databases ?  That
might help us and the FTP team if such files appear again in new
packages.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Kalign3

[Charles Plessy]

Le Thu, Mar 19, 2020 at 12:29:05AM +0100, Steffen Möller a écrit :
> 
> I checked but
> https://salsa.debian.org/med-team?utf8=%E2%9C%93=kalign does not
> show anything newish.

Hi Steffen,

I do not know why this page indicates "3 weeks ago" for kalign...
However, the repository's canonical page surely shows my commits of
yesterday...

https://salsa.debian.org/med-team/kalign

Cheers.

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Kalign3

[Charles Plessy]

Hello everybody,

Kalign3 was published a few days ago in Bioinformatics...

I have pushed the new upstream release and a bunch of changes to Salsa.

If somebody is eager to continue the work while I sleep, feel free :)

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

About the license of Cluster

[Charles Plessy]

Dear Michael,

we, the Debian Med project (CCed on its public mailing list), are
redistributing a large number of bioinformatics software through the
Debian GNU/Linux operating system package archive, and as you probably
know we care deeply about ensuring that what we distribute is Free.

I am contacting you because one of the packages that we distribute,
cluster3, contains code derived from your Cluster software, and
therefore inherited its license.

https://web.archive.org/web/20150109081227/http://rana.lbl.gov/EisenSoftwareSource.htm

Unfortunately, as this license is restricted to the academic/non-profit
community, it does not pass Debian's criteria for freedom.

https://www.debian.org/social_contract#guidelines

Nevertheless, I was delighted to read on your lab's website that you are
“in the process of making sure our legacy software is all available and
has appropriate open source licenses attached”.

http://www.eisenlab.org/software.html

I was wondering if you had an estimate timeline for that, or if in the
meantime you could give us and the authors of cluster3 the permission to
relicense the cluster derived code under a standard Free license ?

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Running Debian Med through Singularity.

[Charles Plessy]

Hi all,

long time no post,

happy new year !

At work, our cluster is running CentOS... but it has Singularity
installed.

I just updated the Debian wiki to add instructions on how to create an
image with Blends metapackages such as med-cloud:

https://wiki.debian.org/singularity#Example_3:_Build_a_larger_image_from_scratch

Next step is perhaps to find an easy way to make stable images with
all the backports of the Debian Med bioinformatics tools installed...

Have a nice day,

Charles

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Debian Med policy deployment via CI jobs.

[Charles Plessy]

Le Tue, Mar 12, 2019 at 12:54:05PM +0100, Andreas Tille a écrit :
> 
> thanks for the interesting hint in any case.  Besides what I wrote
> before: Would you mind adding this as suggestion to our team policy?
> These single mail would probably be forgotten otherwise.

And voilà :)

I did not pay attention that the html file had to be committed, so the
changes are not on line yet.

Would you mind if I would try to make the CI job run rst2html ?

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: qiime(2) had unsatisfiable dependencies in d/control

[Charles Plessy]

Le Tue, Mar 12, 2019 at 08:25:49AM +0100, Andreas Tille a écrit :
> 
> This is another very good example that we are on one hand doing bad in
> caring for our users sufficiently and on the other hand users care to
> less to help us by simply testing what we are providing.

Hi all,

by the way, I have tested continuous integration on Salsa and it looks
like a great tool.  You can see in the perlprimer repository for
instance:

https://salsa.debian.org/med-team/perlprimer/pipelines

The configuration file is plain boilerplate and lies in the debian
directory:

https://salsa.debian.org/med-team/perlprimer/blob/master/debian/gitlab-ci.yml

Documentation provided by the Salsa CI team is very effective:

https://salsa.debian.org/salsa-ci-team/

Have a nice day,

Charles

-- 
Charles Plessy  Tsurumi, Kanagawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Another issue in test suite of new version of bioperl.

[Charles Plessy]

Le Thu, Feb 07, 2019 at 01:30:26PM +0100, Andreas Tille a écrit :
> 
> Can the other explicitly mentioned Uploaders (Charles, Steffen) please
> give a statement whether they plan to contribute to this package and if
> my actions are sensible or not?

Hi Andreas,

it has been a very long time I have not used or uploaded BioPerl so it
is hard for me to comment, but if its refactoring is ongoing, maybe it
is wiser to go for a well-tested version in Buster.  So I think that
your choice makes sense.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Heads-up for melting 4 users! (Was: Replace melting version 4 by melting version 5 or additional package melting5?)

[Charles Plessy]

Le Fri, Oct 26, 2018 at 01:43:59PM +0200, Andreas Tille a écrit :
> 
> if none of the melting4 users will mind that their beloved tool will
> vanish and be replaced by something new but incompatible I'll go on and
> will put meting5 directly into the package melting.  Please do not say
> you was not informed. ;-)

Hi Andreas,

thanks for the heads-up.

It is a long time I did not have to use software such as MELTING, but
after reading the homepage, I confirm that dropping version 4 while
introducing version 5 should be fine.  After all, version 4 also does
not contain all features of version 5.

Have a nice Sunday,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Epcr and primer-blast

[Charles Plessy]

Le Wed, Oct 10, 2018 at 11:45:38AM +0200, Andreas Tille a écrit :
> 
> I'm about to update the epcr package but its homepage[1] says:
> 
>The e-PCR suite of tools has been retired. Please consider using
>PrimerBLAST[2] as an alternative if you are interested in designing
>PCR primers or identifying target sequences for your primers.
> 
>For more information, see "Electronic-PCR (e-PCR) is retiring, use
>Primer-BLAST instead"[3] at the NCBI Insights blog.
> 
> Please excuse my ignorance but I know nothing about primer design at
> all.  I somehow suspect that the command line tool e-PCR should now be
> replaced by a web tool (or am I missing something?  I can not find
> something inside the blast package which looks like a command line
> replacement).  Currently epcr has a popcon which is somehow "medium" in
> our Debian Med package set - so there is some relevant user base that
> is using a discontinued / replaced tool.

Hi Andreas,

a search for "primer-blast" in GitHub's repository for the NCBI C++
toolkit only returns a page containing the URL of the web service,
confirming that there does not seem to be an offline version.

In my experience, people doing large-scale primer design (where
command-line or off-line versions are definitely needed) tend to use
Primer3 directly or (more often?) through a wrapper.  Nevertheless, I
would suggest to keep the ncbi-epcr package as long as it does not have
a RC bug (which I expect to eventually as GCC continues to evolve).

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Digressions (Re: Bio-Linux 9)

[Charles Plessy]

Le Sun, Jun 24, 2018 at 11:26:32AM +0100, Tony Travis a écrit :
> On 24/06/18 01:21, Charles Plessy wrote:
> > 
> > Very much agreed.  I see how bioconda is slowly overtaking us, just by
> > providing an essential feature: the ability to install software via a
> > package manager without having to ask a busy sysadmin to run a sudo apt
> > install command. 
> 
> A very important aspect of "Bioconda" is that it provides a solution to
> 'dependency hell' in which conflicting versions of supporting software
> for a given pipeline can't be installed on the same system. The issue of
> having to ask a system admin to install packages is not the main issue.

Hi Tony,

the problem with system-wide installations is important enough to be
mentionned multiple times in the Bioconda paper just published in
Nature Methods:

"Importantly, it obviates reliance on system-wide administration
privileges by allowing users to generate isolated software
environments in which they can manage software versions by project,
without generating incompatibilities and side-effects"

"The alternatives can be categorized into system-wide (Debian-Med,
Genotoo Science, Biolinux, and Homebrew) and per-user (EasyBuild, GNU
Guix, and BioBuilds) installation mechanisms. The system-wide
approaches lack the ability to put the scientist in control of the
installed software stack, and thus do not meet the requirements for
reproducibility outlined above."

"With its ability to maintain isolated software environments,
integration into major workflow management systems, and lack of
requirement for any administration privileges for use, the Conda
package manager is the ideal tool to ensure sustainable and
reproducible software management."

https://www.nature.com/articles/s41592-018-0046-7

In Debian we do not have native tools for making userland
compartimentalised environments, but still, it would be really nice to
be able to run install commands in the shape of:

apt install --local thispackage/thatversion

and get the version from snapshot.d.o if needed.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Digressions (Re: Bio-Linux 9)

[Charles Plessy]

Le Sat, Jun 23, 2018 at 11:45:04AM +0200, Steffen Möller a écrit :
> 
> And if we just remove that red section? After all, we do have ITPs for
> what red is meant to express. So, I would rather have red as an indication
> of a delta to conda - or to bio-linux to stay in the thread.

Hi Steffen,

I think that it is a good idea.  The red section is somehow a relic from
the past because our growth made it unmaintainable, because the Debian
Med developer community is broader and collectively we have a good
intuition of what should be packaged next, and as you wrote later
in your email, because the added value in Debian is in integration,
which translates to the keyword "workflow" in Debian Med.

> To digress a bit - to care for single packages is a bit from the past. It
> is a requirement, but nothing that a distribution can sell.

Very much agreed.  I see how bioconda is slowly overtaking us, just by
providing an essential feature: the ability to install software via a
package manager without having to ask a busy sysadmin to run a sudo apt
install command.  But most of our packages do not have pre/post-inst/rm
scripts, and their contents could be dropped seamlessly in the
appropriate XDG directories of local users, had we the tool.  And we
have a fairly comprehensive (but not exhaustive) collections of versions
available in snaphsot.debian.org, with an increasing coverage of
autpkgtests that would allow to doublecheck that mixing packages from
previous releases would still work.  Altogether, we have an excellent
base for providing whole workflows to local users, we just need some
people to do it, and I have the impression that it requires to be able
to spend full-time attention to the project at the beginning, which is
hard for everybody who already have routine tasks generated by their
main contribution to Debian Med...  Oh well, I hope I will eventually
manage to join a Debian Med sprint :)

Have a nice Sunday,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: .py endings or no .py endings for scientific packages

[Charles Plessy]

Le Tue, Jun 19, 2018 at 09:47:27PM +0200, Andreas Tille a écrit :
> 
> Sure.  That's why we assembled IMHO good documentation and links that
> really sound constructive and helpful[1].  If you think there is room
> for enhancement please enhance (or send me patches I'd happily include).
> 
> [1] https://wiki.debian.org/UpstreamGuide#Language_extensions_in_scripts 

Hi Andreas,

I would not argue that the reasons listed in the wiki are not good, but
usually we are arriving too late and in my opinion none of these reasons
overcome the trouble caused by being incompatible with the direct users
of the upstream software that we package and modify (not to mention that
the documentation that we ship may become inconsistent if we do not
propagate the modification there...).  Regarding providing symlinks, it
does not prevent our users to pick the upstream-incompatible command
name without being informed in advance.

In the end, I do not understand why so much energy is spent changing the
last letters of a command, while implementation names seems to be
accepted at the beginning at the name.  Why "perlfoo" but not "foo.pl" ?

Altogether, the upstream guide is good, dropping a note in the upstream
mailbox of issue tracker is fine, but for the sake of ourselves and our
users, I think that there is no need to change the command names when it
is too late.

So, do we agree that opotional Lintian overrides are a good compromise ?

Have a nice day,

-- 
Charles Plessy
Greeting you from Okinawa

Re: .py endings or no .py endings for scientific packages

[Charles Plessy]

Le Sat, Jun 16, 2018 at 08:14:36PM +0200, Steffen Möller a écrit :
> 
> In a recent email exchange with Chris I had explained the situation
> with downstream packages depending on those .py files and he just
> suggested to properly override the lintian warning with an explanation.
> I found that a very reasonable thing to do.

Hi Steffen,

indeed, it is a Policy "should", meaning that one should only derogate
with a good reason, and I think that our reason is good.  Lintian
overrides will be a good way to communicate and keep track of our
exceptions.

> How about a paragraph in the Debian Med policy? Maybe like
> "Many packages created for scientific purposes have executables with
> language-characteristic suffices like .pl or .py. This is not appropriate
> for public interfaces of a software that should be implementation-agnostic.
> It is a Debian Policy requirement to correct this for packages uploaded
> to the main distribution. Such distribution-specific changes however
> are discouraging the exchange of protocols between scientists. The
> package maintainer is encouraged to work with upstream to correct
> the naming of these files, but may decide to locally only override
> the lintian warning for the time upstream needs to distribute a corrected
> version of their software."

Good idea.  And the Lintian overrides can link to the Debian Med policy.

Regarding the text above, I would go even further and not suggest to
contact upstream with a rename requests, unless the script is a "public
interface", which is almost never the case in our packages.

Have a nice Sunday,

-- 
Charles

Re: .py endings or no .py endings for scientific packages

[Charles Plessy]

Le Fri, Jun 15, 2018 at 03:52:08PM +0100, Tony Travis a écrit :
> 
> I use Debian-Med packages every day for my scientific work and I really
> appreciate the hard work that the Debian-Med team have done to make this
> software available via the Debian Sid repositories that Ubuntu is based
> on, but I dislike the dogma about issues like removing .py suffixes and
> the 'technical committee' dictating to me or you how we should work...

Hi Tony,

In retrospect, my wording was quite unfortunate and unfair to the
technical committee, which has evolved a lot in the recent years.  I am
sorry for this.

Unless there are strong objections, I propose that we (the Debian Med
project) collectively ask the Policy maintainers to at least soften the
recommendation to rename upstream scripts, and to ask to the technical
committee to resolve the dispute if the discussion becomes unproductive.

Actually, this has been discussed some years ago already, so we do not
need to over-redo the discussion again.  One of the reasons why I did
not go for the TC at that time is that I had the impression that too
many of its members would vote against us.  However, most seats have
been rotated now...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753

On our side, the main arguments for not renaming the scripts is that it
makes us incompatible with upstream.  Am I missing any other major point?

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: .py endings or no .py endings for scientific packages

[Charles Plessy]

Le Fri, Jun 15, 2018 at 01:48:17PM +0200, Steffen Möller a écrit :
> 
> I just updated cnvkit locally and found Michael's patch "Remove .py
> extensions as per Debian policy". I personally came to the conclusion
> that differences to upstream in the naming of binaries is detrimental
> for the acceptance of our distribution in the scientific community.
> Just, nobody wants to risk to have their larger scripts/workflows fail
> at some point because Debian does its own thing.
> 
> For cnvkit it seems particular unfortunate since conda already
> distributes it. And they with some good confidence do not care about .py
> suffices. So incompatibilities with the community at larger would be
> guaranteed. If we truly care about the removal of .py suffices then we
> should attempt to convince upstream about it.

Hi Steffen and everybody,

I think that deviating from upstream file names is a disservice to our
users.  In my experience, people who push the hardest for the renaming
are people who have no stakes in the package itself.  I failed to get
the Policy changed on that topic, but my personal opinion would be to
disregard it until the technical committee would armtwist us to hurt our
users (or open the way to a Policy change).

The disservice is not hypothethical.  I advertised a Debian package to a
colleague, and he came back to me saying that the scripts made by
another colleague did not work... Indeed the other colleague was not
using Debian, and therefore was compatible with Upstream and the rest of
the world...

Have a nice week-end,

-- 
Charles

Re: htslib: version 1.8 drops symbol cram_nop_decode_reset without bumping soversion

[Charles Plessy]

Le Sat, Apr 28, 2018 at 03:48:54PM +0200, Mattia Rizzolo a écrit :
> On Fri, Apr 27, 2018 at 11:53:36PM +0200, Andreas Tille wrote:
> 
> > I think we both agree that the discussion of upstream is technically not
> > the best.
> 
> Feels to me they just don't perceive the need for proper symbol
> management, which is not particularly surprising.

Well, on my side I am surprised since the htslib authors clearly aim
at providing their library to a broad range of developers of
bioinformatics tools.  I think that if somebody would have time to
prepare a patch, it would have good chances to be accepted.

In the meantime, I think that updating the .symbols file without
changing the soname is the solution with the best tradeoff between
risk, extra work, and deviaiton from upstream.

Have a nice week-end,

-- 
Charles

Re: r-pkg-team page on wiki.d.o.

[Charles Plessy]

Le Fri, Jan 12, 2018 at 07:17:32PM +0300, Boris Pek a écrit :
> 
> Sorry, but it looks ugly:
> https://salsa.debian.org/explore/groups?utf8=%E2%9C%93=Debian+R+Packages+Maintainers
> 
> Please add the link in the end of description.

Amended, thanks.  I also moved the group ID from the description the
wiki page.

Have a nice week-end,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: r-pkg-team page on wiki.d.o.

[Charles Plessy]

Le Fri, Jan 12, 2018 at 09:23:46AM +0100, Dylan Aïssi a écrit :
> >
> > https://wiki.debian.org/Teams/r-pkg-team
> 
> It could be useful to add this link in the description of the team in
> the salsa page.

Done, thanks for the suggestion !

-- 
Charles

Re: A common group on salsa.debian.org for R packages ?

[Charles Plessy]

Le Thu, Jan 11, 2018 at 12:34:05PM +0300, Boris Pek a écrit :
> >
> > Thus, people would only need to ask for membership if they want to
> > create a new project (needs Master level), or if they have a guest
> > account and are not member of the Science or Med team (that would be
> > Developer level).
> 
> Sorry for a late reply to this thread. But I am wondering: why have you
> decided to make a separate Salsa group instead of making of special
> subgroup in Debian Science Team group?

Hi Boris,

at that time I did not know about subgroups.

In any case, I think that it should not make a big differnece: since we
want to not only share the repositories with the whole science-team
group, but also with the Debian and the future Debian Med groups, we
need anyway to manage the group sharing of the repositories.

(In the long term we need to write a command that spots which
repositories are not appropriately shared, and corrects that).

Following the discussions on flat structures and stable URLs, I also
started to wonder about just putting the repositories in the Debian
group directly.  This would not make a big difference, except that the
risk of accident of a) our API calls to touch the wrong repository, and
b) other DD's API calls to mess accidently with our repositories would
be slightly higher.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

r-pkg-team page on wiki.d.o.

[Charles Plessy]

Hello everybody,

I just drafted a r-pkg-team page on wiki.debian.org:

https://wiki.debian.org/Teams/r-pkg-team

Please feel free, to correct, expand, ...

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: A common group on salsa.debian.org for R packages ?

[Charles Plessy]

Le Tue, Jan 09, 2018 at 06:31:45AM +0900, Charles Plessy a écrit :
> Le Mon, Jan 08, 2018 at 03:19:27PM +0100, Andreas Tille a écrit :
> > 
> > Sleep well.  Would you consider moving also the R packages of Debian Med
> > project (remaining on Alioth currently) as well in the next couple of
> > days?
> 
> Just started !

Should be done soon (the group sharing is still running - slowly).

Here is what I have done.

# Block update of the old repositories (on Alioth in /git/debian-med)
for pack in $(ls -d r-*)
do
cat << __HOOK__ > $pack/hooks/pre-receive
#!/bin/sh

cat <https://salsa.debian.org/r-pkg-team/$pack

EOF

exit 1
__HOOK__
chmod 775 $pack/hooks/pre-receive
done

# Import the debian-med repos (see previous email).
for pack in $(cat /home/charles/rpackmed) ; do ./import.sh 
https://anonscm.debian.org/git/debian-med/$pack r-pkg-team ;done

# Set commit emails
for pack in $(cat /home/charles/rpackmed) ; do ./emails_on_push.sh 
${pack%%.git} ;done

# Give Developer access to all members of the Debian and science-team
# groups
for gid in 2 2136 ; do for pack in $(cat /home/charles/rpackmed) ; do curl -X 
POST --header "Private-Token: $(cat ~/gitlabtoken.txt)" 
"https://salsa.debian.org/api/v4/projects/r-pkg-team%2F${pack%%.git}/share?group_id=$gid_access=30;
 ; done ; done

# Notify the redirector admins
for pack in $(cat /home/charles/rpackmed) ; do printf "debian-med/%s%71.71s\n" 
${pack%%.git} r-pkg-team/${pack%%.git} >> r-pkg-team.conf ; done
# See https://salsa.debian.org/salsa/AliothRewriter/merge_requests/43

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: A common group on salsa.debian.org for R packages ?

[Charles Plessy]

Le Mon, Jan 08, 2018 at 03:19:27PM +0100, Andreas Tille a écrit :
> 
> Sleep well.  Would you consider moving also the R packages of Debian Med
> project (remaining on Alioth currently) as well in the next couple of
> days?

Just started !

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: A common group on salsa.debian.org for R packages ?

[Charles Plessy]

> On Sun, Jan 07, 2018 at 09:50:23PM +0900, Charles Plessy wrote:
> 
> > Next, I would like to transfer the R packages that are in the
> > `science-team`.  But at the moment I do not have enough privileges.
> > Can someboody boost my status ?  It can be just temporary of course.

Le Sun, Jan 07, 2018 at 02:35:37PM +0100, Anton Gladky a écrit :
> 
> I think you have now enough rights to move the projects.

Le Sun, Jan 07, 2018 at 05:26:34PM +0100, Sébastien Villemot a écrit :
> 
> Once you have done that, please do not forget to update the alioth rewrite map
> with the new location for R packages:
> 
>  
> https://salsa.debian.org/salsa/AliothRewriter/blob/master/definitions/debian-science.conf

Thanks, I think that I am done now.  After deriving a list of packages
from the current ones listed in the Alioth redirector, I have:

 - Imported the projects from the science-team group, using Mehdi's
   helper scripts.

for pack in $(cat /home/charles/rpacks) ; do ./import.sh 
https://salsa.debian.org/science-team/$pack r-pkg-team ;done

 - Deleted the originals.

for pack in $(cat /home/charles/rpacks) ; do curl -X DELETE --header 
"Private-Token: $(cat ~/gitlabtoken.txt)" 
https://salsa.debian.org/api/v4/projects/science-team%2F$pack ;done

  - Notified the redirector admins, who merged the pull request within 2
minutes

https://salsa.debian.org/salsa/AliothRewriter/merge_requests/36

 - Set commit emails

for pack in $(cat /home/charles/rpacks) ; do ./emails_on_push.sh $pack ;done

 - Given Developer access to all members of the Debian and science-team groups
   (technically, this is still running).

for gid in 2 2136 ; do for pack in $(cat /home/charles/rpacks) ; do curl -X 
POST --header "Private-Token: $(cat ~/gitlabtoken.txt)" 
"https://salsa.debian.org/api/v4/projects/r-pkg-team%2F$pack/share?group_id=$gid_access=30;
 ; done ; done

I have also renamed the r-base project "r-base-backports" and set its
default branch to debian/jessie-backports, and deleted the
r-base.deletemeIn2017 repository.

And now, I am going to bed :)

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: A common group on salsa.debian.org for R packages ?

[Charles Plessy]

> On Sun, Jan 07, 2018 at 09:04:06AM +0900, Charles Plessy wrote:
> > 
> > I will create a team on GitLab.  How about "r-packages-team" ?

Le Sun, Jan 07, 2018 at 07:52:14AM +0100, Andreas Tille a écrit :
> 
> I consider r-pkg-team a more typical name.

Thanks for the suggestion.  I have just created the `r-pkg-team` group
("Debian R Packages Maintainers") on Salsa.

https://salsa.debian.org/groups/r-pkg-team/

For each package in the `r-pkg-team`, I propose to give Developer access
to all the members of the groups Debian, science-team and the future
Debian med team (no name chosen yet).

It can be done programatically as follows.

curl -X POST --header "Private-Token: $(cat gitlabtoken.txt)" 
'https://salsa.debian.org/api/v4/projects/$project_ID/share?group_id=$group_id_access=$access_level'

(See https://docs.gitlab.com/ce/api/projects.html#share-project-with-group
 and https://salsa.debian.org/help/user/permissions )

It is not possible to make a group member of a group.

Thus, people would only need to ask for membership if they want to
create a new project (needs Master level), or if they have a guest
account and are not member of the Science or Med team (that would be
Developer level).

Next, I would like to transfer the R packages that are in the
`science-team`.  But at the moment I do not have enough privileges.
Can someboody boost my status ?  It can be just temporary of course.

Cheers,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: A common group on salsa.debian.org for R packages ?

[Charles Plessy]

> On Thu, Jan 04, 2018 at 11:14:14PM +0900, Charles Plessy wrote:
> > with the mass migration to GitLab on salsa.debian.org, I wonder if it
> > would be a good opportunity to host under the same umbrella all the
> > r-cran/bioc/other source packages that are maintained in a Git
> > repository.  In GitLab, it is possible to give access to a repository to
> > all the members of a group, therefore a "r-pkg-team" group could host
> > the repositories, which would be shared with the "Debian",
> > "science-team" and "med-team" groups.
> > 
> > Hopefully it would make them more visible and might help to attract
> > contributions for package updates.  What do you think about this ?

Le Thu, Jan 04, 2018 at 03:20:32PM +0100, Andreas Tille a écrit :
> 
> Very sensible and the idea was previously discussed in IRC.

Le Thu, Jan 04, 2018 at 04:48:04PM +0100, Sébastien Villemot a écrit :
> 
> I fully support the idea (but I don't expect to have time to work on it before
> alioth is shutdown).

Thanks for your support !

I will create a team on GitLab.  How about "r-packages-team" ?
Hopefully, the use of plural clarifies that the team is not about
the r-base package.  Also, each team has a description and I will
mention there that r-base is out of scope.  (Although there may
eventually be a r-base-backports repository there).

Have a nice Sunday,

-- 
Charles

A common group on salsa.debian.org for R packages ?

[Charles Plessy]

Hello everybody,

with the mass migration to GitLab on salsa.debian.org, I wonder if it
would be a good opportunity to host under the same umbrella all the
r-cran/bioc/other source packages that are maintained in a Git
repository.  In GitLab, it is possible to give access to a repository to
all the members of a group, therefore a "r-pkg-team" group could host
the repositories, which would be shared with the "Debian",
"science-team" and "med-team" groups.

Hopefully it would make them more visible and might help to attract
contributions for package updates.  What do you think about this ?

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Charles Plessy]

Hi Diane and everybody,

Le Tue, Nov 07, 2017 at 05:09:34PM -0800, Diane Trout a écrit :
> 
> I do think we should bring back the symbols file

I think so too.

Symbols file are strange to work with because their update usually goes
through a build failure that outputs a patch, which is not very
intuitive.  And then the patched symbols file has to be edited to remove
the Debian minor version, otherwise it complicates backports etc.
Perhaps it can be simplified, better explained and streamlined.  In any
case, I think that for the htslib it is worth the effort.

> I was wondering if we should split the cram headers into a
> libhts-private-dev so we can at least track what is depending on the
> non-public api.

An ideal solution, and I understand that it may not be easy, would be to
make the upstream users of htslib talk with the htslib developers, so
that they can implement what they want to without needing to access
private functions.  I think that it would fit the aims of both sides.

> I did realize that my thought about updating the SOVERSION might be
> wrong because I was just looking in the source tree for the removed
> functions but I should have been checking the public header files.

Indeed, packages using private functions need to have a tight dependency
on the htslib (unless we are very confident that there are regression
tests that cover this area of the code).  Packages that are more
well-behaved can infer their dependency through the (to be re-added)
symbols file.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Should we package BioConductor TFBSTools? [Was [libtfbs-perl] 04/08: Add upstream's notice of deprecation to the package's description.]

[Charles Plessy]

Le Sat, Oct 21, 2017 at 08:08:49AM +0200, Andreas Tille a écrit :
> 
> when reading this commit log:  Should we package Bioconductor TFBSTools?
> 
> This would need at least a hand full of Bioconductor depencencies but
> usually it is quite straightforward and can be easily done via
> 
>  dh-make-R --team med --test run-unit-test
> 
> plus editing d/copyright a bit.

Hi Andreas,

my gut feeling is that we should better concentrate on packages more at
the core of Bioconductor, or gaining tration to move towards the core,
for example MultiAssayExperiment, unless we get a specific request.

Have a nice day,

-- 
Charles

Concerns about OMICTOOLS terms of service..

[Charles Plessy]

Hello everybody,

it is really great to provide references to metadata repositories that
help describing the software that we distribute.

However, I have looked at the terms of use of OMICtools and I have
serious concerns:

https://omictools.com/terms-of-use

On one hand, the data seems to be Free:

> The user is authorized to modify, extract (i.e., permanently or temporarily
> transfer) and reuse all or part of substantial data, in qualitative or
> quantitative terms, that is contained in the database.

But on the other hand, the "database" holidng the data is protected:

> The user shall be informed that the database architecture, its presentation,
> its layout and the method of classification of data listed therein, such as
> described above, are protected by copyright.
> 
> The user has a simple right of use on said database with a view to the
> access, consultation, modification, extraction and reuse of data in the
> conditions provided in this agreement.
> 
> Therefore, the user has no right to reproduce, adapt, translate or represent 
> the database. 
> 
>  The user also undertakes not to:
> 
>  * reproduce the method of classification of the data used by the Licensor, as
> well as the database architecture;
> 
>  * modify or create derivative works of the database without the Licensor’s
>prior written approval;
> 
>  * use the database with the intention of creating a new database reproducing
>the method of classification of the Licensor and/or the database 
> architecture;
> 
>  * manipulate and/or use the database in a way that could directly or
>indirectly compete with the Licensor;

And the database is defined as follows:

> Database: shall mean the database called “OMICTOOLS”, including:
>
>  * the data. This data is made up of software fact sheets in the scientific
>fields. These sheets may be freely modified by the users;
>
>  * the presentation of data and the structure of the database;
> 
>  * the indexing system and the classification of data per phase (by
>technology, by application and by analysis phase);
> 
>  * the related documentation;
> 
>  * the updates;
> 
>  * the new versions.

Thus, I am not sure if the OMICtools IDs are part of the data or the database.
In addition, I am confused, by the fact that a) the data is said to be free,
but b) the database is not and c) the data is said to be part of the database.

Points like the non-competition clause above are very broad and makes me think
that we should avoid OMICtools.  For instance, when we document OMICtoools ids
in parallel with SciCrunch RRIDs, we foster interoperation of course, but
indirectly it helps people to switch from one to the other, which means that it
helps to "compete with the Licensor".

In contrast, for SciCrunch, "All content of the SciCrunch Sites/Services,
except where otherwise noted, is licensed under a Creative Commons Attribution
License."

Sorry to come a bit late to the party with criticisms.  What is your opinion
on the matter ?

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: debian/upstream/metadata: registry item for the Blends' task pages?

[Charles Plessy]

Le Sat, Jul 29, 2017 at 07:45:23PM +0200, Steffen Möller a écrit :
> 
> In a direct email to Charles (asking if "Registry" was OK after becoming
> aware of the reserved keyword "Registration" with a different semantics,
> "Catalog" would be an alternative) I had raised the idea that we could
> possibly use the same concept to assign packages to task pages of any
> blend. This seems likely to simplify the packager's workflow since all
> information about the package is in the same place. 
> 
> The format could be
> 
>     Registry:
>    - Name: Blend
>   Entry: med/ngs

Hi Steffen and everybody,

sorry to be slow to answer !

I think that the format you propose is fine.

I wonder if this metadata would be even more useful via AppStream.  From
https://appstream.debian.org/:

AppStream is a cross-distro XML format to provide metadata for software
components and to assign unique identifiers to software.

Have a nice week-end,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Backports of R packages.

[Charles Plessy]

Le Thu, Jul 06, 2017 at 11:53:13AM -0700, Nadiya Sitdykova a écrit :
> 
> Would you mind to share with me those documents from debci presentation?

Hello Nadiya,

sorry that I forgot !

You can download the document at the following URL.  My notes are from page 6 
onwards.

http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume201706.pdf

I hope it will be useful to you !

-- 
Charles

Is there a reason why multi-threading is disabled in last-align ?

[Charles Plessy]

Hello everybody,

In last-align, the upstream CXXFLAGS are overwriten by our build system, and 
therefore
some flags are re-added in debian/rules:

CXXFLAGS += -Wall -Wextra -Wcast-qual -Wswitch-enum -Wundef -Wcast-align 
-Wno-long-long -ansi -pedantic -std=c++11

Unfortunately, the -DHAS_CXX_THREADS flag is not there, either by omission, or
because it was not there when debian/rules was written, or was there a resason
to ensure that the program is not built with it for Debian ?

If not, I will add it back (probably via CPPFLAGS, since in my understanding
it is a preprocessor flag).

By the way, the -pthread CXXFLAGS is repalced by a -lpthread LDFLAG: are both
equivalent ?

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Backports of R packages.

[Charles Plessy]

Le Fri, Jun 09, 2017 at 09:13:13PM +0200, Andreas Tille a écrit :
> 
> Since Charles have suggested to setup this he probably has some
> pointers where to read for a first introduction.

Actually, I am scheduled to give a presentation on debci at the next
Debian study group in Tôkyô on Sunday 18 (yes, before our release
party!), but I am not ready yet.  So you can probably plan to have
some documents ready around the 19th or so; I hope it fits your
schedule!

Have a nice week-end,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Backports of R packages.

[Charles Plessy]

Hi Andreas,

$ rmadison r-base
r-base | 2.15.1-4   | oldstable| source, all
r-base | 3.1.1-1| stable-kfreebsd  | source, all
r-base | 3.1.1-1+deb8u1 | stable   | source, all
r-base | 3.3.3-1~bpo8+1 | jessie-backports | source, all
r-base | 3.3.3-1| testing  | source, all
r-base | 3.4.0-1| unstable | source, all

At least for bioconductor packages, we have a problem: for some at the
core of the dependency chain, when compiled against R 3.1.1 in Jessie
they will not work with R 3.3.3 backported for Jessie.  I have not
tested whether the converse is true or false.  For CRAN packages the
situation is easier, although a few of them might be affected (most
likely when declaring a S4 method for the c() generic).  I am trying to
set up a debci system at home to mass-run autopkg tests in
jessie-backports, but could not find time to complete this task.

Anyway for the sake of consistency I think that we/you need to make a
general decision (unless it is already covered by the contribution
policy of Debian backports, but I could not find anything): do we
support the use of newer CRAN / BioC packages on Jessie's 3.3.1, or do
we support their use together with the backported R 3.3.3, in which case
we must force them to depend on it.

Have a nice day

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: CI for fastx-toolkit [Outreachy]

[Charles Plessy]

Le Mon, Jun 05, 2017 at 04:35:37PM -0700, Nadiya Sitdykova a écrit :
> 
> When I run
> 
> fastq_quality_filter -i galaxy/test-data/fastq_qual_filter1.fastq -q 33 -p
> 100
> 
> I've got:
> 
> fastq_quality_filter: bug: got empty array at fastq_quality_filter.c:97

Hi Nadiya,

FASTX-toolkit has an undocumented option `-Q` to set the quality offset.  Thus:

$ fastq_quality_filter -Q64 -i galaxy/test-data/fastq_qual_filter1.fastq -q 33 
-p 100
@CSHL_3_FC042AGLLWW:1:2:8:624
ACTGCAATTGGTTAATCTATATAGCGCTGTGG
+CSHL_3_FC042AGLLWW:1:2:8:624


Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: NHSbuntu

[Charles Plessy]

Le Wed, May 10, 2017 at 11:39:22AM +0200, Andreas Tille a écrit :
> 
> I've just read about NHSbuntu[1] and created a forum entry[2] offering
> cooperation.
 
> [1] 
> https://joinup.ec.europa.eu/community/osor/news/volunteers-tailor-ubuntu-linux-uk%E2%80%99s-health-service
> [2] https://www.openhealthhub.org/t/debian-med/945

Thanks Andreas for the news and great to see that a good contact was 
established.

One of the main challenges for the NHSbuntu project will be to make sure that
the NHSbuntus installed today will be upgraded when security support will be
discontinued.  The recent ransomware storm just highlighted how much critical
infrastructures were running a completely outdated version of their operating
system, in this case Windows. 

On our side we provide means to install latest software on old systems, but it
is still challenge to provide old software on recent systems.  It also goes
against a lot of good practices that I do not have to remind here, but for more
and more specialised software, far from the core of the system, it can respond
to a demand and help our users to run in safer environments, by giving them an
upgrade path for the components of their system that are the most likely to be
attacked.  Or maybe I have too much of an old-style point of view and the whole
problem is to be solved with containerisation ?

Well, that was my 2cent thoughts...

Have a nice Sunday,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: New versions of some Bioconductor packages for R 3.4.0

[Charles Plessy]

Le Thu, May 11, 2017 at 03:29:26PM +0200, Graham Inggs a écrit :
> 
> I've like to package some new versions of existing Bioconductor packages for
> compatibility with R 3.4.0.
> I'm looking at, at least:
> 
> r-bioc-annotationhub
> r-bioc-aroma.light
> r-bioc-biocparallel
> r-bioc-s4vectors
> 
> I see these are all maintained by Debian Med Packaging Team in SVN.
> May I go ahead and commit changes to SVN and upload to experimental, or is
> there a particular workflow to follow?

Hi Graham,

as R 3.4.0 is in Unstable and as the current Bioconductor packages in Unstable
are from a release that does not support R 3.4.0, I think that you can upload
to unstable directly.

And yes, please commit directly to SVN.  Use "Team upload" in the changelog if
you are not Uploader and do not want to become so.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Bug#859255: binNMU needed for more R packages.

[Charles Plessy]

Le Sat, Apr 01, 2017 at 03:24:53PM +0900, Charles Plessy a écrit :
> 
> as a follow-up to #858183, I looked at which other R Bioconductor
> packages were broken by R 3.3.3-1, and it seems that the previous round
> of binNMUs did not repair some of them.
 
> nmu r-bioc-rsamtools_1.26.1-2 . ANY . -m "Rebuild for R 3.3.3." 
> nmu r-bioc-shortread_1.32.0-1 . ANY . -m "Rebuild for R 3.3.3." 
> nmu r-bioc-variantannotation_1.20.2-1 . ANY . -m "Rebuild for R 3.3.3." 
> nmu r-bioc-genomicalignments_1.10.0-1 . ANY . -m "Rebuild for R 3.3.3." 

Hi,

this is a friendly ping as I did not get an answer for more than a week.

The reason why I asked for NMUs instead of rebuilding myself is that I
was under the impression that it would be the solution that is the
easiest for you, since there are no source diffs to inspect with the NMUs.
But if you prefer the other way, please let me know !

Have a nice day,

-- 
Charles

Bug#859255: binNMU needed for more R packages.

[Charles Plessy]

Package: release.debian.org
Severity: grave
X-Debbugs-CC: debian-med@lists.debian.org, debian-scie...@lists.debian.org

Hello again,

as a follow-up to #858183, I looked at which other R Bioconductor
packages were broken by R 3.3.3-1, and it seems that the previous round
of binNMUs did not repair some of them.

Can you make the followig binNMUs ?

nmu r-bioc-rsamtools_1.26.1-2 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-shortread_1.32.0-1 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-variantannotation_1.20.2-1 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-genomicalignments_1.10.0-1 . ANY . -m "Rebuild for R 3.3.3." 

Note to debian-science: there are also R CRAN packages that fail with R
3.3.3, (r-cran-lubridate, r-cran-spam), but I am not yet sure if a
binNMU is enough.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

[solved] Re: binNMU needed for r-bioc- packages broken by R 3.3.3.

[Charles Plessy]

Le Wed, Mar 22, 2017 at 07:34:18PM +0100, Ivo De Decker a écrit :
> 
> On Sun, Mar 19, 2017 at 11:24:50PM +0900, Charles Plessy wrote:
> > the update of R to version 3.3.3 unexpectedly breaks some R packages, which
> > need to be reinstalled from source.  In Debian terms, given how we package R
> > packages, this can be solved by a binNMU.
 
> > nmu r-bioc-s4vectors_0.12.1-2 . ANY . -m "Rebuild for R 3.3.3." 
> > nmu r-bioc-iranges_2.8.1-1-m . ANY . "Rebuild for R 3.3.3."
> > nmu r-bioc-genomicranges_1.26.2-1 . ANY -m "Rebuild for R 3.3.3."
> 
> Scheduled.

Thanks a lot !

I confirm that the problem is solved, as the packages now pass their CI
tests again.  And I see that the binNMUs were propagated to testing,
that is perfect !

Have a nice week-end,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: CI for filo (Was: Outreachy 2017 (Round 14))

[Charles Plessy]

Le Wed, Mar 29, 2017 at 08:37:28AM +0200, Andreas Tille a écrit :
> 
> In principle the best idea would be to convince upstream to choose less
> generic names but I think development of filo is stalled.

Hi all,

indeed the development of filo is stalled.

Filo contains three binaires:

/usr/lib/filo/groupBy
/usr/lib/filo/shuffle
/usr/lib/filo/stats

 * groupBy is the main program in the filo package.  It was branched off the
   groupBy command in bedtools, but then the author changed his mind.
   
   https://github.com/arq5x/bedtools2/issues/418#issuecomment-238037963

 * shuffle has for shure many possible alternatives elsewhere.

 * stats was handy, but I think that it is quite superseded by datamash.

Altogether, I am regularly tempted to request the removal of filo.  But if we
do so, we need to update bedtools to make it ship its own groupBy command
again.  This is not difficult, but probably not the best moment either.

Shall we remove filo after the Release ?

Have a nice day,

-- 
Charles

Bug#858183: binNMU needed for r-bioc- packages broken by R 3.3.3.

[Charles Plessy]

Package: release.debian.org
Severity: grave

Hello everybody,

the update of R to version 3.3.3 unexpectedly breaks some R packages, which
need to be reinstalled from source.  In Debian terms, given how we package R
packages, this can be solved by a binNMU.

A quick look at ci.debian.net shows that a large number of Bioconductor
packages (r-bioc-*) started to fail their tests at the end of February
following the upload of r-base version 3.3.2.20170227-1, which was a release
candidate of 3.3.3.  Some of the failures are direct, and some may be a ripple
effect.

On Bioconductor's support forum 
(https://support.bioconductor.org/p/93695/#93719),
it was suggested to reinstall the packages "BiocGenerics", "S4Vectors",
"IRanges", and "GenomicRanges".  I tried this on my computer (using sbuild 
--make-binNMU)
and their regression tests restarted to pass.  These packages are very central 
in
Bioconductor's dependency graph.

If time remains, how about starting with these four and see if the failures in 
the 
the other packages dissapear ?

nmu r-bioc-biocgenerics_0.20.0-1 . all . -m "Rebuild for R 3.3.3."
nmu r-bioc-s4vectors_0.12.1-2 . ANY . -m "Rebuild for R 3.3.3." 
nmu r-bioc-iranges_2.8.1-1-m . ANY . "Rebuild for R 3.3.3."
nmu r-bioc-genomicranges_1.26.2-1 . ANY -m "Rebuild for R 3.3.3."

Otherwise I can prepare a more extensive list of packages to rebuild.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Keysigning in KAUST, Saudi Arabia

[Charles Plessy]

Hi all, 
 
I am in KAUST, Saudi Arabia, until this Thursday, to attend a conference
on epigenetics (https://keep.kaust.edu.sa/KAUST-Epigenetics-2017/).

If somebody happens to be there and interested to meet, sign keys, etc, 
please let me know ! 

Have a nice day 

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Please provide proper screenshot for seaview (and others)

[Charles Plessy]

Le Tue, Jan 24, 2017 at 09:40:14AM +0100, Andreas Tille a écrit :
> 
> But please do not add any advertising into screenshots as it is currently
> the case for seaview:
> 
>https://screenshots.debian.net/package/seaview
> 
> I have requested removal of this screenshot - it would be great to get a
> proper replacement.

Thanks Andreas for spotting this.

I just uploaded one screenshot from Upstream:

http://doua.prabi.fr/binaries/seaview4.png

Have a nice day,

-- 
Charles

Re: cme and stylistic changes in team uploads

[Charles Plessy]

Hi all,

in my case, I use cme like syntax highlighting: to have a consistent
visual pattern so that it is easier to spot that something changed
in a wrong way.

Thus, for a team upload, I think that it is important to not change
the visual pattern to which the lead maintainers are used to.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)

[Charles Plessy]

Hello everybody, and thanks Carnë for the quick answer !

Le Fri, Dec 16, 2016 at 01:06:35PM +0100, Andreas Tille a écrit :
> 
> On Fri, Dec 16, 2016 at 11:38:02AM +, Carnë Draug wrote:
> 
> > For example, there is now
> > bio-biblio, bio-eutilities, and bio-coordinates which were previously part
> > of bioperl itself.  The core bioperl is now the bioperl-live distribution.
> 
> I guess we could document this in README.Debian since I personally do
> not see a reason to rename the Debian package from bioperl to
> bioperl-live.  Do you think keeping the old name would be confusing for
> insiders?

At the moment, the bioperl Debian source package produces two binary packages:
"libbio-perl-perl" provides the libary itself and "bioperl" provides the
command-line utilities.  As long as on CRAN BioPerl is not renamed
bioperl-live, I think that there is no need to rename the packages.  In any
case, I think that it is good to keep a "bioperl" binary package to install the
command-line utilities and pull the BioPerl libraries by dependency.

> > There is at least one very important fix on the new bioperl which fixes
> > the connection to the NCBI servers (although the fix is simple enough
> > that could be backported).
> 
> A backport of this fix would be helpful if we really decide to revert
> the upgrade.

Indeed, if we can just cherry pick patches from GitHub, it would be good to
apply them in Debian.  Can somebody suggest a list of commits ?

> My original proposal:
> 
>1. Revert the version bump of bioperl and upload the old version
>   with an epoch (1:1.6.924-6).
>2. Upload 1.7.1-2 to experimental
>3. Solve all issues with BioPerl 1.7.x after Stretch release.
>4. Backport 1.7.x to Stretch once issues are solved.
> 
> Keeping bioperl 1.7.1 and rather drop other packages:
> 
>1. Keep bioperl 1.7.1
>2. Drop gbrowse and bioperl-run from Stretch
>3. Check all rdepends of bioperl whether they work with 1.7.1:
>4. Package as many as the needed tools as we might be able to.

I think that, so close to the Debian stable release, and since some BioPerl
components have not been released upstream, the original proposal is wiser.
Debian stable releases last multiple years, so even bioperl 1.7.1 will become
old eventually.  Therefore, I recommend to aim at stability; let's use the
stable backports once the 1.7.x ecosystem has taken shape.

It would help a lot if the new BioPerl modules were released on CRAN.  Debian
has an amazingly productive Perl team, equipped with many helper tools to
facilitate packaging, but the main paradigm is to get released sources from
CRAN.  If we need to rely on the head of the master branch of GitHub
repositories, it will be much harder to ensure consistency, because we can not
make a package update for every commit.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Next sprint

[Charles Plessy]

Hi all,

Thanks Michael for the organisation !

I will probably attend a meeting in Saudi Arabia on February 12th to 15th, so
this time I might be around for a Sprint on the days and week-end that follow.
But I am not entirely sure, so anyway please do not try too hard to accomodate
for my limited availablity !

Have a nice day,

-- 
Charles

Hacktoberfest

[Charles Plessy]

Hi all,

a colleague has caught my attention on the Hacktoberfest:

https://hacktoberfest.digitalocean.com/

In Debian-Med, there are a bunch of integration issues (GCC updates,
integration with shared libraries, etc), that are best to be worked out
upstream.  Perhaps this Hacktoberfest is a good opportunity to prod our
Upstreams who are on GitHub and see if "the community" can help out ?

Just my two cents; I am a bit over-busy these weeks to take the lead.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: vcftools

[Charles Plessy]

Le Tue, Aug 23, 2016 at 03:06:49PM +0100, Tony Travis a écrit :
> 
> I need to process .vcf files with thousands of WGS scaffolds in them
> instead of just a few chromosomes. The latest version of "vcftools" can
> do this, but the version of "vcftools" currently in Bio-Linux 8/Ubuntu
> 14.04 LTS is quite old:
 
> I noticed that your Debian-Med version is in Ubuntu Xenial/16.04 LTS:
 
> What would be the correct way to update the version of "vcftools" in
> Bio-Linux 8/Ubuntu 14.04 LTS?

Dear Tony,

I am not very familiar with Ubuntu, but it seems to me that it is possible to
request official backports:

https://wiki.ubuntu.com/UbuntuBackports

>From the Debian side, there is little we can do, but we sometimes prepare
unofficial backports in our team's PPA:

https://launchpad.net/~debian-med/+archive/ubuntu/ppa

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: A common test-data package for genome assemblers

[Charles Plessy]

Le Wed, Jul 13, 2016 at 08:24:23AM -0700, Afif Elghraoui a écrit :
> 
> I've had a couple packages that indicate the availability of data
> outside of the source distribution that can be used to try out the
> software (and make sure that it actually runs). I didn't think it was a
> good idea to bundle the data in with the actual package since it doesn't
> change between releases and would take up too much space on the archive
> if it was bundled with every upstream tarball.
> 
> For example, at <http://canu.readthedocs.io/en/stable/quick-start.html>,
> there are a few reduced datasets that can be used to run assemblies for
> PacBio and Nanopore sequencing data. Those files can also be used for
> tests of the sprai package, and possibly also for other long-read genome
> assemblers. There's also the option of packaging the Assemblathon data
> for this purpose, or using simulators to generate datasets for testing.
> 
> Does anyone have suggestions or thoughts on this?

Hi Afif,

yes, this is an excellent idea.  Discussions about data packages
spark from time to time (see https://wiki.debian.org/DataPackages
for instance), and it would be exciting to see this happening in
one way or the other !

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Heads up: bioperl release candidate

[Charles Plessy]

Le Thu, Jul 07, 2016 at 10:20:18AM -0400, Michael Crusoe a écrit :
> 
> If someone would like to try updating the Debian package with the release
> candidate and testing it that would be useful:
> 
> https://cpan.metacpan.org/authors/id/C/CJ/CJFIELDS/BioPerl-1.007000_003.tar.gz

Hi Michael and everybody,

I tested the packaging of /BioPerl-1.007000_004.tar.gz, and it went fine.  Some
regression tests could not be run as not all the optional modules and software
were installed on my laptop.

Our automated test did not report anything significant.  Here is a copy of the
typos it found.

I: bioperl: spelling-error-in-manpage usr/share/man/man1/bp_biogetseq.1p.gz 
retrives retrieves
I: bioperl: spelling-error-in-manpage 
usr/share/man/man1/bp_extract_feature_seq.1p.gz specifed specified
I: bioperl: spelling-error-in-manpage usr/share/man/man1/bp_hivq.1p.gz retreive 
retrieve
I: bioperl: spelling-error-in-manpage ... use --no-tag-display-limit to see all 
(or pipe to a file/program)
W: bioperl: manpage-has-bad-whatis-entry usr/share/man/man1/bp_netinstall.1p.gz
W: bioperl: manpage-has-bad-whatis-entry usr/share/man/man1/bp_search2gff.1p.gz
W: bioperl: manpage-has-bad-whatis-entry usr/share/man/man1/bp_seqcut.1p.gz
I: libbio-perl-perl: spelling-error-in-manpage 
usr/share/man/man3/Bio::Align::AlignI.3pm.gz wont won't
I: libbio-perl-perl: spelling-error-in-manpage 
usr/share/man/man3/Bio::AnalysisI.3pm.gz refrence reference
I: libbio-perl-perl: spelling-error-in-manpage 
usr/share/man/man3/Bio::AnalysisI.3pm.gz folowing following
I: libbio-perl-perl: spelling-error-in-manpage ... use --no-tag-display-limit 
to see all (or pipe to a file/program)
W: libbio-perl-perl: manpage-has-bad-whatis-entry 
usr/share/man/man3/Bio::Index::Stockholm.3pm.gz
W: libbio-perl-perl: manpage-has-bad-whatis-entry 
usr/share/man/man3/Bio::OntologyIO::Handlers::BaseSAXHandler.3pm.gz
W: libbio-perl-perl: manpage-has-bad-whatis-entry 
usr/share/man/man3/Bio::OntologyIO::obo.3pm.gz
W: libbio-perl-perl: manpage-has-bad-whatis-entry ... use 
--no-tag-display-limit to see all (or pipe to a file/program)
W: libbio-perl-perl: manpage-has-errors-from-man 
usr/share/man/man3/Bio::SeqIO::bsml.3pm.gz 361: warning [p 4, 0.2i]: can't 
break line

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Do you have popularity-contest set to yes?

[Charles Plessy]

Hi Andreas,

on my side I bought a new laptop last year, so for some packages that I
uploaded long time ago and that have not been very active or useful recently, I
probably do not count in popcon anymore.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: http://upstream-metadata.debian.net/

[Charles Plessy]

Le Mon, Jun 27, 2016 at 04:21:23PM +0200, Andreas Tille a écrit :
> On Mon, Jun 27, 2016 at 04:14:55PM +0200, Olivier Sallou wrote:
> > Hi Charles,
> > 
> > http://upstream-metadata.debian.net/ seems unavailable, connections
> > remain waiting.
> 
> Charles, I think you should do
> 
>echo "upstream-metadata   in  a  117.121.245.165" | gpg --clearsign | mail 
> chan...@db.debian.org 
> 
> If I remember correctly it was on the same host as blends.debian.net
> and this was moved by GPLhost.

Hi Olivier and Andreas,

I just updated the IP address, thanks for the hint.  I realised some time ago
that the service was unavailable, but I thought it was caused by the upgrade
to Jessie...

The fact that Olivier is the first to report the problem in public suggests
that not many people have a use of this service.  Earlier this year, I started
a discussion about terminating upstream-metadata.debian.net and there was not
much objections against it.

In 2014, the service was affected by a bug that I could not resolve, and I
could not get any help for it.

https://lists.debian.org/debian-qa/2014/06/msg00022.html

Altogether I am blocked and it is clear that I will not be able to provide
a good quality of service alone.

As a pet project, I tried a couple of times to reimplement the whole system
in Haskell, but I still have to iron out my skills on simple issues such as
the handling of command-line options, etc.

Altogether, while I am satisfied that I could start this project and provide a
prototype, I also realise that the design is very naive, for instance I admit
that I do not know what would happen in case of concurrent access to the
database.

So in my opinion, it can not continue at a one-man project.

Have a nice day

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: Request for discussion: Is our Sprint more of a Mini-DebConf? What to have next?

[Charles Plessy]

Le Fri, Jun 17, 2016 at 11:04:33PM +0200, Steffen Möller a écrit :
> 
> Eh, we have Charles at RIKEN, who is badly overdue to join - here or there.

Hi Steffen and everybody,

it would be great to have a meeting somewhere near Japan's timezone.  Currently
I am still in a state of constant tiredness with all the productivity loss that
it induces (and when I hear my colleagues say that week-end is great to write
papers, I wonder if I should laugh or cry: don't they know that kindergartens
are closed on week-ends ??).  Altogether, fear of jet lag and work backlog made
me avoid the Debian Sprints.  But things are getting better and better.

There are fundraising schemes to organise international workshops in Japan,
this is an option that I have not explored very well at the moment...

Have a nice week-end,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: Fwd: [Debian-med-packaging] Bug#823673: samtools: FTBFS in testing

[Charles Plessy]

forcemerge 822701 -1
thanks

Le Sat, May 07, 2016 at 08:20:03PM +0200, Olivier Sallou a écrit :
> 
> Has samtools been updated accordingly to match  libhts >= 1.3.1 ? I 
> understand that yes from previous emails, but is described bug linked to the 
> otherbug?

Hi Olivier,

sorry, I have been confused and confusing.  Samtools was not yet uploaded, so I
should have marked bug #822701 only pending and not fixed.  Now I have uploaded
version 1.3.1-2, which solves the problem.

Bon dimanche,

-- 
Charles

Re: fails to build against htslib 1.3.1

[Charles Plessy]

Control: forwarded -1 https://github.com/samtools/htslib/issues/374

Le Wed, May 04, 2016 at 09:10:48PM +0900, Charles Plessy a écrit :
> Le Wed, May 04, 2016 at 11:29:27AM +0200, Andreas Tille a écrit :
> > 
> > that developers of quite important libs (important in terms of breaking
> > about 20 packages - probably way more unpackaged software) are not able
> > to craft a reliable interface.  I wonder whether we should try to
> > explain them the trouble they are creating with their release management
> > and whether we should upload any new version to experimental first and
> > test other packages against it.
> 
> let's not discard too quickly the possibility that this was really a bug
> and not a design decision.
> 
> I reported the problem at <https://github.com/samtools/htslib/issues/374>;
> let's see the answer.

Good news, the answer is that the "incompatibility" is only in the test suite
of samtools, which took into account a failure caused by a bug present in
htslib 1.3 and fixed in htslib 1.3.1.

I expect that it applies to bcftools as well.

Have a nice week-end,

-- 
Charles

Re: fails to build against htslib 1.3.1

[Charles Plessy]

Le Wed, May 04, 2016 at 11:29:27AM +0200, Andreas Tille a écrit :
> 
> that developers of quite important libs (important in terms of breaking
> about 20 packages - probably way more unpackaged software) are not able
> to craft a reliable interface.  I wonder whether we should try to
> explain them the trouble they are creating with their release management
> and whether we should upload any new version to experimental first and
> test other packages against it.

Hi Andreas,

let's not discard too quickly the possibility that this was really a bug
and not a design decision.

I reported the problem at ;
let's see the answer.

Cheers,

-- 
Charles

Re: fails to build against htslib 1.3.1

[Charles Plessy]

Le Wed, May 04, 2016 at 11:03:36AM +0200, Olivier Sallou a écrit :
> Seems it should be fixed soon [0]
> 
> Bug is still open, but samtools 1.3.1 should not be impacted anymore.
> htslib 1.3.1 break samtools 1.3, but should be inline with samtools
> 1.3.1 (need to match versions)
> 
> I don't understand however why bug is not fixed or lowered yet.
> 
> [0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701

Hi Olivier and everybody,

sorry, I forgot to close the bug in version 1.3.1-1's changelog.

I will close it now.

Have a nice day,

-- 
Charles

Re: Does bwa really need to be limited to amd64?

[Charles Plessy]

Le Fri, Apr 08, 2016 at 01:04:15AM -0700, Afif Elghraoui a écrit :
> 
> As I've mentioned before, I'm trying to get circlator into testing. I
> requested of the release team to allow it to migrate despite it's being
> uninstallable on i386 [1]. I was then asked if there was any way to fix
> that, so I looked into the problematic dependencies. bwa is set to amd64
> and kfreebsd-amd64 only.
> 
> When I looked through the changelog, this looked like it was done a few
> years ago because of the need for SSE2. In the current debian/rules, I
> see that SSE2 is only added if the architecture matches amd64, but I
> don't see anything about this in the upstream Makefile or READMEs.
> 
> I don't have a chance to test out a build right now, but does anyone see
> a problem with expanding the architecture list?

Hi Afif,

BWA failed to build on i386 at version 0.7.5a-1 with the following error,
despite the -D_NO_SSE2 option:

/usr/lib/gcc/i486-linux-gnu/4.7/include/emmintrin.h:32:3: error: #error 
"SSE2 instruction set not enabled"

https://buildd.debian.org/status/fetch.php?pkg=bwa=i386=0.7.5a-1=1370353173

I expect that if you try to build it on i386, it will fail again.

In any case, for most bioinformatics software that is now developed on amd64, I
would not trust output of the programs built successfully on other
architectures unless there are good regression tests.

So I take the opportunity to say a big thank you to the people working on
regression tests right now :)

Have a nice day,

-- 
Charles

Re: Proposal to start link time optimisation for Debian Med packages

[Charles Plessy]

Le Wed, Mar 30, 2016 at 01:36:58PM +0200, Steffen Möller a écrit :
> 
> I had started this friendly and constructive thread on Debian Devel on
> link time optimisation
> 
> https://lists.debian.org/debian-devel/2016/03/msg00399.html
> 
> and my personal consensus is that we should possibly start with the most
> rewarding scientific packages of ours to see how it goes. What do you
> think?

Hi Steffen and everybody,

here is a quick side comment, sorry for not having the time to participate
to that thread.

Related to optimisation, we systematically override -O3 to -O2.  Probably in
most of the cases the upstream authors never benchmarked the difference anyway,
but in remaining cases, aren't we making the programs in our packages slower
only for the sake of building everything with the same flags and avoiding
compilation errors on architectures where nobody ever reported that these
programs in particular have been used ?

Have a nice day,

-- 
Charles

Re: Associating packages with file types using appstream succeeded

[Charles Plessy]

Le Wed, Feb 10, 2016 at 07:15:02PM +0100, Petter Reinholdtsen a écrit :
> 
> The goal was to use appstream to announce file format support in a
> non-GUI package (aka one without a .desktop file), and we used the khmer
> package as an example.  It is now listed as a package supporting the
> application/vnd.oxli.countgraph MIME type:
> 
> % appstreamcli what-provides mimetype application/vnd.oxli.countgraph
> Identifier: oxli [generic]
> Name: khmer
> Summary: in-memory DNA sequence kmer counting, filtering & graph traversal
> Package: khmer
> 
> %
> 
> To do this, we added debian/khmer.metainfo.xml with the following
> content and installed it in /usr/share/appdata/:
> 
> 
> 
>   oxli
>   MIT
>   khmer
>   in-memory DNA sequence kmer counting, filtering  graph 
> traversal
>   
> 
>   khmer is a library and suite of command line tools for working
>   with DNA sequence. It is primarily aimed at short-read
>   sequencing data such as that produced by the Illumina
>   platform. khmer takes a k-mer-centric approach to sequence
>   analysis, hence the name.
> 
>   
>   
> application/vnd.oxli.countgraph
>   
> 

Hi Petter,

this is a great result, especially now that it is easy for any project to submit
new media types to the IANA.

I added the following information to the MimeTypesSupport page in the Debian 
wiki:

Packages can declare support for media types using the AppStream system, by
placing metainfo XML files in /usr/share/appdata/, with names such as
.metainfo.xml. Commands like appstreamcli will then be able to 
report
which package supports which media types, and package managers will be able 
to
suggest the package for installation. 

https://wiki.debian.org/MimeTypesSupport#For_package_installation

Corrections or improvements are welcome !

Have a nice day,

-- 
Charles

Re: Fwd: orthanc REMOVED from testing

[Charles Plessy]

Le Fri, Dec 25, 2015 at 08:18:40PM +0100, Julien Lamy a écrit :
> 
> You're right, I missed another piece of information on the migration
> page: the last line mentioning libdcmtk4-dev [1]. Looking at the binary
> packages of dcmtk in sid [2], it seems that old stuff like dcmtk-www or
> libdcmtk4-dev is still there, which is referenced in the "cruft report"
> of ftp-master [3]. Can we ask ftp-masters for the removal of the old
> dcmtk stuff, or is there some action to take on the mentioned dependent
> packages first?
> 
> [1] https://release.debian.org/migration/testing.pl?package=dcmtk
> [2] https://packages.debian.org/source/sid/dcmtk
> [3] https://ftp-master.debian.org/cruft-report-daily.txt

Bonjour Julien,

in that case, we just have to wait:

"In the cases handled by [cruft-report], there is no need to request that your
package be removed, they are handled in batches from times to times (apart from
the "Architecture Not Allowed In Source" case, which still need a removal
request). "

https://wiki.debian.org/ftpmaster_Removals

Joyeuses, fêtes,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: Fwd: orthanc REMOVED from testing

[Charles Plessy]

Le Thu, Dec 24, 2015 at 05:45:21PM +0100, Sébastien Jodogne a écrit :
> 
> FYI, orthanc has just been removed from testing.
> 
> But, the bug that justifies its removal from testing is fixed since November 
> 10th, 2015:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804571
> 
> Is there something that remains to be done to migrate new versions of orthanc 
> to testing?

Joyeux Noël Sébastien and everybody !

orthanc depends on libdcmtk5, which is only in Unstable for the moment.  dcmtk
is marked as valid candidate for migration, but has already 12 days, and I do
not understand why migration has not happened yet...

Cheers,

-- 
Charles

Re: header package for samtools

[Charles Plessy]

Le Wed, Dec 23, 2015 at 07:00:25PM -0800, Afif Elghraoui a écrit :
> 
> Specifically, I was looking to package lofreq [1], but it requires the
> samtools headers and its static library libbam.a, expecting users to
> have a compiled copy of the source distribution for samtools.

Hi Afif,

for the works that expect libbam.a and legacy samtools headers, we still
distribute the libbam-dev package, from the samtools-legacy package.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: header package for samtools

[Charles Plessy]

Le Wed, Dec 23, 2015 at 08:01:07PM -0800, Afif Elghraoui a écrit :
> 
> lofreq requires at least samtools 1.1. I did try using the libbam-dev
> package for this, but it wasn't compatible.
> 
> In any case, I think there is a similar situation with pysam and the
> samtools R-bindings, but that they just distribute code copies.

Hi Afif,

how about asking to the lofreq authors if they can use the htslib directly
instead of libbam ?

If not, it should be easy to add a samtools-dev package as you proposed.

Cheers,

-- 
Charles

Re: Why is blasr's testing migration still stalled? RC bugs are all fixed

[Charles Plessy]

Le Sun, Dec 20, 2015 at 07:26:44PM -0800, Afif Elghraoui a écrit :
> 
> blasr had two RC bugs, both of which are fixed, but the testing
> migration is held up and it looks like the reason is "updating blasr
> introduces new bugs" [1]. Those two bugs are fixed and tagged as such
> with the version currently in unstable. I don't really know any other
> way to indicate that the package in unstable doesn't have RC bugs. Does
> anyone know what the problem could be?

Hi Afif,

maybe the testing migration script has not yet revisited blasr's case yet ?
>From the moment blasr is 5 days old, there may be up to 24 hours before
the migration scripts run again.  Thus, I think that it is not worrysome
that on the 6th day, blasr has not yet migrated.

Hoping to not being proven wrong tomorrow,

-- 
Charles

Where to send ephemerous messages related to Debian Med ?

[Charles Plessy]

Hi all,

I tend to refrain to post messages like "I am on it", etc, when preparing an
upload, but then I tend to be scooped by Andreas, who is so efficient those
days :)  I wonder if there would be a good place for such messages on different
communication media.

 - IRC ?  On my side, I am not a big fan of IRC, since to use it I need to 
dedicate
   most of my screen surface to it (I am shortsighted) and most of my time to it
   (relevant messages tend to be buried by lots of lines about who entered and
   who left).  But maybe I am just using an inefficient client (xchat).  Anyway,
   the big drawback of IRC is that, unless one spends some time setting up a 
bot,
   the messages are only visible to those who are connected.

 - Identica ?  I see that some Debian developers are using it.  Is it possible
   to create a Debian Med group that one can follow without being logged in ?
   That could be neat.

 - Other suggestions ?

Cheers,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Sponsorship request: snap-aligner

[Charles Plessy]

Le Wed, Sep 30, 2015 at 04:06:31AM +, Michael Crusoe a écrit :
> transrate-tools is also ready
> 
> gbp clone git://anonscm.debian.org/debian-med/transrate-tools.git

Hi Michael,

I think that your "install" file will not work outside the amd64 architecture:

$ cat transrate-tools.install 
./obj-x86_64-linux-gnu/src/bam-read /usr/bin/

Maybe you can find a solution similar to what is done in multi-arch packages,
or perhaps a wildcard would be simply enough.

   https://wiki.debian.org/Multiarch/Implementation#Dynamic_debian.2F.2A_files

Cheers,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Sponsorship request: snap-aligner

[Charles Plessy]

Le Wed, Sep 30, 2015 at 03:42:27AM +, Michael Crusoe a écrit :
> gbp clone git://anonscm.debian.org/debian-med/snap-aligner.git

Hi Michael,

I found non-Free statements in some files under import/pdclibhdfs/src/,
for example:

* TITLE: TstReadHdfs.tdprj.xml   *
**
* Copyright 2009-2010 by Teradata Corporation.   *
**
* ALL RIGHTS RESERVED.   *
**
* TERADATA CONFIDENTIAL AND TRADE SECRET

That would make the files unredistributable, but I guess it is just a honest
mistake ?  Can you investigate this further ?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: RFS: daligner (NEW)

[Charles Plessy]

Le Sun, Aug 30, 2015 at 07:43:33AM +0200, Andreas Tille a écrit :
 On Sat, Aug 29, 2015 at 01:29:10PM -0700, Afif Elghraoui wrote:
  Hi, all,
  I've finished preparing a new package, daligner. Could someone please
  upload to unstable?
 
 Done.  Thanks

Hi Andreas,

you'be been faster than me of a few minutes :)

Afif, I see that you forwarded the manpages upstream; if they are accepted to
not hesitate to also forward the patches on the Makefiles.

Have a nice week-end,

-- 
Charles

Re: How to edit the tasks list

[Charles Plessy]

Le Sat, Aug 22, 2015 at 04:17:51PM +, Michael Crusoe a écrit :
 On Thu, Aug 20, 2015 at 1:18 PM Andreas Tille andr...@an3as.eu wrote:
 
 $ debcheckout -a debian-med
 declared svn repository at svn+ssh://
 svn.debian.org/svn/blends/projects/med/trunk/debian-med/
 svn co svn+ssh://svn.debian.org/svn/blends/projects/med/trunk/debian-med/
 debian-med ...
 svn: E17: URL 'svn+ssh://
 svn.debian.org/svn/blends/projects/med/trunk/debian-med' doesn't exist
 checkout failed (the command above returned a non-zero exit code)

Hi Michael,

the repository was converted to Git, but this has not yet been
reflected to debcheckout: the VCS fields are corrected in Git, but
packages were not uploaded yet.

http://anonscm.debian.org/cgit/blends/projects/med.git/

In the meantime, you can clone the repositories without debcheckout.

git+ssh://git.debian.org/git/blends/projects/med.git

Have a nice Sunday,

-- 
Charles

Re: samtools 1.2 package layout change

[Charles Plessy]

Le Thu, Aug 13, 2015 at 03:03:34PM +0100, Tim Booth a écrit :
 
 I was looking to see if it was worth pulling the samtools 1.2 package
 into Bio-Linux (Ubuntu LTS Backports) and I can see that the package for
 1.2 has all the utility scripts going into /usr/bin where before they
 were in /usr/{lib,share}/samtools.  A slew of Lintian warnings results.
 
 I wondered if this is a deliberate change or just an artefact of the new
 build system?  I'd be happy to commit a fix that either restores the old
 layout or else adds Lintian overrides.  What do you think?

Hi Tim,

in the current 1.2 package, the scripts are installed in /usr/bin by the
upstream build system, while before version 1.0 we installed them by hand in
/usr/share, since they were not installed by the upstream build system.

For the sake of compatibility with other distributions and platforms (that is,
the rest of the World), I think that we should not remove the file extensions.
Feel free to add a Lintian overrides.  On my side, I am not doing so because
overrides should be for false positives, while here it is the Policy that is
plain wrong.

Regarding missing manpages, before writing them I would recommend to contact
upstream to make sure they would adopt them and maintain them.  Otherwise, they
will bitrot and we will send wrong information to our users, again in a only
Debian does it wrong way.  For these Lintian warnings, I also do not write
overrides because they are true positives.  But feel free to override them if
they annoy you.

For spelling-error-in-manpage allows to allows one to, once one upstream
developer who was native speaker disagreed; since then I ignore this spelling
error.

I think that spelling-error-in-binary usr/bin/samtools compres compress is a
false positive; sorry for not overriding it earlier.  compres only appears
in the output of strings /usr/bin/samtools in a way that does not seem
to be related to user output, and not in the source code.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan