Re: Bug#1040500: routine-update: Don't create d/salsa-ci.yml file

[Dylan Aïssi]

Hi Andreas,

Le ven. 7 juil. 2023 à 11:24, Andreas Tille  a écrit :
>
> Thanks for your opinion about this.  What I mean with de facto standard:  We
> have about 2000 repositories configured to check debian/salsa-ci.yml.  I have
> not yet found a way to set the according field via gitlab API to something
> else.  If this is scriptable I'd happily remove debian/salsa-ci.yml.  For the
> moment I state two votes against salsa-ci.yml. ;-)
>

We have a tool in Debian for that gitlab-rulez [1].
I haven't tried it on salsa yet, but it should work as we use it with our
gitlab instance.

Best regards,
Dylan

[1] https://tracker.debian.org/pkg/gitlab-rulez

Re: Bioconductor API Bump to 3.13

[Dylan Aïssi]

Hi Nilesh,

Le mar. 31 août 2021 à 09:07, Nilesh Patra  a écrit :
>
> I just happened to see this commit[1]. Has the transition begun?
> If so, can I do anything to help?
>

Yep :-) See https://bugs.debian.org/991919#44

I don't have too much free time. So, Feel free to upload all packages
you can with routine-update.
You can follow the order of this list
> https://release.debian.org/transitions/html/r-api-bioc-3.13.html

But, remember some bioc packages are not present in this list. In this
case, this diagram can help you
> https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/BioC_dependency-tree.ditaa

Best,
Dylan

Re: Bug#991919: Bioconductor API Bump to 3.13

[Dylan Aïssi]

Hi,

Le jeu. 26 août 2021 à 09:49, Paul Gevers  a écrit :
>
> If this question is to the release team, than the following question we
> asked earlier requires an answer:
> > What's the status wrt. to the reverse dependencies. Do those that are
> > binNMU-able build against the new version?
>

No, all these reverse dependencies need a manual upgrade with the new
upstream releases, they are not binNMU-able.
The Debian R Packages team will upgrade to the new upstream releases
all of the reverse dependencies.

Best,
Dylan

Re: Bioconductor API Bump to 3.13

[Dylan Aïssi]

Hi Steffen, hi Andreas,

