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#944785: pufferfish now builds

[Michael Crusoe]

That's great news, please go for it!

--
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 FAIR Service Architecture in ELIXIR-NL, DTL Projects

On Thu, Mar 24, 2022, 18:38 Andrius Merkys  wrote:

> Hello,
>
> I have stumbled upon pufferfish in Salsa which used to FTBFS. I patched
> its build system a bit and now it builds successfully. If it is OK with
> you, I can continue finalizing the package.
>
> Best,
> Andrius
>

Bug#994892: evdi-dkms: fails to build for kernel 5.14.0-1

[Michael Crusoe]

I made myself a personal package of the head of upstream, which worked for
me.

It is based off of
https://github.com/DisplayLink/evdi/commit/b0b2c80eb63f9b858b71afa772135f434aea192a

https://people.debian.org/~crusoe/evdi/

Cheers,

On Fri, Oct 1, 2021 at 11:54 AM Hanno Stock 
wrote:

> Thanks, I attached the upstream bug report. It seems they don't have a
> patch yet - or at least not one that is halfway verified to be correct.
> I'll keep an eye on it and probably package a development version as soon
> as they have a fix in. In the past it took quite a while till they made a
> release out of it.
>
> Am Do, 30. Sep 2021, um 22:13, schrieb Justin Searle:
> > I can confirm I am having the same issue for the last few weeks, with
> > the same make.log error messages, resulting in no graphics upon boot.
> > Only solution I've found so far is to remove the 5.14 kernel.  All
> > other packages are fully updated to Sid.
>
> --
> To unsubscribe, send mail to 994892-unsubscr...@bugs.debian.org.
>

Bug#962717: q2-quality-control seems so uncover segfaults in bowtie2

[Michael Crusoe]

On Fri, 15 Jan 2021 at 11:22, Andreas Tille  wrote:

> On Fri, Jan 15, 2021 at 11:16:48AM +0100, Michael Crusoe wrote:
> > bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used,
> so
> > try with clearing out LD_PRELOAD first
>
> Ahhh, this makes perfectly sense and might explain why some autopkgtests
> are failing here in my cowbuilder setup while working properly
> otherwise.  How exactly can I "clearing out LD_PRELOAD" (I've never
> heard about this.)
>

unset LD_PRELOAD

or prepend "LD_PRELOAD= " prior to the affected commands

Good luck!

Bug#962717: q2-quality-control seems so uncover segfaults in bowtie2

[Michael Crusoe]

bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used, so
try with clearing out LD_PRELOAD first

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Michael Crusoe]

Dear Nilesh,

Thanks again for doing this.

Don't forget step 8 of https://wiki.debian.org/SIMDEverywhere#Approach ;
I've updated the sample scripts for multi-compiling x86 at different SIMD
levels

Please also update https://wiki.debian.org/SIMDEverywhere#Packages_Status &
https://wiki.debian.org/SIMDEverywhere#Candidate_packages as you add SIMDe
support to packages.

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Michael Crusoe]

On Mon, 7 Dec 2020 at 12:44, Nilesh Patra  wrote:

> Hi again,
>
> Since that didn't work, I manually added a typedef definition for it, and
> it works now on both am64 machine and arm64 porter box - with passing
> build-time tests.
> I've pushed to salsa.
>

Ah, good thing I used a different branch.


> I'd be really grateful if you could take a look at my changes and let me
> know if they look fine.
>

I'll leave comments on Salsa

Have you been sending PRs and otherwise forwarding your patches upstream?


>
> Also, another question: This package has a MPL-2.0 license and AFAIK, MPL
> is a restrictive Free software license, so does this qualify for adding in
> a "Built-Using" field?
>

Re-reading https://wiki.debian.org/SIMDEverywhere#Approach item 6, we see
"if the source package requires the full source code be available"

Does the MPL have this requirement?

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Michael Crusoe]

On Mon, 7 Dec 2020 at 11:49, Nilesh Patra  wrote:

> Hi Michael
>
> Thanks for the hint, I did this (not yet pushed):
>
> -#include 
> -
>  /* yes I know, the top of this file is quite ugly */
>
> +define SIMDE_ENABLE_NATIVE_ALIASES
> +#include 
>
> But I end up with the same error that I pasted earlier. Am I missing
> something in the hint?
> Please let me know.
>

This is because  upstream used a private symbol, __v4sf is not part of the
public interface for any x86 SIMD:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=v4sf

Looking at /usr/lib/gcc/x86_64-linux-gnu/9/include/xmmintrin.h we find the
following definition

/* Internal data types for implementing the intrinsics.  */
typedef float __v4sf __attribute__ ((__vector_size__ (16)));

But this doesn't look very portable.

Grepping through the SIMDe source for a portable version, we see that
__vector_size__ is used in simde/simde-common.h

#  if \
HEDLEY_GCC_VERSION_CHECK(4,8,0)
#define SIMDE_VECTOR(size) __attribute__((__vector_size__(size)))

So we keep looking for a usage of SIMDE_VECTOR involving a float, and in
simde/x86/sse.h we find

SIMDE_ALIGN_TO_16 simde_float32  f32 SIMDE_VECTOR(16) SIMDE_MAY_ALIAS;

so the portable thing to emulate the private definition is to do

typedef simde_float32 __v4sf SIMDE_VECTOR(16);

I've done so in a branch at
https://salsa.debian.org/med-team/scrappie/-/tree/mr-c-wip

FYI, you mentioned using the porterbox to test, you can also cross-build
for arm64 on an amd64 system using cowbuilder-dist.

We can check http://crossqa.debian.net/src/scrappie (The "cross" link on
the right side of https://tracker.debian.org/pkg/scrappie) to confirm that
cross-building has worked in the past.

cowbuilder-dist sid build scrappie_1.4.2-3.dsc --host-arch arm64

If you have qemu-user-static installed it can even run build-time tests via
"--no-auto-cross"

cowbuilder-dist sid build scrappie_1.4.2-3.dsc --host-arch arm64
--no-auto-cross

Bug#976479: [Request for help] Bug: #976479 scrappie: FTBFS: scrappie_matrix.h:5:14: fatal error: immintrin.h: No such file or directory

[Michael Crusoe]

Hey Nilesh,

No problem for me when you ask for help!

I suspect that
https://salsa.debian.org/med-team/scrappie/-/commit/a00691d910110a460ef5e61a6c74cc2cb0e1a626#5dc91bdd30262777c0556235b73413cd5865a144_0_31
is the issue
You should add the regular simde includes here, so that v4sf typedef works

define SIMDE_ENABLE_NATIVE_ALIASES#include 



On Mon, 7 Dec 2020 at 11:28, Nilesh Patra  wrote:

> Hi Michael and others,
>
> Scrappie looks like a candidate where we can use the simde trick.
> I tried doing a patch, and it works on amd64 machine, but not on an arm64
> porter box :/ (with issues with __v4sf)
>
> And I'm not sure how to fix this, and hence this is a humble request to
> please take a look - and any help/hints would be really great.
> My patch is pushed to salsa[1]
> I'm also sorry if these pings are somehow irritating, since I need help
> admittedly.
>
> [1]: https://salsa.debian.org/med-team/scrappie
>
> Pasting the (relevant part of) failing arm64 log:
>
> make[1]: Entering directory '/home/nilesh/scrappie/scrappie'
> mkdir build
> cd build && \
> cmake .. -DCMAKE_BUILD_TYPE=Release && \
> make
> -- The C compiler identification is GNU 10.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Performing Test HAS_OPENMP
> -- Performing Test HAS_OPENMP - Success
> -- Looking for hdf5.h
> -- Looking for hdf5.h - not found
> -- Looking for hdf5/serial/hdf5.h
> -- Looking for hdf5/serial/hdf5.h - found
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/nilesh/scrappie/scrappie/build
> make[2]: Entering directory '/home/nilesh/scrappie/scrappie/build'
> make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent
> make rule.
> make[3]: Entering directory '/home/nilesh/scrappie/scrappie/build'
> make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
> Scanning dependencies of target scrappie_objects
> make[4]: Leaving directory '/home/nilesh/scrappie/scrappie/build'
> make[4]: Entering directory '/home/nilesh/scrappie/scrappie/build'
> [  2%] Building C object CMakeFiles/scrappie_objects.dir/src/decode.c.o
> In file included from /usr/include/simde/x86/avx.h:27,
>  from
> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'log_ps':
> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:106:22: warning:
> dereferencing type-punned pointer will break strict-aliasing rules
> [-Wstrict-aliasing]
>   106 |   x = _mm_max_ps(x, *(v4sf*)_ps_min_norm_pos);  /* cut off
> denormalized stuff */
>   |  ^~~
> In file included from /usr/include/simde/x86/avx.h:27,
>  from
> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:110:22: warning:
> dereferencing type-punned pointer will break strict-aliasing rules
> [-Wstrict-aliasing]
>   110 |   x = _mm_and_ps(x, *(v4sf*)_ps_inv_mant_mask);
>   |  ^~~~
> In file included from /usr/include/simde/x86/sse3.h:30,
>  from /usr/include/simde/x86/ssse3.h:30,
>  from /usr/include/simde/x86/sse4.1.h:31,
>  from /usr/include/simde/x86/sse4.2.h:31,
>  from /usr/include/simde/x86/avx.h:31,
>  from
> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:113:31: warning:
> dereferencing type-punned pointer will break strict-aliasing rules
> [-Wstrict-aliasing]
>   113 |   emm0 = _mm_sub_epi32(emm0, *(v4si*)_pi32_0x7f);
>   |   ^
> In file included from /usr/include/simde/x86/sse3.h:30,
>  from /usr/include/simde/x86/ssse3.h:30,
>  from /usr/include/simde/x86/sse4.1.h:31,
>  from /usr/include/simde/x86/sse4.2.h:31,
>  from /usr/include/simde/x86/avx.h:31,
>  from
> /home/nilesh/scrappie/scrappie/src/scrappie_matrix.h:6,
>  from /home/nilesh/scrappie/scrappie/src/decode.h:5,
>  from /home/nilesh/scrappie/scrappie/src/decode.c:3:
> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h: In function 'exp_ps':
> /home/nilesh/scrappie/scrappie/src/sse_mathfun.h:228:31: warning:
> dereferencing type-punned pointer will break 

