Bug#1023807: seqan-needle: /usr/bin/needle is already shipped by emboss

[Michael Crusoe]

control: forwarded -1 https://github.com/seqan/needle/issues/128

They are different programs, with different interfaces, alas.

So a workaround will be needed: probably we should rename the binary
`seqan-needle` and provide a directory with a regular `needle` that can be
added to a user's `PATH`.

On Wed, Nov 16, 2022 at 4:26 PM Andreas Tille  wrote:

> Hi Michael,
>
> Am Thu, Nov 10, 2022 at 01:34:32PM +0100 schrieb Andreas Beckmann:
> > Package: seqan-needle
> > Version: 1.0.1.0.0.git.3011926+ds-1
> > Severity: serious
> >
> > There is already a (unrelated?) /usr/bin/needle binary in the Debian
> > archive, provided by the emboss package.
>
> Do you think this "needle" (which is an unfortunate name in both
> packages) is a drop in replacement for needle inside emboss or
> is it something else?
>
> Kind regards
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe ; he/him
https://orcid.org/-0002-2961-9670
CWL Project Leader, Software Freedom Conservancy, Common Workflow Language
project
Promovendus, VU Amsterdam, Computer Systems & Bioinformatics
Project Leader Compute Platform in ELIXIR-NL, DTL Projects
ELIXIR-DE Communication Officer, Research Center Jülich

Bug#966270: seqan3 FTBFS with gcc 10

[Michael Crusoe]

Thanks, Andreas. I didn't commit the fix as it didn't work for me either.

Upstream is investigating the issue at
https://github.com/seqan/seqan3/issues/1993

--
Michael R. Crusoe

On Mon, Jul 27, 2020, 22:34 Andreas Tille  wrote:

> Hi Michael,
>
> On Mon, Jul 27, 2020 at 11:52:16AM +0200, Michael Crusoe wrote:
> > Reply from upstream
> >
> > https://gitter.im/seqan/Lobby?at=5f1e97ece9066820051dc93e
> >
> > > You can fix that reported error by specifying `cmake
> > -DCMAKE_CXX_FLAGS="-std=c++17 -fconcepts" <...>`
>
> I've commited a patch implementing this but it keeps on FTBFS.
>
> Any more ideas?
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>

Bug#966270: seqan3 FTBFS with gcc 10

[Michael Crusoe]

Reply from upstream

https://gitter.im/seqan/Lobby?at=5f1e97ece9066820051dc93e

> You can fix that reported error by specifying `cmake
-DCMAKE_CXX_FLAGS="-std=c++17 -fconcepts" <...>`

Bug#961382: hyphy: baseline violation on amd64/i386

[Michael Crusoe]

Sure, I'll add this to my queue

On Sun, May 31, 2020 at 7:54 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Sat, May 23, 2020 at 11:10:37PM +0300, Adrian Bunk wrote:
> > Source: hyphy
> > Version: 2.2.7+dfsg-1
> > Severity: serious
> >
> > https://buildd.debian.org/status/package.php?p=hyphy
> >
> > That package in stretch and buster builds with -msse3
> > for no apparent reason.
> >
> > The package in unstable/testing is built with
> > "-march=native -mtune=native -mavx  -mfma".
>
> do you think this package could be a target for simde in the near future
> or should we rather remove those options for the moment.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Bug#961779: obs-studio: FTBFS when using SIMDE

[Michael Crusoe]

Attached is a fix , also available at
https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/3 for
the convenience of the maintainers


On Fri, May 29, 2020 at 7:51 AM Adrian Bunk  wrote:

> Source: obs-studio
> Version: 25.0.8+dfsg1-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=obs-studio=sid
>
> ...
> -- No Native SSE2 SIMD Support - Using SIMDE
> ...
> CMake Error at libobs/CMakeLists.txt:482 (add_library):
>   Cannot find source file:
>
> util/simde/check.h
> ...
>


-- 
Michael R. Crusoe
commit 8bdc468f32c8da5edb8ac689fb08a18bfe86ae50
Author: Michael R. Crusoe 
Date:   Fri May 29 10:30:02 2020 +0200

remove last references to the bundled simde paths