Le jeu. 5 août 2021 à 06:18, Andreas Tille  a écrit :
> Sure.  We need a transition.  Dylan (in CC) was kind enough to trigger
> this in the past and we should do so right after the release (I'm
> announcing here pseudo-VAC due to personal reasons on one hand as well
> as DebConf business - so please do not trust too much on my contribution
> on this transition.
>
> We do not habe better automatism than routne-update and the transition
> coordination webpage listing a sensible sequence to do this, thought.

The transition tracker is on at
https://release.debian.org/transitions/html/r-api-bioc-3.13.html

We are now waiting for the green-light from the release team (at
https://bugs.debian.org/991919) to start the transition of
bioconductor packages.

Best,
Dylan

Bug#991919: transition: r-api-bioc-3.13

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debia...@lists.debian.org, debian-med@lists.debian.org


Hi,
Bioconductor 3.13 was released in May [1]. All r-bioc-* packages need
a manual upgrade (after the release of bullseye).

[1] https://bioconductor.org/news/bioc_3_13_release/

Please set up a tracker manually, since this is a transition of a
virtual package name.

Ben file:
-
title = "r-api-bioc-3.13";
is_affected = .depends ~ /r-api-bioc/;
is_good = .depends ~ "r-api-bioc-3.13";
is_bad = .depends ~ "r-api-bioc-3.12";
-

Best,
Dylan

Re: Help for optimir autopkgtest needed

[Dylan Aïssi]

Hi Andreas,

My laptop has decided to die last week, so I can do only minor edits
through the salsa web interface.

Le ven. 4 déc. 2020 à 23:58, Andreas Tille  a écrit :
>
> I updated the packaging of optimir in Git[1] but its autopkgtest
> fails with
>
>  > Starting Library preparation...
> Error with system call: Bowtie2 index creation failed: command line = 
> bowtie2-build -f 
> /tmp/autopkgtest.FxuHx2/autopkgtest_tmp/OptimiR_Results_Dir/OptimiR_lib/fasta/optimiR_library.fa
>  
> /tmp/autopkgtest.FxuHx2/autopkgtest_tmp/OptimiR_Results_Dir/OptimiR_lib/bowtie2_index/optimiR_alignment_library
>  -q

The autopkgtest seems to be successful with salsa-ci:
https://salsa.debian.org/med-team/optimir/-/pipelines/203997

Is it possible that the error is transitional?

Best,
Dylan

Re: shapeit4 and AVX2

[Dylan Aïssi]

Dear Giulio,

I am CCing the public Debian Med mailing list and Michael Crusoe who
can help to improve the Debian package in order to have an AVX2 binary
optimized.

Le jeu. 5 nov. 2020 à 15:20, Giulio Genovese
 a écrit :
>
> I have noticed you are the author of the following patch for the shapeit4 
> debian package:
> https://salsa.debian.org/med-team/shapeit4/-/blob/master/debian/patches/use_shared_libs.patch
>
> I noticed that this causes shapeit4 to not use the AVX2 instruction set:
> -CXXFLAG=-O3 -mavx2 -mfma
> +#CXXFLAG=-O3 -mavx2 -mfma
>  #Portable version without avx2 (much slower)
> -#CXXFLAG=-O3
> -LDFLAG=-O3
> +CXXFLAG=$(CPPFLAGS) $(CXXFLAGS) -O3
> +LDFLAG=$(LDFLAGS) -O3
>
> This causes shapeit4 to run significantly slower than it could on most 
> systems where this package would be installed.
>
> I assume that the reason for this is that older CPUs do not support AVX2. Is 
> it really important though to support these old systems? I doubt anybody 
> would run such a tool on old machines. However, there might be reasons for 
> this decision that I might be missing so I am curious to know the goals of 
> this modification.
>

You are right, this is the Debian policy to provide binaries that
respect the architecture baseline [1] to support older CPUs. And you
are also right when you said nobody uses this tool on this kind of
outdated CPU. Personally, I don't have time to work on that but I
guess someone else in the Debian Med team would be interested?

Best,
Dylan

[1] https://wiki.debian.org/ArchitectureSpecificsMemo#amd64

Re: False positive lintian tag: requires-r-api

[Dylan Aïssi]

Hi Felix,

Thanks for your prompt answer!

Le jeu. 9 juil. 2020 à 02:34, Felix Lechner
 a écrit :
> Yes. At least for the package r-cran-getopt, the package depends on
> r-api-X.X, (4.0 for arch all) but the regular expression includes no
> period (yet has a plus):
>
> Please just let me know which characters you would like to allow. No MR 
> needed.

By looking into the history of r-base (which provides the virtual
r-api-xx package), we have: r-api-3, r-api-3.4, r-api-3.5 and
r-api-4.0. Only the last one should be in the Debian archive right
now. I think it would be fine if lintian could detect both formats
r-api-X and r-api-X.X where X is numeric.

Thanks again!

Best,
Dylan

False positive lintian tag: requires-r-api

[Dylan Aïssi]

Hi Andreas, hi Felix

Le mer. 8 juil. 2020 à 15:16, Andreas Tille  a écrit :
>E: r-cran-getoptlong: requires-r-api
>
> Dylan, any idea what might be wrong here?

This seems to be a false positive from lintian, this tag seems to be
always emitted even when the binary package has correct dependencies
:-S
The salsa-ci artifacts have correct dependencies for this package [1]
and for another (random) package [2], and both have this tag.

@Felix Do you know where the problem could be in this lintian check?

Best,
Dylan

[1] https://salsa.debian.org/r-pkg-team/r-cran-getoptlong/-/jobs/853034
[2] https://salsa.debian.org/r-pkg-team/r-bioc-annotationdbi/-/jobs/853327

Re: What happened to r-bioc-complexheatmap?

[Dylan Aïssi]

Hi Andreas,

Le mer. 8 juil. 2020 à 15:16, Andreas Tille  a écrit :
>E: r-cran-getoptlong: requires-r-api
>
> Dylan, any idea what might be wrong here?

By looking into the git repo, I have no idea why this tag is emitted.
I will investigate it this evening ( I am at work without a root
access :-( ).

BTW, the previous bug between dh-r and r-other-rosa should now be
fixed in the git repo of dh-r.

Best,
Dylan

Re: RoSA ante portas - happily pass this on

[Dylan Aïssi]

Hi Andreas, hi Steffen,

Le sam. 4 juil. 2020 à 12:30, Steffen Möller  a écrit :
> Lintian still is
> lintian ../rosa_1.0-1_amd64.changes
> E: r-other-rosa: requires-r-api

This tag is now fixed using a workaround to a problem I guess in dh-r.
We had a similar problem some times ago:
https://bugs.debian.org/897262#10

I don't know how to fix that in dh-r.

Best,
Dylan

Re: RoSA ante portas - happily pass this on

[Dylan Aïssi]

Le sam. 4 juil. 2020 à 11:27, Andreas Tille  a écrit :
>
> While I think your changes are pretty sensible it does not solve the
> problem.
>

:-( I will investigate this again later today


Dylan

Re: RoSA ante portas - happily pass this on

[Dylan Aïssi]

Hi Andreas,

Le sam. 4 juil. 2020 à 09:43, Andreas Tille  a écrit :
> @Dylan: Any idea how to fix
>
> E: r-other-rosa: requires-r-api

\o/ this tag is finally useful :-)

I pushed a change that should fix this issue. I was not able to test
because r-cran-lsd is not available (still in NEW). Could you try this
change for me?

Best,
Dylan

Re: RFS or upload permissions for python-pomegranate

[Dylan Aïssi]

Le jeu. 2 janv. 2020 à 10:35, Michael Crusoe
 a écrit :
>
> Thank you Dylan Aïssi !

You are welcome!

Best,
Dylan

Please allow optimir to migrate to testing

[Dylan Aïssi]

Hi release team,

I guess the summer break period (+ debconf2019) was not the best time
for my request. I try it again :-), could you allow optimir to migrate
to testing?

Thank you.

Best,
Dylan

-- Forwarded message -
De : Dylan Aïssi 
Date: jeu. 18 juil. 2019 à 10:15
Subject: Please add force hint to enable optimir testing migration
To: 
Cc: Debian Med Packaging Team 


Hi release team,

please add a force-hint to add the testing migration of

   optimir 1.0-2

While optimir is arch all it has some unsatisfiable Depends:
python3-pysam, bowtie2 and samtools on i386 which seem to block the
testing migration [1]. Thanks.

Best regards,
Dylan

[1] https://lists.debian.org/debian-med/2019/07/msg00149.html

Re: Migration to testing of optimir is blocked - why?

[Dylan Aïssi]

Hi Mattia,

Le mer. 17 juil. 2019 à 18:15, Mattia Rizzolo  a écrit :
> Just mentioning: arch:all needs to be installable on amd64 and i386, the 
> other archs are there only for reference.  If that isn't possible you can 
> contact the release team to ask for a "force"-hint and make that migrate 
> nonetheless (future migrations will happen without hinting)

So, I was not totally wrong with my assumption :-). Thanks for this precision.

Best,
Dylan

Re: Migration to testing of optimir is blocked - why?

[Dylan Aïssi]

Hi Andreas,

Le mer. 17 juil. 2019 à 16:49, Andreas Tille  a écrit :
>
> The Excuses link[2] is your friend.  The Architecture all package
> expects to be able to run on *all* architectures but it can't since some
> Depends are only available on amd64 this is a problem.  I try to
> remember what the solution was.  I think in some cases we used the ugly
> hack to make the package Architecture: any and
>   Build-Depends: bowtie2, python3-pysam
> which provides the package only where those dependencies exist.  But
> that's not a nice solution.  I think we did not do this trick for
> metaphlan2 but if I remember correctly that needed a manual hint from
> release team to propagate.  Sorry, I simply forgot - may be you check
> the list archive for a proper solution?
>

Thanks for your explanation. My friend in [2] was not very clear to me
:-), maybe because I wrongly thought only amd64 will be considered. I
will check the list archive to find a proper solution otherwise I will
use the ugly hack. Thanks again.

