Bug#850648: Missing source of manual-031.pdf

[Doug Torrance]

Hi Andreas,

On 01/09/2017 06:26 AM, Andreas Tille wrote:

to my understanding manual-031.pdf will be considered as "binary without
source" and thus rejected by ftpmaster.  The best way to solve this
would be to ask upstream for the source files - the second best using
Files-Excluded to remove the PDF from the source tarball.


A new upstream version was just released which includes the manual source!

(Ironically, they decided to add another manual for an old Mathematica 
script *without* source.  Since it's not as important, I added this new 
one to Files-Excluded.)


I've packaged this latest version and it has been pushed git for review.

Thanks!
Doug

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

Thank you again for your patience and extra help!

On Sun, Jan 15, 2017 at 05:51:09PM -0700, Sean Whitton wrote:
> > Ah!  Yes, this is the spec that addresses my question to #3.  That
> > said, in the past some of my other work on d/copyright has been said
> > to be "worse than useless" even though it adhered to the spec, and
> > even though it seemed to reflect what I saw reading the packages
> > COPYING file, in addition to spending a while reading VCS commits for
> > stuff I wasn't sure about.  This has led me to wonder about the tribal
> > rules that are not in the spec...
> 
> Could you give me an example of a rule like that?

It'll take time to dig up examples from my backups, so I'll need to
defer concrete examples until something like mid February.  It might
be stuff like my failure to identify a package that is following DEP-5
vs SPDX, but because of comments like "worst than useless" I figured
there must have been some rule I didn't understand...because that's
way too strong of a reaction for something that is a question of
style. :-)  At this point, however, I don't think further discussion
fits into this thread, because it is too tangential to muse-el.

By the way, is one space indentation for copyright definition blocks
what should now be used (commit
5ba94789a7f35d5938d88226c6ea35fd98635a5b)?  I noticed the packaging
guide's example uses one space, but most of the copyright-format/1.0
packages I've looked at use four.  Just a convention?

> > Would you please check to see if my latest commit to d/copyright is
> > ok?  It's what makes the most sense to me.  As far as I can tell, it
> > might be problematic because it infers that Eric Marsden changed
> > cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.
> 
> No, it doesn't actually imply that Marsden changed that file in 2004
> (the spec does explain this!).

Ah, from packaging-manuals/copyright-format/1.0 "Not all copyright
notices may apply to every individual file, and years of publication
for one copyright holder may be gathered together" [1].  So short form
rules I misunderstood are:

* Wildcards are hungry globs.
* Lists of files are white-space, tab, or newline separated strings.
* Years may be specified as either a comma-separated list of discrete
  years, or a year-to-year range.
* Refer to individual files or VCS for specific dates when multiple
  files are grouped, because [1].

I also wonder how many contributors there must be to justify a
"Primary copyright holder, and others" statement, and also if one
needs to do VCS archaeology to find and list all of the potential
one-off contributors.

> Go ahead and `dch -r`!

Done, finally! :-D

Cheers,
Nicholas


signature.asc
Description: Digital signature

Re: What GPU can be assumed for autopkgtests

[Nicholas Breen]

On Mon, Jan 16, 2017 at 10:21:57AM +0800, Paul Wise wrote:
> On Mon, Jan 16, 2017 at 12:12 AM, Andreas Tille wrote:
> 
> > I remember these messages in connection with some (other?) package on
> > autobuilders but I can't make up my mind which one and I'm obviously
> > doing the wrong web search queries.
> 
> I don't know enough about OpenMPI and the logs you posted don't seem
> to mention the underlying cause of not being able to start the daemon,
> so I'm not sure, sorry. Maybe try stracing it?

Perhaps #494046 ?  One of my packages still requires the suggested workaround,
setting OMPI_MCA_plm_rsh_agent=/bin/false .

#839387 is also relevant when it gets to autobuilding on the non-Linux kernels.



-- 
Nicholas Breen
nbr...@debian.org

Re: What GPU can be assumed for autopkgtests

[Paul Wise]

On Mon, Jan 16, 2017 at 12:12 AM, Andreas Tille wrote:

> I remember these messages in connection with some (other?) package on
> autobuilders but I can't make up my mind which one and I'm obviously
> doing the wrong web search queries.