diff --git a/debian/changelog b/debian/changelog
index d777c65..52e8e8c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+obs-studio (25.0.8+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/0009-use-libsimde-dev.patch: update to remove last
+references to the bundled simde paths (Closes: #961779)
+
+ -- Michael R. Crusoe   Fri, 29 May 2020 10:28:38 +0200
+
 obs-studio (25.0.8+dfsg1-1) unstable; urgency=medium
 
   [ Michael R. Crusoe ]
diff --git a/debian/patches/0009-use-libsimde-dev.patch b/debian/patches/0009-use-libsimde-dev.patch
index 4414e8b..1a27581 100644
--- a/debian/patches/0009-use-libsimde-dev.patch
+++ b/debian/patches/0009-use-libsimde-dev.patch
@@ -11,3 +11,19 @@ Subject: Use the simd everywhere headers from libsimde-dev
  
  #define __m128 simde__m128
  #define _mm_setzero_ps simde_mm_setzero_ps
+--- obs-studio.orig/libobs/CMakeLists.txt
 obs-studio/libobs/CMakeLists.txt
+@@ -186,13 +186,6 @@
+ 
+ 	if(NEEDS_SIMDE)
+ 		set(libobs_PLATFORM_HEADERS
+-			util/simde/check.h
+-			util/simde/hedley.h
+-			util/simde/mmx.h
+-			util/simde/simde-arch.h
+-			util/simde/simde-common.h
+-			util/simde/sse.h
+-			util/simde/sse2.h
+ 			util/threading-posix.h)
+ 	else()
+ 		set(libobs_PLATFORM_HEADERS

Bug#956828: This bug creates noise (Was: bedtools: fails to migrate to testing for too long: FTBFS on several archs)

[Michael Crusoe]

That's fine by me

--
Michael R. Crusoe

On Thu, May 7, 2020, 09:53 Andreas Tille  wrote:

> Hi Michael,
>
> this bug continuously creates noise on the testing removal front.  I'd
> really love to ask for removal the failing arches for the moment.
>
> What do you think?
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>

Bug#958091: wtdbg2: Baseline violation on amd64/i386 and FTBFS everywhere else

[Michael Crusoe]

This looks like something I can fix for all architectures and still respect
the baselines with SIMDe, yes.

On Sat, Apr 18, 2020 at 6:26 PM Andreas Tille  wrote:

> Hi Adrian,
>
> recently Michael Crusoe injected simde which should solve the SSE issue
> in a more elegant way.  Michael, would you comment on this whether we
> should apply this patch or rather use simde here?
>
> Kind regards
>
>   Andreas.
>
> On Sat, Apr 18, 2020 at 02:54:12PM +0300, Adrian Bunk wrote:
> > On Sat, Apr 18, 2020 at 02:44:54PM +0300, Adrian Bunk wrote:
> > > Source: wtdbg2
> > > Version: 2.5-1
> > > Severity: serious
> > > Tags: ftbfs patch
> > >
> > > https://buildd.debian.org/status/package.php?p=wtdbg2
> > >
> > > ...
> > > gcc: error: unrecognized command line option ‘-mpopcnt’
> > > gcc: error: unrecognized command line option ‘-msse4.2’
> > > make[1]: *** [Makefile:27: kbm2] Error 1
> > >
> > >
> > > Fix attached.
> >
> > Additionally the package should become
> >   Architecture: any-amd64
> > and the i386 package removed.
> >
> > It uses SSE (but not SSE4.2) unconditionally, so cannot be built
> > on i386 without baseline violation and in any case not anywhere else.
> >
> > cu
> > Adrian
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Bug#955403: bedtools ftbfs, failing tests on armel, armhf, i386, mipsel

[Michael Crusoe]

On Tue, Mar 31, 2020 at 1:19 PM Andreas Tille  wrote:

> Hi Michael,
>
> On Tue, Mar 31, 2020 at 11:12:45AM +0200, Matthias Klose wrote:
> > Package: src:bedtools
> > Version: 2.29.2+dfsg-3
> > Severity: serious
> > Tags: sid bullseye
> >
> > bedtools ftbfs, failing tests on armel, armhf, i386, mipsel. All 32bit
> archs?
> >
> > [...]
> > --
> >  Test Results
> > --
> > Tools passing:  bamtobed bamtofastq bed12tobed6 bedtobam bigchroms
> closest
> > cluster complement coverage expand fisher flank general genomecov
> getfasta
> > groupby intersect jaccard makewindows map merge multicov reldist shift
> sort
> > spacing split subtract
> > Tools failing:  negativecontrol sample slop
> > NB: the 'negativecontrol' test is supposed to fail. If it wasn't caught,
>
> I wonder whether the most straightforward fix is to drop 32bit archs?
>

I don't think dropping the 32bit archs is urgent right now.

Bug#951139: Can someone please have a look (Was: Bug#951139: toil fails it's autopkg tests)

[Michael Crusoe]

I've uploaded new packages of toil, cwltool, and python-schema-salad that
should fix this

Bug#945225: cppreference-doc: Fails to build from source: tries to install not generated qch file.

[Michael Crusoe]

On Wed, 27 Nov 2019 16:00:05 +0200 Povilas Kanapickas 
wrote:
> On 11/27/19 1:19 PM, Michael Crusoe wrote:
> > Maybe this patch from Ubuntu will help?
> >
http://patches.ubuntu.com/c/cppreference-doc/cppreference-doc_20170409-1.1ubuntu1.patch
>
> Hi,
>
> I will look into this bug ASAP. Couldn't do this so far due to lack of
> time due to my work.

I've tested the patch and it works in a pbuilder chroot. Here's a pull
request for it: https://github.com/p12tic/cppreference-doc_debian/pull/5

It would be great to get this fixed soon, the new seqan3 package build-deps
on cppreference-doc and I'd like to see that migrate to testing.

Thanks for all your work!

Bug#947463: bio-tradis: autopkgtest regression: Use of uninitialized value $total_uis (and lots of mv: cannot stat '/tmp/aut.....)

[Michael Crusoe]

Yes, I have a fix for that at
https://salsa.debian.org/med-team/bio-tradis/commit/8b810e2d293ce99653b899337da3aa8d413fae48

I need someone to either upload 1.4.5+dfsg2-1 or give me upload privileges:

gbp clone g...@salsa.debian.org:med-team/bio-tradis

or

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow bio-tradis


On Wed, Jan 8, 2020 at 9:15 PM Paul Gevers  wrote:

> Hi Micheal,
>
> On Fri, 3 Jan 2020 09:31:43 +0100 Michael Crusoe
>  wrote:
> > > With a recent upload of bio-tradis the autopkgtest of bio-tradis fails
> > > in testing when that autopkgtest is run with the binary packages of
> > > bio-tradis from unstable. It passes when run with only packages from
> > > testing.
> >
> > Why are we mixing testing scripts and binaries?
>
> We're not, at least not most of the time. What I meant was that we
> tested the autopkgtest of src:bio-tradis from unstable with the
> src:bio-tradis binaries from unstable in testing. The idea is to see
> what happens if the package in unstable would migrate.
>
> Paul
>
>

-- 
Michael R. Crusoe

Bug#945472: python-datrie: FTBFS with recent hypothesis version

[Michael Crusoe]

[whoops, forgot to CC everyone]

On Mon, 9 Dec 2019 12:14:02 +0100 Matthias Klose  wrote:
> On 09.12.19 11:46, Andreas Tille wrote:
> > Hi,
> >
> > I have upgraded python-datrie in Git[1] to latest upstream version
> > (0.8).  It shows the same issue - so I admit I have no better clue than
> > reporting the issue upstream which I'd rather leave to the official
> > Uploader of the package.
> >
> > BTW, we probably should expect build issues with Python 3.8[2]
>
>
https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch

I can confirm that this patch fixes the build and I've opened a merge
request at
https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1

Can someone with more permissions than I have accept that merge request and
upload the new package?

Thanks and happy new year!

Bug#947462: htslib: FTBFS on big-endian architectures

[Michael Crusoe]

Control: severity -1 important
Control: forwarded -1
https://github.com/samtools/htslib/issues/355#issuecomment-566058829

Dear Graham,

Thank you for your report. This issues is already known by upstream. So as
to not hold up multiple transitions, the s390x builds of htslib (and its
reverse-dependencies) have been removed from the archive as per
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948092

Therefore I'm lowing the severity of this issue to important so htslib and
the rest can all migrate to testing.

Hopefully upstream will find a solution soon.

Cheers,

-- 
Michael R. Crusoe

Bug#947964: gatb-core: hardcoded libcppunit-1.14-0 (and libhdf5-103) dependency instead of shlibs:Depends

[Michael Crusoe]

Hello,

I've fixed this at https://salsa.debian.org/med-team/gatb-core and it is
available for sponsoring by any Debian Developer.

gbp clone g...@salsa.debian.org:med-team/gatb-core

Or I can be given permission to upload the fixed package

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow gatb-core

Thanks for the report!

Bug#947463: bio-tradis: autopkgtest regression: Use of uninitialized value $total_uis (and lots of mv: cannot stat '/tmp/aut.....)

[Michael Crusoe]

Control: forwarded -1
https://github.com/sanger-pathogens/Bio-Tradis/issues/116


On Fri, 27 Dec 2019 11:42:05 +0100 Paul Gevers  wrote:
> Dear maintainers,
>
> With a recent upload of bio-tradis the autopkgtest of bio-tradis fails
> in testing when that autopkgtest is run with the binary packages of
> bio-tradis from unstable. It passes when run with only packages from
> testing.

Why are we mixing testing scripts and binaries?

> Additionally, looking at the failure mode in unstable, it seems some
> package (samtools?) made your (test?) dependencies non-installable in
> unstable. You probably need to fix that as well, or raise the issue with
> the samtools maintainer.

Yes, we did this. bio-tradis has a version parsing bug and it thinks that
samtools 1.10 is older than samtools 1.0, thus passing arguments to
samtools in the wrong form

This has been fixed in https://salsa.debian.org/med-team/bio-tradis but
there are other test issues, so I've asked upstream to investigate their
seriousness at https://github.com/sanger-pathogens/Bio-Tradis/issues/116

Bug#945472: python-datrie: FTBFS with recent hypothesis version

[Michael Crusoe]

On Mon, 9 Dec 2019 12:14:02 +0100 Matthias Klose  wrote:
> On 09.12.19 11:46, Andreas Tille wrote:
> > Hi,
> >
> > I have upgraded python-datrie in Git[1] to latest upstream version
> > (0.8).  It shows the same issue - so I admit I have no better clue than
> > reporting the issue upstream which I'd rather leave to the official
> > Uploader of the package.
> >
> > BTW, we probably should expect build issues with Python 3.8[2]
>
>
https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch

I can confirm that this patch fixes the build and I've opened a merge
request at
https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1

Can someone with more permissions than I have accept that merge request and
upload the new package?

Thanks and happy new year!

-- 
Michael R. Crusoe

Bug#947717: pbcopper FTBFS on all architectures except x32

[Michael Crusoe]

pbcopper's latest release has slipped in a code copy of libssw which uses
x86 SIMD intrinsics. I've pushed up a fix along the lines I made to libssw
to enable cross architecture compilation at
https://salsa.debian.org/med-team/pbcopper/commit/f9678ed29590b57fe30638eed3d6819577b4ace1
and it awaits sponsorship

Thanks,

On Sun, Dec 29, 2019 at 5:45 PM Andreas Tille  wrote:

> Control: tags -1 help
>
> Hi,
>
> it might be that the new upstream version is targeting only at amd64
> (and by chance builds on x32).  If there is a hint from porters how to
> fix the build the only idea I have is to restrict it to amd64 (and x32).
>
> Kind regards
>
>Andreas.
>
> On Sun, Dec 29, 2019 at 02:15:58PM +0100, Paul Gevers wrote:
> > Source: pbcopper
> > Version: 1.3.0+dfsg-1
> > Severity: serious
> > Justification: ftbfs
> > Tags: ftbfs sid bullseye
> >
> > Dear maintainer,
> >
> > Your package fails to build from source on all buildds except x32. Your
> > package is involved in the pbbam and htslib transitions and blocking
> > progress. Please have a look.
> >
> > Paul
> >
> > https://buildd.debian.org/status/package.php?p=pbcopper
> >
> > Tail of log for pbcopper on arm64:
> >
> > cc -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude -I../include
> > -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c11 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread
> > -MD -MQ 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o' -c
> ../src/align/cssw/ssw.c
> > ../src/align/cssw/ssw.c:38:10: fatal error: emmintrin.h: No such file or
> > directory
> >38 | #include 
> >   |  ^
> > compilation terminated.
> > [9/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o' -c
> > ../src/align/LinearAlignment.cpp
> > [10/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o' -c
> > ../src/align/BandedChainAlignment.cpp
> > [11/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o' -c
> > ../src/align/AffineAlignment.cpp
> > [12/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o' -c
> > ../src/align/SparseAlignment.cpp
> > [13/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 

Bug#946850: last-align ftbfs on non-x86 architectures

[Michael Crusoe]

I did look at the code, the AVX2 code is actually used, and I've made the
package more compatible for more architectures via the simde library at
https://salsa.debian.org/med-team/last-align/tree/simde

Since I don't have upload rights to last-align, I invite sponsorship of my
changes. Or someone can grant me upload right and I'll do it myself:

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow last-align

On Tue, Dec 17, 2019 at 1:24 PM Matthias Klose  wrote:

> did somebody even look at the code?  The AVX2 code is never used. Looks
> like an
> unguarded include.
>
>

-- 
Michael R. Crusoe

Bug#937145: nitime: Python2 removal in sid/bullseye

[Michael Crusoe]

A Python3 version of this package, also updated to the latest release, is
available at https://github.com/yarikoptic/nitime/pull/1 for sponsorship

Thanks

Bug#907489: Bug#938431: Fixing sambamba 0.8.6

[Michael Crusoe]

On Sun, Dec 15, 2019 at 3:18 AM Matthias Klumpp 
wrote:

> Am Do., 28. Nov. 2019 um 16:37 Uhr schrieb Pjotr Prins <
> pjotr2...@thebird.nl>:
> >
> > When 1.18 arrives I think it is a good time to get sambamba and biod
> > in Debian again.
>
> They always were in Debian, just not in a release because the packages
> were broken ^^
> The LDC transition went really well this time, I don't think it has
> ever been this smooth! No regressions this time, hurray!
>

Huzzah, indeed!


> There are also two brand new remaining issues: Apparently, for some
> reason, SONAME isn't set correctly for BioD, producing a Lintian error
> - not sure what happens there, and which component is to blame for
> that (Meson or LDC, most likely). Also, Sambamba doesn't *actually*
> build yet:
> ```
> roup -L=-rpath
> -L=/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
> slicereader.d:71: error: undefined reference to 'cram_to_bam'
> collect2: error: ld returned 1 exit status
> ```
> The cram_to_bam is private in htslib, so it shouldn't be used by other
> applications. Not sure whether htslib or Sambamba needs to be changed
> here, I simply worked around this issue for testing, and when this is
> resolved, Sambamba builds & works.
>

You'll be wanting libhts-private-dev, but libhts is broken in unstable
right now; sorry!


-- 
Michael R. Crusoe

Bug#925749: Bug#936888: liblemon: ftbfs with GCC-9

[Michael Crusoe]

A future Seqan3 release will need liblemon, so I'll look into it.

On Mon, Dec 2, 2019 at 12:36 PM Andreas Tille  wrote:

> Control: tags -1 help
>
> Hi,
>
> I wonder if there might be some remaining interest in liblemon.  The
> Debian Med team who introduced it into Debian does not need it any more
> for any of its packages.  It seems it us orphaned upstream.  I'd be
> willing to keep the package alive if someone might provide a patch for
>
>/<>/liblemon-1.3.1+dfsg/lemon/maps.h:193:36: error: non-type
> template parameters of class type only available with '-std=c++2a' or
> '-std=gnu++2a'
>
> as reported in bug #925749 but otherwise I'll ask ftpmaster for removal.
>
> Kind regards
>
>Andreas.
>
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Bug#921495: Bioperl 1.7.4 should not migrate to Buster

[Michael Crusoe]

Thanks Andreas Beckmann!

Would breaks+replaces libbio-perl-run-perl (<<1.7.3) make sense?

On Thu, Nov 28, 2019 at 12:00 AM Andreas Beckmann  wrote:

> Followup-For: Bug #921495
> Control: found -1 1.7.6-1
>
> libbio-perl-perl is missing proper
>   Breaks+Replaces: libbio-perl-run-perl (<< 1.7.3)
>
> There is a typoed (lib?io-perl-run-perl) and wrongly versioned
>   Breaks: libio-perl-run-perl (<= 1.7.3-1), roary (<= 3.12.0+dfsg-2)
> without corresponding Replaces. (Without the typo it would break the
> 'fixed' version in sid, too.)
> And (<< 1.7.3-1) would be wrong, too, since it hits a potential
> 1.7.3-1~bpo10+1
>
> Also the broken version of roary is likely wrong: you most likely want
>   roary (<< 3.13)
> (just think of a buster-pu upload of roary 3.12.0+dfsg-2+deb10u1).
>
>
> Andreas
>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

https://orcid.org/-0002-2961-9670

m...@commonwl.org
+1 480 627 9108

Bug#945225: cppreference-doc: Fails to build from source: tries to install not generated qch file.

[Michael Crusoe]

On Thu, 21 Nov 2019 10:35:24 -0300
=?utf-8?q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= <
lisan...@debian.org> wrote:
> Source: cppreference-doc
> Version: 20170409-1
> Severity: serious
> Justification: FTBFS
>
> Hi! Your package is currently trying to install a file no longer created
since Qt4 support was dropped.
> There seems to be Qt5 build dependencies, so maybe something else is
going on. If you need help please pin me.

Maybe this patch from Ubuntu will help?
http://patches.ubuntu.com/c/cppreference-doc/cppreference-doc_20170409-1.1ubuntu1.patch

Bug#944409: python-bx ftbfs on all 32bit architectures

[Michael Crusoe]

Control: forwarded -1 https://github.com/bxlab/bx-python/issues/48

On Sat, 9 Nov 2019 13:53:25 +0100 Matthias Klose  wrote:
> see https://buildd.debian.org/status/package.php?p=python-bx
> Exception: 2147483648 is larger than the maximum possible size
(2147483647)

Thanks, I had already reported this upstream.

Bug#855494: Broken with different error - I'm going to ask for removal of the package soon

[Michael Crusoe]

On Thu, 4 Apr 2019 07:21:25 +0200 Andreas Tille 
wrote:
> Hi,
>
> I stumbled again about this package:
>
> $ runPmv
> Run PMV from  /usr/lib/python2.7/dist-packages/Pmv
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/Pmv/__init__.py", line 378, in
runPmv
> from Pmv.moleculeViewer import MoleculeViewer
>   File "/usr/lib/python2.7/dist-packages/Pmv/moleculeViewer.py", line 19,
in 
> from DejaVu.Geom import Geom
>   File "/usr/lib/python2.7/dist-packages/DejaVu/__init__.py", line 201,
in 
> from Viewer import Viewer
>   File "/usr/lib/python2.7/dist-packages/DejaVu/Viewer.py", line 50, in

> from DejaVu.Camera import Camera
>   File "/usr/lib/python2.7/dist-packages/DejaVu/Camera.py", line 39, in

> import Image
> ImportError: No module named Image
> hit enter to continue

I got farther, but now the "dashboard" module won't load (no traceback).
The tests still fail spectacularly.

This is very old and non-free code. I suggest that all mglools* and
autodocktools* packages be removed.

Bug#925745: libgtextutils is marked for autoremoval from testing

[Michael Crusoe]

Maybe this isn't worth our time. libgtextutils is only needed for fastx
toolkit.

Both are officially abandoned by upstream since 2017.

>From the fastx toolkit readme:

https://github.com/agordon/fastx_toolkit/blob/master/README#L7

* FASTX TOOLKIT is unmaintained software. *
* No new features have been added since 2010. *
* *
* There are many better alternatives for low-level FASTQ/FASTA*
* manipulation. Use at your own risk.

Bug#942789: libbio-{db-{biofetch,gff,seqfeature},searchio-hmmer,tools-run-remoteblast}-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)

[Michael Crusoe]

All of those have been submitted, but were rejected due to my lack of
uploader privileges.

Any DD can allow me to upload the fixed packages via the following command


dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow ${srcpackage}


--
Michael R. Crusoe

On Wed, Oct 30, 2019, 19:09 Andreas Beckmann  wrote:

> Followup-For: Bug #942789
>
> There are some more related Breaks+Replaces needed:
>
>   Unpacking libbio-db-gff-perl (1.7.3-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbio-db-gff-perl_1.7.3-1_all.deb (--unpack):
>trying to overwrite '/usr/bin/bp_bulk_load_gff', which is also in
> package bioperl 1.7.2-3
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>
>   Preparing to unpack .../libbio-db-seqfeature-perl_1.7.3-1_all.deb ...
>   Unpacking libbio-db-seqfeature-perl (1.7.3-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbio-db-seqfeature-perl_1.7.3-1_all.deb
> (--unpack):
>trying to overwrite '/usr/bin/bp_seqfeature_delete', which is also in
> package bioperl 1.7.2-3
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>
> i.e. both libbio-db-gff-perl and libbio-db-seqfeature-perl need
> an additional Breaks+Replaces: bioperl (<< 1.7.3)
>
>
> Andreas
>

Bug#935086: insighttoolkit4 REMOVED from testing

[Michael Crusoe]

Attached is a patch to force gcc 8; so far it has gotten farther than the
previous failure for me (but my local build is still at 86%)



On Fri, Oct 4, 2019 at 7:57 AM Andreas Tille  wrote:

> Hi Steve and Gert,
>
> since I have no idea about itk I have ignored this issue.  Is there
> any chance to get this fixed soon to make sure this package and its
> rdepends will migrate back to testing soon?
>
> Kind regards
>
>   Andreas.
>
> On Fri, Oct 04, 2019 at 04:39:19AM +, Debian testing watch wrote:
> > FYI: The status of the insighttoolkit4 source package
> > in Debian's testing distribution has changed.
> >
> >   Previous version: 4.12.2-dfsg1-4
> >   Current version:  (not in testing)
> >   Hint: 
> > Bug #935086: insighttoolkit4: FTBFS with GCC-9: use of undeclared
> identifier '__builtin_is_constant_evaluated'
> >
> > The script that generates this mail tries to extract removal
> > reasons from comments in the britney hint files. Those comments
> > were not originally meant to be machine readable, so if the
> > reason for removing your package seems to be nonsense, it is
> > probably the reporting script that got confused. Please check the
> > actual hints file before you complain about meaningless removals.
> >
> > --
> > This email is automatically generated once a day.  As the installation of
> > new packages into testing happens multiple times a day you will receive
> > later changes on the next day.
> > See https://release.debian.org/testing-watch/ for more information.
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

https://orcid.org/-0002-2961-9670

m...@commonwl.org
+1 480 627 9108
commit 6947f1988913e72dd25345eb346e9e8386b88ef7
Author: Michael R. Crusoe 
Date:   Fri Oct 4 12:59:33 2019 +0200

Force the use of gcc/g++ 8

diff --git a/debian/changelog b/debian/changelog
index 7edae471..daf82bbd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+insighttoolkit4 (4.12.2-dfsg1-5) UNRELEASED; urgency=medium
+
+  * Force the use of gcc/g++ 8.
+
+ -- Michael R. Crusoe   Fri, 04 Oct 2019 12:20:29 +0200
+
 insighttoolkit4 (4.12.2-dfsg1-4) unstable; urgency=medium
 
   * d/rules: Remove build dir right after installation
diff --git a/debian/control b/debian/control
index cbc59fa8..932f5d3b 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,9 @@ Build-Depends: debhelper (>= 9),
 libnifti-dev, 
 	libhdf5-dev,
 	dh-python,	
-	python-all-dev
+	python-all-dev,
+g++-8,
+gcc-8
 #	libvtk6-dev -- only needed if we enable one of the following modules:
 # VtkGlue, LevelSetsv4Visualization
 Standards-Version: 4.1.4
diff --git a/debian/rules b/debian/rules
index f8c50710..f49eb4aa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -86,7 +86,7 @@ pkg_python = insighttoolkit$(VER_MAJOR)-python
 override_dh_auto_configure-indep:
 
 override_dh_auto_configure-arch: pre-build
-	dh_auto_configure -- $(CMAKE_FLAGS)
+	CC=gcc-8 CXX=g++-8 dh_auto_configure -- $(CMAKE_FLAGS)
 
 override_dh_auto_build-indep:
 

Bug#905206: Seems to crash in fortran lib

[Michael Crusoe]

Here is the crash with debug symbols (courtesy libc6-dbg libgfortran5-dbg
and a locally created profnet-snapfun-dbgym)

root@mrc-tux:/tmp# profnet_snapfun switch 385 55 10 46 100 PROFin.dat
PROFacc_tst.jct none

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:
#0  0x7faaf117e0ff in ???
at
/build/glibc-sPWrSm/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x7faaf1680018 in formatted_transfer_scalar_read
at ../../../src/libgfortran/io/transfer.c:1649
#2  0x7faaf1681803 in formatted_transfer
at ../../../src/libgfortran/io/transfer.c:2326
#3  0x55a7ca3a63c6 in rdjct_jct2_
at ./snapfun_dir/prof.f:1042
#4  0x55a7ca3a7c64 in rdjct_
at ./snapfun_dir/prof.f:876
#5  0x55a7ca3b0967 in prof
at ./snapfun_dir/prof.f:108
#6  0x55a7ca39f25e in main
at ./snapfun_dir/prof.f:179
Segmentation fault (core dumped)

On Thu, Oct 3, 2019 at 12:35 PM olivier sallou  wrote:

>
>
> Le jeu. 3 oct. 2019 à 12:08, Michael Crusoe  a
> écrit :
>
>> On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou 
>> wrote:
>> > Looking at core generated file and using gdb we see that it fails in
>> > fortran lib.
>> >
>> > Either program tries something wrong in a fortran updated lib version,
>> > either the fortran lib is itself buggy.
>> >
>> > I have no fortran knowledge to debug this however. And it lacks debug
>> info
>> > to find calling line in profnet.
>>
>> The debug symbols exists for non-amd64 archs:
>> https://packages.debian.org/sid/profnet-snapfun-dbgsym
>>
>
> Fun to see it in different arch but not amd64... Will give a try when
> possible.
>
>
>> So you can make your own debug symbols locally by rebuilding the package,
>> or someone could upload a new source package as it has been almost a year.
>> I made some cosmetic cleanups to the Debian packaging if that is a good
>> enough excuse (though snapfun still segfaults for me)
>>
>> >
>> > Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct
>> > none dbg
>> >
>> > Gdb result:
>> >
>> > Core was generated by `profnet_snapfun switch 385 55 10 46 100
>> PROFin.dat
>> > PROFacc_tst.jct none dbg'.
>>
>> --
>> Michael
>>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project
<http://www.commonwl.org/>
https://orcid.org/-0002-2961-9670
<https://impactstory.org/u/-0002-2961-9670>
m...@commonwl.org
+1 480 627 9108

Bug#905206: Seems to crash in fortran lib

[Michael Crusoe]

On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou  wrote:
> Looking at core generated file and using gdb we see that it fails in
> fortran lib.
>
> Either program tries something wrong in a fortran updated lib version,
> either the fortran lib is itself buggy.
>
> I have no fortran knowledge to debug this however. And it lacks debug info
> to find calling line in profnet.

The debug symbols exists for non-amd64 archs:
https://packages.debian.org/sid/profnet-snapfun-dbgsym

So you can make your own debug symbols locally by rebuilding the package,
or someone could upload a new source package as it has been almost a year.
I made some cosmetic cleanups to the Debian packaging if that is a good
enough excuse (though snapfun still segfaults for me)

>
> Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct
> none dbg
>
> Gdb result:
>
> Core was generated by `profnet_snapfun switch 385 55 10 46 100 PROFin.dat
> PROFacc_tst.jct none dbg'.

--
Michael

Bug#933527: snakemake: fails to install: SyntaxError: duplicate argument 'stay_on_remote' in function definition

[Michael Crusoe]

The current packaging builds and installs fine for me; shall I upload?

On Thu, Sep 5, 2019 at 4:51 PM Andreas Tille  wrote:

> Hi folks,
>
> this issue is urgent since if snakemake is not installable several of
> our packages where snakemake is in (Build-)Depends are broken.  Is
> anybody working on this?
>
> Kevin, you are listed as only Uploader.  Does your time limit permit you
> to work on this package?  Any other volunteers to add themselves to the
> list of Uploaders and care for this package?
>
> Kind regards
>
>  Andreas.
>
> On Mon, Sep 02, 2019 at 10:09:22AM +0200, Andreas Tille wrote:
> > Hi,
> >
> > On Wed, Jul 31, 2019 at 10:37:22AM +0200, Andreas Beckmann wrote:
> > > Version: 5.5.3-1
> > > Severity: serious
> > >
> > > during a test with piuparts I noticed your package failed to install.
> As
> > > per definition of the release team this makes the package too buggy for
> > > a release, thus the severity.
> > >
> > > >From the attached log (scroll to the bottom...):
> > >
> > >   Setting up snakemake (5.5.3-1) ...
> > > File "/usr/lib/python3/dist-packages/snakemake/remote/gfal.py",
> line 29
> > >   def __init__(self, *args, keep_local=False,
> stay_on_remote=False, is_default=False, stay_on_remote=False, retry=5,
> **kwargs):
> > >   ^
> > >   SyntaxError: duplicate argument 'stay_on_remote' in function
> definition
> > >
> >
> > I can confirm this issue.  Michael has commited a fix together with the
> > new version.  I've commited some more changes but the current state in
> > Git does not pass build time tests:
> >
> > ...
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _
> >
> > path = '/build/snakemake-5.5.4/tests/test_issue328', shouldfail = False
> > snakefile = '/build/snakemake-5.5.4/tests/test_issue328/Snakefile'
> > subpath = None, no_tmpdir = False, check_md5 = True, cores = 3
> > params = {'forcerun': ['split']}
> > results_dir =
> '/build/snakemake-5.5.4/tests/test_issue328/expected-results'
> > @py_assert1 = None, @py_assert3 = None, @py_assert6 = None
> >
> > def run(path,
> > shouldfail=False,
> > snakefile="Snakefile",
> > subpath=None,
> > no_tmpdir=False,
> > check_md5=True, cores=3, **params):
> > """
> > Test the Snakefile in path.
> > There must be a Snakefile in the path and a subdirectory named
> > expected-results.
> > """
> > results_dir = join(path, 'expected-results')
> > snakefile = join(path, snakefile)
> > assert os.path.exists(snakefile)
> > assert os.path.exists(results_dir) and os.path.isdir(
> > results_dir), '{} does not exist'.format(results_dir)
> > with tempfile.TemporaryDirectory(prefix="snakemake-") as tmpdir:
> > config = {}
> > # handle subworkflow
> > if subpath is not None:
> > # set up a working directory for the subworkflow and
> pass it in `config`
> > # for now, only one subworkflow is supported
> > assert os.path.exists(subpath) and os.path.isdir(
> > subpath), '{} does not exist'.format(subpath)
> > subworkdir = os.path.join(tmpdir, "subworkdir")
> > os.mkdir(subworkdir)
> > # copy files
> > for f in os.listdir(subpath):
> > copy(os.path.join(subpath, f), subworkdir)
> > config['subworkdir'] = subworkdir
> >
> > # copy files
> > for f in os.listdir(path):
> > print(f)
> > copy(os.path.join(path, f), tmpdir)
> >
> > # run snakemake
> > success = snakemake(snakefile,
> > cores=cores,
> > workdir=path if no_tmpdir else tmpdir,
> > stats="stats.txt",
> > config=config, **params)
> > if shouldfail:
> > assert not success, "expected error on execution"
> > else:
> > >   assert success, "expected successful execution"
> > E   AssertionError: expected successful execution
> > E   assert False
> >
> > tests/tests.py:124: AssertionError
> > - Captured stdout call
> -
> > in.txt
> > expected-results
> > Snakefile
> > - Captured stderr call
> -
> > PermissionError in line 4 of
> /build/snakemake-5.5.4/tests/test_issue328/Snakefile:
> > [Errno 13] Permission denied: '/nonexistent'
> >   File "/build/snakemake-5.5.4/tests/test_issue328/Snakefile", line 4,
> in 
> >   File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line
> 699, in __init__
> >   File "/usr/lib/python3/dist-packages/pytools/persistent_dict.py", line
> 441, in __init__
> >   File 

Bug#925700:

[Michael Crusoe]

I think this can be worked around by adding -Werror=stringop-truncation to
CXXFLAGS

-- 
Michael R. Crusoe

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Michael Crusoe]

Dear maintainers,

I have a fix for this bug (by copying in the relevant files from OpenJDK 9)
at https://salsa.debian.org/java-team/icedtea-web/merge_requests/5

It is a hack, but from my testing it works.

I hope this is helpful; I would like to see this package stay in Debian
Buster.

Cheers,

-- 
Michael R. Crusoe

Bug#921315: samtools: baseline violation on i386

[Michael Crusoe]

On Mon, 04 Feb 2019 08:43:08 +0200 Adrian Bunk  wrote:
> Source: samtools
> Version: 1.9-2
> Severity: serious
> Tags: patch
>
> SSE is not part of the i386 baseline, fix:
>
> --- debian/rules.old 2019-02-03 20:43:51.747130097 +
> +++ debian/rules 2019-02-03 20:44:04.383129977 +
> @@ -5,7 +5,7 @@
>
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>  ifneq (,$(filter $(DEB_HOST_ARCH),i386 kfreebsd-i386 hurd-i386))
> -  export DEB_CFLAGS_MAINT_APPEND=-msse -mfpmath=sse
> +  export DEB_CFLAGS_MAINT_APPEND=-ffloat-store

Very cool, I did not know about this option; thank you!

>  endif
>
>  %:
>
>

Bug#891994: epigrass: Depends on Qt4-only python-qwt5-qt4

[Michael Crusoe]

On Wed, 12 Sep 2018 22:40:38 +0200 "Gudjon I. Gudjonsson" 
wrote:
> Hi
>
> On Wednesday, 12 September 2018 21:01:16 CEST Flavio Coelho wrote:
> > This error seems to be due to missing "dbfread" package which is
available
> > on Debian as "python3-dbfread"
>
> You are right but epigrass is built with python2 on Debian but dbfread is
only built
> with python3 even if it is documented to work with python2.7.
>
> Does epigrass work with pyhton3?

https://pythonhosted.org/epigrass/install.html says no

> I tried to find the upstream sources for epigrass but the newest version
I could find is 2.4.5
> but version 2.4.7 is in Debian.

See https://pypi.org/project/epigrass/#files

Bug#914814: spades: FTBFS with jemalloc/experimental

[Michael Crusoe]

On Sat, 5 Jan 2019 11:05:38 +0200 Faidon Liambotis 
wrote:
> Therefore attached is a patch that addresses this using the je_rallocx
> API. It also deals with the deprecation of the stats.cactive statistic
> (as of jemalloc 4.0), using the stats.active instead.
>
> The patch should be 3.6.0-compatible as well and can go in anytime and
> ahead of a potential jemalloc transition. It is lightly tested (i.e.
> builds and runs the test suite).

Dear Faidon,

Thank you for your patch. I was unable to get the tests to complete
locally. Via an upload to experimental I confirmed that they do hang on the
build machines as well:
https://buildd.debian.org/status/fetch.php?pkg=spades=amd64=3.13.0%2Bdfsg-2%7E0jemalloc5=1547148149=0

I see a couple paths forward:

1. The patch is evolved so that the tests pass
2. jemalloc is rolled back from 5 to 3 as it breaks an established package
and the archive is starting to freeze for Buster
3. Same as 2, but a jemalloc5 package is introduced for packages that are
compatible.

My goal is that Spades is not dropped from Buster, but looking at the
schedule (and the length of the NEW queue) I am afraid that this may happen.

Obviously method 1 would be ideal, if it can be accomplished in time.

Bug#907624: What ffindex do we want to package

[Michael Crusoe]

I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent FTBFS
of hhsuite: https://bugs.debian.org/917495 as our packaged version is
missing the "ffsort_index" function.

The hh-suite github repo contains a submodule pointing at their fork of
ffindex at ~ 2017-06-01:
https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib  →
https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac

I suggest that we package it as part of hhsuite until another package needs
it.

hhsuite does provide  "*-Source*" packages that include ffindex, so we
wouldn't need a multi-source build.



În joi, 20 dec. 2018 la 11:59, Andreas Tille  a scris:

> Ping?
> Steffen, if you did not had a specific reason I assume it was by
> mistake and will replace the Segfaulting code by the original one.
> If I do not hear from you I assume you will agree.
> Kind regards, Andreas.
>
> On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> > Hi,
> >
> > after reading https://github.com/soedinglab/ffindex_soedinglab/issues/4
> > I came to the conclusion that we somehow picked the wrong fork of
> > ffindex.  For me it seems very probable that if we pick the old codebase
> > bug #907624 which was introduced when choosing this will vanish if we
> > revert to the previously packaged code base.  I have a local commit
> > which is doing this:
> >
> >
> > diff --git a/debian/changelog b/debian/changelog
> > index 6a26115..c409f4f 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,12 @@
> > +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED; urgency=medium
> > +
> > +  * The previous location on Github was an improperly choosen fork
> > +(see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> > +Here the version is now named "0.9.9.7+sog" (Saved On Github)
> > +to make it alphabethically later than the previous one.
> > +
> > + -- Andreas Tille   Wed, 19 Dec 2018 09:16:09 +0100
> > +
> >  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable;
> urgency=medium
> >
> >* Fix watch file (version should actually be +git20171201.74550c8 but
> > diff --git a/debian/watch b/debian/watch
> > index 91b4f38..b47f123 100644
> > --- a/debian/watch
> > +++ b/debian/watch
> > @@ -1,4 +1,4 @@
> >  version=4
> >
> > -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> > -https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> > +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> > +https://github.com/ahcm/ffindex.git HEAD
> >
> >
> >
> > Upstream at github.com/ahcm/ffindex was extremely quick to tag a
> > release and so it is at least active.
> >
> > Steffen, was your pick intentional or did you just stumbled by chance
> > over the other fork?  Are you OK with reverting to the old code?
> >
> > Kind regards
> >
> >   Andreas.
> >
> > PS: I reported the segfault issue to the according fork anyway
> > https://github.com/soedinglab/ffindex_soedinglab/issues/7
> >
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670

m...@commonwl.org
+1 480 627 9108 / +370 653 11125

Bug#905438: htslib: FTBFS on i386: 2 tests fail

[Michael Crusoe]

Andreas Tille, et al. I propose that we drop *-i386 for htslib, as it is
blocking a lot of packages.

On Sat, 04 Aug 2018 16:45:42 +0200 Andreas Beckmann  wrote:
> Source: htslib
> Version: 1.9-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
past)
>
> Hi,
>
> htslib/experimental FTBFS on i386:
>
https://buildd.debian.org/status/fetch.php?pkg=htslib=i386=1.9-1=1532825380=0
>
>
>   ./test_view -@4 -i reference=ce.fa range.cram CHROMOSOME_II:2980-2980
CHROMOSOME_IV:1500-1500 CHROMOSOME_II:2980-2980 CHROMOSOME_I:1000-1100 >
range.tmp
>   ./compare_sam.pl range.tmp range.out
>   ./test_view -@4 range.bam CHROMOSOME_II:2980-2980
CHROMOSOME_IV:1500-1500 CHROMOSOME_II:2980-2980 CHROMOSOME_I:1000-1100 >
range.tmp
>   ./compare_sam.pl range.tmp range.out
> test_vcf_api:
> /<>/test/test-vcf-api /tmp/JMIB5wVvT_/test-vcf-api.bcf
> bcf_get_format_float didn't produce the expected output.
>
> .. failed ...
>
> test_vcf_sweep:
> /<>/test/test-vcf-sweep /tmp/JMIB5wVvT_/test-vcf-api.bcf
>
> The outputs differ:
> /<>/test/test-vcf-sweep.out
> /<>/test/test-vcf-sweep.out.new
> .. failed ...
>
>
> Andreas
>
>

Bug#891752: Bug #891752 in cwltool marked as pending

[michael . crusoe]

Control: tag -1 pending

Hello,

Bug #891752 in cwltool reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/med-team/cwltool/commit/9c1bd76a8598898dea22f2f81d3b51860ad17148


Fix FTBFS. (Closes: #891752)



(this message was generated automatically)
-- 
Greetings

Bug#884548: seqan2: FTBFS: several tests fail

[Michael Crusoe]

On Sat, 16 Dec 2017 16:40:11 +0100 Andreas Beckmann  wrote:
> Source: seqan2
> Version: 2.3.2.000platform-issues8-6f85721+dfsg-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the
past)
>
> Hi,
>
> seqan2 FTBFS on most platforms with failing unittests:
>
> https://buildd.debian.org/status/package.php?p=seqan2=experimental
>
> on amd64:
>
> The following tests FAILED:
> 257 - test_demo_tutorial_journaled_set_solution_online_search_finder
(Failed)
> 382 - app_test_razers (Failed)
> 383 - app_test_razers3 (Failed)
> 384 - app_test_razers3_sequential (Failed)
>
>
> Andreas
>

Thank you Andreas,
This long series of experimental builds were produced in cooperation with
upstream to fix all these failing tests. AMD64 is fixed as
of 2.4.0~rc2+dfsg-1.

If someone wants to assist upstream with the remaining failing tests I
would invite them to present themselves at
https://github.com/seqan/seqan/issues/2245

Bug#882169: seqan2: FTBFS on indep-only build

[Michael Crusoe]

On Sun, 19 Nov 2017 21:26:34 +0100 Andreas Beckmann  wrote:
> Source: seqan2
> Version: 2.3.2.000platform-issues6-9cf5a69+dfsg-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the
past)
>
> Hi,
>
> seqan2 FTBFS during the indep-only build of the arch:all packages:
>
>
https://buildd.debian.org/status/fetch.php?pkg=seqan2=all=2.3.2.000platform-issues6-9cf5a69%2Bdfsg-3=1511019385=0
>
>debian/rules override_dh_installman
> make[1]: Entering directory
'/<>/seqan2-2.3.2.000platform-issues6-9cf5a69+dfsg'
> $DEB_BUILD_OPTIONS is [parallel=4]
> dh_link
> find -L
/<>/seqan2-2.3.2.000platform-issues6-9cf5a69+dfsg/debian/seqan-apps/usr/bin
-name . -o -type d -prune -o -type l -exec rm {} +
> find:
'/<>/seqan2-2.3.2.000platform-issues6-9cf5a69+dfsg/debian/seqan-apps/usr/bin':
No such file or directory
> debian/rules:107: recipe for target 'override_dh_installman' failed
> make[1]: *** [override_dh_installman] Error 1
>
>
> You probably want a override_dh_xxx-arch target there, but looking at the
> rules file I don't get what you are doing there. Why is dh_link called
> in override_dh_installman? And are the two find calls in in
> override_dh_link-arch and override_dh_installman not doing the same?
> And could be simplified to
>
> # delete broken symlinks - some apps are not built on all architectures
> find -L $(CURDIR)/debian/$(pkgapps)/usr/bin -type l -delete

Thanks!
>
> Then there is this comment:
> # we generate only those manpages where binaries are linked to /usr/bin
> Which somehow implies: the list of manpages included some arch:all doc
It does not
> package depends on the architecture where the package was built ???
> Shouldn't that rather be a superset?
>
>
> Andreas
>
> PS: using the full hash would only marginally increase the length of the
version number ;-)

This is to indicate that the commits come from
https://github.com/h-2/seqan/commits/fix/platform_issues
>
>

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

[Michael Crusoe]

I have a fix checked in as part of the 2.1-1 release, but it is blocked on
me uploading a python3 version of sphinx-guzzle

Pe 4 iul. 2017 23:12, "Sascha Steinbiss"  a scris:

> Hi all,
>
> >> I've applied this patch to get the build working now that Python 3.6 is
> a
> >> supported version in Ubuntu. I admit I don't entirely understand why it
> is
> >> necessary! Maybe you do? :)
> >>
> > Now that python3.6 is supported in Debian, khmer FTBFS:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=khmer;
> arch=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0
>
> Does anyone know more about this issue? Otherwise I'd be inclined to
> simply apply the patch in BTS to get the bug fixed...
>
> Kind regards
> Sascha
>

Bug#823508: Useless in Debian

[Michael Crusoe]

The khmer package latest upstream version now uses this theme. I would be
happy to take over maintenance.

On Thu, 5 May 2016 09:29:14 -0400 David =?iso-8859-1?Q?Pr=E9vot?= <
taf...@debian.org> wrote:
> Package: python-guzzle-sphinx-theme
> Version: 0.7.10-1
> Severity: serious
>
> [ Filled as an RC-bug by the maintainer to see the package auto-removed
>   from testing. ]
>
> I packaged python-guzzle-sphinx-theme in order to build php-guzzle-doc,
> but php-guzzle is going away, see #821698. There is a priori little
> point in shipping python-guzzle-sphinx-theme in any Debian stable
> release anymore.
>
> I intend to follow up with an RM request once php-guzzle is gone, unless
> anyone objects (but feel free to beat me to it).
>
> Regards
>
> David

Bug#852819: [Debian-med-packaging] Bug#852819: [mypy] Package is missing typeshed defs for python stdlib's

[Michael Crusoe]

forwarded 852819 https://github.com/python/mypy/issues/2769
tags 852819 confirmed

thanks

Hello Leonhard,

My apologies for not testing the package. Clearly a test needs to be added!

Bug#796020: Bug#796497: reconsidering the removal of ruby-hpricot

[Michael Crusoe]

On Sat, Sep 3, 2016 at 11:21 AM, Axel Beckert  wrote:

> Hi Antonio,
>
> Antonio Terceiro wrote:
> > On Tue, Aug 18, 2015 at 06:26:06PM +0200, Christian Hofstaedtler wrote:
> > - something else can replace ruby-ronn and we manage to make reverse
> >   (build) dependencies switch to it.
>
> Before starting to use ronn in an official release of
> unburden-home-dir, I tried different tools and was very unsatisfied:
>
> * go-md2man
> * pandoc
>
> There is also https://github.com/sunaku/md2man which is not yet
> packaged. Haven't tried that one yet since it requires a newer version
> of rubygems (2.5.2) than in Debian Unstable (2.5.1):
> https://github.com/sunaku/binman/issues/4



For the jaligner package we had a good experience with asciidoctor program

http://sources.debian.net/src/jaligner/1.0%2Bdfsg-4/debian/jaligner.adoc/
http://sources.debian.net/src/jaligner/1.0%2Bdfsg-4/debian/rules/#L16
http://sources.debian.net/src/jaligner/1.0%2Bdfsg-4/debian/control/#L12

Bug#803550: [Debian-med-packaging] Bug#803550: rsem: uninstallable on architectures without bowtie

[Michael Crusoe]

Thanks Sascha!
Pe 13 mai 2016 11:45 p.m., "Sascha Steinbiss"  a
scris:

> Hi all,
>
> I re-introduced the build dependency on bowtie and also did some minor
> housekeeping. Committed the fix in git.
>
> Cheers
> Sascha
>
> > On 19 Mar 2016, at 14:34, Andreas Beckmann  wrote:
> >
> > Package: rsem
> > Followup-For: Bug #803550
> >
> > Hi,
> >
> > the
> >  B-D: bowtie | bowtie2
> > was dropped in the last upload, causing uninstallable rsem packages
> > being produced for many architectures, again.
> >
> >
> > Andreas
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
>

Bug#822474: mira: FTBFS: error: 'accumulate' is not a member of 'std'

[Michael Crusoe]

Thank you Martin for your report. I've contacted upstream who has already
fixed the issue in a soon to be released new version.

Bug#817188: [Debian-med-packaging] Bug#817188: libbamtools-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/libbamtools-dev/html/functions_v.html

[Michael Crusoe]

Hello Andreas Beckmann,

Thank you for the report!

I've uploaded a new version though I was unable to replicate the piuparts
test to verify it. Any guidance on what command I should add to my
checklist would be appreciated.

On Tue, Mar 8, 2016 at 9:34 PM, Andreas Beckmann  wrote:

> Package: libbamtools-doc
> Version: 2.4.0+dfsg-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
>
> >From the attached log (scroll to the bottom...):
>
>   Selecting previously unselected package libbamtools-doc.
>   Preparing to unpack .../libbamtools-doc_2.4.0+dfsg-4_all.deb ...
>   Unpacking libbamtools-doc (2.4.0+dfsg-4) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/libbamtools-doc_2.4.0+dfsg-4_all.deb (--unpack):
>trying to overwrite
> '/usr/share/doc/libbamtools-dev/html/functions_v.html', which is also in
> package libbamtools-dev 2.4.0+dfsg-3+b1
>   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/var/cache/apt/archives/libbamtools-doc_2.4.0+dfsg-4_all.deb
>
>
> cheers,
>
> Andreas
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>

Bug#814875: [Debian-med-packaging] Bug#814875: libsis-jhdf5-java: FTBFS: jni.h:45:20: fatal error: jni_md.h: No such file or directory

[Michael Crusoe]

I've attached a patch
You'll need to make use of the `jvm_includes` variable that /usr/share/java/
java_defaults.mk defines.
On Wed, Feb 17, 2016 at 10:03 PM Andreas Tille  wrote:

> Sorry, but do you have a better hint for me since my attempt below did
> not change anything?
>
> Kind regards
>
>   Andreas.
>
> On Tue, Feb 16, 2016 at 01:42:29PM +0100, Andreas Tille wrote:
> > On Tue, Feb 16, 2016 at 11:44:20AM +0100, Emmanuel Bourg wrote:
> > > Le 16/02/2016 11:19, Andreas Tille a écrit :
> > >
> > > > I wonder whether this might be a missing symlink or so inside
> > > > openjdk-8-jdk?
> > >
> > > openjdk-8 changed some symlinks (see #760301). There is a make fragment
> > > available in /usr/share/java/java_defaults.mk defining the right
> include
> > > option for the current JDK.
> >
> > In case you wanted to provide a hint to do
> >
> > diff --git a/debian/rules b/debian/rules
> > index 86df809..57139da 100755
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -8,7 +8,7 @@ export
> TESTCLASSPATH=/usr/share/java/junit4.jar:/usr/share/java/testng.jar:/usr/
> >
> >  DPKG_EXPORT_BUILDFLAGS = 1
> >  include /usr/share/dpkg/buildflags.mk
> > -
> > +include /usr/share/java/java_defaults.mk
> >
> >  %:
> > dh $@ --with javahelper
> >
> >
> > I need to admit this does not change the situation.  Any more precise
> > hint?
> >
> > Kind regards
> >
> >   Andreas.
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
-- 
Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu

Common Workflow Language projectUniversity of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe


libsis-jhdf5-java.patch
Description: Binary data

Bug#779296: trimmomatic: directory of adapters missing from package

[Michael Crusoe]

On Thu, Feb 26, 2015 at 4:01 PM Andreas Tille andr...@an3as.eu wrote:

 Hi Michael,

 On Thu, Feb 26, 2015 at 08:40:22PM +, Michael Crusoe wrote:
  End users will expect adapter files to be installed and available. Please
  push into Jessie.

 OK.  I'll bump the severity of this bug to serious.

   Regarding the actual bug:  Do you have a clue to what directory in the
   installed package the adapters need to be moved.  It seems they are
   relative to the actual working dir and users are supposed to call the
   package out of the source tree which is not possible.  Any hint about
   the correct file system layout (if needed with patches) would be
   welcome.  I'd like to fix this as soon as possible.
  
 
  The path to the specific adapter file to use is set by the user via the
  ILLUMINACLIP option, so the files can go into any directory;
  /usr/share/docs/trimmomatic/examples or /usr/share/trimmomatic come to
 mind
 
  Their location should be highlighted in the manual pages and
  /usr/share/doc/README.Debian

 Since we are using a wrapper anyway I have set this inside the wrapper
 and thus do not see any need for README.Debian.  If you agree, please
 have a look at

https://people.debian.org/~tille/packages/trimmomatic/

 and please test the package whether I have interpreted your links
 correctly and the package can be uploaded as is.  If you could provide
 a test using the adapters this would be more than welcome.  Our goal
 should be tro get at least 80% of our packages autopkgtest-able.


Trimmomatic uses a nonstandard argument parser. ILLUMINACLIP is command
line option, not an environmental variable. Adding `export
ILLUMINACLIP=/usr/share/${ILLUMINACLIP}/adapters` to the wrapper script
will have no effect.

Here is an example command line

TrimmomaticSE --phred33 input.fq.gz output.fq.gz
ILLUMINACLIP:/usr/share/trimmomatic/TruSeq3-SE:2:30:10 LEADING:3 TRAILING:3
SLIDINGWINDOW:4:15 MINLEN:36

However no FASTQ format sequence files are provided in the package so I
can't write a test case.



 Kind regards

   Andreas.

 --
 http://fam-tille.de

Bug#779296: trimmomatic: directory of adapters missing from package

[Michael Crusoe]

On Thu, Feb 26, 2015 at 4:26 PM Andreas Tille andr...@an3as.eu wrote:

 Hi Michael,

 On Thu, Feb 26, 2015 at 09:16:07PM +, Michael Crusoe wrote:
   Since we are using a wrapper anyway I have set this inside the wrapper
   and thus do not see any need for README.Debian.  If you agree, please
   have a look at
  
  https://people.debian.org/~tille/packages/trimmomatic/
  
   and please test the package whether I have interpreted your links
   correctly and the package can be uploaded as is.  If you could provide
   a test using the adapters this would be more than welcome.  Our goal
   should be tro get at least 80% of our packages autopkgtest-able.
  
 
  Trimmomatic uses a nonstandard argument parser. ILLUMINACLIP is command
  line option, not an environmental variable. Adding `export
  ILLUMINACLIP=/usr/share/${ILLUMINACLIP}/adapters` to the wrapper script
  will have no effect.
 
  Here is an example command line
 
  TrimmomaticSE --phred33 input.fq.gz output.fq.gz
  ILLUMINACLIP:/usr/share/trimmomatic/TruSeq3-SE:2:30:10 LEADING:3
 TRAILING:3
  SLIDINGWINDOW:4:15 MINLEN:36

 OK.  Would you mind having a look at

https://people.debian.org/~tille/packages/trimmomatic/

 again?  Could you confirm that this package will close the bug and
 provides what users expect?


The command I gave you was from their webpage; alas it contains two small
errors: should be `-phred33` (single dash) and the adapter file needs to be
a correct path; the file extension is missing.

TrimmomaticSE -phred33 input.fq.gz output.fq.gz
ILLUMINACLIP:/usr/share/trimmomatic/TruSeq3-SE.fa:2:30:10
LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36

This runs successfully on my system with local data.


  However no FASTQ format sequence files are provided in the package so I
  can't write a test case.

 Well, we actually can add our own to debian/tests, can't we?


Right. I've tracked down the sequences they used in their paper but I can't
find license nor copyright information:
http://www.ebi.ac.uk/ena/data/view/SRX131047

While these files are rather large (113MiB) I could generate a subset for
testing purposes.



 Kind regards

 Andreas.

 --
 http://fam-tille.de

Bug#776881: closed by Charles Plessy ple...@debian.org (Bug#776881: fixed in bowtie 1.1.1-2)

[Michael Crusoe]

Thanks!

On Tue Feb 03 2015 at 4:21:08 AM Debian Bug Tracking System 
ow...@bugs.debian.org wrote:

 This is an automatic notification regarding your Bug report
 which was filed against the bowtie package:

 #776881: bowtie: '-debug' binaries break `bowtie-build`

 It has been closed by Charles Plessy ple...@debian.org.

 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Charles Plessy 
 ple...@debian.org by
 replying to this email.


 --
 776881: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776881
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems



 -- Forwarded message --
 From: Charles Plessy ple...@debian.org
 To: 776881-cl...@bugs.debian.org
 Cc:
 Date: Tue, 03 Feb 2015 03:19:00 +
 Subject: Bug#776881: fixed in bowtie 1.1.1-2
 Source: bowtie
 Source-Version: 1.1.1-2

 We believe that the bug you reported is fixed in the latest version of
 bowtie, which is due to be installed in the Debian FTP archive.

 A summary of the changes between this version and the previous one is
 attached.

 Thank you for reporting the bug, which will now be closed.  If you
 have further comments please address them to 776...@bugs.debian.org,
 and the maintainer will reopen the bug report if appropriate.

 Debian distribution maintenance software
 pp.
 Charles Plessy ple...@debian.org (supplier of updated bowtie package)

 (This message was generated automatically at their request; if you
 believe that there is a problem with it please contact the archive
 administrators by mailing ftpmas...@ftp-master.debian.org)


 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Format: 1.8
 Date: Tue, 03 Feb 2015 10:44:39 +0900
 Source: bowtie
 Binary: bowtie bowtie-examples
 Architecture: source amd64 all
 Version: 1.1.1-2
 Distribution: unstable
 Urgency: high
 Maintainer: Debian Med Packaging Team debian-med-packaging@lists.
 alioth.debian.org
 Changed-By: Charles Plessy ple...@debian.org
 Description:
  bowtie - Ultrafast memory-efficient short read aligner
  bowtie-examples - Examples for bowtie, the ultrafast memory-efficient
 short read al
 Closes: 776881
 Changes:
  bowtie (1.1.1-2) unstable; urgency=high
  .
* Team upload.
* Install missing commands.  Closes: #776881.
 Checksums-Sha1:
  07a28a0af4b78bbdf722ad8cc22dfd44e30420cd 2195 bowtie_1.1.1-2.dsc
  0e26e94bbc417620c580061503abd54397176224 13064
 bowtie_1.1.1-2.debian.tar.xz
  98a40fd8f05f9131be1e772558b0e3f08696fc46 1369362 bowtie_1.1.1-2_amd64.deb
  2b586fc20f2f2c8654b7fc48624e5083a82ce241 6307360
 bowtie-examples_1.1.1-2_all.deb
 Checksums-Sha256:
  44f5af7bdedfc5330c004b37f3c014ecbefe5d290a593eb9b6e4be8d639897ed 2195
 bowtie_1.1.1-2.dsc
  bc6ee5fa83667e6e042b750b88eedfa770276713892610df06f5a6cf79f81ea3 13064
 bowtie_1.1.1-2.debian.tar.xz
  bd176deb2caea1b3a7088724e6c308cb6b7b13aa36951be97de98109514be253 1369362
 bowtie_1.1.1-2_amd64.deb
  a77dd074cecef4dce1b1cb8aa021bafdeb7c90211c315f759a83ed4a8ccd255d 6307360
 bowtie-examples_1.1.1-2_all.deb
 Files:
  2210cbccf2207c970495ee228d0629ba 2195 science optional bowtie_1.1.1-2.dsc
  2a35d285f03c48d7619f40c198551720 13064 science optional
 bowtie_1.1.1-2.debian.tar.xz
  116b8244f07442931ce4aaff2f910f0c 1369362 science optional
 bowtie_1.1.1-2_amd64.deb
  1067dde15b877c86092bbee12bebef3c 6307360 science optional
 bowtie-examples_1.1.1-2_all.deb

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCgAGBQJU0DKhAAoJEMW9bI8ildUCbQ0QAJ147vfy4ZzeMyVFKkUpO2Kr
 1CFNpMzun1J3qRokRwcB+bkdrK7PptsBF5iBlWO5p5cWL5E8CUE2lpkKlyPMudzU
 qUEQSJy0/f+v+HDDfsqVO38vp4OHa9byaOkOFrx02idsxhkxLJO2jUfaLGvlaT3k
 1CtJOpWEcvE9FEIxXNWLcguBO/LKB4uRwijsIo15UT/r9XAl3lktWZxVcn3D/aOC
 dbNz773QDzzmucFgf9NHzaownqEz5SmwnFUZWPnIMbTR2sCGLpRUu9xl8vlz/i1/
 3Mt5O45xJbnGIi+FaXLJt6gjyap0eMHtFkG+arIynqkOg8KdkQWR3p0epx2QiZWz
 ynnljuDiTtINirqy2phOW3MSF3bDl9AvJonNk4x9OnbugyY5j2xW6Pm540lshLlr
 A3EUid+5bx+7HjWnRL8ghFTmtOj3JBeiQkzZ05NBU21PFJmBoVEIjX3qmhmkdZT+
 sVOBvm5mGATdM8wAM4PUWHHbJhibuHGQD0lGc2OOdKvkLmfMA+63TFsyugYG1Nuf
 QDtO/Sb4/GR+U8E85yMT/viylrGckB2RbR+1Wo3fOT0CzyD46WUfCG8/F2pXq631
 QwAuG6zggjxTmQryTxciKvJ+907UGDU4GKcrApG16ApRbw+dNQQLZB/TXyh5Ktii
 gnr5JgXiXaJjK8swvXvH
 =vGNd
 -END PGP SIGNATURE-


 -- Forwarded message --
 From: Michael R. Crusoe michael.cru...@gmail.com
 To: Debian Bug Tracking System sub...@bugs.debian.org
 Cc:
 Date: Mon, 02 Feb 2015 20:14:46 +
 Subject: bowtie: '-debug' binaries break `bowtie-build`
 Package: bowtie
 Version: 1.1.1-1
 Severity: grave
 Justification: renders package unusable


 Hello,

 Looks like the debug versions of 'bowtie-build-l' and 'bowtie-build-s' are
 present instead thus breaking the 'bowtie-build' wrapper making the package
 useless.



 -- System Information:
 Debian Release: 8.0
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)

 Kernel: Linux