Best,
Dylan

Migration to testing of optimir is blocked - why?

[Dylan Aïssi]

Hi,

The migration of optimir [1] to testing was blocked during the freeze
for Buster. But since the freeze is over, optimir never moved to
testing and I don't know why. He has some dependencies which are
available only in amd64, so could this be a problem for the migration?
Should I restrict the arch of optimir to amd64 only to unblock its
from unstable? Or the problem is from somewhere else?

Best,
Dylan

[1] https://tracker.debian.org/pkg/optimir

fastqc: htsjdk.samtools.util.RuntimeIOException: java.io.IOException: Stream closed

[Dylan Aïssi]

Control: severity -1 serious

Hi,
I have tested the testsuite with the upstream binary (FastQC 0.11.8)
and there is no error, so the testsuite is fine. This bug was probably
hidden before we added the test of bam and sam files. Currently,
fastqc from our package is unable to process bam and sam files which
is very annoying for Buster. I guess we have to modify
htsjdk-api.patch, but I admit I have no clue how to fix it. The
easiest way should be to add SAMFileReader like suggested in [1]. Any
suggestion?

Best,
Dylan

[1] https://github.com/samtools/htsjdk/issues/767#issuecomment-264843094

Re: FW: Bio linux download

[Dylan Aïssi]

Hi Tony,

Le lun. 20 mai 2019 à 22:21, Tony Travis
 a écrit :
> Hi, Dylan.
>
> I've installed the "metaphlan2" package from Ubuntu "bionic-proposed"
> successfully, with no errors reported. If "metaphlan2" is installed,
> "med-bio" will install without errors in Ubuntu-MATE 18.04.2 LTS:
>

Thanks for you report.

> Please let me know if/when the broken version of "metaphlan2" will be
> updated in the Ubuntu repositories?

You will be automatically notified when metaphlan2 will be updated in
Ubuntu repositories.
LP: #1777165 will switch to "Fix released".

Best,
Dylan

Re: FW: Bio linux download

[Dylan Aïssi]

Hi Graham,

Le mer. 24 avr. 2019 à 21:19, Graham Inggs  a écrit :
>
> Is this LP: #1777165 [1]?  Let's get this fixed, I'm happy to sponsor
> a SRU [2] upload.
>

I am preparing the fix [1], I will ping you when it is ready.

Best,
Dylan

[1] https://salsa.debian.org/med-team/metaphlan2/commits/ubuntu/bionic

Re: Please help with Conda packaging [Was: Bug#926416: ITP: conda -- OS-agnostic, system-level binary package manager and ecosystem]

[Dylan Aïssi]

Hi,

If we have some questions regarding conda, we can ask to upstream,
they should be happy to help us.

  https://github.com/conda/conda/issues/1235

Best,
Dylan

Re: multiqc | Add more registries (074d642d)

[Dylan Aïssi]

Hi Steffen,

Le lun. 25 mars 2019 à 23:23, Steffen Möller  a écrit :
> Ooops! Well done!

It was quite easy, I tried to merge my packaging attempt into yours :-).

