Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd

[Fabian Klötzl]

Hi Samuel,

I forwarded the bug to the GCC tracker and they said that your 
interpretation of the docs is correct. I doubt whether they are willing 
to change the behaviour, but we'll see.


Best,
Fabian

Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd

[Fabian Klötzl]

forwarded 945133 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419

Bug#944299: ITP: phylonium -- Fast and Accurate Estimation of Evolutionary Distances

[Fabian Klötzl]

Hi all,

I started packaging phylonium locally. However, I can't push to salsa 
because of some "default branch" issue. As I am only a "Developer" for 
that repo, I can't change it my self. Could someone fix that for me or 
make me a maintainer so that I can do it?


Best
Fabian

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


On 07.11.19 13:34, Fabian Kloetzl wrote:

Package: wnpp
Severity: wishlist
Owner: Fabian Klötzl 

* Package name: phylonium
   Version : 1.1
   Upstream Author : Fabian Klötzl 
* URL : https://github.com/evolbioinf/phylonium
* License : GPL
   Programming Lang: C++
   Description : Fast and Accurate Estimation of Evolutionary Distances

This is the phylonium program for estimating the evolutionary distances
between closely related genomes. It is much faster than alignment based
approaches for phylogeny reconstruction and usually more accurate than
competing alignment-free methods.

This package will be co-maintained in the Debian Med Team.

Bug#936088: [Debian-med-packaging] Bug#936088: marked as done (libmurmurhash autopkg tests fail)

[Fabian Klötzl]

I saw that there was something wrong with the CI of libmurmurhash but 
didn't have the time to look into it, yet. Thanks to Matthias for the 
patch and to Andreas for releasing a new version so quickly.


Best,
Fabian

Bug#922010: RFS: libmurmurhash 1.3

[Fabian Klötzl]

On 11.02.19 22:24, Andreas Tille wrote:

I had a look on the build logs[1] and at least mips and s390x keep
on failing (some archs are not yet build).

Sorry for keeping you busy with this


That's fine, because it is entirely my fault; Wouldn't have happened if 
I had merged your automake suggestion.


Pushed a new release to salsa.


To quote another authority: "Everything
should be made as simple as possible, but not simpler." (A. Einstein)
I regard the simple Makefile as to simple for the intended purpose.



Touché.

Fabian

Bug#922010: RFS: libmurmurhash 1.3

[Fabian Klötzl]

Hi Andreas,

On 11.02.19 15:41, Andreas Tille wrote:



Furthermore, I added some man page links. I also wanted to remove
some private functions from the .symbols file. However, that resulted in a
lintian error.

Could you be more verbose about what you did and what lintian error was
issued?  Normally you do not simply remove symbols vrom the .symbols
file manually.  You should rather declare the interface private inside
the code and update the symbols file.


Long Description: PMurHash comes with a few functions e.g. 
"PMurHash32_Process" which I use internally, but I don't want to 
support. The true API of libmurmurhash consists of six functions 
"prefixed with lmmh_ or MurmurHash3_. Only these functions appear in the 
header supplied by the -dev package. As they are the public interface, 
only they should appear in the symbols file, right?



So my advise to upstream is:

1. Declare the private functions really private
Got it; managed to define the PMurHash with visibility hidden. Will 
create a new upstream version with bumped soname some time.

2. Use Automake


I leave it to Lennart Poettering to describe the madness that are the 
autotools: „Das ist ein Perlskript, das ein m4-Skript generiert, das ein 
Shellskript generiert, was ein Makefile generiert.“ [1] Even though I 
know automake, I am a bit reluctant to add it to libmurmurhash, because 
I think that for such a small project a simple makefile should suffice. 
(And it works just fine on Arch Linux *cough*)



3. Bump SONAME if the resulting lib has changed / removed symbols

Please note:  Bumping SONAME also means changing the package name and
thus trying another round inside new queue.  While currently ftpmaster
is incredibly quick I've seen relion sitting there for longer than
expected due to the same reason (admittedly way more complex code to
review).  In any case the tour via new queue has a non-predictable delay
time and may be we wait until mash has migrated to testing before doing
this.