Bug#976572: bio-eagle: FTBFS: MemoryUtils.hpp:34:10: fatal error: xmmintrin.h: No such file or directory

[Michael Crusoe]

I pushed a commit that works around the _mm_malloc / xmmintrin.h issue ,
but there is usage of the rdtsc assembly operand that I don't have an arm64
analogue for.

On Sat, 5 Dec 2020 at 21:07, Andreas Tille  wrote:

> Hi Steve,
>
> On Sat, Dec 05, 2020 at 04:18:53PM +, Steve McIntyre wrote:
> >
> > xmmintrin.h is fundamentally tied to x86-only SIMD intrinsics. Either
> > the package doesn't support non-x86, or there's a bug and it's
> > mis-detecting which platform you're on.
>
> I guess the problem is that debian/rules should build Architecture: all
> properly and not try to build Architecture specific targets which are
>Architecture: any-amd64 any-i386
>
> I'll try to fix this on my arm64 machine later (if noone will beat me
> in this).
>
> Alternatively it could make use of simde.  Michael?
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project 
https://orcid.org/-0002-2961-9670
m...@commonwl.org

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

[Michael Crusoe]

Thank Berhard for this patch.

Also the autopkgtests do not yet patch with i386 (at least):

Testing bedtools shuffle:
shuffle.t1...1,10c1,10
< chr2 34697611 34698079 trf 789
< chr4 97373990 97374163 trf 346
< chr1 211569500 211569740 trf 434
< chr15 100895645 100895867 trf 273
< chr10 79193410 79193587 trf 187
< chr2 180138393 180138558 trf 199
< chr11 1280504 1280642 trf 242
< chr2 194322764 194322799 trf 70
< chr18 24454309 24454406 trf 79
< chr18 58907072 58907113 trf 73
---
> chr1 49390118 49390586 trf 789
> chr13 60419956 60420129 trf 346
> chr9 88507701 88507941 trf 434
> chr1 176220424 176220646 trf 273
> chr7 69225121 69225298 trf 187
> chr2 25938602 25938767 trf 199
> chr7 13377 133111315 trf 242
> chr3 5894626 5894661 trf 70
> chr7 144738233 144738330 trf 79
> chr9 28526037 28526078 trf 73
fail
shuffle.t2...1c1
< chr1 2158771 2159239 trf 789
---
> chr1 3126067 3126535 trf 789
3,4c3,4
< chr3 -219961 -219721 trf 434
< chr2 -515372 -515150 trf 273
---
> chr3 747335 747575 trf 434
> chr2 451924 452146 trf 273
10c10
< chr3 -422590 -422549 trf 73
---
> chr3 544706 544747 trf 73
12,13c12,13
< chr5 -6185 -6080 trf 149
< chr4 -914083 -914045 trf 58
---
> chr5 96 961216 trf 149
> chr4 53213 53251 trf 58
15,17c15,17
< chr1 548923 549393 trf 339
< chr1 95584 96012 trf 202
< chr1 1063033 1063076 trf 59
---
> chr1 1516219 1516689 trf 339
> chr1 1062880 1063308 trf 202
> chr1 2030329 2030372 trf 59
20c20
< chr1 1922714 1922891 trf 302
---
> chr1 2890010 2890187 trf 302
fail
shuffle.t3...1c1
< chr1 2158771 2159239 trf 789
---
> chr1 3126067 3126535 trf 789
3,4c3,4
< chr3 -219961 -219721 trf 434
< chr2 -515372 -515150 trf 273
---
> chr3 747335 747575 trf 434
> chr2 451924 452146 trf 273
10c10
< chr3 -422590 -422549 trf 73
---
> chr3 544706 544747 trf 73
12,13c12,13
< chr5 -6185 -6080 trf 149
< chr4 -914083 -914045 trf 58
---
> chr5 96 961216 trf 149
> chr4 53213 53251 trf 58
15,17c15,17
< chr1 548923 549393 trf 339
< chr1 95584 96012 trf 202
< chr1 1063033 1063076 trf 59
---
> chr1 1516219 1516689 trf 339
> chr1 1062880 1063308 trf 202
> chr1 2030329 2030372 trf 59
20c20
< chr1 1922714 1922891 trf 302
---
> chr1 2890010 2890187 trf 302
fail
shuffle.t4...ok
shuffle.t5...1,10c1,10
< chr2 34697611 34698079 trf 789
< chr4 97373990 97374163 trf 346
< chr1 211569500 211569740 trf 434
< chr1 211569500 211569740 trf 434
< chr5 12248678 12248716 trf 58
< chr1 10051107 10051141 trf 68
< chr3 63788079 63788115 trf 63
< chr1 56972561 56972612 trf 66
< chr1 56972561 56972612 trf 66
< chr5 27921185 27921353 trf 150
---
> chr1 49390118 49390586 trf 789
> chr1 49390118 49390586 trf 789
> chr1 176220424 176220646 trf 273
> chr1 176220424 176220646 trf 273
> chr2 25938602 25938767 trf 199
> chr3 5894626 5894661 trf 70
> chr2 57803306 57803344 trf 58
> chr4 13407024 13407058 trf 68
> chr3 18198257 18198308 trf 66
> chr1 71587801 71587968 trf 159
fail

On Wed, Oct 28, 2020 at 7:14 AM Bernhard Übelacker 
wrote:

> Dear Maintainer,
> I just tried to have a look at these failing tests "sample" and "slop",
> and found both are caused by having variables of type long.
> These have a sizeof of 4 on these 32 bit systems, while the usage
> suggests they are expected to be 8 bytes.
>
> Attached patch replaces the use of long by CHRPOS in the places where
> they cause the tests to fail. With it applied they succeed when
> building at i386 and armhf with current testing.
>
> Kind regards,
> Bernhard
>


-- 
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project 
https://orcid.org/-0002-2961-9670
m...@commonwl.org

Bug#968053: [Help] Re: seqan autopkg test failures triggered by gcc-defaults

[Michael Crusoe]

The newer range-v3 package has been accepted into the archive. If that
doesn't work, then we may need to switch back to the code copy.

--
Michael R. Crusoe

On Sun, Aug 16, 2020, 22:04 Aaron M. Ucko  wrote:

> Andreas Tille  writes:
>
> > make[4]: *** [test/view/CMakeFiles/view.chunk.dir/build.make:66:
> test/view/CMakeFiles/view.chunk.dir/chunk.cpp.o] Error 1
>
> I can reproduce this error (below), which parallel make somewhat buries,
> but don't have a suggested fix offhand, sorry.
>
> In file included from /.../include/range/v3/range/concepts.hpp:37,
>  from /.../include/range/v3/action/concepts.hpp:23,
>  from /.../include/range/v3/range/conversion.hpp:23,
>  from /.../test/view/chunk.cpp:16:
> /.../include/range/v3/iterator/concepts.hpp: In instantiation of
> ‘constexpr const bool
> ranges::forward_iterator int>, false>::outer_cursor> >’:
> [...]
> /.../include/range/v3/range/concepts.hpp:88:21:   required from ‘constexpr
> const bool ranges::input_range int> > >’
> /.../test/view/chunk.cpp:41:9:   required from here
> /.../include/range/v3/iterator/concepts.hpp:334:9: error: the value of
> ‘ranges::input_iterator int>, false>::outer_cursor> >’ is not usable in a constant expression
>   334 | input_iterator &&
>   | ^
> /.../include/range/v3/iterator/concepts.hpp:327:17: note:
> ‘ranges::input_iterator int>, false>::outer_cursor> >’ used in its own initializer
>   327 | CPP_concept input_iterator =
>   | ^~
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ |
> http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
>
>

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#820060: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Michael Crusoe]