Le sam. 23 mars 2019 à 12:22, Steffen Möller  a écrit :
> That escaped me. Many thanks. And, amazingly, we apparently had even
> more hands at the package than we thought.

We are like a team ;-)

> I did not find the current license. No idea of highcharts.js is
> redistributable. Maybe we can change the code to include it online from
> https://code.highcharts.com/highcharts.js and have everything in
> contrib? I don't exactly know how multiqc works, but if it works without
> needing highcharts for generating the reports, and only the addressee of
> the generated pages needs to be online to experience the report, then it
> is contrib, not non-free, right?

Yep, the license of highcharts.js is quite hidden. There is a
reference in the "Non-commercial" paragraph of this webpage:
  https://shop.highsoft.com/highcharts

The MultiQC's code is too closely related to highcharts.js' code, we
have to use the same version ( the current version in MultiQC is 5
whereas the latest version is 7).
So, we should target a specific version (at least the major version) like this:
  https://code.highcharts.com/stock/5.0/highstock.js

Maybe we can provide a script for users to download and install the
correct version of highstock.js for MultiQC.
Similar mechanism was used for libdvdcss2 (and Flash Player) some times ago.

The highstock.js is embedded in the generated html report and it's
very useful because we can easily share the report to other people
without any Internet access.

Best,
Dylan

Re: Too many hands on MultiQC Fwd: Bug#925304: Acknowledgement (ITP: multiqc -- output gathering for RNA sequencing across tools and samples)

[Dylan Aïssi]

Hi Andreas, hi Steffen,

Unfortunately, MultiQC is not DFSG compatible because its main
component is Highcharts (CC BY-NC 3.0).
  https://github.com/ewels/MultiQC/issues/800

But this tool is very useful, so maybe we can push it in non-free.

Best,
Dylan

Re: Debian Med Badge - just like Conda has it?

[Dylan Aïssi]

Le sam. 15 sept. 2018 à 21:30, Steffen Möller  a écrit :
>
> https://bioconda.github.io/_static/badge-generator/

Not as pretty but we have those ones:
https://badges.debian.net/


Dylan

Re: Upload rights request

[Dylan Aïssi]

Hi Mattia,

Le ven. 28 sept. 2018 à 14:38, Mattia Rizzolo  a écrit :
> In which case, this should happen very soon, the keyring-maint team is
> having some troubles, but I'd expect this to happen at most in the
> upcoming weekend (should have happened 4 days ago…)

Thanks for these news :-)

Best,
Dylan

Upload rights request

[Dylan Aïssi]

Hi,

Can someone give me the upload rights for these packages?
- minimac4
- r-cran-leaps
- r-cran-shinythemes
- r-cran-rlumshiny

dcut dm --uid "bob.dyb...@gmail.com" --allow minimac4 r-cran-leaps
r-cran-shinythemes r-cran-rlumshiny

Thanks,
Dylan

PS: this should be my last request of upload rights, my DD application
was Approved, I 'm still waiting for the creation of my account.

RFS: biosyntax.

[Dylan Aïssi]

Hi,
I have updated biosyntax which should go to the NEW queue due to new
binary packages. Thanks.

Best,
Dylan

RFS: python-ratelimiter

[Dylan Aïssi]

Hi,

Snakemake, a package from Debian Med, is blocked in unstable (among
others) because python-ratelimiter is not available anymore in
testing. So, I fixed the RC bug and I did some minor updates for
python-ratelimiter [1].

Could you review/merge this [1] and upload the package?

Thanks.

Best,
Dylan

[1] 
https://salsa.debian.org/python-team/modules/python-ratelimiter/merge_requests/1

RFS: python-colormath, python-spectra and python-lzstring

[Dylan Aïssi]

Hi,

Could someone upload them? (colormath is a dependency of spectra). Thanks.

These packages are dependencies for MultiQC [1] which still need some
work before to be uploaded.

Best,
Dylan

[1] http://multiqc.info/

Request for review: minimac4 and libstatgen

[Dylan Aïssi]

Hi,

I finished packages for minimac4 and one of its dependency libstatgen.

Could I have a review of them before to upload to NEW?
Especially for libstatgen, because the upstream makefile does not
generate a shared library, so it is the first time that I have to
manually generate a shared library and deal with SONAME. I did them
directly into the rule file instead to patch makefile because upstream
makefiles are quite complex and I don't want to heavy touch them. Of
course, I will ask to upstream to update their makefiles to provide a
shared library.

Thanks.

Best,
Dylan

RFS: bolt-lmm and gemma

[Dylan Aïssi]

Hi,

I fixed FTBFS for bolt-lmm and gemma, could someone give me upload rights?

Thanks.

Best,
Dylan

AppStream file to store upstream metadata: registry and bibliography references

[Dylan Aïssi]

Hi all,

I started discussions with AppStream devs to add new tags in the AppStream
file. This file contains upstream metadata and it is cross distro in
contrary to our d/upstream/metadata.