I don't know enough about OpenMPI and the logs you posted don't seem
to mention the underlying cause of not being able to start the daemon,
so I'm not sure, sorry. Maybe try stracing it?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sun, Jan 15, 2017 at 04:51:24PM -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> > I found some more errors in the copyright file.  Rather than go back and
> > forth once again, I fixed them in our team git repository.  I set the
> > changelog back to UNRELEASED: if you are okay with the changes, please
> > `dch -r`, commit and push, and I will upload.
> 
> Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
> the file is time stamped <2001-08-24 emarsden>?  

Ah, sorry.

> For httpd.el, I agree that "2001, 2003" is more accurate, but is it
> allowed?  In the past, when I've submitted patches to this effect the
> maintainer of the package changed the lines to something like
> "2001-2003", even though the VCS and copyright embedded in the file
> specified discreet years rather than a range...which led me to believe
> that a discreet range is unacceptable.

A discrete range is fine.

> Ah!  Yes, this is the spec that addresses my question to #3.  That
> said, in the past some of my other work on d/copyright has been said
> to be "worse than useless" even though it adhered to the spec, and
> even though it seemed to reflect what I saw reading the packages
> COPYING file, in addition to spending a while reading VCS commits for
> stuff I wasn't sure about.  This has led me to wonder about the tribal
> rules that are not in the spec...

Could you give me an example of a rule like that?

> Would you please check to see if my latest commit to d/copyright is
> ok?  It's what makes the most sense to me.  As far as I can tell, it
> might be problematic because it infers that Eric Marsden changed
> cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

No, it doesn't actually imply that Marsden changed that file in 2004
(the spec does explain this!).

Go ahead and `dch -r`!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Hi Sean,

On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> I found some more errors in the copyright file.  Rather than go back and
> forth once again, I fixed them in our team git repository.  I set the
> changelog back to UNRELEASED: if you are okay with the changes, please
> `dch -r`, commit and push, and I will upload.

Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
the file is time stamped <2001-08-24 emarsden>?  For httpd.el, I agree
that "2001, 2003" is more accurate, but is it allowed?  In the past,
when I've submitted patches to this effect the maintainer of the
package changed the lines to something like "2001-2003", even though
the VCS and copyright embedded in the file specified discreet years
rather than a range...which led me to believe that a discreet range is
unacceptable.

Thank you for the addition of FSF (c) holder, and for adding the final
newline back in.  I'm guessing it disappeared as an artefact of a git
rebase.  A manual git rm elpa-muse.maintscript was also necessary
(argh).

> > > 3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
> > > reflected in d/copyright.
> > 
> > I broke these out into individual stanzas, because I'm short on time
> > right now and wasn't able to find canonical documentation quickly
> > enough.  Comma separated or
> > Files: file1
> >file2
> > 
> > both seem like likely possibilities.  Would it be a nuisance to the
> > maint-guide maintainers if I filed a bug requesting some guidelines on
> > how to group things?  Is that the most appropriate package to file a
> > bug against for this issue?
> 
> You couldn't find the info in the spec?
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Ah!  Yes, this is the spec that addresses my question to #3.  That
said, in the past some of my other work on d/copyright has been said
to be "worse than useless" even though it adhered to the spec, and
even though it seemed to reflect what I saw reading the packages
COPYING file, in addition to spending a while reading VCS commits for
stuff I wasn't sure about.  This has led me to wonder about the tribal
rules that are not in the spec...

Would you please check to see if my latest commit to d/copyright is
ok?  It's what makes the most sense to me.  As far as I can tell, it
might be problematic because it infers that Eric Marsden changed
cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

> > For some reason my piuparts installation isn't working properly, but
> > manually I tested both clean install and upgrading in a clean sid
> > chroot. (this is how I tested #1 and #6)
> 
> piuparts is failing here too, due to issues in the ldap packages.  I
> also tested the manual upgrade and it works :)

:-)


Kind regards,
Nicholas


signature.asc
Description: Digital signature

Re: How can a package (r-bioc-rbgl_1.48.1+dfsg-1) be deleted from mentors

[Andreas Tille]

Hi Christopher,

On Sun, Jan 15, 2017 at 05:24:27PM +, Christopher Hoskin wrote:
> That's odd - I got a message (below) last year saying it had been
> removed. It no longer appears in my list when I log into mentors, so
> it's not obvious to me how I could delete it.