Fully agree on this one; Let's take one step after the other, first 
libmurmurhash, then mash, then our other packages, and, maybe if we want 
to and the API/ABI is stable, other debian packages.


Best,
Fabian


1: https://cre.fm/cre209-das-linux-system?t=15:53

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi Andreas,

On 07.02.19 14:58, Andreas Tille wrote:

There are also build issues of libmurmurhash on some architectures[2]

Any idea what to do next?

[2] https://buildd.debian.org/status/package.php?p=libmurmurhash=sid


I hope to have fixed the build issues upstream. Have pushed a new—and 
hopefully working—version to salsa. Could you sponsor another upload? I 
will take a further look at the package next week.


Have a nice weekend
Fabian

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi,

On 07.02.19 16:00, Andreas Tille wrote:
> I've obviously missed that part of your mail.  It is fixed now and I'll
> re-upload.

No worries. The alternative would have been to create a separate set of
unit tests for the 32bit architectures.

> 
> Meanwhile I've fixed the symbols file in Git.  Please git pull.
> 

While your at it, could you also push the tags? Thanks in advance
Fabian

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

On 07.02.19 14:58, Andreas Tille wrote:


Unfortunately the -DARCH32 flag (which is set according to the build log[1]) 
does
not help on i386 architecture:


./mash info -d test/reads.msh > test/reads.json
diff test/genomes.json test/ref/genomes.json
7c7
<  "hashType" : "MurmurHash3_x86_32",
---

  "hashType" : "MurmurHash3_x64_128",


mash uses two different hash functions depending on the architecture: 
MurmurHash3_x86_32 for 32 bit and MurmurHash3_x64_128 for 64 bit 
architectures; These produce different hash values. The tests compare 
the results of one run with a precomputed result. However, the tests 
check against the 64bit reference. Thus they are bound to fail on 32bit. 
Hence my suggestion to turn the tests off for 32bit.




There are also build issues of libmurmurhash on some architectures[2]

This is curious. One of the three hash functions is wrong, but at least 
consistently wrong. I'll look into that.


Fabian

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi Andreas,

On 07.02.19 08:10, Andreas Tille wrote:


Unfortunately it does not pass its build time tests any more now that I
rebuild it for uploading.


I had a look and could trace the failure to two issues. 1) The test 
should run sequentially; can be fixed via a simple override. 2) The 
previous commit (ARCH32) doesn't work as expected [1]. Building on AMD64 
will still have the -DARCH32 flags. This then leads to a different hash 
function being used and the tests failing. I tried to fix the 
conditional in the makefile but cannot figure out what is wrong with it 
in the first place. Also it should deactivate unit tests on 32bit while 
at it. Could you take another look at the conditional?


Best
Fabian


1: 
https://salsa.debian.org/med-team/mash/commit/42bf5484376d9b3e5ae4271f7d0e998ae0daac34

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi Andreas,