If you are using the d/u/metadata to store bibliography references or
registry refences you can take part of discussions here [1-2].

Currently, they agree to add registry references but still need to find the
tag name. Concerning the bibliography references there is no consensus but
I still think from a scientific point of view it could be useful to have a
bibliography in this file and in the software center.

The idea is to move some information (or all?) from
debian/upstream/metadata to the AppStream which is cross distrib and
ideally maintained by upstream. Ok we already have some troubles to get
manpages from upstream so an AppStream file is a dream :-). But at least if
upstream wants to provide metadata, there is a possibility with this file.

So, if you are interested (or not :-), you can go there [1-2] to give your
point of view.

Best,
Dylan

[1] https://github.com/ximion/appstream/issues/189
[2] https://github.com/ximion/appstream/issues/190

Re: RFS: chromhmm and r-cran-metamix

[Dylan Aïssi]

Hi,

bolt-lmm is ready to go in the NEW queue.

Package name: bolt-lmm
URL: https://data.broadinstitute.org/alkesgroup/BOLT-LMM/
License: GPL-3+
Description: Efficient large cohorts genome-wide Bayesian mixed-model
association testing
 The BOLT-LMM software package currently consists of two main algorithms, the
 BOLT-LMM algorithm for mixed model association testing, and the BOLT-REML
 algorithm for variance components analysis (i.e., partitioning of
 SNP-heritability and estimation of genetic correlations).

https://salsa.debian.org/med-team/bolt-lmm


Thanks.

Best,
Dylan




2018-05-25 14:27 GMT+02:00 Dylan Aïssi <bob.dyb...@gmail.com>:
> Hi,
>
> Could I get upload rights for chromhmm?
>
> r-cran-metamix is ready to be sent to the NEW queue.
>
> Thanks.
>
> Best,
> Dylan

RFS: chromhmm and r-cran-metamix

[Dylan Aïssi]

Hi,

Could I get upload rights for chromhmm?

r-cran-metamix is ready to be sent to the NEW queue.

Thanks.

Best,
Dylan

Re: TR: Debian has RRID SCR_006638

[Dylan Aïssi]

Hi all,

2018-04-25 12:21 GMT+02:00 Fabien Pichon :
> As I said in my previous e-mail : YOU tell me what you want WE publish.
>
> It is YOUR communication **NOT** OMICtools' one.
>
> I just offered a "media" support after an Andreas' suggestion. No more.
>
> You should maybe discuss all together in Debian Med about what you want
> OMICtools can do, and just come back to me when you all agreed.
> Thanks,

So, using the script from Andreas, I generated a list for March and
April (only 1 package for April, it can probably be merged with
March).
The list is available here [1]. From the 22 new packages, I excluded 4
of them because they are not really new (renamed or the team became
maintainer). 4 other R packages are excluded because not relevant for
the OMICtools public (they are some dependencies of other packages). I
am undecided for 3 other R packages (r-cran-rwave, r-cran-waveslim and
r-cran-wavethresh), any opinion is welcome.

They are 11 packages which seem interesting to be announced on the
OMICtools newsletter. As the name of a package does mean nothing, I
propose to add the short description of the package. No interest to
mention the version here. Maybe guys from OMICtools can add a link to
the related page of the package on their website if people want more
information.

If everybody agree, I will add the short description and I will send
them to Fabien.

Best,
Dylan

PS: many steps are done manually to generate this list, but does not
matter, we can progressively automate that.

[1] 
https://salsa.debian.org/daissi-guest/list_new_debian-med/blob/master/list_new_debian-med_2018-03_and_2018-04.csv

Re: TR: Debian has RRID SCR_006638

[Dylan Aïssi]

Hi Fabien,

2018-04-25 8:37 GMT+02:00 Fabien Pichon :
>
> If what Dylan proposed is convenient for a majority of persons (and if the
> list and script he sent are correct) I can have something ready this week or
> the next one.

Of course, they are not correct :-) I will have another look today but
it should be better to use UDD instead and I have to learn how to use
it.

But, what do you need exactly? Only new packages (first upload into
Debian) or updated packages (I guess it is the first one).
I will have to manually cure the list because some packages could be
not related to omics... I am not sure if it is useful to highlight
them on your blog.

Best,
Dylan

Re: TR: Debian has RRID SCR_006638

[Dylan Aïssi]

Hi all,

2018-04-19 14:16 GMT+02:00 Andreas Tille :
>> To answer Andreas, we, at OMICtools, could publish every month, the list of 
>> new packages available in Debian Med on our blog :
>> https://omictools.com/blog, if you feel it can helps.

Thanks Fabien for this. :-)

>> We just need a list of these tools and the corresponding OMICS_[0-9]{5} 
>> RRID, if present.
>
> I think about some method to automatically create such a list.  Steffen,
> would you volunteer to assemble it manually for the moment?

Steffen, did you already perform this? I quickly wrote a small script
to do this (attached).
It could be useful (... or not :-)) before to do a cleanest work.

I also attached the generated list for March.

