My report from Debian Med sprint

[Andreas Tille]

Hi,

as usual the Debian Med sprint[1] was happening at beginning of the year.
This year we met in Barcelona.  As usual the sprint was quite
productive.  The Salsa migration (basically done by Sascha Steinbiss)
needed some extra care for some issues which distracted a bit from the
actual packaging work.

My personal report can be found as usual in the Wiki[2] - here is a copy
of my activities:

 1. Migration to Salsa of some Debian-Med relevant packages of DebiChem
team
 2. Introduce Fabien Pichon into script to obtain package metadata
 3. Uploads
 * sponsored libbpp* and bppsuite
 * updated bedtools
 * updated python-cutadapt (+ depencency python-xopen)
 * updated diamond-aligner
 * updated examl
 * sponsored galaxy-lib to new
 * updated hilive
 * updated libsbml (#890089)
 * fix bio-travis (#890096)
 * fix kalign (#890256) 
 4. Start script to read machine readable data from salsa
(finalised past sprint[3])
 5. Mentoring Cédric Lood at the example of packages bandage and porechop
(both need more work)
 6. Fixed and uploaded rejected packages:
 * python-bd2k
 * nanook
 * obitools
 * r-cran-rmarkdown 
 7. Assemble list of missings in Debian compared to Bio-Linux
(some missings were uploaded past sprint)
 8. Moved team policy to Git

The sprint was happening in a nice atmosphere - here are some images
from the attendees[4], barcelona and my trip to other Debian friends
afterwards.

Kind regards and thanks for supporting Debian Med sprints

  Andreas.


[1] https://wiki.debian.org/Sprints/2018/DebianMed2018
[2] https://wiki.debian.org/Sprints/2018/DebianMed2018#line-130
[3] 
https://salsa.debian.org/blends-team/website/blob/master/misc/machine_readable/fetch-machine-readable_salsa.py
[4] http://fam-tille.de/spanien/barcelona/#11

-- 
http://fam-tille.de

Re: Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Dear Andreas,

сб, 24 мар. 2018 г. в 17:33, Andreas Tille :

On Sat, Mar 24, 2018 at 02:35:41PM +, Liubov Chuprikova wrote:
> > Is there a way to test graphical applications in *ncbi-tools-x11?
>
> I once had the idea in the figtree package to use xvfb-run[1].  It was
> not really successful and most probably the answer is: No, there is no
> sensible way to test X applications right now.
>

Thank you for the сomprehensive answers and interesting example provided! I
have looked through it and I will return to this subject after completing
with *ncbi-tools-bin*.


> > I haven't changed the copyright yet because I am likely to add more
> > additional test files later.
>
> >From my personal point of view I would add a copyright notice right
> when injecting additional files that need to be mentioned.  Its just
> that the memory is fresh what was done to get the file.
>

Yes, I haven't thought that it would be a better practice! I'll try to
follow your advice.

Kind regards,
Liubov

ncbi-tools6 does not simply build via gbp due to changed files

[Andreas Tille]

Hi Aaron,

since Liubov Chuprikova added autopkgtest to ncbi-tools6 I tried to
build the package but failed.  The repository contains upstream files
that are different from the upstream tarball and it is not clear to me
how this package should be build at all with this setup.  Moreover it
seems to be the only package of Debian Med team that is not using
source/format 3.0 (quilt) which should be used according to our
policy[1] unless a different format brings a specific advantage.  I can
confirm that also with "3.0 (quilt)" the package does not build due to
those changed files.

Would you mind switching to this format and add the changes as quilt
patches?  Otherwise I'd consider it necessary that you add a
debian/README.source how your fellow developers can easily build the
package.

Kind regards

  Andreas.

[1] https://debian-med.alioth.debian.org/docs/policy.html#debian-source-format

-- 
http://fam-tille.de

Re: Bug#879619: Autopkgtest for ncbi-tools6

[Andreas Tille]

Dear Liubov,

On Sat, Mar 24, 2018 at 02:35:41PM +, Liubov Chuprikova wrote:
> 
> I have started to work on writing tests for *ncbi-tools6*, which is the
> source for multiple binary packages.

Yes.  Its tough that you want to tackle this more complex package which
is definitely very valuable since its a frequently used package.

> Some of them contain shared libraries,
> others are with data files and only two contain executables (
> *ncbi-tools-bin* and *ncbi-**tools-x11*). Is there a way to test graphical
> applications in *ncbi-tools-x11?

I once had the idea in the figtree package to use xvfb-run[1].  It was
not really successful and most probably the answer is: No, there is no
sensible way to test X applications right now.

> *Should I ignore non-executable binary packages?

Yes.  Even if the wording is not fully correct.  When autopkgtests are
run all binary packages are installed besides the source package on the
testing machine.  Thus the test is working on all binary packages in
principle - but we are running the command line executables in the test
suite.  The special way I prefer to provide the test script also as
user installable example in /usr/share/doc//run-unit-test
is strictly speaking not what autopkgtest is doing - it runs any
script that is specified in PKGSOURCE/debian/tests/control (= in the
unpackaged source package).

But if we stick to the user executable example this should be installed
into the package containig the command line executables binary package.
 
> Meanwhile, I have pushed my first efforts to check some of the
> functionality inside *ncbi-tools-**bin *(commit
> ).
> At the moment, the commands in the test run one by one and the test exits
> on the first fail. I thought it would be better if the test gathers exit
> statuses of each command and returns only global exit status instead and
> maybe some summary of which commands fail? I could implement this idea if
> you don't think it is too much.

Well, I'm fine if you think this is better.  But we need to look for
errors whereever it happens and I do not consider it very important to
do the sophisticated design you are proposing.  So it does not harm but
I think it is more important to add the way you obtained the data to
d/control (as in the previous example).
 
> I haven't changed the copyright yet because I am likely to add more
> additional test files later.

>From my personal point of view I would add a copyright notice right
when injecting additional files that need to be mentioned.  Its just
that the memory is fresh what was done to get the file.

> However, I always doubt that I don't see
> something else that I need to pay attention to. I'll be happy to receive
> any recommendations from you!

Without having built the package and tested the script it looks sensible
to me as it is.  I'll start a build and will give further remarks if
needed.

Thanks for your work on this

  Andreas.


[1] 
https://salsa.debian.org/med-team/figtree/blob/master/debian/tests/run-unit-test
 

-- 
http://fam-tille.de

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hello Andreas,

I have started to work on writing tests for *ncbi-tools6*, which is the
source for multiple binary packages. Some of them contain shared libraries,
others are with data files and only two contain executables (
*ncbi-tools-bin* and *ncbi-**tools-x11*). Is there a way to test graphical
applications in *ncbi-tools-x11? *Should I ignore non-executable binary
packages?

Meanwhile, I have pushed my first efforts to check some of the
functionality inside *ncbi-tools-**bin *(commit
).
At the moment, the commands in the test run one by one and the test exits
on the first fail. I thought it would be better if the test gathers exit
statuses of each command and returns only global exit status instead and
maybe some summary of which commands fail? I could implement this idea if
you don't think it is too much.

I haven't changed the copyright yet because I am likely to add more
additional test files later. However, I always doubt that I don't see
something else that I need to pay attention to. I'll be happy to receive
any recommendations from you!

Thank you,
Liubov

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/