I confirm its odd but its listed at

   
https://udd.debian.org/dmd/?email1=debian-med-packag...@lists.alioth.debian.org=html#todo

under

   mentors  r-bioc-rbgl New version available on mentors: 1.48.1+dfsg-1 
(uploaded on 2016-08-15T14:06:25+00:00)

BTW, I did not assumed that's your fault ...

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: How can a package (r-bioc-rbgl_1.48.1+dfsg-1) be deleted from mentors

[Christopher Hoskin]

Dear Andreas,

That's odd - I got a message (below) last year saying it had been
removed. It no longer appears in my list when I log into mentors, so
it's not obvious to me how I could delete it.

Christopher



Delivered-To: christopher.hos...@gmail.com
Received: by 10.79.34.169 with SMTP id i41csp1409149ivi;
Fri, 11 Nov 2016 12:01:05 -0800 (PST)
X-Received: by 10.28.216.9 with SMTP id p9mr14012724wmg.11.1478894465429;
Fri, 11 Nov 2016 12:01:05 -0800 (PST)
Return-Path: 
Received: from wv-debian-mentors1.wavecloud.de
(wv-debian-mentors1.wavecloud.de. [185.22.221.46])
by mx.google.com with ESMTP id 62si12604112wml.99.2016.11.11.12.01.05
for ;
Fri, 11 Nov 2016 12:01:05 -0800 (PST)
Received-SPF: neutral (google.com: 185.22.221.46 is neither permitted
nor denied by best guess record for domain of
supp...@mentors.debian.net) client-ip=185.22.221.46;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 185.22.221.46 is neither permitted nor
denied by best guess record for domain of supp...@mentors.debian.net)
smtp.mailfrom=supp...@mentors.debian.net
Received: from [82.199.139.46] (localhost [127.0.0.1]) by
wv-debian-mentors1.wavecloud.de (Postfix) with ESMTP id 087F38144E for
; Fri, 11 Nov 2016 20:01:05 + (UTC)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: "mentors.debian.net" 
To: christopher.hos...@gmail.com
Subject: r-bioc-rbgl package has been removed from Mentors
Message-Id: <2016200105.087f381...@wv-debian-mentors1.wavecloud.de>
Date: Fri, 11 Nov 2016 20:01:05 + (UTC)

Your package r-bioc-rbgl 1.48.1+dfsg-1 has been removed from mentors.debian=
.net for the following reason:

Package was uploaded to official Debian repositories

Thanks,

--=20
mentors.debian.net


On 15 January 2017 at 17:15, Andreas Tille  wrote:
> Hi,
>
> r-bioc-rbgl_1.48.1+dfsg-1 was uploaded for sponsoring to new which I
> did.  Before it got accepted it was overridden by version 1.50.0+dfsg1-1
> by myself as team upload to new which is now in unstable.  Unfortunately
> the old version keeps on hanging on mentors and makes constant noise on
> my developers dashboard.  How can we get rid of this?
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de

How can a package (r-bioc-rbgl_1.48.1+dfsg-1) be deleted from mentors

[Andreas Tille]

Hi,

r-bioc-rbgl_1.48.1+dfsg-1 was uploaded for sponsoring to new which I
did.  Before it got accepted it was overridden by version 1.50.0+dfsg1-1
by myself as team upload to new which is now in unstable.  Unfortunately
the old version keeps on hanging on mentors and makes constant noise on
my developers dashboard.  How can we get rid of this?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: What GPU can be assumed for autopkgtests

[Andreas Tille]

Hi Paul,

On Sun, Jan 15, 2017 at 09:17:27PM +0800, Paul Wise wrote:
> 
> It is unlikely any buildd, puiparts host or debci host has a GPU.
> Often they are virtual machines with only serial console for input if
> any. So the safe bet for OpenCL is the CPU-based ICD, pocl-opencl-icd.

OK, seems I'm at least half-way through.  Now I get:


DNA interleaved sequence file, default parameters :
Could not create topdir for cache[autopkgtest-lxc-kivtvg:02003] 
[[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node 
in file ess_singleton_module.c at line 597
[autopkgtest-lxc-kivtvg:02003] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to 
start a daemon on the local node in file ess_singleton_module.c at line 168
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  orte_ess_init failed
  --> Returned value Unable to start a daemon on the local node (-127) instead 
of ORTE_SUCCESS
--
--
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):

  ompi_mpi_init: ompi_rte_init failed
  --> Returned "Unable to start a daemon on the local node" (-127) instead of 
"Success" (0)
--
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)
[autopkgtest-lxc-kivtvg:2003] Local abort before MPI_INIT completed completed 
successfully, but am not able to aggregate error messages, and not able to 
guarantee that all other processes were killed!


I remember these messages in connection with some (other?) package on
autobuilders but I can't make up my mind which one and I'm obviously
doing the wrong web search queries.

Any further hints?

Thanks so far in any case

  Andreas.


-- 
http://fam-tille.de

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sat, Jan 14, 2017 at 09:04:28PM -0700, Nicholas D Steeves wrote:
> I think it's finally ready.

I found some more errors in the copyright file.  Rather than go back and
forth once again, I fixed them in our team git repository.  I set the
changelog back to UNRELEASED: if you are okay with the changes, please
`dch -r`, commit and push, and I will upload.

> > 3) Eric Marden's copyright on contrib/{cgi.el, httpd.el} is not
> > reflected in d/copyright.
> 
> I broke these out into individual stanzas, because I'm short on time
> right now and wasn't able to find canonical documentation quickly
> enough.  Comma separated or
> Files: file1
>file2
> 
> both seem like likely possibilities.  Would it be a nuisance to the
> maint-guide maintainers if I filed a bug requesting some guidelines on
> how to group things?  Is that the most appropriate package to file a
> bug against for this issue?

You couldn't find the info in the spec?

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

> > 4) contrib/pyblosxom/make-blog has a custom license.
> This one required research.  Fixed.

Great work figuring this one out!