Best,
Dylan
abyss 2.0.3-1 OMICS_6
andi 0.12-2 OMICS_09287
andi 0.12-3 OMICS_09287
ariba 2.11.1+ds-1 OMICS_17327
ariba 2.11.1+ds-2 OMICS_17327
bedops 2.4.32+dfsg-1 OMICS_00949
bedops 2.4.32+dfsg-2 OMICS_00949
blasr 5.3+0-2 OMICS_05134
canu 1.7+dfsg-1 OMICS_14592
centrifuge 1.0.3-1 OMICS_12217
coils 2002-6 OMICS_07850
diamond-aligner 0.9.19+dfsg-1 OMICS_08011
dwgsim 0.1.12-1 OMICS_00249
freebayes 1.1.0-2 OMICS_00059
gwyddion 2.50-1 OMICS_07548
gwyddion 2.50-2 OMICS_07548
jellyfish 2.2.8-2 OMICS_01056
jellyfish 2.2.8-3 OMICS_01056
kissplice 2.4.0-p1-3 OMICS_01321
libbiod 0.1.0-5 OMICS_20057
mhap 2.1.3+dfsg-1 OMICS_13515
phyutility 2.7.3+dfsg-1 OMICS_21687
plink1-9 1.90~b5.3-180221-1 OMICS_00206
prodigal 2.6.3-2 OMICS_01493
python-cutadapt 1.16-1 OMICS_01086
r-bioc-limma 3.34.9+dfsg-1 OMICS_00769
r-bioc-pcamethods 1.70.0-1 OMICS_14344
sambamba 0.6.7-1 OMICS_07586
samtools 1.7-2 OMICS_00090
sniffles 1.0.8+ds-1 OMICS_16283
stacks 2.0Beta9+dfsg-1 OMICS_01567
treeview 1.1.6.4+dfsg1-3 OMICS_01574


List_NewPackages_DebianMed.sh
Description: application/shellscript

RFS: ChromImpute -- Large-scale systematic epigenome imputation

[Dylan Aïssi]

Hi,

Could someone upload it? Thanks.

Best,
Dylan


Package name: chromimpute
URL: http://www.biolchem.ucla.edu/labs/ernst/ChromImpute/
License: GPL-2
Description: Large-scale systematic epigenome imputation
 ChromImpute takes an existing compendium of epigenomic data and uses it to
 predict signal tracks for mark-sample combinations not experimentally mapped
 or to generate a potentially more robust version of data sets that have been
 mapped experimentally. ChromImpute bases its predictions on features from
 signal tracks of other marks that have been mapped in the target sample and
 the target mark in other samples with these features combined using an
 ensemble of regression trees.

This package will be maintained by the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/chromimpute.git/

Re: RRID update on salsa on packages starting with A+B

[Dylan Aïssi]

Hi Steffen, hi Andreas,

2018-03-28 14:16 GMT+02:00 Andreas Tille :
>
>> Via salsa, though, well, not. Should lintian invoke yamllint, possibly?
>
> As far as I know syntax errors in upstream files are fetched by lintian.
> Its the downside of just using the not yet uploaded commits as data
> input that we do not run lintian on these.
>

Currently, the lintian checks for integrity of d/u/metadata are
disabled due to some security problem [1] but maybe should be
re-enabled soon [2].

Best,
Dylan

[1] 
https://anonscm.debian.org/git/lintian/lintian.git/commit/checks/upstream-metadata.pm?id=6119d49c3b
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862373

Re: RFS: bioSyntax -- Syntax highlighting for computational biology

[Dylan Aïssi]

Hi Andreas,

2018-03-24 17:46 GMT+01:00 Andreas Tille :
> Uploaded.  Could you please make some suggestion in what task
> (=metapackage) we should put what binary package?  I'm undecided between
> med-bio and med-bio-dev and which binary package should be mentioned in
> that task(s).

Thanks for the upload.