So I improved the upstream libmurmurhash, adapted the package and filed 
an ITP (#921353). I even managed to locally build mash against the new 
package. So hereby I kindly ask you to fix the last lintian issue about 
NMU which I don't fully understand and then maybe sponsor an upload.


Best
Fabian

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

As promised, I pushed my packaging attempt. However, I didn't manage to 
create a repository under med-team, thus it is under my account [1].


Best
Fabian

1: https://salsa.debian.org/kloetzl-guest/libmurmurhash

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi Andreas,

I started a new project `libmurmurhash` which should fix the problem of
code duplication [1]. However, I could not yet check whether my code
produces the correct result on big endian systems without crashing. On
x64 it works fine and I also produced a working package locally. I could
commit it to salsa tomorrow.

The upstream project just needs a bit more polishing (documentation,
better tests) before I would call it done.

Have a nice Sunday,
Fabian

1: https://github.com/kloetzl/libmurmurhash

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi,

There are 162 packages in Debian containing the string MurmurHash. Some
of them use an implementation called PMurHash which fixes the endianess
issue.

On 07.01.19 16:42, Andreas Tille wrote:
> It seems to be time to package MurmurHash3 separately, isn't it?

Yeah, I think it makes sense to create a libmurmurhash package and then
have all "bad" implementations link against that. I will look at some
oof the code and start a project.

Best,
Fabian

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

[Fabian Klötzl]

forwarded 918566 https://github.com/marbl/Mash/issues/106
thanks

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

[Fabian Klötzl]

mash internally uses MurmurHash 3 which is sensitive to the endianess. 
There is a note in the source [1], but no preventive measures are taken. 
I will forward this upstream and might even have a go at this myself.


(In theory this should not be a big issue expect for slightly 
inaccurate/different results.)


Fabian

1: 
https://github.com/marbl/Mash/blob/aabd5925e7cfc097a8d89e2d8691ac4af5b95d37/src/mash/MurmurHash3.cpp#L52

Bug#912235: Bug#912235: figtree FTBFS with OpenJDK 11

[Fabian Klötzl]

forwarded 912235 https://github.com/rambaut/figtree/issues/128


I agree, using Java 8 is the easy solution, not the nice one. Even with 
the hot-of-the-press version 1.4.4 the problem exists, so I opened an 
issue upstream [1]. I will continue looking into this even if Java is 
not my strength.


Fabian

1: https://github.com/rambaut/figtree/issues/128

Bug#912235: [Debian-med-packaging] Bug#912235: figtree FTBFS with OpenJDK 11

[Fabian Klötzl]

Thank you for reporting. I added a fix to the repo. Will get resolved 
with the next upload.


Best
Fabian

Bug#908459: theseus FTBFS with gcc 8

[Fabian Klötzl]

On 11.09.2018 15:58, Adrian Bunk wrote:

Control: reopen -1

Some builds were still running into #897876 due to the buildd chroots
only regenerated twice per week (which is not something you should be
worried about), but the armhf/i386 and ppc64el FTBFS look more like
actual problems that need fixing in theseus.


Unfortunately, fixing this will take a while longer. I first have to 
figure out how to build an arm vm because I don't want to debug remotely 
via the autobuilds. ☺


Best,
Fabian

Bug#908459: theseus FTBFS with gcc 8

[Fabian Klötzl]

Hi Andreas,

On 10.09.18 13:59, Andreas Tille wrote:
> /usr/bin/gcc -O3 -ffast-math -fstrict-aliasing -funroll-loops 
> -fomit-frame-pointer -Wall -Werror -pedantic -std=c99 -Wno-unused-result 
> -Wformat-truncation=0 -pthread  -c logistic_dist.c
> logistic_dist.c: In function 'evallogisticML':
> logistic_dist.c:172:1: error: 'reciptmp.16' is used uninitialized in this 
> function [-Werror=uninitialized]
>  evallogisticML(const double *x, const int n,
>  ^~
> cc1: all warnings being treated as errors
> 

That is a compiler bug [1, 2]. Temporarily deactivating -ffast-math or
-Werror should help to move on, nonetheless.

Best,
Fabian

1: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897876

Bug#908459: [Debian-med-packaging] Bug#908459: theseus FTBFS with gcc 8

[Fabian Klötzl]

Thanks for reporting. There were plenty of string related errors. Fixed 
in git repo.

Bug#908039: figtree: Crashes with NoClassDefFoundError

[Fabian Klötzl]

On 05.09.2018 16:13, Andreas Tille wrote:


I commited the same change that helped for cgview.  Not tested yet but
setting tag pending to prevent others from spending time with this most
probably solved problem.



Tested and it works. Thank you very much. So apparently supplying a 
classpath via the commandline and the manifest are different things. 
Thanks for telling me, Java.


You would make me very happy, if you were to upload at your leisure.

Best,
Fabian

Bug#908039: figtree: Crashes with NoClassDefFoundError

[Fabian Klötzl]

On 05.09.2018 14:46, Andreas Tille wrote:

Probably same as #907559.


Yeah, that looks related.




Would you mind adding batik-constants.jar to CLASSPATH and try again?



As far as I understand java, I already tried that. One can give 
additional paths to the java executable via the -cp parameter. That is 
what I did with the command given, above. Trying the shell variable 
CLASSPATH does not lead to any improvement either.


That is whats bugging me. There is a XMLConstants in the 
batik-constants.jar. However, java just decides not to load it even 
though compilation was fine.


Best,
Fabian

Bug#887632: [Debian-med-packaging] Bug#887632: progressivemauve FTBFS with glibc 2.26

[Fabian Klötzl]

Hi all,

This bug is easily fixed by forcing mauve to use the native getopt. A
half-hearted fix is pushed. However, I have trouble removing the
unnecessary files from the orig tarball, because the pristine-tar branch
contains only a .delta and a .id file?

Any help would be appreciated.

Best
Fabian

Bug#859202: warning: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

[Fabian Klötzl]

Tags: patch

Hi,

Since version 3.6.2, there is a proper check for the availability of
readdir_r. So we could leave things as they are and wait for libc to
remove readdir_r at which point the warnings will also vanish. Or we
could force dcmtk to no longer use readdir_r by disabling the check. I
attached a patch for the latter.

Best,
Fabian
From: Fabian Klötzl 
Date: Fri, 22 Dec 2017 12:55:35 +
Subject: do not use readdir_r anymore

---
 CMake/GenerateDCMTKConfigure.cmake | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/CMake/GenerateDCMTKConfigure.cmake b/CMake/GenerateDCMTKConfigure.cmake
index dc1e920..924586a 100755
--- a/CMake/GenerateDCMTKConfigure.cmake
+++ b/CMake/GenerateDCMTKConfigure.cmake
@@ -616,7 +616,8 @@ ENDIF(WIN32 AND NOT CYGWIN)
   CHECK_FUNCTIONWITHHEADER_EXISTS("_fpclassf(0.0f)" "${HEADERS}" HAVE_PROTOTYPE__FPCLASSF)
   CHECK_FUNCTIONWITHHEADER_EXISTS("getgrnam_r((char*)0,(group*)0,(char*)0,0,(group**)0)" "${HEADERS}" HAVE_GETGRNAM_R)
   CHECK_FUNCTIONWITHHEADER_EXISTS("getpwnam_r((char*)0,(passwd*)0,(char*)0,0,(passwd**)0)" "${HEADERS}" HAVE_GETPWNAM_R)
-  CHECK_FUNCTIONWITHHEADER_EXISTS("readdir_r((DIR*)0,(dirent*)0,(dirent**)0)" "${HEADERS}" HAVE_READDIR_R)
+  #CHECK_FUNCTIONWITHHEADER_EXISTS("readdir_r((DIR*)0,(dirent*)0,(dirent**)0)" "${HEADERS}" HAVE_READDIR_R)
+  set(HAVE_READDIR_R 0)
   CHECK_FUNCTIONWITHHEADER_EXISTS(nanosleep "${HEADERS}" HAVE_PROTOTYPE_NANOSLEEP)
   CHECK_FUNCTIONWITHHEADER_EXISTS("::pw_gecos" "${HEADERS}" HAVE_PASSWD_GECOS)
 

Bug#780816: December: tophat

[Fabian Klötzl]

Hi Andreas,

On 04.12.2017 17:33, Andreas Tille wrote:
> On Mon, Dec 04, 2017 at 02:09:48PM +0100, Fabian Klötzl wrote:
>> I just pushed some changes to build tophat with our version of libbam.
>> Not sure if the previously mentioned issue in [1] is fixed; can't test,
> 
> Thanks to the test suite we now know that the issue is not solved yet:
> 
> $ sh run-unit-test 

That should be done with my recent commit; The new samtools version used
a different set of arguments.

That's an old one down for the advent calendar. ☺

Best
Fabian

Bug#780816: [Debian-med-packaging] Bug#780816: December: tophat

[Fabian Klötzl]

On 04.12.2017 17:33, Andreas Tille wrote:
> Thanks to the test suite we now know that the issue is not solved yet:
> 
> $ sh run-unit-test 
> 
> [2017-12-04 17:28:54] Beginning TopHat run (v2.1.1)
> ---
> [2017-12-04 17:28:54] Checking for Bowtie
>   Bowtie version:2.3.3.1
> Error locating program: samtools_0.1.18
> 
> 
> Unfortunately a grep for this explicite string has several hits.  I
> have no idea what might happen if we replace it by /usr/bin/samtools.

Ah, I took this as a build-only problem. Will look into it.

Fabian

Bug#780816: December: tophat

[Fabian Klötzl]

Hi all,

I just pushed some changes to build tophat with our version of libbam.
Not sure if the previously mentioned issue in [1] is fixed; can't test,
because my cowbuild just broke. :(

Best,
Fabian

[1]: https://lists.debian.org/debian-med/2014/10/msg4.html

Bug#752860: bug 752860 is forwarded to https://github.com/Teuniz/EDFbrowser/issues/38

[Fabian Klötzl]

forwarded 752860 https://github.com/Teuniz/EDFbrowser/issues/38
thanks

Bug#866646: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

[Fabian Klötzl]

Hi Andreas,

On 02.09.2017 14:54, Andreas Tille wrote:
> The htslib issue remains the same but I have no idea how to fix it.

The problem is that Allele.h defines a friend function called `json`
residing in global namespace. However, hts.h already defined a value of
an enum with the same name, thus the symbols clash. Basically, a

sed -i 's/json/to_json/' src/Allele.*

will fix the issue (also one call in Sample.cpp:267). However, in the
long term hts should stop exporting such generic names. C++ invented
namespaces and `enum class` exactly to avoid these problems. As htslib
is pure C, they should prefix their symbols, as everyone else does it.

Btw, I had to add -std=c++11 for a successful build.

Best,
Fabian

Bug#807486: ITP: INDELible -- A powerful and flexible simulator of biological evolution

[Fabian Klötzl]

Package: wnpp
Severity: wishlist
Owner: "Debian Med Team" 

* Package name: INDELible
  Version : 1.03
  Upstream Author : William Fletcher
* URL : http://abacus.gene.ucl.ac.uk/software/indelible/
* License : GPL
  Programming Lang: C++
  Description : A powerful and flexible simulator of biological evolution

INDELible is a new, portable, and flexible application for biological
sequence simulation that combines many features in the same place for
the first time. Using a length-dependent model of indel formation it
can simulate evolution of multi-partitioned nucleotide, amino-acid,
or codon data sets through the processes of insertion, deletion, and
substitution in continuous time.
..
Nucleotide simulations may use the general unrestricted model or the
general time reversible model and its derivatives, and amino-acid
simulations can be conducted using fifteen different empirical rate
matrices. Substitution rate heterogeneity can be modelled via the
continuous and discrete gamma distributions, with or without a proportion
of invariant sites. INDELible can also simulate under non-homogenous
and non-stationary conditions where evolutionary models are permitted
to change across a phylogeny.
..
Unique among indel simulation programs, INDELible offers the ability to
simulate using codon models that exhibit nonsynonymous/synonymous rate
ratio heterogeneity among sites and/or lineages.


This package will be maintained as part of the Debian Med packaging team.

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

[Fabian Klötzl]

Package: wnpp
Severity: wishlist
Owner: "Fabian Klötzl" <kloe...@evolbio.mpg.de>

* Package name: andi
  Version : 0.9.4
  Upstream Author : Fabian Klötzl <kloe...@evolbio.mpg.de>
* URL : https://github.com/EvolBioInf/andi
* License : GPL
  Programming Lang: C
  Description : Efficient Estimation of Evolutionary Distances

This is the andi program for estimating the evolutionary distance between 
closely related genomes. These distances can be used to rapidly infer 
phylogenies for big sets of genomes. Because andi does not compute full 
alignments, it is so efficient that it scales even up to thousands of bacterial 
genomes.

I am the upstream author and think this program is useful for the scientific 
community to rapidly infer phylogenies. The Debian package will be maintained 
as part of the Debian Med team.

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

[Fabian Klötzl]

On 05.10.2015 10:55, Andreas Tille wrote:
> I guess for non-German speakers andy might be a random 4 letter 
> combination and nobody will confuse it with the tyical nickname of 
> a German Andreas. :-)

Great, I'll stick with "andi" then and continue packaging.

Thanks for the quick advice
Fabian

Bug#794729: [u...@debian.org: Bug#794729: libdivsufsort-dev: missing dependency on libdivsufsort3]

[Fabian Klötzl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 06.08.2015 08:32, Andreas Tille wrote:
 Hi Fabian,
 
 I hope you read the mailing list 
 debian-med-packag...@lists.alioth.debian.org or at least have
 subscribed this package in the Debian Package Tracker.  If not
 please do either of one to receive the bug reports of your
 package.

Done.

 BTW, using d-shlibs would prevent such kind of problems.  You can
 find an example usage for instance here:
 
 git://anonscm.debian.org/debian-med/libmems.git

Ok, I will have a look at it.

Also, I included Thomasz in the conversation, as he is also interested
in packaging libdivsufsort and has already committed some patches
(which may or may not already fix the issue).

Fabian



 - Forwarded message from Aaron M. Ucko u...@debian.org
 -
 
 Date: Wed, 05 Aug 2015 21:46:25 -0400 From: Aaron M. Ucko
 u...@debian.org To: Debian Bug Tracking System
 sub...@bugs.debian.org Subject: Bug#794729: libdivsufsort-dev:
 missing dependency on libdivsufsort3 X-Debian-PR-Message: report
 794729 X-Debian-PR-Package: libdivsufsort-dev X-Debian-PR-Keywords:
  X-Debian-PR-Source: libdivsufsort
 
 Package: libdivsufsort-dev Version: 2.0.1-1 Severity: serious 
 Justification: Policy 8.4
 
 libdivsufsort-dev should depend on libdivsufsort3 to ensure that 
 libdivsufsort.so won't dangle.
 
 $ ls -l /usr/lib/libdivsufsort.* lrwxrwxrwx 1 root root 22 Jul 28
 10:59 /usr/lib/libdivsufsort.so - libdivsufsort.so.3.0.1 $ ls -lL
 /usr/lib/libdivsufsort.so ls: cannot access
 /usr/lib/libdivsufsort.so: No such file or directory
 
 Could you please fix that?  While you're at it, you might also 
 consider changing libdivsufsort3's section from science to libs, 
 since it's not of direct end-user interest.
 
 Thanks!
 
 -- System Information: Debian Release: stretch/sid APT prefers
 testing APT policy: (500, 'testing'), (500, 'stable'), (300,
 'unstable') Architecture: amd64 (x86_64) Foreign Architectures:
 i386
 
 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale:
 LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell:
 /bin/sh linked to /bin/dash Init: systemd (via
 /run/systemd/system)
 
 -- no debconf information
 
 ___ 
 Debian-med-packaging mailing list 
 debian-med-packag...@lists.alioth.debian.org 
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-pac
kaging

 
 
 - End forwarded message -
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVwwquAAoJEA/ahZpWA3bB/SoP/3GOaVTIicl3UgikReOOm9Qu
OvX4Upyv6oKqYHU707ecI9ChFDco9i1FVdIG61/rZhXtNkPb1lJIwp5YI/b5YcE4
wOcoPQZkQB3vgyGKHW473wr+cK4Cue7EzI1wwrs/t4OysE1H/ziAgbz1YDrskdeE
qjnT6QPDLT7EomlJJ+yfts2Pq0YAjDihTyACZ6bT0XiVG02lP9QrftU5YbilSZta
YneQqV3rbYqwbLeP9+/QWwm9VIoVkMspXPrCtH5Iwc4JZoUTKU1x1yWMGb+qj1nE
37aHA11wN9+ajw/w9SC09AlhauFqhQd4QyUaIDSpTWdmOk33KGP2zc/1BFPbKsAE
GfFvYMny8Leic65yRXlikj3VyPK3blD4dOtMpE62OSqe/X2kdfzwmuHav9hsRaPT
BVCQckbWVLl4GkzgRCMKWvFlfA/cXiyQEwGc3TTprF5uyVf/KoyKFDHDWuAtLv+P
13MD0GX1XbZzexh8wW9P3DvwZVrXr/azrcWk7lyv+5+QGeYnmsdQ5RpjIMPd2B3P
lHCdXzTyjmQEQBLAlb4tD2JysVr6v8UxdWBNLvTOB2vT9B7/gQs5+vf4cMPgljz+
PJXwCa82ZVswwfk8VkNU2R3FUlaNDAQJvJysRVOrnMyEo9n4nHP3YyZH/kZNHaHw
jIpTzwM5MfuB4I2brj2x
=UjNQ
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org