I'm not seeing a successful build on big-endian. Of the offically supported
architectures, only s390x is big-endian and it's build is disabled.

--
Michael R. Crusoe

On Sat, Apr 11, 2020, 20:52 Liubov Chuprikova 
wrote:

> Hi Andreas,
>
> It looks like the upstream fixed the issue in some recent version, as
> according to the logs [1], the package builds now for big-endians as well.
> Do you agree, that we can close the bug as well as the issue?
>
> Best regards,
> Liubov
>
> [1] http://buildd.debian.org/python-biom-format
>

Bug#890061: galaxy-lib_19.5.1-1_amd64.changes REJECTED

[Michael Crusoe]

There is lots of other AFL 2.1 and AFL 3.0 code already in Debian,
including subversion

https://sources.debian.org/src/subversion/1.10.4-1/debian/copyright/?hl=55#L56

Full list:
https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+AFL

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
m...@commonwl.org

On Sat, Aug 3, 2019, 00:05 Thorsten Alteholz <
ftpmas...@ftp-master.debian.org> wrote:

>
> Hi Michael,
>
> according to [1] the AFL is not DFSG compatible. So I am afraid I have
> to reject your package.
>
>  Thorsten
>
> [1] https://lists.debian.org/debian-legal/2012/09/msg00082.html
>
>
>
>
> ===
>
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
>
>
___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

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#909743: Wrong upstream version check

[Michael Crusoe]

control: tags -1 patch

On Thu, 27 Sep 2018 16:18:16 +0200 Paul van der Vlis 
wrote:
> Package: qemu
> Version: 1:2.12+dfsg-3
>
> https://tracker.debian.org/pkg/qemu says:
> "A new upstream version is available: 3.0.0-rc4".
>
> But version 3.0 is already released last month. So there is something
> wrong with the script what checks the upstream version I guess.

I've submitted a patch for this at
https://salsa.debian.org/qemu-team/qemu/merge_requests/11

Bug#939537: ITP: vg -- tools for working with genome variation graphs

[Michael Crusoe]

I've merged and pushed all my changes, the build finishes and the regular +
autopkgtests pass.

TODO:
1. Send more patches upstream
2. Review the following patches and see if we can eliminate even more code
copies:
#use_packaged_vcflib  # 1.0.0+dfsg-1 is incompatible with the bundled htslib
#use_packaged_htslib  # waiting on
https://github.com/samtools/htslib/pull/904/files or similiar to be merged
& new htslib release
#use_packaged_vw # debian package is out of date, missing
array_parameters.h, and not in testing/stable
#use_packaged_sdsl # fails many tests, local copy is a newer snapshot than
Debian's
#use_packaged_protobuf ?

On Mon, Jan 13, 2020 at 11:20 AM Michael Crusoe 
wrote:

> I have 1.20.0 in my local repository, not yet pushed
>
> According to my build logs that did not succeed either.
>
> I'll update my local copy to 1.21 as well, and then I'll compare the patch
> modifications; pushing up the diff if that seems useful
>
> On Sun, Jan 12, 2020 at 11:43 AM Andreas Tille 
> wrote:
>
>> Hi Michael,
>>
>> On Fri, Sep 06, 2019 at 02:16:16PM +0900, Michael R. Crusoe wrote:
>> > * Package name: vg
>> >   Version : 1.18.0+ds
>>
>> by chance I stumbled upon that package.  I have no real interest in it
>> but I was wondering about the status of this ITP.  Upstream is meanwhile
>> at 1.21.0 and thus I did an upgrade (including adapting the many patched
>> to the build system.  I pushed my changed but I need to admit I've
>> broken the build.
>>
>> Before I investigate in fixing the build I wonder what might be your
>> plan with this package.
>>
>> Kind regards
>>
>>  Andreas.
>>
>> --
>> http://fam-tille.de
>>
>
>
> --
> Michael R. Crusoe
>


-- 
Michael R. Crusoe

Bug#939537: ITP: vg -- tools for working with genome variation graphs

[Michael Crusoe]

I have 1.20.0 in my local repository, not yet pushed

According to my build logs that did not succeed either.

I'll update my local copy to 1.21 as well, and then I'll compare the patch
modifications; pushing up the diff if that seems useful

On Sun, Jan 12, 2020 at 11:43 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Fri, Sep 06, 2019 at 02:16:16PM +0900, Michael R. Crusoe wrote:
> > * Package name: vg
> >   Version : 1.18.0+ds
>
> by chance I stumbled upon that package.  I have no real interest in it
> but I was wondering about the status of this ITP.  Upstream is meanwhile
> at 1.21.0 and thus I did an upgrade (including adapting the many patched
> to the build system.  I pushed my changed but I need to admit I've
> broken the build.
>
> Before I investigate in fixing the build I wonder what might be your
> plan with this package.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

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#922620: minimap2: FTBFS on pppc64el - unknown line option '-msse2';

[Michael Crusoe]

Sure, here it is
https://salsa.debian.org/med-team/minimap2/commit/0ff91329dcd01ec3c015688803afc0a3c3bbcda9


On Fri, Jan 10, 2020 at 4:52 PM Andreas Tille  wrote:

> Hi Michael,
>
> do you think you can solve this with your latest "SSE on all archs" trick?
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
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#938501: Please port smalt to Python3 (Was: Bug#938501: smalt: Python2 removal in sid/bullseye) [EXT]

[Michael Crusoe]

Dear all,

I have finished the Python3 conversion based off of Andreas's work:
https://salsa.debian.org/med-team/smalt/blob/master/debian/patches/2to3.patch

Andreas: feel free to sponsor the upload, or to give me upload permissions:
dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow smalt

Cheers,

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#947066: closed by michael.cru...@gmail.com (Michael R. Crusoe) (Bug#947066: fixed in htslib 1.10.2-1)

[Michael Crusoe]

On Sat, Dec 21, 2019 at 2:36 AM John Marshall 
wrote:

> On 20 Dec 2019, at 19:21, Debian Bug Tracking System <
> ow...@bugs.debian.org> wrote:
> > htslib (1.10.2-1) unstable; urgency=medium
> > .
> >   * New upstream version
> >   * debian/source/options: ignore changes to aclocal.m4 config.h.in
> configure
> >   * debian/control: remove libhts-private-dev (Closes: #947066)
>
> These changes have not yet been pushed to
> salsa.debian.org/med-team/htslib.git so it is difficult to verify the bug
> fix.
>

Oops, mea culpa. I've pushed them up.


>
> What is the purpose of the htslib-test subpackage? Its description says it
> contains the test data and scripts (from test/*), presumably so the
> upstream HTSlib test suite can be run against the library and tools
> installed from libhts3 and the subpackage currently named tabix. Why then
> does it also include HTSlib source code and an incomplete copy of HTSlib's
> build infrastructure?
>

I believe that was the easiest way to build and run the unit tests against
the installed libhts library. If you can find a simpler or smaller method
to build + run the unit tests (especially if any changes needed can be
incorporated upstream) then that would be very welcome!

Cheers,
-- 
Michael R. Crusoe

Bug#937606: Droping Python2 support for Biopython

[Michael Crusoe]

On Fri, Dec 20, 2019 at 12:51 PM Andreas Tille  wrote:

> On Fri, Dec 20, 2019 at 03:15:49PM +, Peter Cock wrote:
> > We (upstream) have just released Biopython 1.76 which should be
> > the final release to support Python 2 anyway:
>
> Cool.  Its dropped from the Debian package anyway so we just do
> a simple upgrade (if time permits ... any takers welcome).
>

python-biopython 1.76-1 is already pushed to salsa.debian.org and will be
uploaded to the archive once the current release has migrated to testing
:-)


-- 
Michael R. Crusoe

Bug#942447: Build bwa on ppc64el

[Michael Crusoe]

Control: fixed -1 0.7.17-4

On Wed, 16 Oct 2019 17:21:30 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard <
fre...@debian.org> wrote:
> Package: src:bwa
> Version: 0.7.17-3
>
> --
>
> Dear maintainer,
> with some basic changes I could enable bwa to built on ppc64el.
> Here is a merge request :
> https://salsa.debian.org/med-team/bwa/merge_requests/1

Dear Frédéric,

I've merged
https://salsa.debian.org/med-team/bwa/commit/36c81322c38c2db87e793a33bd2c1f7b7c58a71c
instead, which enable building on all architectures including ppc64el using
the SIMDe library: https://github.com/nemequ/simde

If you can help contribute AltiVec implementations for SSE2, SSE, or MMX
intrinsics to SIMDe then that would be very appreciated!

Thank you for your contribution,

-- 
Michael R. Crusoe

Bug#925499: bowtie2 arm64 (aarch64) package

[Michael Crusoe]

On Tue, 16 Apr 2019 11:02:36 +0200 Andreas Tille  wrote:
> Hi Jun,
>
> On Tue, Apr 16, 2019 at 09:17:59AM +0200, Jun Aruga wrote:
> > Thanks for showing the mentoring program. I will look at the MoM.
>
> :-)
>
> > > If you want to try packaging
> > >
> > >https://github.com/nemequ/simde.git
> > >
> > > in a MoM project feel free to let me know.  It seems you are qualified
> > > in terms of beeing easily able to test it with bowtie2 on arm64
> > > hardware.
> >
> > Andreas, I want to try the packaging of simde and bowtie2 to support
Arm64.

Oops, I forgot that you had claimed simde for packaging. I started a
package at https://salsa.debian.org/med-team/simde but I'm waiting to see
if upstream will make a versioned release:
https://github.com/nemequ/simde/issues/50

Already I have included simde as a code copy in many Debian packages,
including bowtie2. Thanks for the hint!

Once the simde package is done we can replace the code copies with a proper
build-depends on libsimde-dev

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#936551: C++ help for freebayes needed

[Michael Crusoe]

On Tue, Dec 17, 2019 at 5:13 PM Andreas Tille  wrote:

>
> > Usually, many C headers already have this, but apparently this one
> > hasn't. That may fix this and any other issues as well (I haven't
> > tested that though). If it doesn't, the compiler has to be told that
> > this instruction is okay to use in the particular header, or the C
> > code has to be fixed to accomodate for that.
>
> @Michael Crusoe: Do you have some contact to htslib authors?  May
> be its the best to forward this upstream.
>
>
I don't know the htslib people well, but I do know ekg, the freebayes
upstream. I'm engaging with him directly on GitHub; he does want to be a
better upstream and is appreciative of the Debain-Med team's efforts!


-- 
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#924128: prokka: creates world writable directory tree /var/lib/prokka/*

[Michael Crusoe]

On Sat, 9 Mar 2019 23:26:01 +0100 Andreas Tille  wrote:
> Control: severity -1 normal
>
> On Sat, Mar 09, 2019 at 08:24:46PM +0100, Andreas Beckmann wrote:
> >
> > during a test with piuparts I noticed your package creates a world
> > writable directory tree.
> >
> > >From the attached log (scroll to the bottom...):
> >
> > 0m49.9s ERROR: Command failed (status=1): ['chroot',
'/srv/piuparts/tmp/tmpLm6y7M',
'tmp/scripts/pre_remove_50_find_bad_permissions']
> >   ERROR: BAD PERMISSIONS
> >   drwxrwxrwx 3 root root  60 Mar  5 02:46 /var/lib/prokka
> >   drwxrwxrwx 4 root root  80 Mar  5 02:46 /var/lib/prokka/db
> >   drwxrwxrwx 2 root root 260 Mar  5 02:46 /var/lib/prokka/db/cm
> >   drwxrwxrwx 2 root root 580 Mar  5 02:46 /var/lib/prokka/db/genus
>
> I actually did some effort to make this dir world writable since users
> *need* to write and update these databases.  Do your have any suggestion
> for a better approach which enables every user to update a common
> database?  I was wondering whether I should create a group prokka and
> making the dir only writable for users belonging to this group.  But for
> a first packaging attempt testing user responses this seemed to be over
> enginering.  There is also some work done at upstream to enable a better
> solution for user writable databases.

Is making a "prokka" group to own this directory the only option?

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#944905: RM: jellyfish [arm64 mips64el ppc64el riscv64] -- ANAIS; Non-AMD64 not supported by upstream

[Michael Crusoe]

Thanks Graham, that is true. However it is extremely unlikely that anyone
is counting DNA substrings on non-AMD64 for the foreseeable future.

I believe the amd64 build failure was a fluke.

Being that upstream doesn't support non-AMD64 and that the Debian Med team
doesn't have many resources, I feel comfortable with my request.

On Sun, Nov 17, 2019 at 2:43 PM Graham Inggs  wrote:

> arm64, mips64el and riscv64 were all successful in the most recent
> rebuild, and amd64 failed.
>
> On Sun, 17 Nov 2019 at 15:33, Michael R. Crusoe
>  wrote:
> >
> > Package: ftp.debian.org
> > Severity: normal
> >
> > Thanks!
> >
>


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

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

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

Bug#942582: Build cnvkit on ppc64el

[Michael Crusoe]

Control: block -1 by 944041

On Fri, 18 Oct 2019 16:07:51 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard <
fre...@debian.org> wrote:
> Dear maintainer,
> is there any reason that cnvkit isn't built on ppc64el ?
> Looks like it builds out of the box.

Thanks, I didn't see that python-pysam was building on more architectures.
I'll add the other archs now.

Alas, this will be blocked by the conflict with the pandas 0.25.x package
in unstable :-(

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#944303: python-typing-extensions ftbfs with 3.8 as a supported Python3 version

[Michael Crusoe]

This is a bug in the libpython3.8-stdlib package. See my similar request to
fix libpython3.7-stdlib:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922285

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#758064: FTBFS with clang instead of gcc

[Michael Crusoe]

On Thu, 29 Dec 2016 06:59:50 +0100 Matthias Klose  wrote:
> Control: tags -1 + moreinfo
>
> please recheck with 0.168 available in experimental, and provide an
updated
> patch if necessary.

0.175-2 was tested on 2019-01-09 and now gets a configure time error of

checking for gcc with GNU99 support... no
configure: error: gcc with GNU99 support required

https://clang.debian.net/logs/2019-01-09-8svn/elfutils_0.175-2_unstable_clang.log

Bug#941805: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: hmmpgmd_ga] ... FAILED [crash!]

[Michael Crusoe]

Thanks Olivier. I don't have upload permissions for hmmer, so any DD is
welcome to update the changelog and upload my fixes.

Cheers,

--
Michael R. Crusoe

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#930240: ncbi-blast+ FTCBFS: configures for the build architecture

[Michael Crusoe]

On Sun, 09 Jun 2019 20:52:48 -0400 u...@debian.org (Aaron M. Ucko) wrote:
> Helmut Grohne  writes:
>
> > The attached patch fixes the issues above, but does not make ncbi-blast+
> > cross buildable. It seems to build a project_tree_builder with the host
> > compiler and then fails running it. I didn't figure out how to fix this.
>
> It's possible to point the build system at prebuilt native copies of
> project_tree_builder and another helper named datatool, so adding a
> preliminary configure+build round for these two tools should do the
> trick.  I'll take care of it when I get a chance.
>
> Thanks for the report and initial patch!

Dear Aaron,

Shall we apply the incremental patch, or should we wait for your full fix?

Cheers,

-- 
Michael R. Crusoe

Bug#932003: ITP: mypyc -- Mypy to Python C Extension Compile

[Michael Crusoe]

Thanks Andrej!

I recently learned that mypyc is being rolled into the main mypy package
upstream, so I'm holding off for the next release of mypy

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
m...@commonwl.org

On Wed, Sep 11, 2019, 21:40 Andrej Shadura 
wrote:

> Hi,
>
> On Sat, 13 Jul 2019 18:29:45 +0200 "Michael R. Crusoe"
>  wrote:
> > Package: wnpp
> > Severity: wishlist
> >
> > Subject: ITP: mypyc -- Mypy to Python C Extension Compile
> > Package: wnpp
> > Owner: Michael R. Crusoe 
> > Severity: wishlist
> >
> > * Package name: mypyc
> >   Version : 0.0.git.20190713T1002.833151a+ds1
> >   Upstream Author : Copyright: © 2017-2018 Jukka Lehtosalo and
> contributors
> > * URL : http://www.mypy-lang.org/
> > * License : Expat
> >   Programming Lang: C
> >   Description : Mypy to Python C Extension Compile
> >  *Mypyc is (mostly) not yet useful for general Python development.*
> >  .
> >  Mypyc is a compiler that compiles mypy-annotated, statically typed
> >  Python modules into CPython C extensions. Currently our primary focus
> >  is on making mypy faster through compilation -- the default mypy wheels
> >  are compiled with mypyc.  Compiled mypy is about 4x faster than
> >  without compilation.
> >  .
> >  Mypyc compiles what is essentially a Python language variant using
> "strict"
> >  semantics. This means (among some other things):
> >  .
> >   * Most type annotations are enforced at runtime (raising ``TypeError``
> on
> > mismatch)
> >  .
> >   * Classes are compiled into extension classes without ``__dict__``
> > (much, but not quite, like if they used ``__slots__``)
> >  .
> >   * Monkey patching doesn't work
> >  .
> >   * Instance attributes won't fall back to class attributes if undefined
> >  .
> >   * Metaclasses not supported
> >  .
> >   * Also there are still a bunch of bad bugs and unsupported features :)
> >  .
> >  Compiled modules can import arbitrary Python modules, and compiled
> modules
> >  can be used from other Python modules.  Typically mypyc is used to only
> >  compile modules that contain performance bottlenecks.
> >  .
> >  You can run compiled modules also as normal, interpreted Python
> >  modules, since mypyc targets valid Python code. This means that
> >  all Python developer tools and debuggers can be used.
> >  .
> >  This package provides the command-line interface.
> >
> > Remark: This package is maintained by Debian Med Packaging Team at
> >https://salsa.debian.org/med-team/mypy
>
> I’m going to review this; if you need a sponsor, I can do, just let me
> know.
>
> --
> Cheers,
>   Andrej
>

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#917421: cwltool: should probably recommend (not depend on) python3-prov

[Michael Crusoe]

On Thu, 27 Dec 2018 17:09:46 +0100 Jonas Smedegaard  wrote:
> Package: cwltool
> Version: 1.0.20181217162649+dfsg-4
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> If I understand the changelog entry for 1.0.20181217162649+dfsg-4 release
> correctly - i.e. that python3-prov is used in all but exotic cases, but
> this library does not technically break when omitted, then it is the
> perfect use of "Recommends:".
>
> Please consider if more appropriate to declaring the relationship as a
> recommendation rather than a definitive dependency.

Dear Jonas,

Thank you for your report. Alas not having python3-prov installed causes
too many errors as the provenance feature is currently woven throughout the
cwltool codebase:

tests/test_anon_types.py:3: in 
from cwltool.command_line_tool import CommandLineTool
cwltool/command_line_tool.py:38: in 
from .docker import DockerCommandLineJob
cwltool/docker.py:22: in 
from .job import ContainerCommandLineJob
cwltool/job.py:24: in 
from prov.model import PROV
E   ModuleNotFoundError: No module named 'prov'

Is there a particular reason you'd like to avoid this dependency?

Cheers,

-- 
Michael R. Crusoe

Bug#935579: cwltool: bad upstream test testing udocker, not cwltool

[Michael Crusoe]

Hey Steve,

I think this is fixed in my recent upload, let me know if it works for you.

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
m...@commonwl.org

On Sat, Aug 24, 2019, 09:24 Steve Langasek 
wrote:

> Package: cwltool
> Version: 1.0.20181217162649+dfsg-10
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
>
> Hi Michael,
>
> Since the introduction of cwltool 1.0.20181217162649+dfsg-1, the cwltool
> autopkgtests in Ubuntu have been failing on all architectures except for
> amd64.  The reason for this is that upstream has added tests for the
> handling of udocker, a third-party tool which is downloaded from the
> Internet during the test and which is not properly ported to non-x86
> architectures.
>
> I don't think this is a useful test to have as an autopkgtest generally,
> because it's dependent on the behavior of a third-party resource downloaded
> from the network whose behavior may change over time (at minimum, the
> resource might go away).  And since it has caused autopkgtests to regress
> on
> all non-amd64 architectures in Ubuntu, I've uploaded the attached patch to
> Ubuntu to suppress the udocker tests.
>
> Unfortunately, in the meantime it appears that some other change has caused
> cwltool to FTBFS in both Debian and Ubuntu.  But in any case, please
> consider including this change in your next upload.
>
> Thanks,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Bug#934629: ITP: seqan3 -- C++ library for the analysis of biological sequences (development)

[Michael Crusoe]

Correction: This package is maintained by Debian Med Packaging Team at
https://salsa.debian.org/med-team/seqan3

Bug#925700:

[Michael Crusoe]

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

-- 
Michael R. Crusoe

Bug#930928: mypy: New upstream release

[Michael Crusoe]

How about we start on the latest version via an upload to experimentsl?

I must admit  that I don't have a plan for the new compiled versions of
mypy yet.

--
Michael R. Crusoe

On Sun, Jun 23, 2019, 01:21 Salvo Tomaselli  wrote:

> Hello,
>
> I understand, but at this stage, with release almost there, uploading
> to unstable would not be so bad I guess.
>
> Anyway my problem is that localslackirc uses github and there it pulls
> mypy from pip (so latest version) but in debian of course it builds
> with the package, so having the mismatch is making development a bit
> difficult for me, because the build fails on github but works on my
> local machine, so adding a "ignore" comment would make it fail on my
> machine and pass on github :D
>
> Anyway, I guess I can wait some more weeks.
>
> Best
>
> Il giorno sab 22 giu 2019 alle ore 20:33 Michael Crusoe
>  ha scritto:
> >
> > Hello,
> >
> > During a freeze I don't upload new versions to unstable.
> >
> > On Sat, Jun 22, 2019 at 6:51 PM Salvo Tomaselli 
> wrote:
> >>
> >> Package: mypy
> >> Version: 0.670-2
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> there is a new upstream release for this.
> >>
> >> Could you upgrade?
> >>
> >> If needed, I can help.
> >>
> >> Best
> >>
> >> -- System Information:
> >> Debian Release: 10.0
> >>   APT prefers unstable
> >>   APT policy: (500, 'unstable'), (500, 'testing')
> >> Architecture: amd64 (x86_64)
> >> Foreign Architectures: i386
> >>
> >> Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT)
> >> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE= (charmap=UTF-8)
> >> Shell: /bin/sh linked to /bin/dash
> >> Init: systemd (via /run/systemd/system)
> >>
> >> Versions of packages mypy depends on:
> >> ii  python3   3.7.3-1
> >> ii  python3-mypy  0.670-2
> >>
> >> mypy recommends no packages.
> >>
> >> Versions of packages mypy suggests:
> >> pn  mypy-doc  
> >>
> >> -- no debconf information
> >>
> >
> >
> > --
> > Michael R. Crusoe
> > Co-founder & Lead, Common Workflow Language project
> > https://orcid.org/-0002-2961-9670
> > m...@commonwl.org
> > +1 480 627 9108
>
>
>
> --
> Salvo Tomaselli
>
> "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
> senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
> -- Galileo Galilei
>
> http://ltworf.github.io/ltworf/
>

Bug#930928: mypy: New upstream release

[Michael Crusoe]

Hello,

During a freeze I don't upload new versions to unstable.

On Sat, Jun 22, 2019 at 6:51 PM Salvo Tomaselli  wrote:

> Package: mypy
> Version: 0.670-2
> Severity: normal
>
> Dear Maintainer,
>
> there is a new upstream release for this.
>
> Could you upgrade?
>
> If needed, I can help.
>
> Best
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mypy depends on:
> ii  python3   3.7.3-1
> ii  python3-mypy  0.670-2
>
> mypy recommends no packages.
>
> Versions of packages mypy suggests:
> pn  mypy-doc  
>
> -- no debconf information
>
>

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

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

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

Bug#928333: RM: htslib [i386 hurd-i386 kfreebsd-i386] -- ANAIS; ROM; *i386 no longer supported upstream

[Michael Crusoe]

Package: ftp.debian.org
Severity: normal
Owner: Debian Med team 

Hello, this request is a repeat of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914991

The *i386 packages have somehow crept back in for all the
reverse-(build-)deps of htslib binary packages.

Could the removal of *i386 binary packages that (build-)depend on any
of the htslib binary packages be repeated?

Thanks. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927850

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
m...@commonwl.org

Bug#927850: unblock: htslib/1.9-11

[Michael Crusoe]

Hey Andreas,

I think a helpful ftpmaster person converted my simple request into "doing
the right thing" about the reverse-(build-)deps as well.  I will repeat the
request with references to both this bug and that previous request.

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
m...@commonwl.org

On Wed, May 1, 2019, 06:52 Andreas Tille  wrote:

> Hi Michael,
>
> it seems you found a clever way to ask ftpmaster for removal of a set of
> packages for i386 architectures in #914991.  Would you mind to do this
> again / update the current versions of those packages.  For the next five
> days I'm occupied with non-Debian real life and it would be great if this
> issue would be settled.
>
> Kind regards
>
> Andreas.
>
> On Tue, Apr 30, 2019 at 09:56:57PM +0200, Paul Gevers wrote:
> > Hi,
> >
> > On 30-04-2019 21:39, Andreas Tille wrote:
> > > I have no idea why the packages re-appeared after #914991 was closed.
> >
> > Probably newer versions got uploaded to unstable, which built on all
> > releases where they could.
> >
> > > Is there any way to easily ask ftpmaster to redo the removals that
> where
> > > done before?
> >
> > I don't, sorry.
> >
> > Paul
> >
>
>
>
>
> --
> http://fam-tille.de
>

Bug#927850: unblock: htslib/1.9-11

[Michael Crusoe]

Dear Release Team,

Please consider this unblock request, it is a minimal change and prevents
nearly 70 packages from being removed from testing.

Thanks!

Bug#925499: bowtie2 arm64 (aarch64) package

[Michael Crusoe]

Hello Jun,

Thank you for your report and for your work to improve the architecture
support on several projects!

I think this is a good idea for after the "buster" release. Could you
prepare a pull request at https://salsa.debian.org/med-team/bowtie2 and we
can merge it then?

Alternatively we could do a build in the experimental suite, and then you
could test building all the packages that have a build-time or run-time
dependency on bowtie2 under aarch64. I have a feeling that we may need to
adjust some (many?) other packages which is why I advocate for this to wait
for the next release cycle. If it goes well, then we could backport the
adjustments (or propose for the "buster.1" point release).

$ apt-cache rdepends bowtie2
bowtie2
Reverse Depends:
  ariba
  unicycler
  trinityrnaseq
 |tophat
  srst2
  rsem
  python-pbalign
  pbalign
  paleomix
  metaphlan2-data
  metaphlan2
  giira
  gasic

Cheers,

Bug#909715: glam2: Please provide autopkgtest

[Michael Crusoe]

Dear Saira,

A pull request on salsa would be great! We can also add you to the team as
well; if you request membership through the salsa interface.

Cheers and thanks,

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
https://impactstory.org/u/-0002-2961-9670
m...@commonwl.org

On Fri, Mar 15, 2019, 16:30 Saira Hussain  wrote:

> On Thu, 27 Sep 2018 08:08:54 +0200 Andreas Tille  wrote:
> > Package: glam2
> > Severity: minor
> > Tags: newcomer
> >
> > Please provide autopkgtest for this package.
> Hi, I am Saira and I want to apply for the current Outreachy.
>
> I just wrote autopkgtest by adding the folder including some basic tests.
> I would like to submit this file. What is the best way?
> Should I send a patch here or can you add me to the salsa-debian-med?
>
> Best
> S.H.
> >
> > -- System Information:
> > Debian Release: 9.5
> > APT prefers stable-updates
> > APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages glam2 depends on:
> > ii libc6 2.24-11+deb9u3
> > pn libfftw3-double3 
> >
> > glam2 recommends no packages.
> >
> > glam2 suggests no packages.
> >
> >
>
>
>

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#923637: ffindex FTCBFS: uses mpicc

[Michael Crusoe]

Thank you Helmut for your testing and your patch.

I've applied it at
https://salsa.debian.org/med-team/ffindex/commit/5a7eeb53972e97ee264eb67d9df2f6c7089e4e14

However I'm just a Debian Maintainer, so I'll need a DD to grant me upload
permission:

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow ffindex

În dum., 3 mar. 2019 la 10:36, Helmut Grohne  a scris:

> Source: ffindex
> Version: 0.9.9.9-1
> Tags: upstream patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> ffindex fails to cross build from source, because it uses mpicc. mpicc
> is unfixable in terms of cross building, which is why it is being moved
> to pkg-config upstream. Rather than wrap your build in mpicc, you can
> compute the relevant flags using pkg-config just like any other library.
> The attached patch implements that and makes ffindex cross buildable
> once you add pkg-config to Build-Depends. Please consider applying it.
>
> Helmut
>


-- 
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#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#910742: fixed in setuptools-scm-git-archive 1.0-2

[Michael Crusoe]

Hello,

I'm still not able to use this package's minimal .egg-info

A fix is provided at
https://salsa.debian.org/python-team/modules/setuptools-scm-git-archive/merge_requests/1

Here is an example for a new package I'm making, sourmash.

 debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py clean

Note: Bypassing https://pypi.org/simple/setuptools_scm_git_archive/
(disallowed host; see http://bit.ly/2hrImnY for details).


Note: Bypassing https://pypi.org/simple/setuptools-scm-git-archive/
(disallowed host; see http://bit.ly/2hrImnY for details).

Couldn't find index page for 'setuptools_scm_git_archive' (maybe
misspelled?)

Note: Bypassing https://pypi.org/simple/ (disallowed host; see
http://bit.ly/2hrImnY for details).

No local packages or working download links found for
setuptools_scm_git_archive
Traceback (most recent call last):
  File "setup.py", line 84, in 
setup(**SETUP_METADATA)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 142,
in setup
_install_setup_requires(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 137,
in _install_setup_requires
dist.fetch_build_eggs(dist.setup_requires)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 586, in
fetch_build_eggs
replace_conflicting=True,
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
780, in resolve
replace_conflicting=replace_conflicting
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1063, in best_match
return self.obtain(req, installer)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1075, in obtain
return installer(requirement)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 653, in
fetch_build_egg
return cmd.easy_install(req)
  File "/usr/lib/python3/dist-packages/setuptools/command/easy_install.py",
line 698, in easy_install
raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution for
Requirement.parse('setuptools_scm_git_archive')
E: pybuild pybuild:338: clean: plugin distutils failed with: exit code=1:
python3.7 setup.py clean
dh_auto_clean: pybuild --clean --test-pytest -i python{version} -p 3.7
returned exit code 13
make: *** [debian/rules:5: clean] Error 13
dpkg-buildpackage: error: debian/rules clean subprocess returned exit
status 2
I: copying local configuration
E: Failed autobuilding of package


-- 
Michael R. Crusoe

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#918251: d-shlibs: devlibs error: There is no package matching [libsvm3-dev] and noone provides it

[Michael Crusoe]

Dear Andreas,

That worked; thanks! I've pushed the fix to Salsa, ready to be part of the
next upload:
https://salsa.debian.org/med-team/libpsortb/commit/412ddc0ec32d03164d308b226019750c91d83b25

Do we still need d-shlibs to make a fix on their end?

În sâm., 5 ian. 2019 la 00:58, Andreas Tille  a scris:

> Hi Michael,
>
> On Fri, Jan 04, 2019 at 11:10:42AM -0800, Michael R. Crusoe wrote:
> > Package: d-shlibs
> > Version: 0.83
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > While fixing the missing linkage to libsvm in libpsortb I received the
> > following message:
> >
> > devlibs error: There is no package matching [libsvm3-dev] and noone
> provides
> > it, please report bug to d-shlibs maintainer
> >
> > So here I am :-)
> >
> > d-shlibmove --commit \
> > --multiarch \
> > --devunversioned \
> > --exclude-la \
> > debian/tmp/usr/lib/*/libsvmloc.so
> > Library package automatic movement utility
> > devlibs error: There is no package matching [libsvm3-dev] and noone
> provides it, please report bug to d-shlibs maintainer
>
> I can not really reproduce this but you do not need until this
> bug is fixed in d-shlibs.  You can easily add
>
> --override s/libsvm3-dev/libsvm-dev/ \
>
> which should do the trick.  (If not let me know how I can
> reproduce the issue.)
>
> Kind regards
>
>   Andreas.
>
> --
> 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#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#892223: fixed in seqan2 2.4.0+dfsg-9

[Michael Crusoe]

FYI, in building +dfsg-9 we are seeing new bus errors on armhf (which
previously passed the tests)
https://buildd.debian.org/status/logs.php?arch=armhf=seqan2

https://buildd.debian.org/status/fetch.php?pkg=seqan2=armhf=2.4.0%2Bdfsg-9=1544194851=0

And on mips there is a new test failure (tests previously passed here):

https://buildd.debian.org/status/fetch.php?pkg=seqan2=mips=2.4.0%2Bdfsg-9=1544151238=0

Given that these architectures (and sparc64) previously built fine for
Debian, I suggest we revert this patch for now.

===
armel bus errors:
===

 39/400 Test  #46: test_test_index_crosscompare_dna
..Bus error***Exception:
 0.01 sec
TEST SUITE test_index
SEQAN_ENABLE_DEBUG == 1
SEQAN_ENABLE_TESTING == 1
SEQAN_CXX_FLAGS == "SEQAN_CXX_FLAGS_NOT_SET"
SEQAN_ASYNC_IO == 1
testIndexCrossCompareDna OK

 46/400 Test  #52: test_test_index_fm_rank_dictionary
Bus error***Exception:
0.01 sec
TEST SUITE tests
SEQAN_ENABLE_DEBUG == 1
SEQAN_ENABLE_TESTING == 1
SEQAN_CXX_FLAGS == "SEQAN_CXX_FLAGS_NOT_SET"
SEQAN_ASYNC_IO == 1
RankDictionaryTest_Constructor type parameter seqan::RankDictionary, 1u,
1u> > > OK
RankDictionaryTest_Constructor type parameter seqan::RankDictionary,
1u, 1u> > > OK
RankDictionaryTest_Constructor type parameter
seqan::RankDictionary,
seqan::Levels,
1u, 1u> > > OK
RankDictionaryTest_Constructor type parameter
seqan::RankDictionary,
seqan::Levels,
1u, 1u> > > OK
RankDictionaryTest_Constructor type parameter
seqan::RankDictionary,
seqan::Levels,
1u, 1u> > > OK
RankDictionaryTest_Constructor type parameter
seqan::RankDictionary > >,
seqan::Levels,
1u, 1u> > > OK
RankDictionaryTest_Constructor type parameter
seqan::RankDictionary,
seqan::Levels,
1u, 1u> > > OK

===
mips test failure
===

  5/397 Test   #7: test_align_parallel_data_structures
...Child aborted***Exception:
 0.10 sec
TEST SUITE test_align_parallel_data_structures
SEQAN_ENABLE_DEBUG == 1
SEQAN_ENABLE_TESTING == 1
SEQAN_CXX_FLAGS == "SEQAN_CXX_FLAGS_NOT_SET"
SEQAN_ASYNC_IO == 1
test_align_parallel_wavefront_task_scheduler_construct OK
test_align_parallel_wavefront_task_scheduler_async OK
test_align_parallel_wavefront_alignment_scheduler_construct OK
test_align_parallel_wavefront_alignment_scheduler_async OK
double free or corruption (out)

Bug#914928: ITP: python-typing-extensions -- Backported and Experimental Type Hints for Python

[Michael Crusoe]

Thank you for the information.

I'm already using this for schema_salad. I'll patch out the need for it and
request removal of this package when  Py3.6 is retired.

--
Michael R. Crusoe


În vin., 7 dec. 2018, 01:57 Piotr Ożarowski  [Michael Crusoe, 2018-12-06]
> > How soon is soon?
>
> I guess in a month or so. Depends on how fast 3.7 as default transition
> will be finished. Before Buster release in any case.
>

Bug#914928: ITP: python-typing-extensions -- Backported and Experimental Type Hints for Python

[Michael Crusoe]

How soon is soon?

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
https://impactstory.org/u/-0002-2961-9670
m...@commonwl.org

În joi, 6 dec. 2018, 19:27 Piotr Ożarowski  >  The typing module was added to the standard library in Python 3.5 on a
> >  provisional basis and will no longer be provisional in Python 3.7.
> However,
> >  this means users of Python 3.5 - 3.6 who are unable to upgrade will not
> be
> >  able to take advantage of new types added to the typing module, such as
> >  typing.Text or typing.Coroutine.
>
> we will remove 3.6 from Debian soon, is it worth packaging it?
> or are you targetting backports?
>
>

Bug#911076: Request for sponsorship: libdeflate -- fast, whole-buffer DEFLATE-based compression and decompression)

[Michael Crusoe]

g...@salsa.debian.org:med-team/libdeflate.git

Thanks!

În lun., 15 oct. 2018 la 14:12, Michael R. Crusoe 
a scris:

> Package: wnpp
> Severity: wishlist
> Owner: Debian Med team 
>
> * Package name: libdeflate
>   Version : 1.0
>   Upstream Author : Eric Biggers 
> * URL : https://github.com/ebiggers/libdeflate
> * License : MIT
>   Programming Lang: C
>   Description : fast, whole-buffer DEFLATE-based compression and
> decompression
>
> The supported formats are:
>  .
>  DEFLATE (raw)
>  zlib (a.k.a. DEFLATE with a zlib wrapper)
>  gzip (a.k.a. DEFLATE with a gzip wrapper)
>  libdeflate is heavily optimized. It is significantly faster than the zlib
>  library, both for compression and decompression, and especially on x86
>  processors. In addition, libdeflate provides optional high compression
> modes
>  that provide a better compression ratio than the zlib's "level 9".
>
> libdeflate is a recommended dependency of htslib and will be
> team-maintained by
> Debian Med
>
>

-- 
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

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#892223: seqan2: FTBFS on sparc64: 39 tests failed out of 403

[Michael Crusoe]

On Tue, 06 Mar 2018 18:08:48 -0500 "Aaron M. Ucko"  wrote:
> Source: seqan2
> Version: 2.4.0+dfsg-8
> Severity: normal
> Tags: upstream
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
>
> Builds of seqan2 for sparc64 (admittedly not a release architecture)
> have been failing lately, per the below excerpt from [1].  The tests
> that "Failed" generally if not always returned -10, presumably
> corresponding to having encountered SIGBUS (10 on this architecture)
> -- no surprise,

Yes, upstream is aware.

> since sparc64 is notoriously strict about memory
> access alignment.

Can you expand upon this? Is there a guide for correcting this issue?

Thanks,

Bug#890667: lintian: Missing link between cwl-runner interpreter and package cwltool or virtual package cwl-runner

[Michael Crusoe]

Thank you Chris for your response.

I only recently added the `cwl-runner` virtual package to cwltool as we are
about to introduce another CWL runner, toil, to the archive soon.

Here's a Lintian error from the latest seqan-apps package:

E: seqan-apps: missing-dep-for-interpreter cwl-runner => cwltool
(usr/share/commonwl/alf.cwl) #!cwl-runner
N:
N:You used an interpreter for a script that is not in an essential
N:package. In most cases, you will need to add a Dependency on the
package
N:that contains the interpreter. If the dependency is already present,
N:please file a bug against Lintian with the details of your package so
N:that its database can be updated.
N:
N:In some cases a weaker relationship, such as Suggests or Recommends,
N:will be more appropriate.
N:
N:Severity: important, Certainty: possible
N:
N:Check: scripts, Type: binary


2018-02-17 21:19 GMT+02:00 Chris Lamb :

> tags 890667 + moreinfo
> thanks
>
> Hi Michael,
>
> > Please update Lintian so that it knows about "cwl-runner" interpreters:
> they
> > provide the "cwl-runner" virtual package.
>
> Doesn't Lintian already know about them? :)  This should have been
> introduced
> via https://bugs.debian.org/851126.
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>



-- 
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

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#881317: RM: r-bioc-edger -- ROM; No chance to upgrade to latest version due to not fullfillable dependency from r-cran-locfit

[Michael Crusoe]

Fine by me. Looks like it isn't needed by trinityrnaseq anymore, so that
build-depends can be dropped.

Unfortunately it is a dependency on the recently packaged bio-tradis, as I
think you are aware.


2017-11-10 10:16 GMT+02:00 Andreas Tille :

> Package: ftp.debian.org
> Severity: normal
>
> Hi,
>
> I'm opening this bug also for discussion on the Debian Med list.
>
> The situation with r-bioc-edger is the following:  In the recent package
> locfit was only used for testing the package and the test was simply
> removed
> by a patch.  In all later upstream versions locfit became a required part
> of the code.
>
> Locfit has a problematic license as discussed in its ITP/RFP #731599.
> The about text says explicitly:
>
> the Locfit code, as distributed, should not, and can not, be used to
> derive meaningful benchmarks, either for the speed or accuracy of
> algorithms.
> Anyone wishing to use Locfit in any kind of comparative benchmark
> study must contact and obtain permission from the Author.
>
> Unfortunately several attempts to contact the Author for clarification
> failed and I somehow gave up (I'd be more than happy if somebody would
> keep on trying since there are other packages affected by the locfit
> code).
>
> Since we are not able to upgrade r-bioc-edger in main I think we should
> remove it from main to not confuse users.  Usually local installation of
> Bioconductor packages is quite simple so fetching a recent version is
> not a real problem for the user.
>
> If somebody wants to package r-cran-locfit for non-free and r-bioc-edger
> in contrib it has to pass the new queue anyway and this removal will not
> harm.
>
> Any opinions?
>
> Kind regards
>
> Andreas.
>
>


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

Bug#877297: libnxt: usb:v03EBp* too inclusive, leads to false positive matches

[Michael Crusoe]

Package: libnxt
Version: 0.3-8
Severity: normal

Dear Maintainers,

I have no NXT devices installed on my system, but I get an alert that I
should
install libnxt due to the following modalias match in
/usr/share/appdata/libnxt.metainfo.xml:

usb:v03EBp*

(While I am running Debian Stable, I confirmed that the latest libnxt still
has this overly broad match)

This very broad alias matches my laptop's touchscreen digitizer. Alas the
appstream spec does not seem to allow for exclusions.

Here's an alternative:


usb:v03EBp[0-79]*
usb:v03EBp8[0-79]*
usb:v03EBp88[1-9]*
usb:v03EBp880[02-9]*

For completeness, here is the lsusb -v output for my laptop's touchscreen
digitizer:

Bus 001 Device 009: ID 03eb:8801 Atmel Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x03eb Atmel Corp.
  idProduct  0x8801
  bcdDevice   10.32
  iManufacturer   1 Atmel
  iProduct2 Atmel maXTouch Digitizer
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   66
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  250mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  2 Atmel maXTouch Digitizer
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 639
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  3 Atmel maXTouch Control
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  39
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
Device Status: 0x
  (Bus Powered)

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=ro_RO.utf8, LC_CTYPE=ro_RO.utf8 (charmap=UTF-8),
LANGUAGE=ro_RO.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnxt depends on:
ii  libc6 2.24-11+deb9u1
ii  libusb-0.1-4  2:0.1.12-30

Versions of packages libnxt recommends:
ii  nxt-firmware  1.29-20120908+dfsg-7

libnxt suggests no packages.

-- no debconf information

-- 
Michael R. Crusoe

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#860746: ITP: easel -- a library of C functions for biological sequence analysis

[Michael Crusoe]

You are welcome!

git+ssh://git.debian.org/git/debian-med/easel.git is ready for review

2017-04-19 20:11 GMT+03:00 Andreas Tille :

> Very sensible!  Thanks for working on this
> Andreas.
>
> On Wed, Apr 19, 2017 at 10:06:57AM -0700, Michael R. Crusoe wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Debian Med team 
> >
> > * Package name: easel
> >   Version : 0.43
> >   Upstream Author : Sean R. Eddy 
> > * URL : https://github.com/EddyRivasLab/easel
> > * License : BSD-3-clause
> >   Programming Lang: C
> >   Description : a library of C functions for biological sequence
> analysis
> >
> >  Easel is an ANSI C code library for computational analysis of
> >  biological sequences using probabilistic models. Easel is used by
> >  HMMER, the profile hidden Markov model software that underlies the
> >  Pfam protein families database, and by Infernal, the profile
> >  stochastic context-free grammar software that underlies the Rfam RNA
> >  family database. Easel aims to make similar applications more robust
> >  and easier to develop, by providing a set of reusable, documented, and
> >  well-tested functions.
> >
> > Several existing packages contain code copies and it is high time this
> and the example
> > apps were seperately packaged.
> >
> > This will be team maintained by Debian Med
> >
> >
>
> --
> http://fam-tille.de
>



-- 
Michael R. Crusoe
Community Engineer & Co-founder
Common Workflow Language project 
https://impactstory.org/u/-0002-2961-9670
michael.cru...@gmail.com
+1 480 627 9108
+32 2 808 25 58

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#851468: ITP: python-galaxyxml -- XML Generation libraries for Galaxy Tool/ToolDeps XML

[michael . crusoe]

Package: wnpp
Severity: wishlist
Owner: anton.kho...@ukr.net

* Package name: python-galaxyxml
  Version : 0.1
  Upstream Author : Eric Rasche 
* URL : https://github.com/erasche/galaxyxml
* License : Apache-2.0
  Programming Lang: Python
  Description : XML Generation libraries for Galaxy Tool/ToolDeps XML

 Galaxy XML Generation Libraries support building of Tool XML and Tool 
Dependencies XML.
The package is the dependency for argparse2tool.

Remark: This package will be maintained bz the Debian Med team at
  https://anonscm.debian.org/git/debian-med/python-galaxyxml.git

Bug#851126: lintian: cwl-runner should be added to acceptable interpreter list

[michael . crusoe]

Package: lintian
Version: 2.5.50
Severity: normal

Dear Maintainer,

Please, add cwl-runner to the list of acceptable interpeters. It is found in 
cwltool package, a reference implementation for Common Worklflow Language 
standard.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.27.90.20170109-1
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.29-2
ii  gettext   0.19.8.1-1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.18
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1~rc4-1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2

Versions of packages lintian recommends:
ii  dpkg 1.18.18
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1~rc4-1
ii  perl-modules-5.24 [libautodie-perl]  5.24.1~rc4-1

Versions of packages lintian suggests:
ii  binutils-multiarch 2.27.90.20170109-1
ii  dpkg-dev   1.18.18
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#845982: Please clarify several issues with cwltool

[Michael Crusoe]

There is no particular urgency to get cwltest into the archive ahead of any
other new package.

2016-12-12 22:25 GMT+02:00 Andreas Tille <andr...@fam-tille.de>:

> Hi Michael,
>
> I just want to make sure you understood that if we want to get a new
> package through new queue (cwltest) that this is really urgent now.
> Since I'm not really sure what to do next (if you take over from here or
> you might urgently need help) I'll stay idle until I read from you more
> detailed information to the questions below.
>
> Kind regards
>
>   Andreas.
>
> On Sun, Dec 11, 2016 at 05:31:28PM +0100, Andreas Tille wrote:
> > On Fri, Dec 09, 2016 at 01:18:04PM +, Michael Crusoe wrote:
> > > >   1. Patch to not use python-typing.
> > > >  Why this?  Adding the package to Build-Depends would be cheap
> > >
> > > At some point the python2 typing package went away?
> >
> > No idea but according to
> >
> > $ apt-cache policy python-typing
> > python-typing:
> >   Installiert:   3.5.2.2-1
> >   Installationskandidat: 3.5.2.2-1
> >   Versionstabelle:
> >  *** 3.5.2.2-1 501
> > 501 http://httpredir.debian.org/debian testing/main amd64
> Packages
> >  50 http://httpredir.debian.org/debian unstable/main amd64
> Packages
> > 100 /var/lib/dpkg/status
> >
> > everything seems to be fine.
> >
> > > >   2. Lagging behind upstream.
> > > >  Are there any reasons?
> > >
> > > Yes, only py2 compat and I wanted to add py3 before updating :-P
> >
> > Hmmm, but we want to have latest upstream in Stretch (no matter what
> > Python version), right?
> >
> > > >   3. I injected latest upstream (1.0.20161207161158) in my local Git
> > > >  repository
> > > >   * cwltest is now separate - do we want to package it as well?
> > >
> > > Yes please
> >
> > I injected
> >
> > https://anonscm.debian.org/git/debian-med/cwltest.git
> >
> > Please take over from here since you are the expert.  And please make
> > this of high priority if we want to feed the latest and greatest code
> > into Stretch.
> >
> > > >   * after removing it from set of requriements I was running into
> > > >
> > > > Download error on https://pypi.python.org/simple/schema-salad/:
> [Errno
> > > > -3] Temporary failure in name resolution -- Some packages may not be
> found!
> > > > Couldn't retrieve index page for 'schema-salad'
> > > > Scanning index of all packages (this may take a while)
> > > > Reading https://pypi.python.org/simple/
> > > > Download error on https://pypi.python.org/simple/: [Errno -3]
> Temporary
> > > > failure in name resolution -- Some packages may not be found!
> > > > No local packages or working download links found for
> > > > schema-salad<2,>=1.21.20161206204028
> > > > error: Could not find suitable distribution for
> Requirement.parse('schema-
> > > > salad<2,>=1.21.20161206204028')
> > >
> > > Yes, schema salad also needs to be updated
> >
> > Done.
> >
> > > >   4. Continuing with python-schema-salad I noticed that it is lagging
> > > >  behind as welland it is now >= 2 (2.0.20161122040508)
> > >
> > > *sigh* please ignore the 2.x series of schema salad -- that was not my
> doing
> >
> > I excluded 2.x series from d/watch - please find a more sensible
> > solution for the future since I consider this hackish.
> >
> > > > I do not feel competent to decide what version is fit for Debian 9.
> If
> > > > we do nothing cwltool is out - so IMHO we should urgently upgrade all
> > > > needed packages but I have no idea what might be the right procedure.
> > > >
> > > > Michael, could you please take over (and thus join the advent
> calendar
> > > > effort ;-))
> >
> > I admit I basically ignored cwl related packages since I assumed you
> > would care for the code where you are upstream.  Please let us know if
> > you have reasons for not beeing able to care.  We happily help to have
> > the recent code without bugs in Stretch but we need more information
> > from you to take action.
> >
> > Kind regards
> >
> >  Andreas.
> >
> >
> > --
> > 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
> >
>
> --
> http://fam-tille.de
>



-- 
Michael R. Crusoe
Community Engineer & Co-founder
Common Workflow Language project <http://www.commonwl.org/>
https://impactstory.org/u/-0002-2961-9670
michael.cru...@gmail.com
+40 720 781 765
+1 480 627 9108

Bug#845982: Please clarify several issues with cwltool

[Michael Crusoe]

2016-12-09 12:19 GMT+00:00 Andreas Tille :

> Hi Michael,
>
> I assumed simply adding the now available python-keepalive would easily
> fix the bug would be a simple task.  However, I stumbled about several
> issues which prevented me from conituning here since I have no idea
> about the internals.
>
>   1. Patch to not use python-typing.
>  Why this?  Adding the package to Build-Depends would be cheap
>

At some point the python2 typing package went away?


>
>   2. Lagging behind upstream.
>  Are there any reasons?
>

Yes, only py2 compat and I wanted to add py3 before updating :-P


>   3. I injected latest upstream (1.0.20161207161158) in my local Git
>  repository
>   * cwltest is now separate - do we want to package it as well?
>

Yes please


>   * after removing it from set of requriements I was running into
>
> Download error on https://pypi.python.org/simple/schema-salad/: [Errno
> -3] Temporary failure in name resolution -- Some packages may not be found!
> Couldn't retrieve index page for 'schema-salad'
> Scanning index of all packages (this may take a while)
> Reading https://pypi.python.org/simple/
> Download error on https://pypi.python.org/simple/: [Errno -3] Temporary
> failure in name resolution -- Some packages may not be found!
> No local packages or working download links found for
> schema-salad<2,>=1.21.20161206204028
> error: Could not find suitable distribution for Requirement.parse('schema-
> salad<2,>=1.21.20161206204028')
>

Yes, schema salad also needs to be updated



>   4. Continuing with python-schema-salad I noticed that it is lagging
>  behind as welland it is now >= 2 (2.0.20161122040508)
>

*sigh* please ignore the 2.x series of schema salad -- that was not my doing


> I do not feel competent to decide what version is fit for Debian 9.  If
> we do nothing cwltool is out - so IMHO we should urgently upgrade all
> needed packages but I have no idea what might be the right procedure.
>
> Michael, could you please take over (and thus join the advent calendar
> effort ;-))
>
>   Andreas.
>
> --
> http://fam-tille.de
>



-- 
Michael R. Crusoe
Community Engineer & Co-founder
Common Workflow Language project 
https://impactstory.org/u/-0002-2961-9670
michael.cru...@gmail.com
+40 720 781 765
+1 480 627 9108