I did a pull request (I don't have enough rights to push directly): I
put biosyntax-gedit into the med-bio task. I selected med-bio and not
med-bio-dev because this package is to help to visualize sequences and
not to help in development of bioinformatics applications. I chose to
mention only biosyntax-gedit and not the others almost randomly,
probably because I use gedit more frequently than others. But this
should not be a big problem, because next time that biosyntax will
need to go in the new queue (probably quickly because upstream is
working on a plugin for nano), I will create a meta package (=
biosyntax-all), so we will be able to mention only this meta-package
in our tasks (right approach?).

Best,
Dylan

RFS: bioSyntax -- Syntax highlighting for computational biology

[Dylan Aïssi]

Hi,

Could someone review and upload it? Thanks.

Best,
Dylan


Package name: biosyntax
URL: https://biosyntax.org/
License: GPL-3
Description: Syntax Highlighting for Computational Biology (gedit)
 Syntax highlighting for computational biology to bring you intuitively close
 to your data. BioSyntax supports .sam, .flagstat, .vcf, .fasta, .fastq, .faidx
 , .clustal, .pdb, .gtf, .bed files & more.

This package will be maintained by the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/biosyntax.git/

Re: RFS: ChromHMM -- Chromatin state discovery and characterization

[Dylan Aïssi]

Hi Andreas,

2018-03-12 10:00 GMT+01:00 Andreas Tille :

> I've asked upstream for release tags[1].  May be upstream will set those
> tags and you do not need a get-orig-source script any more but if not it
> makes sense to use such a script.  I've provided an example that even
> removes Files-Excluded in our packaging example[2] (at least if you
> specify the files to exclude in a single line separated by spaces).

Thanks for this. The other point here is about example files, the
github archive doesn't provides these files whereas the archive on
their main website provides them.
Of course, I can put these files into debian/ but I prefer to not have
these ~30Mo in the debian/ folder.
I will try to convince upstream to put these files in github to have a
clean archive.

> Regarding the installation of ChromHMM.jar:  I'm not very picky about
> this but I'm usually installing JAR files to /usr/share/java but I
> accept your decision to use /usr/share/chromhmm/ instead.  Just want
> to make sure that this is a decision you have drawn intentionally.

Honestly, I used the same method as I did before for beagle packaging
without asking myself more questions (and I don't remember why I did
this for beagle).
Thanks for pointing this, I will fix this for the next upload.

> I've run `cme fix dpkg-control` and uploaded the current state of Git to
> NEW.

Oups, sorry to forgot the "cme fix".

Thanks for the upload.

Best,
Dylan

RFS: ChromHMM -- Chromatin state discovery and characterization

[Dylan Aïssi]

Hi,

Could someone upload it? Thanks.

Best,
Dylan


Package name: chromhmm
URL: http://compbio.mit.edu/ChromHMM/
License: GPL-3+
Description: Chromatin state discovery and characterization
 ChromHMM is software for learning and characterizing chromatin states.
 ChromHMM can integrate multiple chromatin datasets such as ChIP-seq data of
 various histone modifications to discover de novo the major re-occuring
 combinatorial and spatial patterns of marks. ChromHMM is based on a
 multivariate Hidden Markov Model that explicitly models the presence or
 absence of each chromatin mark. The resulting model can then be used to
 systematically annotate a genome in one or more cell types. By automatically
 computing state enrichments for large-scale functional and annotation datasets
 ChromHMM facilitates the biological characterization of each state. ChromHMM
 also produces files with genome-wide maps of chromatin state annotations that
 can be directly visualized in a genome browser.

This package will be maintained by the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/chromhmm.git/

Re: Some R packages are still present in the Debian Med repository

[Dylan Aïssi]

2018-03-10 0:10 GMT+01:00 Andreas Tille :
>
> Done.  I wonder whether we should fix the entries in AliothRewriter
> accordingly.
>

Thanks Andreas.

About AliothRewriter, it is already done ;-)

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


Best,
Dylan

Some R packages are still present in the Debian Med repository

[Dylan Aïssi]

Hi,
I moved pvclust and permute from Debian Med salsa repository to Debian
R team (respectively r-cran-pvclust and r-cran-permute).
Could someone remove them from the Debian Med team?

Thanks,
Dylan

Re: Depends available in other PPA's

[Dylan Aïssi]

Hi Tony,

2018-03-07 19:29 GMT+01:00 Tony Travis :
>
> Do you or anyone else object if I add the ToolChain test PPA dependency?
>
>> ppa:ubuntu-toolchain-r/test
>

I don't use the Debian Med PPA so I am probably not the most concerned
person here.
I would like to say it is not a problem for me to add this PPA as dependency.


For information the Debian Med PPA is full at 70%, so maybe some
packages which target Ubuntu 10.10 could be removed (shim and
shim-driver-signature-topaz).
I did a pull request to our policy to improve the PPA part [1] but I
forgot to mention it on the mailling list.

Best,
Dylan

[1] https://salsa.debian.org/med-team/community/policy/merge_requests/1/diffs

RFS: jheatchart -- Heat map charting library for Java

[Dylan Aïssi]

Hi,

Could someone upload it? Thanks.

Best,
Dylan


Package name: jheatchart
URL: http://www.javaheatmap.com/
License: LGPL-3+
Description: Heat map charting library for Java
 The JHeatChart library provides a simple API for generating Java heat maps.
 Output heat maps as .png, .jpg or .gif images. Generate Image objects for
 further processing. Show generated Image in a Swing JPanel. Fully customisable
 colours, dimensions, fonts etc. Linear, logarithmic and exponential
 colour scales.

This is a dependency of ChromHMM. This package will be maintained by
the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/jheatchart.git

RFS: python-fitbit

[Dylan Aïssi]

Hi,

I updated python-fitbit, the new version builds new binary packages,
so it should go into the NEW queue. Can someone sponsor it?

python-fitbit (0.3.0-2) UNRELEASED; urgency=medium

  * Move documentation into a new package python-fitbit-doc.
  * Bump Standards-Version: 4.1.3 (no changes needed).
  * Update debhelper compat to 11.
  * Build new package python3-fitbit (Python 3).
  * Remove Build-Depends required by disabled tests.

Thanks

Best regards,
Dylan

Re: Depends available in other PPA's