> > Don't forget to update the changelog for the above, and `dch -r`.  I
> > would recommend testing with piuparts to confirm the (1) and (6) are
> > resolved.  I'm confident that I'll be able to upload once you've
> > resolved these six points, though I've replied to your other comments
> > below.
> 
> For some reason my piuparts installation isn't working properly, but
> manually I tested both clean install and upgrading in a clean sid
> chroot. (this is how I tested #1 and #6)

piuparts is failing here too, due to issues in the ldap packages.  I
also tested the manual upgrade and it works :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: What GPU can be assumed for autopkgtests

[Paul Wise]

On Sun, Jan 15, 2017 at 9:07 PM, Andreas Tille wrote:

> Is there any hint how this test can be run on the autopkgtest
> hardware?

It is unlikely any buildd, puiparts host or debci host has a GPU.
Often they are virtual machines with only serial console for input if
any. So the safe bet for OpenCL is the CPU-based ICD, pocl-opencl-icd.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

What GPU can be assumed for autopkgtests

[Andreas Tille]

Hi,

the log from phyml autopkgtest[1] says:

...
beignet-opencl-icd: no supported GPU found, this is probably the wrong 
opencl-icd package for this hardware
(If you have multiple ICDs installed and OpenCL works, you can ignore this 
message)

OpenCL error: CL_DEVICE_NOT_FOUND from file , line 118.
...


Is there any hint how this test can be run on the autopkgtest
hardware?

Kind regards

   Andreas.

[1] 
https://ci.debian.net/data/packages/unstable/amd64/p/phyml/20170114_190256.autopkgtest.log.gz

-- 
http://fam-tille.de

Bug#851367: marked as done (RFS/ITP: python-scandir/1.4-1)

[Debian Bug Tracking System]

Your message dated Sun, 15 Jan 2017 12:27:35 +0100
with message-id <20170115112734.l6ocoais3zh2o...@mapreri.org>
and subject line Re: Bug#851367: RFS/ITP: python-scandir/1.4-1
has caused the Debian Bug report #851367,
regarding RFS/ITP: python-scandir/1.4-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
851367: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851367
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "python-scandir"

 * Package name: python-scandir
   Version : 1.4-1
   Upstream Author : Ben Hoyt
 * URL : https://github.com/benhoyt/scandir
 * License : BSD-3-clause
   Section : python

  It builds those binary packages:

python-scandir - Backport of the "scandir" stdlib module (Python 2)

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-scandir


  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/p/python-scandir/python-scandir_1.4-1.dsc

  It is packaged within the Debian Python Modules Team's repositories :

Vcs-Git:
https://anonscm.debian.org/git/python-modules/packages/python-scandir.git
Vcs-Browser:
https://anonscm.debian.org/cgit/python-modules/packages/python-scandir.git

  Thanks,

Snark on #debian-python
--- End Message ---
--- Begin Message ---
On Sun, Jan 15, 2017 at 11:53:02AM +0100, Julien Puydt wrote:
> Done.

There, uploaded.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Bug#851367: RFS/ITP: python-scandir/1.4-1

[Julien Puydt]

Hi,

On 15/01/2017 10:55, Mattia Rizzolo wrote:

Control: tag -1 moreinfo
Control: owner -1 !

On Sat, Jan 14, 2017 at 01:00:42PM +0100, Julien Puydt wrote:

  I am looking for a sponsor for my package "python-scandir"


o/


https://anonscm.debian.org/git/python-modules/packages/python-scandir.git


d/control:

Build-Depends: debhelper (>= 10), dh-python, libpython2.7-dev, python, 
python-setuptools

please replace those python deps by using either python-all-dev or
python-dev.



Done.

Snark on #debian-python

Bug#851367: RFS/ITP: python-scandir/1.4-1

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: owner -1 !

On Sat, Jan 14, 2017 at 01:00:42PM +0100, Julien Puydt wrote:
>   I am looking for a sponsor for my package "python-scandir"

o/

> https://anonscm.debian.org/git/python-modules/packages/python-scandir.git

d/control:

Build-Depends: debhelper (>= 10), dh-python, libpython2.7-dev, python, 
python-setuptools

please replace those python deps by using either python-all-dev or
python-dev.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851367: RFS/ITP: python-scandir/1.4-1

[Julien Puydt]

Hi,

On 14/01/2017 17:35, Adam Borowski wrote:

On Sat, Jan 14, 2017 at 01:00:42PM +0100, Julien Puydt wrote:

  I am looking for a sponsor for my package "python-scandir"

 * Package name: python-scandir

python-scandir - Backport of the "scandir" stdlib module (Python 2)


I got the impression Python 2 is not supposed to be included in Buster;
everyone will need to migrate after Stretch is released.

I'm not a snake-lover so I'm not certain, but if that's the case, this
package would be kind of pointless.


I wouldn't package it if it weren't about maintaining another already 
existing package, python-pathlib2. And since python-pathlib2 is one of 
the many deps of sagemath -- a big project which still hasn't migrated 
properly to Python 3, I want to keep python-pathlib2 alive.


Snark on #debian-python

FTBFS in jellyfish trying to move strangely named shared library jellyfish.so.0.0.0U which does not exist

[Andreas Tille]

Hi,

I intended to upgrade jellyfish[1] to make sure autopkgtest will run.
When trying to build I've got a strange new FTBFS:

libtool: install: ranlib 
/build/jellyfish-2.2.6/debian/tmp/usr/lib/perl/5.24.0/jellyfish.a
libtool: warning: remember to run 'libtool --finish /usr/lib/perl/5.24.0'
mv: cannot stat 'jellyfish.so.0.0.0U': No such file or directory
libtool:   error: error: relink 'swig/perl5/jellyfish.la' with the above 
command before installing it
Makefile:1051: recipe for target 'install-perlextLTLIBRARIES' failed
make[4]: *** [install-perlextLTLIBRARIES] Error 1
make[4]: Leaving directory '/build/jellyfish-2.2.6'


I vaguely suspect that this might be connected to the latest perl
upgrade but I have never seen things like this.  I can confirm that
in the build chroot there is

root@sputnik:/build/jellyfish-2.2.6# find . -name "jellyfish.so.0.0*"
./debian/tmp/usr/lib/perl/5.24.0/jellyfish.so.0.0.0
./swig/perl5/.libs/jellyfish.so.0.0.0T


I have no idea how to deal with these appendixes 'T' or 'U' to the
library version.

Any hints?

Kind regards

 Andreas.


[1] https://anonscm.debian.org/git/debian-med/jellyfish.git

-- 
http://fam-tille.de