[Dylan Aïssi]

Hi Tony,

2018-02-12 16:06 GMT+01:00 Tony Travis :
> Is it possible to refer to dependencies like this available in other
> PPAs when building packages?

It seems possible [1] but for the whole PPA not for an individual
package. Not sure that it is reasonable to add dependency to other PPA
here.


Best,
Dylan

[1] 
https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Depending_on_other_PPAs

Re: Salsa migration of Debian Med team packages

[Dylan Aïssi]

Hi,

2018-02-13 14:00 GMT+01:00 Andreas Tille :
> No objections and thanks to Dylan for bringing this up (I just missed
> this).

I just did a pull request [1] to fix Alioth redirections for these packages.

Best,
Dylan

[1] https://salsa.debian.org/salsa/AliothRewriter/merge_requests/152

Re: Salsa migration of Debian Med team packages

[Dylan Aïssi]

Hi Sascha,

Thanks for the migration.

I think all R packages (r-*) can be removed from the Debian Med
repository, they moved into the Debian R team repository [1] some
weeks ago [2].

Best,
Dylan

[1] https://salsa.debian.org/r-pkg-team
[2] https://lists.debian.org/debian-med/2018/01/msg00026.html

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

[Dylan Aïssi]

Hi,

2018-01-10 12:59 GMT+01:00 Charles Plessy :
>
> I just drafted a r-pkg-team page on wiki.debian.org:
>
> https://wiki.debian.org/Teams/r-pkg-team
>

Thanks Charles for this.

It could be useful to add this link in the description of the team in
the salsa page. Like this someone who arrives on the salsa page of the
team can have direct access to the documentation and does not need to
search for it.
This could also be done for the science (and the future med) team salsa pages.

Sorry, I can't do it myself, I don't have enough rights.

Best,
Dylan

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

[Dylan Aïssi]

Hi,
I just transferred the dh-r package from debian-science to r-pkg-team [1-2].
But I don't have right to remove the repository at debian-science. Can
someone do it for me?


Best,
Dylan

[1] https://salsa.debian.org/r-pkg-team/dh-r
[2] https://salsa.debian.org/salsa/AliothRewriter/merge_requests/41



2018-01-08 22:31 GMT+01:00 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: Proposal for Registry-display on task pages

[Dylan Aïssi]

Hi Andreas,

2017-10-19 12:40 GMT+02:00 Andreas Tille :
>
> Well, it might be that we have some typos in our data but this
> duckduckgo.com detour seems very suspicious to me and I would love to
> avoid this.
>

The solution will come from OMICtools, they will provide an API that
will permit to directly link to their website (if I am not wrong).
Fabien from OMICtools (in CC) just asked me about our next sprint to
be able to participate. I think, it will be easier to speak about this
API at the sprint.

It seems to me that nothing dates or place of the next sprint are
still not set or I missed something?

Best,
Dylan

Re: Proposal for Registry-display on task pages

[Dylan Aïssi]

Hi Andreas,

2017-10-19 8:29 GMT+02:00 Andreas Tille :
> On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
>>   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
>> end is what I want)
>
> The link
>
> https://duckduckgo.com/?q=\OMIC_6
>
> should lead to something related to abyss but it does not. :-(
>

It's normal, the OMICtools ID here is incorrect, the correct ID is
OMICS_6 with a "S". We started to correct these ID but some still
need to be corrected.

Best,
Dylan

Re: References to registries -> debian-med policy?

[Dylan Aïssi]

Hi Steffen,

2017-09-16 18:37 GMT+02:00 Steffen Möller :
>
> I have added a sentence to the Debian Med policy and also pushed
> the "Registry:" entry for the UpstreamMetadata wiki page that our
> policy is pointing to.
>

Thank you for this.

After a discussion with Fabien (from OMICtools) in August, we switched
the name of the SCR_XX IDs from "RRID" to "SciCrunch" (for a
randomly example [1]). But, now I see that you come back to "RRID". In
the UpstreamMetadata wiki page, you also use the name "RRID" for these
IDs. Just to be sure, what is now the recommended name for these IDs?

Best,
Dylan

[1] https://anonscm.debian.org/cgit/debian-med/phyml.git/commit/?id=edabc350f1

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

[Dylan Aïssi]

Hi,

2017-08-12 13:25 GMT+02:00 Steffen Möller :
>
> On 12.08.17 11:31, Charles Plessy wrote:
>>
>> 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.
>
>
> I was not aware of it. So, yes, it should go to upstream. I just do not
> fully grasp how to get it in and - is not everything in
> upstream/metadata something for appstream? Also, from what I got, this
> shoud all be redistributed with the upstream source tree and not be kept
> within Debian to the degree I got this right.
>

I agree that could be pushed in the appstream file instead the
metadata file. By this way, it will be easier reused by other
distributions.
Indeed, appstream and upstream/metadata seems to be redundant. We
should probably propose new fields in the specification [1].
We can distribute the appstream file in the deb package until upstream
redistribute it. It was what I have done with the galileo package.

Best regards,
Dylan

[1] https://github.com/ximion/appstream/issues