Re: Please update SIMDE patches in new version of kalign

[Michael Crusoe]

Awesome, thanks!

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

On Sun, Nov 6, 2022, 09:24 Nilesh Patra  wrote:

> On Sun, Nov 06, 2022 at 04:12:18AM +0530, Nilesh Patra wrote:
> > On Fri, Nov 04, 2022 at 11:08:05PM +0100, Andreas Tille wrote:
> > > I injected the new version of kalign into Git.  Unfortunately the file
> > > layout has changed and the files that were patched in the currently
> > > packaged version do not exist any more[1].  It would be great if you
> > > could update the patches to the new version.
> >
> > Michael is probably quite busy, so I took a look at it. This was a non
> > trivial update with many changes.
> >
> > I have uploaded the package which seems to work OK. If you see something
> > is off, please fix it and upload a new revision.
>
> Autopkgtests seem to work fine, there was a FTBFS on i386 because of
> a fallout w/ migrating to cmake layout in d/rules at my end.
>
> Everything seems to be green now! :)
>
> > > [1] https://salsa.debian.org/med-team/kalign/-/jobs/3474689
>
> --
> Best,
> Nilesh
>

Re: Please update simde patches for minimap2

[Michael Crusoe]

Done and uploaded!

On Thu, Oct 14, 2021 at 11:13 AM Andreas Tille  wrote:

> Hi Michael,
>
> I upgraded minimap2 in Git which is now at version 2.22 (we had 2.17)
> and had obviously incorporated simde inside the code so several chunks
> of your simde patch do not apply.  Since I'm not educated about simde
> sufficiently I'd be really happy if you could finalise this and upload
> minimap2.
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>

Re: Providing components.cif.gz [Was: Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced]

[Michael Crusoe]

I would advocate for a local copy (if missing) and an environment variable
to override so that users can get a newer/different version.

I would also encourage upstream to find a way to embed a hash + download
date in their logs and outputs, if possible.

We should also ask PDB to version their files. Do they keep old versions
around?

--
Michael R. Crusoe

On Wed, Sep 8, 2021, 09:07 Andrius Merkys  wrote:

> Hi all,
>
> On 2021-07-19 10:24, Nilesh Patra wrote:
> > On 19 July 2021 12:50:03 pm IST, Andrius Merkys 
> wrote:
> >> Currently I am looking into ProMod3 [3], which seems to be the engine
> >> behind the great SWISS-MODEL service [4]. I seem to have figured out
> >> the
> >> dependencies, will go on to packaging next.
> > Let us know if you need help with packaging the chain, in case you need
> helping hands :-)
>
> So here I am asking for help/suggestions :)
>
> Problem: OpenStructure, a dependency of ProMod3, requires PDB components
> library, components.cif.gz, for some of its protein modeling routines.
> This library is provided by the PDB at [1] and is itself freely
> distributable (PDB discourages from modifying it though), but is updated
> quite often and does not get a version number. Furthermore, people often
> prefer to obtain the most up-to-date copy of components.cif.gz for their
> research, thus providing it in a Debian package of its own would not be
> very convenient.
>
> I am aware of solutions to similar problems, for example, libcifpp
> package, which keeps an up-to-date mmcif_pdbx_v50.dic.gz at
> /var/cache/libcifpp/mmcif_pdbx_v50.dic.gz. This could work for
> components.cif.gz as well, but my main concern is whether keeping
> system-wide components.cif.gz up-to-date is what every user would want.
>
> As a researcher I do my best to perform reproducible science. Thus I
> want to know precise versions/timestamps/checksums of my input
> databases, and have them suddenly change overnight is something akin to
> a nightmare. What is more, there might be more than one user on a
> machine wanting different versions of components.cif.gz.
>
> Thus my candidate solution for providing components.cif.gz for
> OpenStructure would be to talk to the upstream to implement an
> environment variable allowing for greater flexibility. Or maybe there
> are other solutions?
>
> [1] ftp://ftp.wwpdb.org/pub/pdb/data/monomers/components.cif.gz
>
> Best,
> Andrius
>
>

Re: last-align: Baseline violation on amd64?

[Michael Crusoe]

Hey Nilesh.

Thanks for thinking about this. SSE2 is part of the amd64 baseline, so it
is fine.

I guess we could adjust that d/rules to more clearly make a `-plain` on
both amd64 & i386. It is a bit out of date from the style I have been using
more recently.

So you could update it, but there is no error nor any urgency.

Cheers,

On Mon, 19 Apr 2021 at 15:46, Nilesh Patra  wrote:

> Hi Michael,
>
> Whilst compiling last-align for new upstream release, I noticed that
> last-align binaries are not being generated for baseline amd64, i.e.
> without sse/avx et. al. More specifically, there's no instruction to
> build the "-plain" binaries while the same is actually present for
> i386[1]
> So is this a baseline violation? If yes, should we immediately fix it?
>
> [1]:
> https://salsa.debian.org/med-team/last-align/-/blob/master/debian/rules#L49
> [2]:
> https://buildd.debian.org/status/fetch.php?pkg=last-align=amd64=1179-1%2Bb1=1615505159=0
>
> Nilesh
>


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

Re: [Request for review] rna-star

[Michael Crusoe]

On Mon, 1 Mar 2021 at 14:15, Nilesh Patra  wrote:

> Hi Michael
>
> On Mon, 1 Mar, 2021, 5:06 pm Michael Crusoe, 
> wrote:
>
>> Hello Nilesh!
>>
>> Thank you for noticing this.
>>
>> Please add entries to debian/changelog in the future. I use `dch 'changed
>> a thing'` followed by `debcommit -a` instead of using `git commit`, to
>> ensure I document my changes.
>>
>> In your patch you removed `-O3`, I've put that back to simplify the
>> patch. It doesn't hurt to specify that twice.
>>
>
> Many thanks for the review!
>
> I've pushed my cleanups. Can you also add logic to compile rna-star
>> multiple times using -mavx2 on down for amd64 along with a wrapper script?
>>
>
> I'm running out of time this week, would you mind doing so(just once for
> now)?
>

Sure


>
> BTW, this will lead to introduction of another binary, which is probably
> not allowed during soft freeze -- thoughts?
>

No, not another binary package, another binary within the existing package.



-- 
Michael R. Crusoe

Re: [Request for review] rna-star

[Michael Crusoe]

Hello Nilesh!

Thank you for noticing this.

Please add entries to debian/changelog in the future. I use `dch 'changed a
thing'` followed by `debcommit -a` instead of using `git commit`, to ensure
I document my changes.

In your patch you removed `-O3`, I've put that back to simplify the patch.
It doesn't hurt to specify that twice.

I've pushed my cleanups. Can you also add logic to compile rna-star
multiple times using -mavx2 on down for amd64 along with a wrapper script?

https://salsa.debian.org/med-team/mmseqs2/-/blob/32b4e057b5d0e205f32b0b5184433ac155405198/debian/rules#L20
is a good example (along with
https://salsa.debian.org/med-team/mmseqs2/-/blob/32b4e057b5d0e205f32b0b5184433ac155405198/debian/bin/simd-dispatch
)

On Fri, 26 Feb 2021 at 13:44, Nilesh Patra  wrote:

> Hi Michael and other folks,
>
> The version 2.7.8a of rna-star which Steffen uploaded a couple of days ago
> seems to use intel intrinsics which leads unfortunately builds on non-amd64
> Since simde is a good way to mitigate this, I tried using this -- on
> testing on a arm64 porter box, build goes green and autopkgtests (I
> manually an them) look good as well.
>
> Can I please get a review of my changes?
>
> Also, I'm not sure if it'd be good to be uploaded during the soft freeze,
> and need suggestions here. Note that it also uses a "Built-Using" on simde
> due to it's license being GPL3+
>
> Nilesh
>
>

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

Re: Workflow for releasing new upstream versions to experimental?

[Michael Crusoe]

I strongly prefer a separate branch for experimental, to avoid commit
reverts and the like.

My assumption is that all commits to the primary branch are tested and
ready to go and I wish more people used other branches for aspirational or
untested changes (like new releases from upstream). To be fair, I don't
always meet my own aspirations :-)

As for gbp, the following bash snippet does the trick:

cat > debian/gbp.conf < wrote:

> Hi,
>
> Since soft freeze is around the corner, and new upstream versions which
> are **not** targeted fixes is _discouraged_[1]
>
> I plan uploading all new upstream versions till the release of bullseye to
> experimental. Hence I wanted to ask, is it sane to directly commit things
> to "master" branch with changelog revision x.y.z-w~0exp0?
>
> In principle, it would be committed to d/experimental branch for a saner
> workflow, but after bullseye release, this branch can (in most cases) be
> directly merged with master. So instead of maintaining an extra branch, and
> modifying gbp workflow to use that, can commit new upstream releases
> directly to master(and ofcourse, release to experimental)?
>
> Right now I'm following the defined workflow(of d/experimental branch),
> but if there are no objections, I'd go with what I proposed
>
> [1]: https://release.debian.org/bullseye/FAQ.html
>
> Nilesh
>


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

Re: [solved] porting brian on MIPS and POWER, or dropping support

[Michael Crusoe]

On Sun, Jan 31, 2021, 10:18 Étienne Mollier 
wrote:

> Hi all,
>
> The build went well on all architectures not missing build
> dependencies[1].  The current implementation injects no compiler
> optimisation in the state updater steps, so by playing safe the
> package proved to be rather portable.
>

Glad it works now!

I think the nice/responsible thing to do is to try a couple builds in
experimental that uses the -march=native or -mcpu=native flags plus the
remaining flags on a per architecture basis. And only then try to reduce
the -O optimization level or drop some of the other flags as needed (again,
only for the architectures that need that). The result should be sent to
upstream for inclusion and then uploaded to sid.

Do you have time to do that; or do you want to do it together?


> [1] https://buildd.debian.org/status/package.php?p=brian
>
> I feel like I generated a lot of noise while the issue could be
> solved with little change actually, I apologize for this but am
> grateful for your time.
>

I enjoyed the conversation, so please don't hold back!


> Michael Crusoe, on 2021-01-30 19:31:42 +0100:
> > If it is truly for local use, then -march=native is great, but not every
> > architecture supports "-march=native", so you may need to add work
> arounds
> > for archs that don't have that gcc option.
> >
> > Here is the result of some reading of the gcc manual page
> >
> > -march=native & -mtune=native is valid in gcc for the following Debian
> > archs:
> >
> > arm*
> > mips*
> > s390x
> > i386/amd64/x32
> >
> > but not these
> >
> > HPPA
> > M68k
> > riscv64
> > power*/ppc* (no -march at all, but does have -mcpu=native and
> -mtune=native)
> > alpha (no -march at all, but does have -mcpu=native and -mtune=native)
> > sh4 (no -march at all, no -mcpu either)
> > sparc64 (no -march at all, but does have -mcpu=native and -mtune=native)
> > ia64 (no -march, has -mtune but not -mtune=native)
>
> Thanks Michael for this precious information, I will use it to
> bring back some performance to these brian functions, at cost of
> complexity perhaps, once brian is back to Testing, in the coming
> week hopefully.
>

Ah, good, we are on the same page! But we can start now with an upload to
"experimental" without having to wait for the migration to testing 


I don't remember if you've done packaging for the "experimental" section
before, so here are some quick notes that you can skip if you have already.

1. Be sure to use version like 2.4.2-4~0exp0 so that the "proper" release
of 2.4.2-4 will supercede the experimental version
2. Push your changes to a new `debian/experimental` branch instead of the
default branch (currently named "master", but that is another conversation
for another day)
You will need to add --debian-git-branch=debian/experimental or
--git-branch=debian/experimental to `gbp` commands (alas, the option name
isn't consistent)
3. When doing `dch --release`, either add the command line option to set
the distribution to "experimental" or hand edit the top line of the
changelog to achieve the same (the latter is what I do)

Otherwise your packaging workflow should be the same. Use your existing
sid/unstable {cow,p}builder and/or sbuild/debci chroots. A special
"experimental" chroot isn't needed unless you require packages that have
also been uploaded only to the "experimental" psuedo-distribution.


> Have a nice Sunday everyone,  :)
>

Likewise!

Re: [help] porting brian on MIPS and POWER, or dropping support

[Michael Crusoe]

On Sat, 30 Jan 2021 at 17:18, Étienne Mollier 
wrote:

> Hi Michael,
>
> Michael Crusoe, on 2021-01-30 16:51:27 +0100:
> > On Sat, 30 Jan 2021 at 14:33, Étienne Mollier <
> etienne.moll...@mailoo.org>
> > wrote:
>
> > > [1] https://salsa.debian.org/med-team/brian/-/tree/master
> >
> >
> https://salsa.debian.org/med-team/brian/-/blob/master/debian/patches/gsl-compiler-arg.patch#L29
> >
> > -march=native is not allowed as it violates the architecture baseline,
> > unless there is an alternative binary or library built without it.
>
> I would generally agree, but in this case I understood the code
> was compiled (in the background) on the end user's machine[3].
> I don't exclude that I could have misunderstood the mechanism,
> so am triple checking at the moment.  I probably should have put
> the link in the patch header, by the way.
>
> [3] https://brian2.readthedocs.io/en/stable/user/computation.html


If it is truly for local use, then -march=native is great, but not every
architecture supports "-march=native", so you may need to add work arounds
for archs that don't have that gcc option.

Here is the result of some reading of the gcc manual page

-march=native & -mtune=native is valid in gcc for the following Debian
archs:

arm*
mips*
s390x
i386/amd64/x32

but not these

HPPA
M68k
riscv64
power*/ppc* (no -march at all, but does have -mcpu=native and -mtune=native)
alpha (no -march at all, but does have -mcpu=native and -mtune=native)
sh4 (no -march at all, no -mcpu either)
sparc64 (no -march at all, but does have -mcpu=native and -mtune=native)
ia64 (no -march, has -mtune but not -mtune=native)


>
> In any way, I guess putting more regular compiler flags at first
> should give a far safer outcome than current architecture
> dependent selection.
>
> Thanks for your review!  :)
>

You are welcome

-- 
Michael R. Crusoe

Re: [help] porting brian on MIPS and POWER, or dropping support

[Michael Crusoe]

On Sat, 30 Jan 2021 at 14:33, Étienne Mollier 
wrote:

> Hi Michael, and people at ease with architecture ports,
>

Hello!

The package brian[1] has a mechanism based on the GSL which does
> some sort of compilation just-in-time.  The default set of build
> flags works rather well on all flavors of amd64 architecture
> with or without extensions, however not all of the specified
> options by default are supported on all architectures.
>

Hmm.. this sounds like a recipe for a tough time :-D

Personally I put no extra effort for mips :-)


> [1] https://salsa.debian.org/med-team/brian/-/tree/master


https://salsa.debian.org/med-team/brian/-/blob/master/debian/patches/gsl-compiler-arg.patch#L29

-march=native is not allowed as it violates the architecture baseline,
unless there is an alternative binary or library built without it.

-- 
Michael R. Crusoe

Re: [RFS] python-cutadapt 3.2-2

[Michael Crusoe]

Hey Étienne!

You are faster than me! Thanks for fixing this. I granted you upload
permissions. Cheers!

On Sat, 30 Jan 2021 at 11:51, Étienne Mollier 
wrote:

> Good day,
>
> I enabled i386 support on python-cutadapt 3.2-2.  This should
> allow the package to migrate to Testing.  Changes are available
> on Salsa[1].
>
> [1] https://salsa.debian.org/med-team/python-cutadapt/
>
> Please consider upload or DM grants.
>
> Have a nice day,  :)
> --
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/2, please excuse my verbosity.
>


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

Re: Any volunteer to evaluate/fix Python3.9 issues in python-cogent?

[Michael Crusoe]

On Tue, 26 Jan 2021 at 12:27, Michael Crusoe 
wrote:

> FYI: python-cogent requires numba, numba (which is a just-in-time compiler
> for Python) got removed from testing for not supporting Python 3.9 yet.
>
> They finally backported a patch for numba, but the numba armhf tests are
> failing https://qa.debian.org/excuses.php?package=numba They tried to
> work around that with the last upload
> https://tracker.debian.org/news/1222710/accepted-numba-0520-2-source-into-unstable/
> but that didn't work yet.
>
> Python-cogent also depends on jupyter-sphinx and that package is also in a
> tough place: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950598
>

and the 'ipywidgets.embed' issue remains with the latest release of
jupyter-sphinx (I just tested locally)

ModuleNotFoundError: No module named 'ipywidgets.embed'

Re: Any volunteer to evaluate/fix Python3.9 issues in python-cogent?

[Michael Crusoe]

FYI: python-cogent requires numba, numba (which is a just-in-time compiler
for Python) got removed from testing for not supporting Python 3.9 yet.

They finally backported a patch for numba, but the numba armhf tests are
failing https://qa.debian.org/excuses.php?package=numba They tried to work
around that with the last upload
https://tracker.debian.org/news/1222710/accepted-numba-0520-2-source-into-unstable/
but that didn't work yet.

Python-cogent also depends on jupyter-sphinx and that package is also in a
tough place: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950598

On Tue, 26 Jan 2021 at 12:03, Andreas Tille  wrote:

> Hi,
>
> python-cogent is not yet explicitly supporting Python3.9 and the
> packaging was excluding Python3.9 installation.  I removed this
> exclusion[1] since it makes cogent useless in Bullseye.  However, there
> are not really unexpected issues in the test suite.  Any volunteer to at
> least check the amount of work to port to Python3.9 and provide some
> patch for upstream?
>
> Kind regards
>
>  Andreas.
>
> [1]
> https://salsa.debian.org/med-team/python-cogent/-/commit/d0322de57301d93607fb72543894a5873bec372e
>
> --
> http://fam-tille.de
>
>

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

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

Re: [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.

Re: [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?

Re: [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

Re: [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 

Re: [Review needed] simde fixes for plast

[Michael Crusoe]

x86intrin.h is a catch-all, so I can't say without compiling the
application with it or examining the code myself. If it compiles on amd64
then you should be fine, but a quick check with cowbuilder-dist +
qemu-static is always warranted in such situations. Since it built on the
Arm64 porterbox I say you are good to go!

--
Michael R. Crusoe

On Sun, Dec 6, 2020, 12:36 Nilesh Patra  wrote:

>
>
> On Sun, 6 Dec 2020 at 01:49, Michael Crusoe 
> wrote:
>
>> Looks good to me!
>>
>
> Thanks a lot! Could you also once look at my fixes for ngmlr here[1]?
> I just wish to confirm if simde/x86/avx.h is a good-enough replacement
> for x86intrin.h
> (I'm able to build this in arm64 porter box)
>
> [1]: https://salsa.debian.org/med-team/ngmlr/-/tree/simde
>
> Thanks and regards
> Nilesh
>

Re: [Review needed] simde fixes for plast

[Michael Crusoe]

Looks good to me!

On Sat, 5 Dec 2020 at 21:01, Nilesh Patra  wrote:

> Hi,
>
> Plast currently has a RC bug[1] filed for FTBFS on arm64 arch(despite
> Arch: any-amd64 x32 in control file)
>
> I observed that this was using {e,p}mmintrin.h and hence I tried applying
> Michael's simde trick to make it build across other arches. I tried doing a
> patch, and I am able to build it in an arm64 porter box with my changes
> applied.
> (I do not have access to any other porter box at the moment, hence
> un-tested there)
>
> However since I'm pretty new to this stuff, I'm not sure if my changes are
> good to go - hence it'd be really great if Michael or anybody else could
> take a review and either upload, or give me a confirmation to go with the
> upload.
>
> I followed the steps in the wiki[2], and my changes are pushed to the
> simde branch of plast repository in salsa[3].
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976525
> [2]: https://wiki.debian.org/SIMDEverywhere
> [3]: https://salsa.debian.org/med-team/plast/-/commits/simde
>
> Thanks and Regards,
> Nilesh
>


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

Re: [COMBINE-lab/RapMap] rapmap v0.6.0

[Michael Crusoe]

Okay, now that we are on the same page we can address the main issue: in
Debian we have been only packaging RapMap in the service of salmon, using
the salmon tagged releases and version numbers.

We have not yet packaged sailfish, though bcbio uses it, so we have a new
reason to package it soon.



--
Michael R. Crusoe

On Tue, Feb 5, 2019, 17:39 Rob Patro  wrote:

> Hi Michael,
>
>   Indeed, Andreas is right.  The tagging scheme for RapMap is as follows.
> Versions of the code that are used as a library for salmon (or sailfish),
> are tagged as such.  That is, they have the `salmon-` prefix before the
> version.  This ensures that each release of salmon or sailfish is tied to a
> specific commit of rapmap for reproducible builds.  However, the master
> branch has versions tagged without any prefix (apart from `v`).  That being
> said, one of the main points of the recent release was to sync-up with all
> of the recent developments made in the develop-salmon branch, so that the
> next release on that branch `salmon-0.13.0` should be essentially the same
> as what was released in v0.6.0.
>
> Best,
> Rob
> On Feb 5, 2019, 4:57 AM -0500, Andreas Tille , wrote:
>
> Hi,
>
> On Tue, Feb 05, 2019 at 11:17:25AM +0200, Michael Crusoe wrote:
>
> We packaged rapmap for Debian because we were packaging salmon as well.
> Looks like we adopted the numbering of the salmon-v* release of rapmap
> (recently 0.12) so this 0.6.0 release will currently be ignored as it is
> numerically smaller.
>
> Is that okay with you? What would you like done in the future?
>
>
> As far as I understood (which does not mean that it is correct) new
> rapmap releases are featuring a 'salmon-' prefix and are closely related
> to salmon releases. This understanding is in fact in contrast to the
> recent rapmap 0.6.0 release and is not visible for our scanner for new
> releases that is at version 0.12 as Michael said.
>
> Kind regards
>
> Andreas.
>
> În mar., 5 feb. 2019 la 06:59, Rob Patro  a
> scris:
>
> This release brings the master branch and tagged release up to date with
> many of the bug fixes, developments and improvements that have been going
> into the develop-salmon branch in support of salmon development. Among
> the most important new features in this release is the ability to have
> rapmap apply *selective-alignment* to improve the sensitivity and
> specificity of the mappings. For more details on *selective-alignment*
> and mapping validation, refer to the release notes of salmon
> <https://github.com/COMBINE-lab/salmon/releases/tag/v0.12.0> --- and
> specifically options related to the --validateMappings. This release also
> adds the ability to optionally write out unmapped reads in the output SAM
> with the -u flag.
>
> —
> You are receiving this because you are subscribed to this thread.
> View it on GitHub
> <https://github.com/COMBINE-lab/RapMap/releases/tag/v0.6.0> or unsubscribe
> <
> https://github.com/COMBINE-lab/RapMap/unsubscribe_via_email/ABROCCsHsxNxyPKPBTagcINRPBQDlL_rks5vKQ-jgaJpZM4CTBbL
> >
> from all notifications for this repository.
>
>
>
> --
> Michael R. Crusoe
> Co-founder & Lead, Common Workflow Language project
> <http://www.commonwl.org/>
> Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
> https://orcid.org/-0002-2961-9670
> <https://impactstory.org/u/-0002-2961-9670>
> m...@commonwl.org
> +1 480 627 9108 / +370 653 11125
>
>
> --
> http://fam-tille.de
>
>

Re: Project idea: port GKL to non-x86

[Michael Crusoe]

With https://salsa.debian.org/java-team/gkl/-/merge_requests/3 I am able to
build a GKL package that runs on non-amd64 (though probably at a huge speed
sacrifice)

Using the resulting libgkl-java package and
https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
I am able to build and run Picards tools on arm64

On Sun, 9 Feb 2020 at 15:51, Jun Aruga  wrote:

> As I heard that igv, artemis depending on picard-tools depending on
> gkl (Intel specific code), I opened a ticket for picard-tools.
>
> This ticket might be a good start to make picard run on multiple CPUs.
> https://github.com/broadinstitute/picard/issues/1467
>
> On Sat, Feb 8, 2020 at 4:39 PM Michael Crusoe 
> wrote:
> >
> > Oh, I was mistaken about the GATK link.
> >
> > picard-tools depends on gkl, and igv and artemis depend on picard-tools
> >
> > On Sat, Feb 8, 2020 at 4:22 PM Jun Aruga  wrote:
> >>
> >> This part is related to building on ARM.
> >>
> >> > @GraceZou, You will have to build from source for ARM. The repo is
> gatk-bwamem-jni. There are instructions in the README on the repo landing
> page. Set the environmental variable to then point to the built library.
> >>
> >> On Sat, Feb 8, 2020 at 4:19 PM Jun Aruga  wrote:
> >> >
> >> > For GATK depending on GKL, I found an interesting page about building
> >> > GATK on ARM.
> >> >
> >> >
> https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
> >> > > We use GATK4-beta1 in ARM,and have several questions about it:
> >> >
> >> > Jun
> >> >
> >> > On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe <
> michael.cru...@gmail.com> wrote:
> >> > >
> >> > > https://github.com/Intel-HLS/GKL
> >> > > A Java wrapper around an Intel optimized implementations of
> PairHMM, Smith-Waterman, and DEFLATE.
> >> > >
> >> > > Uses SIMD intrinsics and assembly.
> >> > >
> >> > > At
> https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is a
> fork using the SIMD Everywhere library, but I lack the expertise to produce
> source versions of the many assembler only routines.
> >> > >
> >> > > Any suggestions / contributions?
> >> > >
> >> > > --
> >> > > Michael R. Crusoe
> >> >
> >> >
> >> >
> >> > --
> >> > Jun | He - His - Him
> >> > jar...@redhat.com / IRC: jaruga
> >>
> >>
> >>
> >> --
> >> Jun | He - His - Him
> >> jar...@redhat.com / IRC: jaruga
> >>
> >
> >
> > --
> > Michael R. Crusoe
>
>
>
> --
> Jun | He - His - Him
> jar...@redhat.com / IRC: jaruga
>
>

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

Re: testing the test environment

[Michael Crusoe]

Dear Maarten,

I know how frustrating it can be!

Does
https://ci.debian.net/doc/file.MAINTAINERS.html#label-How+can+I+reproduce+the+test+run+locally-3F
help? I use both the pbuilder hook and sbuild with lxc setups.

The pbuilder hook is convenient as it gets run everytime I build a package
with pbuilder (I actually use cowbuilder-dist, but it is all the same).
However it inherits all the build-depends from the source package, which
might be more than is defined in debian/tests/control. So if I'm having a
specific autotesk issue I use the sbuild route. Sbuild can also test a
modified debian/tests/* without rebuilding a package, which can save a lot
of time in some circumstances.

--
Michael R. Crusoe

On Sun, Nov 8, 2020, 12:51 Maarten L. Hekkelman 
wrote:

> Hi,
>
> Is it possible to test (debug) the environment in which packages are built
> and packaged? Or do I continue by guessing what might cause a problem and
> try to see if my guess is correct by submitting a new version?
>
> Libzeep e.g. has test code and this fails with a 'host not found' error.
> This is probably because my test code tries to connect to 127.0.0.1 and I
> should perhaps have used 'localhost' instead. But I'm not sure if that will
> work. So now I can create a patch replacing the numeric version with the
> string and hope this will work. I'd rather be sure this is the fix needed
> before I submit another version.
>
> regards, -maarten
>
>

Re: Planning a Debian Med Covid-19 project

[Michael Crusoe]

I would recommend getting as many components of
http://covid19.genenetwork.org/ packaged for Debian as possible.

Workflows are at
https://github.com/hpobio-lab/viral-analysis/tree/master/cwl/pangenome-generate

Maybe someone can start by identifying the software used and seeing which
is already packaged for Debian?

Currently the workflows are run on Arvados. How is the packaging of Arvados
coming along?

--
Michael R. Crusoe

On Fri, Nov 6, 2020, 17:50 Steffen Möller  wrote:

> Dear all,
>
> We have multiple aims. Here are mine:
>
> a) do something good
> b) show to the world that our infrastructure is usable
> c) do something that is not redundant
> d) be educational
> e) come up with findings that can be reproduced
> f) have it all automated, preferably in a way that it can be adapted for
> other diseases/symptoms/whatever.
>
> Idea: We do not go for a single paper that we want to reanalyse (would
> be redundant at best) but get _all_ RNA-seq raw data on Covid-19. I
> thought about  using PiGx-rnaseq (bcbio is not ready) to get us read
> counts and the typical gene set enrichment analyses. With that many
> samples, we should also have options for downstream analyses for which
> earlier efforts possibly lacked the statistical power.
>
> How do you feel about this? Should we prepare a Virtual Sprint for it?
>
> Best,
>
> Steffen
>
>

Re: Videoconference Friday 2020-09-18 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))

[Michael Crusoe]

Thanks for the invitation. I'm on vacation until September 28th so I won't
be able to join.

--
Michael R. Crusoe

On Fri, Sep 18, 2020, 13:38 Andreas Tille  wrote:

> Hi,
>
> in case you might be interested in dealing with test data for Debian
> Med it would be great if you would join our meeting since we should
> put this on our agenda for today and we need expert input.
>
> Kind regards
>
>  Andreas.
>
> On Thu, Sep 17, 2020 at 10:52:40PM +0200, Andreas Tille wrote:
> > Hi,
> >
> > this is the last weekly call for our Debian Med video meeting.  Than
> > we will switch to a two meetings per month meeting.  We will shift
> > weekdays by simply meeting on every
> >
> >2th  and  17th
> >
> > of a month.  So after tomorrow the next meeting will be on 2020-10-02.
> >
> > The last weekly call for a Debian Med COVID-19 video conference will be
> > tomorrow and as always newcomers are welcome.
> >
> > For those who would like to join our next videomeeting it will happen at
> > Friday
> >
> >
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference=20200918T20=37=1
> >
> > The meeting is on the Debian Social channel
> >
> >  https://jitsi.debian.social/DebianMedCovid19
> >
> > These weekly video meetings were started in the Debian Med
> > Biohackathon[1].  The topic is what contributors have done in the past
> > week and to coordinate the work for next week.  Here are the reports
> > of some past meetings:
> >
> >  https://wiki.debian.org/DebianMed/Meeting/WeeklyCovid19
> >
> > To repeat myself: Newcomers are always welcome.
> >
> > Have fun
> >
> >Andreas.
> >
> > [1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>

Re: [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
>
>

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

[Michael Crusoe]

tags 966433 pending
tags 966270 pending

thanks

I've got a fixed version of a release candidate of seqan3 3.0.2 in salsa.
However it needs an updated range-v3 which has yet to be uploaded: see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968053

I can upload the seqan3 3.0.2 release candidate with a code copy of the
fixed range-v3, but as no packages build-depend on seqan3 I don't see the
rush. Please feel free to correct my mis-understanding.

On Thu, Aug 13, 2020 at 9:39 PM Andreas Tille  wrote:

> Hi folks,
>
> I tried to reproduce the issue.  When I try to run the test in a chroot I
> get:
>
> ...
>Required dependency:Range-V3 found.
> --   Required dependency:SDSL found.
> --   Optional dependency:Cereal found.
> --   Optional dependency:Lemon not found.
> --   Optional dependency:ZLIB-1.2.11 found.
> --   Optional dependency:BZip2-1.0.8 found.
> --   Optional dependency:libexecinfo found.
> --   SeqAn3 platform.hpp build:  passed.
> -- Found SeqAn3: /usr/include..
> CMake Error at
> /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:104 (include):
>   include could not find load file:
>
> seqan3_test_component
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (include)
>
>
> CMake Error at
> /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:105 (include):
>   include could not find load file:
>
> seqan3_test_files
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (include)
>
>
> CMake Error at
> /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:106 (include):
>   include could not find load file:
>
> seqan3_require_ccache
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (include)
>
>
> CMake Error at
> /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:107 (include):
>   include could not find load file:
>
> seqan3_require_benchmark
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (include)
>
>
> CMake Error at
> /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:108 (include):
>   include could not find load file:
>
> seqan3_require_test
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (include)
>
>
> CMake Error at
> /tmp/autopkgtest.olJ5KS/autopkgtest_tmp/seqan3-test.cmake:109 (include):
>   include could not find load file:
>
> add_subdirectories
> Call Stack (most recent call first):
>   CMakeLists.txt:11 (include)
>
>
> CMake Error at CMakeLists.txt:32 (seqan3_require_ccache):
>   Unknown CMake command "seqan3_require_ccache".
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/tmp/autopkgtest.olJ5KS/autopkgtest_tmp/build_unit/CMakeFiles/CMakeOutput.log".
> See also
> "/tmp/autopkgtest.olJ5KS/autopkgtest_tmp/build_unit/CMakeFiles/CMakeError.log".
>
>
> For me this looks as if test/seqan3-test.cmake needs some patches.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Re: How to handle patches during a routine update ?

[Michael Crusoe]

Hey Charles,

Here is what I do in this circumstance.

1. `quilt pop -a` to remove all patches
2. `quilt push` one patch at a time. If I see that there was any fuzzing,
then I do a `quilt refresh` before the next `quilt push`.
3. If a patch does apply cleanly I investigate to see if it should be
removed entirely with `quilt delete patchname && git rm
debian/patches/patchname` or fixed via `quilt push -f` and editing the
files indicated in one terminal while reviewing the corresponding `*.rej`
files in another terminal. `quilt refresh` when I'm done fixing the patch,
then continue with step 2
4. When I'm done, I `dch "Refreshed patches" && debcommit -a` or similar

Maybe others have a better method, I'm curious to hear from them as well.

Cheers,

On Wed, Aug 12, 2020 at 12:03 PM Charles Plessy  wrote:

> Hello everybody,
>
> I did not realise how rusty my skills became...
>
> At the moment my main problem is how to handle patch updates.
>
> My specific question here is: after I run routine-update, the process is
> paused with the following message:
>
> W: There is fuzz in some patches.
>Please use another terminal to inspect patches and press RET here
> once ready
>
> I do not know what I am supposed to do to be ready: edit the files ?
> Edit the patches ?
>
> With your precious help, I will not only update this package but also
> update the information in our team policy :)
>
> https://med-team.pages.debian.net/policy/#handling-patches
>
> Have a nice day,
>
> Charles
>
> --
> Charles Plessy
> Debian Med packaging team,
> http://www.debian.org/devel/debian-med
> Akano, Uruma, Okinawa, Japan
>
>

-- 
Michael R. Crusoe

Re: VIP

[Michael Crusoe]

On Wed, Jul 8, 2020 at 3:16 PM Tony Travis <
tony.tra...@minke-informatics.co.uk> wrote:

> Re: https://github.com/keylabivdc/VIP
>
> Hi,
>

Hey Tony,


> Does anyone have experience of running VIP?
>

I don't, but I've taken a look.


> I've been trying to get it working under Ubuntu 18.04/20.04 with
> Debian-Med installed in a Bioconda environment, but I've only managed to
> get it running in the author's Ubuntu 14.04 VIP Docker container...
>

Perhaps try the author's vip2 container?
https://hub.docker.com/r/yang4li/vip2 Though I can find no source for
either container, so it is a bit risky.

The yang4li/vip-docker container uses a very old version of mafft, from
2013.


> It's running, but very slowly, and "mafft" is only running on one core
> even though there are 24 cores available and the "mafft" command-line
> specifies 12 cores. I think it might be caused by running it on an AMD
> Opteron 6000 that does not support SSE2 instructions, but any advice
>

FYI: Mafft does not appear to use SSE2 in its codebase. I checked and the
32-bit mafft 7.467-1 binaries have no SSE2 operands. The 64-bit version
(amd64) does use SSE2, probably due to optimizations by the compiler.

Anyhow, I thought the AMD Opterons are 64bit? Then the do support SSE2 for
sure and
https://en.wikipedia.org/wiki/List_of_AMD_Opteron_microprocessors#Opteron_6100-series_%22Magny-Cours%22_(45_nm)
says they support SSE3 as well.

about VIP would be welcome - It's been running for a week now :-(
>

Could be that mafft has reached a point in the computation that is still
single threaded.

Their script specifies 8 threads:
https://github.com/keylabivdc/VIP/blob/d69b5e7615d8da76ef0dd66e51867c8ec42588d4/MSA.sh#L28

Though that is a different script than in the container, where it
references `--thread $total_cores` where `total_cores` appears to be set to
half of your available cores. Which matches your 12 of 24 cores report.

You could replace that `--threads $total_cores` with `--threads -1` to see
if that helps.


> We're using the pipeline to check Tetse fly microbiota for viruses, but
> it may also be useful for Covid-19 work because the host databases are
> human by default.
>
> Thanks,
>
>Tony.
>

-- 
Michael R. Crusoe

Re: raxml-ng dependency not already packaged

[Michael Crusoe]

When a git submodule is being used, please check the exact commit
referenced in the repository. In this case raxml-ng uses
https://github.com/ddarriba/pll-modules/commit/7a0715a7d8e3c30ae86819425e876d96949d3f4d
(from 2019-11-27, from the 'dev' branch, but not the latest commit from
that branch) and the pll-modules package that was submitted to the NEW
queue is packaging
https://github.com/ddarriba/pll-modules/commit/d6cc565b67ee583daa20363bd0dce19825bf
(from 2019-08-09, the latest commit of their 'master' branch)


On Sun, May 31, 2020 at 5:51 PM Andreas Tille  wrote:

> Hi Shayan,
>
> On Sun, May 31, 2020 at 04:32:25PM +0100, Shayan Doust wrote:
> > Sounds good! Unfortunately, there are no github releases for
> > pll-modules[3] and the last commit pushed was back in 2017 with pending
> > pull requests and issues open for over a year now, so I fear that the
> > author is unresponsive. Would it be acceptable policy-wise if I was to
> > locally create an upstream tarball and package that way as there is no
> > upstream release for uscan to work on?
>
> Uscan knows git mode - I injected the result to
>
>https://salsa.debian.org/med-team/pll-modules
>
> Feel free to keep on working on this
>
>   Andreas.
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Re: Debian package bcftools

[Michael Crusoe]

[I'm cc'ing the Debian Med mailing list as your email contains no private
information]

Dear Giulio,

It is nice to hear that you are finding the Debian package of bcftools
useful. The correct way to request support from the volunteer contributors
to Debian is to documented at https://www.debian.org/Bugs/Reporting

Cheers!

--
Michael R. Crusoe

On Sat, Jun 13, 2020, 20:0 Giulio Genovese 
wrote:

> Hi Michael,
>
> I have noticed you are involved in the packaging of the bcftools software
> as a debian package. I am not sure whether you are the right person I
> should address, but if not maybe you can help me find who I should address
> instead.
>
> I have been working with bcftools and in particular with dockers that must
> run bcftools inside. This is all made very simple by the bcftools debian
> package. However, I have noticed that the approach of installing bcftools
> as a debian package causes apt-get to also pull perl and perl modules which
> cause the docker image to increase in size significantly. The bcftools
> package contains a handful of python and perl binaries, but the main
> software is written in C and has very few dependencies. Currently python is
> a suggested dependency, while perl is a mandatory dependency. This seems a
> bit inconsistent. Could the perl dependency also be made optional? This
> would go a long way making it easier to generate minimalistic docker images
> with a minimal footprint using apt-get.
>
> All the best,
>
> Giulio
>

Re: Please review the announcement for second Debian Med COVID-19 hackathon

[Michael Crusoe]

Thank you Andreas for drafting this announcement, I committed some small
tweaks.

We should list explicitly when we are having video chats. I recommend at
least 3: beginning, middle, and end.

This provides a nice opportunity to meet new contributors.

Can you pick times that work for you and add them to the announcement?

On Thu, Jun 4, 2020 at 3:31 PM Andreas Tille  wrote:

> Hi folks,
>
> due to the great success of the hackathon in April in one of the last
> weekly video meetings we agreed to do another hackathon.  I've drafted
> an announcement mail here:
>
>
> https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/blob/master/202006_Debian-Med_hackathon.md
>
> Please review and enhance ... and finally join our next hackathon in
> mid-June. :-)
>
> Kind regards and thanks to all who contributed
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Re: sonLib - anyone working with it, addressed packaging?!?

[Michael Crusoe]

On Fri, May 22, 2020 at 5:30 PM Steffen Möller 
wrote:

> Hello,
>
> https://github.com/ComparativeGenomicsToolkit/sonLib should be the same
> as / cleaned-up version of
> https://github.com/benedictpaten/sonLib


The later is currently a code copy in https://tracker.debian.org/pkg/vg It
is also not quite the same as
https://github.com/ComparativeGenomicsToolkit/sonLib


> which I need to address the packaging of
>
> https://github.com/benedictpaten/marginPhase
>
> which again is needed for some recent fancy Nanopore assembler.
>
> On https://github.com/benedictpaten/sonLib/graphs/contributors I saw
> mr-c listed as a contributor. @Michael, can you direct me a bit? Anyone
>

My only contribution was a Makefile clean up; I'm ignorant otherwise :-P


> Cheers,
>
> Steffen
>
>

-- 
Michael R. Crusoe

Re: staden-io-lib_1.14.12-1_source.changes ACCEPTED into unstable

[Michael Crusoe]

Hey Steffen,

Did you see my version for experimental
https://salsa.debian.org/med-team/staden-io-lib/-/commits/debian/experimental/
?

I was testing the reverse dependencies, since the ABI changed. I must admit
to having forgotten about this package.

I'll cherry pick some of those commits for a -2 source only upload. Note, I
never got 1.14.12 to build on s390x ...

On Thu, May 21, 2020 at 1:04 AM Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:

>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Mon, 10 Feb 2020 10:51:13 +0100
> Source: staden-io-lib
> Architecture: source
> Version: 1.14.12-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team <
> debian-med-packag...@lists.alioth.debian.org>
> Changed-By: Michael R. Crusoe 
> Changes:
>  staden-io-lib (1.14.12-1) unstable; urgency=medium
>  .
>* Team upload.
>  .
>[ Michael Crusoe ]
>* New upstream version
>* Standards-Version: 4.5.0 (routine-update)
>* debhelper-compat 12 (routine-update)
>* Remove many patches incorporated upstream
>* autopkgtest: s/ADTTMP/AUTOPKGTEST_TMP/g (routine-update)
>  .
>[ Steffen Moeller ]
>* Fixed FTBFS - added dep on libhtscodecs-dev now distributed
>  as a git submodule of staden-io-lib.
>* Rules-Requires-Root: no
>* Adjusted library package name to updated soversion 14
>* Added extra argument to d-shlibmove to override search for
>  unversioned libhtscodecs-dev package
> Checksums-Sha1:
>  1a0110cb4bf61e572522600cacc2f40c738be8b1 2476 staden-io-lib_1.14.12-1.dsc
>  a65bfd4cd7325193ddc49f10a31f8f03d25830c4 3367005
> staden-io-lib_1.14.12.orig.tar.gz
>  d4d5b59e9c5cf431195f761b94ee41c9ab3bfaa6 11392
> staden-io-lib_1.14.12-1.debian.tar.xz
>  72424d5eb43b2dee3ac4acbed2278a1e01270a00 6953
> staden-io-lib_1.14.12-1_source.buildinfo
> Checksums-Sha256:
>  c57e36464e864bdce16d4715bf2940004db2823a25d2b262fd4d60b1900391de 2476
> staden-io-lib_1.14.12-1.dsc
>  34339605809bfef30874792d7ec44b7d399cbdfa1bf5fb868237429339a0ef99 3367005
> staden-io-lib_1.14.12.orig.tar.gz
>  cc829f938325ac9c902adb054c4071b33de9f9fe1948db3eec8da62adc4136df 11392
> staden-io-lib_1.14.12-1.debian.tar.xz
>  c5fe04f25f0a12b0a394a1f776f29bdf3815eab44288f1e4f2df279ac931efaf 6953
> staden-io-lib_1.14.12-1_source.buildinfo
> Files:
>  bc426ba40fb9028a9dc5c990e655eefe 2476 science optional
> staden-io-lib_1.14.12-1.dsc
>  c49b2d08035b7e1ff062aea1c44b2aa5 3367005 science optional
> staden-io-lib_1.14.12.orig.tar.gz
>  d86bc7a54e5f2e09509ac920ef4146e0 11392 science optional
> staden-io-lib_1.14.12-1.debian.tar.xz
>  d346195239476f0c33bf62732ad98ddc 6953 science optional
> staden-io-lib_1.14.12-1_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEhMGXeonn7+0+XKYuL9i+2sAg7tEFAl7FseMACgkQL9i+2sAg
> 7tHL8BAAqFikqHfJnBAPeo6fopzRM1rWdOgkqh5z4mqgyplO8dQ9fEQBtYc4loo3
> SdGMbv+tfXdZxRF0i9YbCO41ZP4bJ8tEgcefB2x2a4+3+pm30r0XWGFlloyOn0Mz
> QpZr45/vU6ZicA6h4IKhP1m9vwh+dynp3mgS46PyIXjUrYaTydlh7U9Q3WrPa1Dw
> u81NmvxTD1NLT331RKw5XQvv9hBTP6km9xhB2kYNUpQzQPYA8reNHJN2DPLLOr70
> PHpAUTuoLFXJH5QyAbl4vzem/yWFmDTN476WRmIhyhpOXyWKV1C4DuZuzXjoH9Vu
> RpcVOnbm7rLCW/UfrgS/dVIbpHZYVLvrMXAYBnPm4bmcFPP0Ck5zDdnqeR0f1Qsc
> Oxm7hzjFIEe5KPeXpJO3scErl4/pwfMGVpZTpzEkIrbffhThADJIhUBjL1SRH1nf
> YxxPrA6fPe+d/a0+5PzhRdDpTfH2FsVURBFKjGlQqV2uxfYqsEkkSA1lNGPepfVc
> XpUY7S4gE3ZvK0lSbU527pvxYu1fqJSWmzYS/SOyMK9nX+K8d3PmfHZY1qO3pMhD
> YN3yLzFGfMbwE2ffO2tVpDuRBiPap9wvcXcgEVicAdybi2wGe0iUPVx1YAWeBFez
> n8Zl6KhWvRL8URTql/FVnMthOinT+rP9jY8qLd4MfcV4q8i1WEs=
> =roZN
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.
>


-- 
Michael R. Crusoe

Re: deb packages using simde but the upstream PR not sent?

[Michael Crusoe]

Hey Jun,

Thanks for this.

Yes, any package in https://wiki.debian.org/SIMDEverywhere#Packages_Status
that lists "Not yet" under "Patches sent upstream?" is available for
sending a PR

On Mon, May 18, 2020 at 11:01 AM Jun Aruga  wrote:

> Hi,
>
> Thanks for adding simde patch to support minimap2 and bwa debian
> package to support non-x86_64 architectures.
> I sent pull-requests for minimap2 and bwa based on the patch yesterday.
>
> https://github.com/lh3/minimap2/pull/607
> https://github.com/lh3/bwa/pull/283
>
> Are there any other deb packages that the simde patch is applied to,
> but the upstream pull-request has not been sent for yet?
>
> Here is the package status I know.
> https://wiki.debian.org/SIMDEverywhere
>
> Thanks.
>
> --
> Jun | He - His - Him
>
>

-- 
Michael R. Crusoe

Re: RFS paml - fixed #957659

[Michael Crusoe]

On Fri, May 8, 2020 at 2:27 PM Étienne Mollier 
wrote:

> Good day,
>
>
> I have not forwarded the patch for the moment, since reporting
> bugs requires posting in a Google Group that forbids contact
> through email, and I have no Google account for the moment, at
> least none usable to my knowledge.  :(
>

Feel free to use me as a mail forwarder :-)


-- 
Michael R. Crusoe

Re: SIMDe use in Debian's MMseqs2

[Michael Crusoe]

Here's a version of Debian's SIMD Everywhere patch as a pull request for
MMseqs2 https://github.com/soedinglab/MMseqs2/pull/309

On Fri, May 8, 2020 at 9:15 PM Michael Crusoe 
wrote:

> [replying on the debian-med list with permission. Please keep Martin and
> Milot CC'd as they do not subscribe]
>
> On Fri, May 8, 2020 at 7:36 PM Milot Mirdita  wrote:
>
>> Hi Michael,
>>
>> I am a developer on the MMseqs2 team and I saw your tweet regarding the
>> AWS ARM64 machines earlier and checked on Debian Salsa if it would be a lot
>> of work enabling ARM64 support with the next release as we worked on that
>> recently.
>>
>
> Hey Milot, thanks for your email!
>
> I saw that Debian's MMseqs2 now uses SIMDe to abstract away different
>> architectures. While this is a very cool technical achievement, I am very
>> uncomfortable with it without being properly integrated into and monitored
>> by our CI regression testing.
>>
>> During ARM64 development I found that there are a lot of subtle issues
>> that can result in differing sensitivity between architectures (e.g.
>> ARM64's default unsigned char type causes issues, there are many crashes on
>> 32-bit ARM). I am also worried that our two most important platforms
>> (SSE4.1 and AVX2) might suffer from performance regressions.
>>
>
> Interesting! On Debian we have to provide binaries that respect the
> architecture baseline. That means no SSE-, SSE2-, only binaries on
> i386/i686 and no SSE3+ only binaries on AMD64. So that's why we compile
> mmseqs2 multiple times, so there is a version that doesn't violate the
> baseline, along with versions that should match the highest level of SIMD
> support available on the user's CPU.
>
> https://salsa.debian.org/med-team/mmseqs2/-/blob/master/debian/rules#L22
>
>
> https://salsa.debian.org/med-team/mmseqs2/-/blob/master/debian/bin/simd-dispatch
>
>
>>
>> We will have ARM64 and hopefully also PPC64LE support in the next
>> release. I would suggest to either wait and use our upstream code, or
>> submit a PR with your changes to us and see how we can integrate everything
>> correctly.
>>
>
> Sure, happy to send the patches! I meant to, but hadn't gotten around to
> it yet
>
> https://wiki.debian.org/SIMDEverywhere#Packages_Status
>
>
>>
>> Also I would be very glad if you could integrate the full regression
>> suite to spot if all architectures  produce consistent results. You can run
>> the regression by calling from the repository:
>> git submodule update --init
>> ./util/regression/run_regression.sh ./path-to-mmseqs-binary
>> scratch-directory
>>
>
> Oh yeah, would love to! Except we need all the upstream sources in a
> single tarball, which git submodules + GitHub releases makes difficult. So
> if you can add a pure source (with all git submodules) tarball to
> https://github.com/soedinglab/MMseqs2/releases that would be appreciated!
>
>
>>
>> We had refactored this test suite to make it as easy as possible to use
>> for Shayan who initially had proposed to package MMseqs2 for Debian. The
>> test subfolder is badly named and contains scratch scripts for feature
>> development. They don't do anything useful for testing such as finding
>> performance or sensitivity drops.
>>
>
> Noted.
>
>
>> Thanks for your work and best regards,
>>
>
> Thank you for sharing your work under a F/OSS license and for your
> contributions to Open Science!
>
>
>> Milot
>>
>
>
> --
> Michael R. Crusoe
>


-- 
Michael R. Crusoe

Re: SIMDe use in Debian's MMseqs2

[Michael Crusoe]

[replying on the debian-med list with permission. Please keep Martin and
Milot CC'd as they do not subscribe]

On Fri, May 8, 2020 at 7:36 PM Milot Mirdita  wrote:

> Hi Michael,
>
> I am a developer on the MMseqs2 team and I saw your tweet regarding the
> AWS ARM64 machines earlier and checked on Debian Salsa if it would be a lot
> of work enabling ARM64 support with the next release as we worked on that
> recently.
>

Hey Milot, thanks for your email!

I saw that Debian's MMseqs2 now uses SIMDe to abstract away different
> architectures. While this is a very cool technical achievement, I am very
> uncomfortable with it without being properly integrated into and monitored
> by our CI regression testing.
>
> During ARM64 development I found that there are a lot of subtle issues
> that can result in differing sensitivity between architectures (e.g.
> ARM64's default unsigned char type causes issues, there are many crashes on
> 32-bit ARM). I am also worried that our two most important platforms
> (SSE4.1 and AVX2) might suffer from performance regressions.
>

Interesting! On Debian we have to provide binaries that respect the
architecture baseline. That means no SSE-, SSE2-, only binaries on
i386/i686 and no SSE3+ only binaries on AMD64. So that's why we compile
mmseqs2 multiple times, so there is a version that doesn't violate the
baseline, along with versions that should match the highest level of SIMD
support available on the user's CPU.

https://salsa.debian.org/med-team/mmseqs2/-/blob/master/debian/rules#L22

https://salsa.debian.org/med-team/mmseqs2/-/blob/master/debian/bin/simd-dispatch


>
> We will have ARM64 and hopefully also PPC64LE support in the next release.
> I would suggest to either wait and use our upstream code, or submit a PR
> with your changes to us and see how we can integrate everything correctly.
>

Sure, happy to send the patches! I meant to, but hadn't gotten around to it
yet

https://wiki.debian.org/SIMDEverywhere#Packages_Status


>
> Also I would be very glad if you could integrate the full regression suite
> to spot if all architectures  produce consistent results. You can run the
> regression by calling from the repository:
> git submodule update --init
> ./util/regression/run_regression.sh ./path-to-mmseqs-binary
> scratch-directory
>

Oh yeah, would love to! Except we need all the upstream sources in a single
tarball, which git submodules + GitHub releases makes difficult. So if you
can add a pure source (with all git submodules) tarball to
https://github.com/soedinglab/MMseqs2/releases that would be appreciated!


>
> We had refactored this test suite to make it as easy as possible to use
> for Shayan who initially had proposed to package MMseqs2 for Debian. The
> test subfolder is badly named and contains scratch scripts for feature
> development. They don't do anything useful for testing such as finding
> performance or sensitivity drops.
>

Noted.


> Thanks for your work and best regards,
>

Thank you for sharing your work under a F/OSS license and for your
contributions to Open Science!


> Milot
>


-- 
Michael R. Crusoe

Re: Help for asking upstreams about free licenses urgently needed (Was: Help: Seeking source code of guppy base caller)

[Michael Crusoe]

The guppy binary license is
https://nanoporetech.com/sites/default/files/s3/terms/Nanopore-product-terms-and-conditions-nov2018-v2.pdf
No source code is provided. No competitors of the company may use the
software. Must be for "research use only".

https://github.com/nanoporetech/flappie/blob/master/LICENCE.txt
"Oxford Nanopore Technologies, Ltd. Public License Version 1.0" is used to
license some of their "source available" software
Only permits "research purposes", violating DFSG guideline #6 "No
Discrimination Against Fields of Endeavor"

https://github.com/haotianteng/Chiron/blob/master/LICENSE.md is the Mozilla
Public License and is DFSG compatible

On Mon, Apr 27, 2020 at 6:40 PM Ben Tris  wrote:

> Sorry to pop in.
> I think this license should be reviewed,
> unless sure it is not a free license.
> To me it looks like a free software license.
> Although not understand most.
>
> What is making this license non-free?
>
> On 27-04-20 17:06, Jun Aruga wrote:
> > On Mon, Apr 27, 2020 at 4:43 PM Andreas Tille  wrote:
> >> Hi again,
> >>
> >> this brings up again my point: We *really*, *really* should take the
> >> chance right now to ask upstreams for free licensing.  The time is good.
> >> We just need somebody who is really doing this.
> > For us, the free licensing is good. But for the company nanopore
> > technologies it is their core competency.
> > I am not sure we can make it happen, but it might be worth trying to ask.
> >
> >> On Mon, Apr 27, 2020 at 04:21:12PM +0200, Michael Crusoe wrote:
> >>> Extracting the linked deb, one finds a binary and a very restrictive
> >>> license. I do not believe that guppy source code is available nor it is
> >>> likely to become available any time soon.
> >>>
> >>> While some of their other basecallers have source code available, I
> would
> >>> not call the license OSS:
> >>> https://github.com/nanoporetech/flappie/blob/master/LICENCE.txt
> > I found guppy client software that might be an alternative to use
> > guppy's function.
> > https://github.com/nanoporetech/pyguppyclient
> >
> > As Michael mentioned, checking other basecallers for nanopore, then
> > communicating the nf-core/nanoseq project using the alternative base
> > caller optionally.
> >
> > I found an interesting document about the basecallers.
> > https://github.com/rrwick/Basecalling-comparison
> >
> > Performance of neural network basecalling tools for Oxford Nanopore
> sequencing
> >
> https://genomebiology.biomedcentral.com/articles/10.1186/s13059-019-1727-y
> >
> >> In this study, we tested four basecalling programs developed by ONT –
> Albacore, Guppy, Scrappie and Flappie
> >> ...
> >> We also tested Chiron (https://github.com/haotianteng/Chiron), a
> third-party basecaller still under development that uses a deeper neural
> network than ONT’s basecallers [3].
> > The third party basecaller Chiron's license is Mozilla Public License,
> v. 2.0.
> > https://github.com/haotianteng/Chiron/blob/master/LICENSE.md
> >
>
>

-- 
Michael R. Crusoe

Re: Help: Seeking source code of guppy base caller (Was: Idea wanted: What is the most key open source projects to fight COVID-19?)

[Michael Crusoe]

Extracting the linked deb, one finds a binary and a very restrictive
license. I do not believe that guppy source code is available nor it is
likely to become available any time soon.

While some of their other basecallers have source code available, I would
not call the license OSS:
https://github.com/nanoporetech/flappie/blob/master/LICENCE.txt



On Mon, Apr 27, 2020 at 2:58 PM Andreas Tille  wrote:

> Hi,
>
> I also tried my luck to find the source code for guppy base caller - but
> failed.  It would of great help if somebody could find out.
>
> Thanks a lot Jun for giving detailed hints so far
>
>  Andreas.
>
> On Fri, Apr 24, 2020 at 08:41:22PM +0200, Jun Aruga wrote:
> > > >
> https://github.com/nf-core/nanoseq/blob/master/bin/scrape_software_versions.py
> > > > guppy
> > > Missing in Debian.  Is it this project
> > >https://staff.aist.go.jp/yutaka.ueno/guppy/  ?
> >
> > Hi, Andreas,
> > No, it seems that guppy is a base caller provided by Oxford Nanopore
> > technologies.
> >
> > ```
> > $ pwd
> > /home/jaruga/git/nf-core/nanoseq
> >
> > $ grep -r guppy *
> > ...
> > conf/base.config:  container = 'genomicpariscentre/guppy-gpu:3.4.4'
> > conf/base.config:  container = 'genomicpariscentre/guppy:3.4.4'
> > ...
> >
> > Then check the containers Dockerfile.
> >
> > https://hub.docker.com/r/genomicpariscentre/guppy/dockerfile
> > > wget -q
> https://mirror.oxfordnanoportal.com/software/analysis/ont_guppy_cpu_${PACKAGE_VERSION}-1~xenial_amd64.deb
> >
> > https://hub.docker.com/r/genomicpariscentre/guppy-gpu/dockerfile
> > > wget -q
> https://mirror.oxfordnanoportal.com/software/analysis/ont_guppy_${PACKAGE_VERSION}-1~xenial_amd64.deb
> > ```
> >
> > It might not be open source software, seeing the following page.
> > Here is a user's page about guppy in Japanese. I could not find the
> > English page.
> > You can see the guppy's screen shot on
> > https://community.nanoporetech.com/downloads page.
> >
> > http://kazumaxneo.hatenablog.com/entry/2020/01/19/145940
> >
> > > Thanks again Jun for your very helpful contribution
> >
> > You are welcome. Let me comment on your comments later.
> >
> > Cheers,
> > Jun
> >
> > --
> > Jun | He - His - Him
> >
> >
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Re: [covid-19] Reviving tensorflow packaging effort (Was: Missing dependancies for streamlit)

[Michael Crusoe]

On Sat, Apr 25, 2020, 12:36 Mo Zhou  wrote:

> Hi Tille,
>
> Is there any COVID-19 package using pytorch blocked due to its absense?
>
> A good news is that I've managed to strip the whole third_party/
> directory of src:pytorch, and started to forward my patches to upstream[1].
> When all my modifications entered the upstream repo, I'll be quite
> confident that our src:pytorch package can enter the archive without
> any (annoying) embedded sources [2].
>
> What I'm doing now is to wait for the upstream to merge my commits, and
> for the ftp-masters to accept my NEW dependency packages.
>
> In that sense, I'd like to take the COVID-19 shortcut to pass NEW
> quickly, if any COVID-19 related package needs pytorch.
>
> --- According to my status page
> https://qa.debian.org/developer.php?login=lumin
> these are the NEW dependency packages:
>
> fp16
> fxdiv
> gloo
> onnx
> psimd
> pthreadpool
>

Go ahead and add them to
https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/NEW-Requests



> I'll start to re-debianize src:pytorch from scratch when all of my
> commits had been upstreamed.
>

Any reason to not add the removed files/folders to the Files-Excluded
stanza of debian/copyright and repack the source while you wait?


> --- all of my on-going work are publically available:
> https://salsa.debian.org/deeplearning-team
> https://github.com/cdluminate/pytorch (messy, not rebased yet)
> The links to my PRs can be found on [1]
>
> [1] https://github.com/pytorch/pytorch/issues/14699
> [2] Finally, we will have a modern deep learning framework in the
> archive. It's better than having nothing even if I'm working on the
> cpu-only (free) version.
>
> On Wed, Apr 08, 2020 at 10:06:12AM +0200, Andreas Tille wrote:
> > Hi Mo,
> >
> > On Wed, Apr 08, 2020 at 02:46:06AM +, Mo Zhou wrote:
> > > On Tue, Apr 07, 2020 at 11:49:07AM +0200, Andreas Tille wrote:
> > > > On Tue, Apr 07, 2020 at 08:56:45AM +0100, Rebecca N. Palmer wrote:
> > > > > tensorflow 1.10 was packaged in experimental, but with reduced
> performance,
> > > > > and was removed because this was considered not worth it:
> > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935769
> > > >
> > > > Ah I simply forgot this.  Thanks for refreshing my mind.
> > >
> > > After that I tried to refresh the packaging and uploaded tensorflow 2.0
> > > to the NEW queue. The ftp-master complained about the embedded snapshot
> > > version of Eigen3. Ftp-masters are not convinced even if I said
> > > tensorflow FTBFS against the version shipped in our archive, and it
> > > could waste lots of my time and energy to patch the related code.
> >
> > I can understand your feeling.  I've re-read the discussion[1] about
> > including eigen3 into the tensorflow source.  The most promising
> > statement was given in
> >
> >
> https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-March/079169.html
> >
> >Sean Whitton spwhitton at spwhitton.name
> >Tue Mar 3 04:04:52 GMT 2020
> >
> >Rejected per your request, but from my point of view this discussion
> is
> >not over -- Policy 4.13 says that packages *should* not use
> convenience
> >copies of code, not that they *must* not.
> >
> >Thank you for all your work on uploading useful ML packages.
> >
> > At first: Thanks also from me!
> >
> > >From my point of view that is not a lost case so we should really try
> > again.
> >
> > > I was so angry at that time so I deleted my name from the maintainers
> > > and wrote the git message "I'm dropping this burden.".
> >
> > Well, sometimes personal feelings are dominating our actions.  I hope we
> > could form some real team around this to spread the technical as well as
> > the organisational burden.
> >
> > > So another kind notice for whoever is willing to take over tensorflow:
> > > also be prepared to fuss with ftp-master.
> >
> > I need to admit that I'm absolutely happy about ftpmaster.  They are
> > currently *extremely* supportive to our COVID-19 hackathon and > 30
> > packages made it from upload to unstable in less than 24 hours!
> >
> > Since I consider it a "promising time" to reach a lot for deep learning
> > tools in Debian which are frequently used in those tools to hunt down
> > COVID-19 I'd like to call for help here for trying again to get
> > tensorflow in - this time even with the Python3 module.
> >
> > Lumin has written an own build system for the C++ library since he has
> > found out that the upstream build system is not usuable for Debian.
> > Regarding the Python3 module he said that its not simply a matter of
> > adapting his build system but "significantly extend" it since the python
> > building process is much more complicated than the process for C++.
> >
> > Any takers for this task?
> >
> > Kind regards
> >
> >Andreas.
> >
> >
> > [1]
> https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-March/079054.html
> >
> > --
> > http://fam-tille.de
> >
>

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

[covid] Progress report, your feedback is needed!

[Michael Crusoe]

Hello all!

Today is last formal day of the 2020 COVID-19 BioHackathon, and I am really
impressed with everything we have accomplished this week!

Please give yourself credit for all your work by adding your name and a few
sentences about what you did to
https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/blob/master/report/paper.md

Either edit directly in the browser, push up a commit from your computer,
or feel free to make a Pull Request if you want extra feedback.

It is really important to explain what we have done as it helps explain the
value of Debian and packaging to others, helps us see exactly how much we
accomplished by working together, and makes it more attractive for others
to join us in the future.

Today may be the formal end of the BioHackathon, but not the end of this
work as the Debian Med team will continue to package and improve biomedical
software and you all are welcome to continue to contribute in any way you
wish.

Cheers!

-- 
Michael R. Crusoe

Re: [RFC] Update libssw? (Needed by parasail)

[Michael Crusoe]

I'm not against it, as long as it doesn't break any existing packages

--
Michael R. Crusoe

On Fri, Apr 10, 2020, 00:31 Nilesh Patra  wrote:

> Hiya,
>
> The upstream of libssw has version - 1.24 [1] mentioned in their code, and
> it seems the haven't made the releases properly.
> (This is not the case with the same file in Debian though)
> Andreas Tille has also opened an issue about the same for making suitable
> releases here [2].
>
> I'm right now trying to package parasail, which has a dependency on libssw
> (After removing the corresponding code copy). Using libssw available in
> debian's archive, I end up with this error [3].
>
> It appears that this is likely due to update in the upstream code. Hence,
> I would request switching libssw to git mode temporarily so as to make an
> update, and upload the same.
>
> Please excuse my brevity if in case this is my personal mistake, and has
> got nothing to do with libssw's update.
>
> [1]:
> https://github.com/mengyao/Complete-Striped-Smith-Waterman-Library/blob/master/src/ssw.c#L59
>
> [2]:
> https://github.com/mengyao/Complete-Striped-Smith-Waterman-Library/issues/72
>
> [3]: https://paste.debian.net/1139433/
>
> Thanks and regards
> Nilesh
>
>
>

Re: Additional info: can not see update note: Salmon

[Michael Crusoe]

Yes, see
https://salsa.debian.org/med-team/salmon/-/blob/master/debian/changelog#L10
for the latest TODO notice about the new puffefish dependency

On Wed, Apr 8, 2020 at 6:14 PM Ben Tris  wrote:

> https://tracker.debian.org/pkg/salmon
>
> This package seems regularly updated now v1.1.0:
>
> https://github.com/COMBINE-lab/salmon
>
>
> (I have no coding skills.)
>
>
>

-- 
Michael R. Crusoe

Re: Missing dependancies for streamlit

[Michael Crusoe]

https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

In general, tests are also allowed to access the internet. As this
> usually makes tests less reliable, this should be kept to a minimum; but
> for many packages their main purpose is to interact with remote web
> services and thus their testing should actually cover those too, to
> ensure that the distribution package keeps working with their
> corresponding web service.
>
> Debian's production CI infrastructure allows unrestricted network
> access, in Ubuntu's infrastructure access to sites other than
> `*.ubuntu.com` and `*.launchpad.net` happens via a proxy (limited to
> DNS and http/https).
>

On Tue, Apr 7, 2020 at 12:46 PM Andreas Tille  wrote:

> On Tue, Apr 07, 2020 at 11:15:17AM +0100, Rebecca N. Palmer wrote:
> > A potential workaround for testing: while package builds (including
> > build-time tests) are not allowed to use the network, autopkgtests *are*
> > allowed to => skip the tensorflow-needing tests in build, but run them
> (with
> > tensorflow from PyPI) in autopkgtest?
>
> Are you sure that autopkgtests *are* allowed to?  That's new to me.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Re: Missing dependancies for streamlit

[Michael Crusoe]

--
Michael R. Crusoe

On Tue, Apr 7, 2020, 03:27 timsn_thtree_net  wrote:

> Hi Andreas,
>
> Not certain what distro/config streamlit was made in, but the Makefile
> assumes that pip = pip3, and it looks like they really want python 3.8,
> but things seem to move ahead with the 3.7.3 version installed.
>
> Going past that by tweaking the makefile there are some things to
> install and some things missing in Debian, as those are outside of
> Debian Med, not certain who coordinates those other python packages.
>
> Missing stuff:
>
> Virtualenv location:
> Installing dependencies from Pipfile…
> An error occurred while installing cachetools>=4.0! Will try again.
>    47/47 — 00:01:01
> An error occurred while installing tensorflow>=2.0.0; python_version <
> '3.8'! Will try again.
> An error occurred while installing mypy==0.761! Will try again.
>
>
> https://packages.debian.org/search?keywords=python3-cachetools
>
> v4.0 is only in bullseye testing
>

You should setup a Debian unstable package building environment using
pbuilder or should. This is required and will also solve some of these
package version issues.


>
>
> https://packages.debian.org/search?suite=default=all=any=names=mypy
>
> mypy 0.770-1 is in bullseye testing
>

I would patch the setup.py to accept the newer mypy. It is unlikely they
need it for running or building, so you may be able to patch it out
completely (and maybe ask the upstream authors to make it optional)


>
> tensorflow 2 apparently requires a pip3 version of > 19 according to
> https://www.tensorflow.org/install, but current buster only has 18.1
>

Since you will have to manually ensure that all the right dependencies are
available it shouldn't be a problem to force the use of a different pip
version.

However, Debian packages are introduced to the "unstable" distribution
first, which has the newer pip version as you noticed, so you should be
fine.



> https://packages.debian.org/bullseye/python3-pip says bullseye testing
> has 20.0.2-3
>
>
> I can try to install those versions of cachetools and mypy, then see
> what how far I get with tensorflow2 (having previous played a bit with
> tensorflow, I know it can be a bear for dependancies).
>

Great, thank you!



>
> TTUL,
>
> TJ
>
>

Re: RFS: simde

[Michael Crusoe]

Thanka for catching that!

It is arch:any for now, but I'll make it arch: all once we get a full build
passing everywhere.

--
Michael R. Crusoe

On Thu, Apr 2, 2020, 11:36 Andreas Tille  wrote:

> On Thu, Apr 02, 2020 at 10:28:08AM +0200, Michael Crusoe wrote:
> > gbp clone g...@salsa.debian.org:med-team/simde.git
>
> Uploaded (after adding d/copyright paragraph for amalgamate.py -
> hope this will speed up cycles in new).
>
> Thanks a lot for your work on this
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>

RFS: simde

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/simde.git

Thanks!

-- 
Michael R. Crusoe

RFS or upload privileges: kalign

[Michael Crusoe]

Hello,

Kalign 3.x now uses SSE and other SIMD intrinsics and its build was also
violating the baseline for AMD64 and i386 by applying the CPU features of
the processor, so I've applied the SIMD Everywhere magic to it. I also
fixed the hardening of the build as it was throwing out our CFLAGS.

gbp clone g...@salsa.debian.org:med-team/kalign.git

or

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow kalign

Cheers,

-- 
Michael R. Crusoe

RFS: routine-update

[Michael Crusoe]

gbp clone g...@salsa.debian.org:science-team/routine-update.git

Thanks!

-- 
Michael R. Crusoe

Fwd: [bio-tools/biotoolsRegistry] bio.tools COVID-19 tools list (#505)

[Michael Crusoe]

FYI

-- Forwarded message -
From: Hans Ienasescu 
Date: Wed, Mar 25, 2020 at 5:50 PM
Subject: [bio-tools/biotoolsRegistry] bio.tools COVID-19 tools list (#505)


This issue is a placeholder for a discussion related to the bio.tools
COVID-19 related tools list.

There is a *COVID-19* related subdomain in bio.tools at:
*https://covid-19.bio.tools *

*Everyone* is encouraged to populate the tools list at the bio.tools
subdomain above.
In order to populate the subdomain you can:

   - *post a link to a bio.tools entry in this thread as a comment*
   - *Tag tools in bio.tools with the COVID-19 collection*
   - Email registry-supp...@elixirmail.cbs.dtu.dk with tool recommendations
   (*less recommended*, *only if you don't have a bio.tools or GitHub
   account*)
   - Post a link to a tool not in bio.tools (*less recommended*, *might
   take a long time until the tool actually gets into bio.tools*)

If you post a tool here or tag tools with the COVID-19 collection, I (and
other willing folks) will update the *https://covid-19.bio.tools
* subdomain as soon as possible.

*Please only post or add tools that are of real relevance to COVID-19!*
What is of *real relevance* is open to discussion and we should have that
discussion, but let's not spam this thread with arguments on what is
relevant.


-- 
Michael R. Crusoe

Re: Introduction: Jun Aruga

[Michael Crusoe]

On Mon, Mar 23, 2020 at 8:22 PM Jun Aruga  wrote:

> > > > I will be attending again, yes! I haven't decided on a particular
> proposal yet. Do you have any particular ideas?
> >
> > I'm currently waiting for getting the money back for my flight to
> > FOSSASIA in Singapore.  I intended to go there and by doing so consuming
> > my "Debian vacation" for this year.  Since "thanks" to Corona I might be
> > able to spent another week for Debian at some other event.  Its not
> > clear yet whether this will be DebConf or Biohackathon.
>
> Hi Andreas,
> It's great to meet you again!
>
> Okay. I have a willing to attend the Biohackathon this year in
> Barcelona, if the current COVID-19 issue will be fixed, and I can go
> outside Czech Republic.
>

If need be, the Europe Biohackathon will go virtual :-)

Applications are due April 2nd!

https://www.biohackathon-europe.org/proposalscall


-- 
Michael R. Crusoe

Re: COVID-19 Biohackathon April 5-11 2020

[Michael Crusoe]

On Mon, Mar 16, 2020 at 10:06 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Mon, Mar 16, 2020 at 09:19:29AM +0100, Michael Crusoe wrote:
> > There is one planned for the week starting April 5th
> >
> > https://github.com/virtual-biohackathons/covid-19-bh20
> > https://github.com/virtual-biohackathons/covid-19-bh20/wiki
> >
> > We should propose Debian-Med related projects, like
>
> I like this idea and I hope my involvement in the issue in my day job
> will not block me to much to contribute here.
>

Great, thanks!

>
> > 1) Tag all COVID-19 related software that is packages or our on wishlist.
> > This should include medical imaging, molecular dynamics modelers,
> > epidemiological tracking and statistics, hospital management, and more
>
> Pretty good idea.  However, we need to trust the readers of this list
> (may be the readers of debian-devel-announce or some social media) to
> complete that tagging and the list of stuff that needs packaging.  I
> can only do technical work.
>

If we want the participation of the wider Debian community, then I think we
need a fair amount of packages tagged prior to April 5th

Where is the best place to do the tagging, on our tasks page?

Can we have a COVID Debian-Med task page?

> 2) Also tag supporting libraries / tools for the above. Should it be the
> > same tag or a different tag?
>
> I'd vote for same tag.
>

Sure.


>
> > 3) Use these tags to highlight related bugs in Debian
>
> +1
>

Great, how to do this? Do we spam BTS with user tags, or is there a way to
get all bugs for a list of packages?


>
> > 4) Make versions of published workflows available using the Common
> Workflow
> > Language and biocontainers.pro software containers (which uses Debian &
> > Conda)
> >
> > What else am I missing?
> >
> > I've created
> > https://salsa.debian.org/med-team/community/2020-covid19-hackathon as a
> > place to store notes and other planning materials.
>
> Good! Should we add a list of software to package and once it is done
> point ftpmaster to that list to rank it with higher preference?
>

Great idea, I've started
https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/needs_packaging
as a quick and dirty list


>
> Is something in the new queue a potential candidate for fast-processing?
>

Good question, I haven't had time to check yet; I've got a virtual
conference today and tomorrow (USA time), so I have to focus on that now.


> > Sylvestre Ledru has encouraged us to post something to debian-announce@
> as
> > well, but I want to have a plan from this group first. My draft
> > announcement is at
> >
> https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/debian-announce_draft
> > so please help me refine the text.
>
> I hope to be able to do this in the next couple of hours.
>

Thanks!


>
> > Hope all of you are well,
>
> I'm perfectly fine - hope the same for you.
>

Same here, got back to Berlin on Friday. Not leaving for the foreseeable
future :-D


> Thanks a lot for this effort
>

Thank you (all) for the DebianMed community!


-- 
Michael R. Crusoe

COVID-19 Biohackathon April 5-11 2020

[Michael Crusoe]

There is one planned for the week starting April 5th

https://github.com/virtual-biohackathons/covid-19-bh20
https://github.com/virtual-biohackathons/covid-19-bh20/wiki

We should propose Debian-Med related projects, like

1) Tag all COVID-19 related software that is packages or our on wishlist.
This should include medical imaging, molecular dynamics modelers,
epidemiological tracking and statistics, hospital management, and more

2) Also tag supporting libraries / tools for the above. Should it be the
same tag or a different tag?

3) Use these tags to highlight related bugs in Debian

4) Make versions of published workflows available using the Common Workflow
Language and biocontainers.pro software containers (which uses Debian &
Conda)

What else am I missing?

I've created
https://salsa.debian.org/med-team/community/2020-covid19-hackathon as a
place to store notes and other planning materials.

Sylvestre Ledru has encouraged us to post something to debian-announce@ as
well, but I want to have a plan from this group first. My draft
announcement is at
https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/debian-announce_draft
so please help me refine the text.

Hope all of you are well,

-- 
Michael R. Crusoe

Re: Introduction: Jun Aruga

[Michael Crusoe]

On Sun, Mar 15, 2020 at 5:28 PM Jun Aruga  wrote:

> Hello Debian Med team,
>
> My name is Jun Aruga. I am a passionate hobbyist for the
> bioinformatics. Especially genome sequencing area.
>
> I had an opportunity to join Debian Med Sprint event last month in Berlin.
> it was very fun, and inspired me.
>
> https://wiki.debian.org/Sprints/2020/Debian%20Med%20Sprint%20Feb%202020%2C%20Berlin


Hey Jun!

It was really nice to finally meet you and it was great to have you at the
Sprint!


>
>
> As I am usually at Fedora project, and maybe I can not work directly
> for the Debian packaging.
> But I am happy to contribute something to bio open source projects,
> when Debian Med team needs it.
>
> I am looking forward to seeing you, and work together again.
>
>
> P.S. I noticed that this year's Biohackathon Europe event is on the
> website now.
>
> https://www.biohackathon-europe.org/
> > BARCELONA 2020 NOVEMBER 9th - 13th
> > Call to proposals now open
>
> Are you planning to do something for the event?
> I love I am involved.
>

That's me and another well known Debian contributor in the video :-D
https://www.youtube.com/watch?v=RNIInb72-z0

I will be attending again, yes! I haven't decided on a particular proposal
yet. Do you have any particular ideas?


>
> Cheers,
> Jun
>
> --
> Jun | He - His - Him
> jar...@redhat.com / IRC: jaruga
>
>

-- 
Michael R. Crusoe

Re: Request for backport: vg

[Michael Crusoe]

Thanks for this. I did my test build wrong; now my results match yours.
Seems that vg will not be backportable unless we track down which of the
dependencies require a newer version.

On Wed, Feb 26, 2020 at 6:03 AM Andreas Tille  wrote:

> On Tue, Feb 25, 2020 at 10:17:30PM +0100, Michael Crusoe wrote:
> > gbp clone g...@salsa.debian.org:med-team/vg.git -b
> debian/buster-backports
> >
> > A test build in a buster backports sbuild just succeeded.
> >
> > Should be already to upload and tag, thanks!
>
> ...
> Test Summary Report
> ---
> t/00_unittest.t (Wstat: 0 Tests: 1 Failed: 1)
>   Failed test:  1
> t/02_vg_construct.t (Wstat: 0 Tests: 25 Failed: 1)
>   Failed test:  24
> t/05_vg_find.t  (Wstat: 0 Tests: 28 Failed: 1)
>   Failed test:  24
> t/07_vg_map.t   (Wstat: 0 Tests: 55 Failed: 1)
>   Failed test:  54
> t/13_vg_sim.t   (Wstat: 0 Tests: 14 Failed: 1)
>   Failed test:  11
> t/16_vg_msga.t  (Wstat: 0 Tests: 14 Failed: 2)
>   Failed tests:  6, 11
> t/18_vg_call.t  (Wstat: 0 Tests: 7 Failed: 2)
>   Failed tests:  3, 7
> t/27_vg_genotype.t  (Wstat: 0 Tests: 5 Failed: 1)
>   Failed test:  3
> t/31_vg_add.t   (Wstat: 0 Tests: 9 Failed: 3)
>   Failed tests:  1-2, 5
> Files=48, Tests=605, 143 wallclock secs ( 0.18 usr  0.05 sys + 194.88 cusr
> 27.50 csys = 222.61 CPU)
> Result: FAIL
>
>
> :-(
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Request for backport: vg

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/vg.git -b debian/buster-backports

A test build in a buster backports sbuild just succeeded.

Should be already to upload and tag, thanks!

-- 
Michael R. Crusoe

Re: Request for backports: libvcflib & hopscotch-map

[Michael Crusoe]

libvcflib is ready for backporting, as it already migrated to "testing"

On Fri, Feb 14, 2020 at 9:18 PM Andreas Tille  wrote:

> On Fri, Feb 14, 2020 at 07:35:55PM +0100, Michael Crusoe wrote:
> > hopscotch-map has successfully migrated to testing, thanks!
>
> Uploaded.
>
> > libvcflib is waiting on https://tracker.debian.org/pkg/gcc-10 which
> needs
> > another 2-3 days
>
> Please ping again - I can confirm that I totally forgot. ;-)
>
> Thanks for the preparation, Andreas.
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Fwd: Please setup http://statnet.org/attribution or modify license to point to http://statnetproject.org/attribution.shtml

[Michael Crusoe]

[ statnet_h...@u.washington.edu bounced, trying
help-ow...@mailman13.u.washington.edu as instructed ]

Hello,

While packaging https://cran.r-project.org/package=statnet.common &
https://cran.r-project.org/package=network we ran into some difficulty
fulfilling the attribution requirements of the LICENSE file as it
references a URL that does not work

(a) you agree to retain in 'statnet.common' and any modifications to
> 'statnet.common'
> the copyright, author attribution and URL information as
> provided at http://statnet.org/attribution


 My guess is that this is a result of the move from statnetproject.org to
statnet.org?

I found http://statnetproject.org/attribution.shtml via
http://statnetproject.org/attribution/ , but it would be really better for
us if one of the following occured:

1. the http://statnet.org/attribution URL worked (easy for us)
2. there was a new release where item (a) of the attribution clause was
updated so that users aren't required to consult an external URL prior to
redistribution (best)
3. there was a new release where the URL is restored to
http://statnetproject.org/attribution.shtml or
http://statnetproject.org/attribution

Thanks for creating, maintaining, and releasing free software and open
science!

-- 
Michael R. Crusoe, on behalf of the Debian-Med team


-- 
Michael R. Crusoe

Please setup http://statnet.org/attribution or modify license to point to http://statnetproject.org/attribution.shtml

[Michael Crusoe]

Hello,

While packaging https://cran.r-project.org/package=statnet.common &
https://cran.r-project.org/package=network we ran into some difficulty
fulfilling the attribution requirements of the LICENSE file as it
references a URL that does not work

(a) you agree to retain in 'statnet.common' and any modifications to
> 'statnet.common'
> the copyright, author attribution and URL information as
> provided at http://statnet.org/attribution


 My guess is that this is a result of the move from statnetproject.org to
statnet.org?

I found http://statnetproject.org/attribution.shtml via
http://statnetproject.org/attribution/ , but it would be really better for
us if one of the following occured:

1. the http://statnet.org/attribution URL worked (easy for us)
2. there was a new release where item (a) of the attribution clause was
updated so that users aren't required to consult an external URL prior to
redistribution (best)
3. there was a new release where the URL is restored to
http://statnetproject.org/attribution.shtml or
http://statnetproject.org/attribution

Thanks for creating, maintaining, and releasing free software and open
science!

-- 
Michael R. Crusoe, on behalf of the Debian-Med team

Request for sponsorship: libbio-alignio-stockholm-perl

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/libbio-alignio-stockholm-perl.git

Thanks!

-- 
Michael R. Crusoe

Re: Request for sponsorship: ataqv

[Michael Crusoe]

On Mon, Feb 17, 2020 at 1:49 PM Andreas Tille  wrote:

> On Mon, Feb 17, 2020 at 01:20:52PM +0100, Michael Crusoe wrote:
> > Yes, I tried the package version first, but as I noted in debian/control:
> >
> > #   libjs-d3,  need a newer version than 3.5.17-2, missing
> the
> > scaleOrdinal function
> >
> > so I kept upstream's version of d3 (4.2.7) and included the full source
> in
> > debian/missing-sources
>
> But the package *node-d3* is at version 4.13.0!  It happens that js-team
> moves to a new package name space and the newer versions are usually
> named node-*.  (I'm just observing this, no idea why.)
>

Oh, I wondered what that was about. Fixed and pushed, thanks!



-- 
Michael R. Crusoe

Re: Request for sponsorship: ataqv

[Michael Crusoe]

On Mon, Feb 17, 2020 at 1:20 PM olivier sallou 
wrote:

> On Mon, 2020-02-17 at 13:08 +0100, Michael Crusoe wrote:
>
> clean step seems to delete a file resulting in gbp build error:
>

I saw that, but it didn't cause me a problem for my packaging workflow.
However it is annoying so I just pushed up a patch to fix that

-- 
Michael R. Crusoe

Re: Request for sponsorship: ataqv

[Michael Crusoe]

Yes, I tried the package version first, but as I noted in debian/control:

#   libjs-d3,  need a newer version than 3.5.17-2, missing the
scaleOrdinal function

so I kept upstream's version of d3 (4.2.7) and included the full source in
debian/missing-sources

On Mon, Feb 17, 2020 at 1:18 PM Andreas Tille  wrote:

> On Mon, Feb 17, 2020 at 01:08:56PM +0100, Michael Crusoe wrote:
> > gbp clone g...@salsa.debian.org:med-team/ataqv.git
>
> Any reason for shipping a code copy of d3.js in debian/missing-sources
> instear of depending from node-d3?
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Request for sponsorship: ataqv

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/ataqv.git

Thanks!

-- 
Michael R. Crusoe

Request for sponsoring: gerp++

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/gerp.git

Thanks!

-- 
Michael R. Crusoe

Re: Request for backports: libvcflib & hopscotch-map

[Michael Crusoe]

hopscotch-map has successfully migrated to testing, thanks!

libvcflib is waiting on https://tracker.debian.org/pkg/gcc-10 which needs
another 2-3 days

On Wed, Feb 12, 2020 at 3:02 PM Andreas Tille  wrote:

> Hi Michael,
>
> I can surely upload to backports - but we need to wait until it has
> hit testing.  Would you mind refreshing this request once this has
> happened since I might forget.
>
> Thanks for your work on this
>
>   Andreas.
>
> On Wed, Feb 12, 2020 at 01:08:14PM +0100, Michael Crusoe wrote:
> > gbp clone g...@salsa.debian.org:med-team/libvcflib.git -b
> > debian/buster-backports
> > gbp buildpackage -S -d -v1.0.0~rc2+dfsg-2
> >
> > and
> >
> > gbp clone g...@salsa.debian.org:med-team/hopscotch-map.git -b
> > debian/buster-backports
> > gbp buildpackage -S -d
> > # no -v needed as it will be new to buster
> >
> > Thanks!
> >
> > --
> > Michael R. Crusoe
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Request for sponsorship to experimental: staden-io-lib 1.14.12-1~r0

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/staden-io-lib.git -b
debian/experimental

Thanks!
--
Michael R. Crusoe

Request for sponsorship: arcp

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/arcp.git

Thanks!

-- 
Michael R. Crusoe

Request for backports: libvcflib & hopscotch-map

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/libvcflib.git -b
debian/buster-backports
gbp buildpackage -S -d -v1.0.0~rc2+dfsg-2

and

gbp clone g...@salsa.debian.org:med-team/hopscotch-map.git -b
debian/buster-backports
gbp buildpackage -S -d
# no -v needed as it will be new to buster

Thanks!

-- 
Michael R. Crusoe

Re: vg_1.21.0+ds2-1_amd64.changes ACCEPTED into unstable, unstable

[Michael Crusoe]

Yay!

Andreas, can I have upload permissions for vg?

--
Michael R. Crusoe

On Tue, Feb 11, 2020, 20:00 Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:

>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon, 13 Jan 2020 11:32:02 +0100
> Source: vg
> Binary: vg vg-dbgsym vg-docs
> Architecture: source amd64 all
> Version: 1.21.0+ds2-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team <
> debian-med-packag...@lists.alioth.debian.org>
> Changed-By: Michael R. Crusoe 
> Description:
>  vg - tools for working with genome variation graphs
>  vg-docs- tools for working with genome variation graphs -- docs
> Closes: 939537
> Changes:
>  vg (1.21.0+ds2-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #939537)
> Checksums-Sha1:
>  2fdd1bfe5853460d471da341fe277f269299c25e 2839 vg_1.21.0+ds2-1.dsc
>  3c27c19904c6837ca8ea0384ef11925b69e82078 82418072
> vg_1.21.0+ds2.orig.tar.xz
>  d7961643d9dbf47ee3027677b204abb078db20c2 28756
> vg_1.21.0+ds2-1.debian.tar.xz
>  463a4687232fc86dc26c0e63bd0f54e1d169d7f7 129396656
> vg-dbgsym_1.21.0+ds2-1_amd64.deb
>  2cdf4a3eb6d5e94de01ac56a8b689a7ba67f7573 119980
> vg-docs_1.21.0+ds2-1_all.deb
>  a5c16bb7bc617b3aa6c1338bba6724d5f89f148d 14979
> vg_1.21.0+ds2-1_amd64.buildinfo
>  dbe2ad0556419300500267c57724f51a610b47ee 5934776 vg_1.21.0+ds2-1_amd64.deb
> Checksums-Sha256:
>  7f4c71540e373d33ce3793deccb0ae24896c4c9a43e195ce49922290346f7401 2839
> vg_1.21.0+ds2-1.dsc
>  c64861e579fb99bd57b6960b2575cc6fad213c3a0ce1ce52e657f03fe576f472 82418072
> vg_1.21.0+ds2.orig.tar.xz
>  f0af215e1de1e083a55f6c44072415793e34368e87556c92a4441a33b64f6120 28756
> vg_1.21.0+ds2-1.debian.tar.xz
>  17822f0426f2d59884daa5d7207c5be0fdc1a4494fefc25c4c74cdd17b83bcd7
> 129396656 vg-dbgsym_1.21.0+ds2-1_amd64.deb
>  d5cb0c91c80f31d23f6b6a8a7785760df6a01d8224e44d3d12ce135afa2ddb8b 119980
> vg-docs_1.21.0+ds2-1_all.deb
>  c76fe26f37ee6b43acd5809f607c050a199487b2c44619c6089ea499c93c00b9 14979
> vg_1.21.0+ds2-1_amd64.buildinfo
>  7e66cca337d0a60d8517381befd024f95ec0d451e0d9b956a7b1fdcefdd92e3e 5934776
> vg_1.21.0+ds2-1_amd64.deb
> Files:
>  4de7981fd62b80f8b7de7d3f733cc9d2 2839 science optional vg_1.21.0+ds2-1.dsc
>  40e9c0f9df6f0909b8c20679336579aa 82418072 science optional
> vg_1.21.0+ds2.orig.tar.xz
>  be0e330486376a0dac5ff8adbab3c738 28756 science optional
> vg_1.21.0+ds2-1.debian.tar.xz
>  f43c8b57a5abf80ff61f5a6080bed4e7 129396656 debug optional
> vg-dbgsym_1.21.0+ds2-1_amd64.deb
>  879a6a162453cee5e8d5b98123b4ea61 119980 science optional
> vg-docs_1.21.0+ds2-1_all.deb
>  f53800a217689a908d8aad59f83e05e4 14979 science optional
> vg_1.21.0+ds2-1_amd64.buildinfo
>  0a98bf396baad54f9bb38d288bba8294 5934776 science optional
> vg_1.21.0+ds2-1_amd64.deb
>
> -BEGIN PGP SIGNATURE-
>
> iQJCBAEBCgAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAl45EYgOHHRpbGxlYUBy
> a2kuZGUACgkQV4oElNHGRtF0txAAj0wQXAycq2BKNllU7UhSKoyo4BN6KSq4xUbu
> ws99pyBhHSdBIEUATbHVy9TG/fYxgB1tg2NDNRkc/HGmX8yodFaRc0DZnjNHHXfW
> WVPRtt6bQlYtia8xrK4aZa6So4UCzgl0qORAup1MGaeYwbir4iTdKOyI2jnwWX9W
> 3T+PnCvRIe6+5jEirk375hzi6SETJCgi1DHOhQpTTbM2b8oV7bjmuvERdY8Gz5SC
> Mq/mgf9NPOngMm8poyN4k7TSWh2tC8DIZbGmzazSHWlLOG17kWG8z9ZG4W7tF9oc
> 03QaVjQl0JGtg27tnfk8eqe4gegUKd2baVair2SuOgkYZqp7JF2i0knx2wrEdzTn
> CIFhKTS09XujmSNUojOt8DqfGlo+CdYgwaIyGYOtmZ4VREMYuFujUXK0SVFVdSN3
> /Ibr/uHXhj3NKfqEWgPWVCIaSX50BsHV+kgcLqw/FyxvNWOYIl/NSwVTOIQdOXxP
> zGB+AONZzE0pQWFRESG1Bcpqt/AhXYk2HEoaG3sJfsImGoUgpIUxCPb/aBtqIG70
> RrrYpglY/JrKkPOWuZG2j6xtHjl7uNOyH7gBHxqrTYioiSxHpdnPxUSmYlGERf9j
> 6eZPyxy0/DNA45SqnKbBWKb8yZlyghfvaiyhVR0Kju8SSyF7gkhTXD5fBuhgqpDB
> T6+2tKE=
> =IZhy
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.
>

Request for sponsorship libgclib_0.11.4-1~rc0

[Michael Crusoe]

gbp clone -b debian/experimental g...@salsa.debian.org:med-team/libgclib.git

After this passes the NEW queue I will contain with
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Thanks,

-- 
Michael R. Crusoe

Request for sponsorship: htscodecs

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/htscodecs.git

Thanks!

-- 
Michael R. Crusoe

Request for Upload Rights: swissknife

[Michael Crusoe]

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow swissknife

Thanks!
-- 
Michael R. Crusoe

Re: Project idea: port GKL to non-x86

[Michael Crusoe]

Oh, I was mistaken about the GATK link.

picard-tools depends on gkl, and igv and artemis depend on picard-tools

On Sat, Feb 8, 2020 at 4:22 PM Jun Aruga  wrote:

> This part is related to building on ARM.
>
> > @GraceZou, You will have to build from source for ARM. The repo is
> gatk-bwamem-jni. There are instructions in the README on the repo landing
> page. Set the environmental variable to then point to the built library.
>
> On Sat, Feb 8, 2020 at 4:19 PM Jun Aruga  wrote:
> >
> > For GATK depending on GKL, I found an interesting page about building
> > GATK on ARM.
> >
> >
> https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
> > > We use GATK4-beta1 in ARM,and have several questions about it:
> >
> > Jun
> >
> > On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe 
> wrote:
> > >
> > > https://github.com/Intel-HLS/GKL
> > > A Java wrapper around an Intel optimized implementations of PairHMM,
> Smith-Waterman, and DEFLATE.
> > >
> > > Uses SIMD intrinsics and assembly.
> > >
> > > At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde
> is a fork using the SIMD Everywhere library, but I lack the expertise to
> produce source versions of the many assembler only routines.
> > >
> > > Any suggestions / contributions?
> > >
> > > --
> > > Michael R. Crusoe
> >
> >
> >
> > --
> > Jun | He - His - Him
> > jar...@redhat.com / IRC: jaruga
>
>
>
> --
> Jun | He - His - Him
> jar...@redhat.com / IRC: jaruga
>
>

-- 
Michael R. Crusoe

Project idea: port GKL to non-x86

[Michael Crusoe]

https://github.com/Intel-HLS/GKL
A Java wrapper around an Intel optimized implementations of PairHMM,
Smith-Waterman, and DEFLATE.

Uses SIMD intrinsics and assembly.

At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is a
fork using the SIMD Everywhere library, but I lack the expertise to produce
source versions of the many assembler only routines.

Any suggestions / contributions?

-- 
Michael R. Crusoe

Request for Sponsorship spdlog_1.5.0-1~rc0 to experimental

[Michael Crusoe]

Now we build a shared library in addition to the header-only library

gbp clone g...@salsa.debian.org:med-team/spdlog.git
--debian-branch=debian/experimental

Thanks!

-- 
Michael R. Crusoe

Re: Should we drop GUI from Cluster3 Debian package to make the remaining free code fit for Debian main (Was: License of cluster3 becomes unspecified since you are linking to a non-existing URL)

[Michael Crusoe]

Summary: cluster3 can not enter Debian main until the src/command.c file is
relicensed by Stanford

On Thu, Feb 6, 2020 at 10:00 AM Andreas Tille  wrote:

> Hi,
>
> since more than two years we did not heard any news regarding the
> license of X11/gui.c which is as far as I can see the only code inside
> the cluster3 code that does not feature a free license.  Since I
> consider the non-GUI code as valuable for Debian users (thanks to the
> authors who considered a free license) I propose hereby to remove
>X11/gui.c
> from the source package and move cluster3 to Debian main.


So if only the GUI code descends from Michael Eisen's code, then we can
move the package out of "non-free", yes.

However, the non-free license is still present in the src/command.c and
that file is required for /usr/bin/cluster3 (and the perl and python
modules which we aren't even building yet)



>   Those who
> consider the GUI an important part of the program are kindly invited to
>
>   1. Keep on contacting the author to consider a free license
>   2. Create a separate package cluster3-gui residing in non-free
>
> Kind regards
>
>  Andreas.
>
>
> On Thu, Sep 14, 2017 at 06:01:37PM +0200, Andreas Tille wrote:
> > Hello Michiel,
> >
> > I'm writing you again[1] about the license of Cluster 3.0.
> > Unfortunately nothing has happended since then since I did not found any
> > contact information.
> >
> > As license statement you are refering to
> >
> > http://rana.lbl.gov/EisenSoftwareSource.htm
> >
> > The fact that this URL does not exist any more is a good example why
> > using URLs instead of an explicit license text is not a good idea.  The
> > current situation is that your software does not have any license at all
> > any more which would even make it non-distributable even in the non-free
> > area of the Debian mirror.
> >
> > I really appreciate that you agreed to a free license and I absolutely
> > share your assumption that Michael Eisen would probably agree as well.
> > Unfortunately I have no idea how to reach a person who could clarify the
> > license.  In any case it would be a really good start if you would use a
> > free license for your own code and add the original license text to the
> > downloadable file.
> >
> > Kind regards
> >
> >   Andreas.
> >
> > [1] https://lists.debian.org/debian-med/2016/02/msg0.html
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Re: Request for sponsorship: seqan3_3.0.1+ds-6~bpo10+1

[Michael Crusoe]

Thanks!

On Tue, Feb 4, 2020 at 6:49 PM Andreas Tille  wrote:

> Done. Please note that I renamed the branch
>
>debian/buster -> debian/buster-backports
>
> Kind regards
>
>Andreas.
>
> On Mon, Feb 03, 2020 at 04:14:21PM +0100, Michael Crusoe wrote:
> > Thanks!
> >
> > --
> > Michael R. Crusoe
> >
> > -- Forwarded message -
> > From: Debian FTP Masters 
> > Date: Mon, Feb 3, 2020, 15:42
> > Subject: seqan3_3.0.1+ds-6~bpo10+1_source.changes REJECTED
> > To: Michael R. Crusoe , Debian Med Packaging
> Team
> > 
> >
> >
> >
> >
> > ACL dm: NEW uploads are not allowed
> >
> > binary:libseqan3-dev is NEW.
> > binary:seqan3-doc is NEW.
> > source:seqan3 is NEW.
> >
> > ===
> >
> > 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.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Request for sponsorship: seqan3_3.0.1+ds-6~bpo10+1

[Michael Crusoe]

Thanks!

--
Michael R. Crusoe

-- Forwarded message -
From: Debian FTP Masters 
Date: Mon, Feb 3, 2020, 15:42
Subject: seqan3_3.0.1+ds-6~bpo10+1_source.changes REJECTED
To: Michael R. Crusoe , Debian Med Packaging Team





ACL dm: NEW uploads are not allowed

binary:libseqan3-dev is NEW.
binary:seqan3-doc is NEW.
source:seqan3 is NEW.

===

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.

Re: Request for review: vg initial packaging

[Michael Crusoe]

Thank you Andeas,

I think the vg package is ready for review & sponsoring.

On Fri, Sep 6, 2019 at 2:11 PM Andreas Tille  wrote:

> Hi Michael,
>
> On Fri, Sep 06, 2019 at 04:37:26PM +0900, Michael Crusoe wrote:
> > https://salsa.debian.org/med-team/vg
> >
> > I know the debian/copyright file needs updating
> >
> > Many code copies in deps/, I removed all that are in Debian except 4
> which
> > are still required due to forking by upstream.
> >
> > The hardening patch is currently disabled, but being worked on actively
> > here at the Japan Biohackathon with Erik.
> >
> > We look forward to submitting this soon!
>
> I've done some minor changes - most of them done automatically by
>
> routine-update --force
>
> (so feel free to run this against your new packages as well).
>
> There is one open lintian bug:
>
> E: vg source: source-is-missing deps/sdsl-lite/external/d3/d3.min.js
> N:
> N:The source of the following file is missing. Lintian checked a few
> N:possible paths to find the source, and did not find it.
> N:
> N:Please repack your package to include the source or add it to
> N:"debian/missing-sources" directory.
> N:
> N:If this is a false-positive, please report a bug against Lintian.
> N:
> N:Please note, that insane-line-length-in-source-file tagged files are
> N:likely tagged source-is-missing. It is a feature not a bug.
> N:
> N:Severity: serious, Certainty: possible
> N:
> N:Check: cruft, Type: source
>
>
> I think removing this and symlinking agains the version in libjs-d3
> should be simple.
>
> Thanks for working on this
>
>Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe

Re: samtools is not migrating - any idea?

[Michael Crusoe]

On Fri, Jan 24, 2020 at 7:16 PM Steffen Möller 
wrote:
>
> https://tracker.debian.org/pkg/samtools
>
> is stuck at 1.9-7. 1.10-3 was uploaded a while back and the tracker says
> that samtools would be transitioning to testing, but is apparently not.

https://release.debian.org/britney/update_output.txt

trying: samtools
skipped: samtools (0, 5, 585)
got: 20+0: a-1:a-0:a-0:a-0:i-17:m-0:m-0:p-0:s-2
* s390x: tophat

Tophat builds on s390x and depends (but not build-depends) on samtools,
which no longer builds on s390x.

So I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949378
"RM: tophat [s390x] -- ROM; Blocking migration of samtools to testing"

> Are the buildds are running testing? Then this would explain why
> bedtools fails to build (added build-dep on samtools 1.10 only after the
> upload).

The buildds run "unstable"

--
Michael R. Crusoe

Re: Request for sponsorship / upload permissions: proteinortho

[Michael Crusoe]

On Mon, Jan 13, 2020 at 1:07 PM Andreas Tille  wrote:

> On Mon, Jan 13, 2020 at 12:42:16PM +0100, Michael Crusoe wrote:
> >   * patch: Use #!/usr/bin/python3 (fixes autopkgtests)
> >   * patch: Find the packaged version of the Diamond aligner
>
> BTW, I've uploaded the latest diamond-aligner with
>
>/usr/bin/diamond
>
> (in addition to /usr/bin/diamond-aligner )
>

Great! I'll leave my patch as it will help with in case of a backport

-- 
Michael R. Crusoe

Request for sponsorship / upload permissions: proteinortho

[Michael Crusoe]

  * patch: Use #!/usr/bin/python3 (fixes autopkgtests)
  * patch: Find the packaged version of the Diamond aligner
  * patch: Improve build hardening via CPPFLAGS & CFLAGS
  * Expanded autopkgtests, following `make test`
  * patch: fix a spelling typo

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

or

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow proteinortho

Cheers,

-- 
Michael R. Crusoe

Re: Suggested removals: mgltools-{cadd,symserv,visionlibraries}

[Michael Crusoe]

I support their removal.

On Thu, Jan 9, 2020 at 6:06 PM Andreas Tille  wrote:

> Some other severity bumps of mgltools-* packages bugs were filed.  This
> shows the relevance of my mail.  I'd love to get rid of bugs nobody
> cares about.
>
> Kind regards, Andreas.
>
> On Thu, Jan 09, 2020 at 02:18:45PM +0100, Andreas Tille wrote:
> > Hi,
> >
> > to support the Python2 removal and to clean up our bug list a bit more
> > I'd suggest to remove all those mgltools-* packages that received bugs
> > of severity serious.  There is no sign that anybody is actively working
> > on these packages to fix the issue.  Neither is there any discussion
> > with upstream like some upstream tag or forwarded link.
> >
> > If I do not see any activity in the next two weeks I'll file ROM bugs
> > for these three packages.
> >
> > BTW, I'm quite tempted to ask for removal of all mgltools-* packages
> > since these non-free packages just consume time I could spent on
> > packages in main and the official uploaders did not cared about an
> > upload since three years.
> >
> > Kind regards
> >
> >Andreas.
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
>

-- 
Michael R. Crusoe

Re: Request for Sponsorship/upload rights: examl

[Michael Crusoe]

Thank you, Andreas Tille!

On Thu, Jan 9, 2020 at 7:58 PM Michael Crusoe 
wrote:

> I've added the "SIMD everywhere" library to examl, expanding it to
> non-AMD64 architectures
> Can this package be uploaded or might I have upload permissions?
>
> gbp clone g...@salsa.debian.org:med-team/examl
>
> or
>
> dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow examl
>
> Thanks!
>
> --
> Michael R. Crusoe
>


-- 
Michael R. Crusoe

Request for Sponsorship/upload rights: examl

[Michael Crusoe]

I've added the "SIMD everywhere" library to examl, expanding it to
non-AMD64 architectures
Can this package be uploaded or might I have upload permissions?

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

or

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow examl

Thanks!

-- 
Michael R. Crusoe

Re: Request for Sponsorship libsys-info{-driver-linux,}-perl

[Michael Crusoe]

On Tue, Jan 7, 2020 at 7:02 PM gregor herrmann  wrote:

> On Tue, 07 Jan 2020 16:18:52 +0100, Andreas Tille wrote:
>
> > On Tue, Jan 07, 2020 at 04:01:48PM +0100, Michael Crusoe wrote:
> > > Heh, thanks gregor!
> > > That's odd that I wasn't able to find these package earlier, sorry for
> the
> > > noise!
> > ... and sorry for not checking as sponsor ...
>
> No worries, there was no harm done.
>
> Michael, would you want to join the perl team? It seems that you are
> sometimes working on med/science related perl stuff; being in both
> teams might make this easier.
>

Sure! I'm https://salsa.debian.org/misterc-guest


-- 
Michael R. Crusoe

Re: Request for Sponsorship libsys-info{-driver-linux,}-perl

[Michael Crusoe]

Heh, thanks gregor!

That's odd that I wasn't able to find these package earlier, sorry for the
noise!

On Tue, Jan 7, 2020 at 3:42 PM gregor herrmann  wrote:

> On Tue, 07 Jan 2020 15:33:56 +0100, Andreas Tille wrote:
>
> > On Tue, Jan 07, 2020 at 01:45:11PM +0100, Michael Crusoe wrote:
> > > gbp clone g...@salsa.debian.org:
> med-team/libsys-info-driver-linux-perl.git
> > > gbp clone g...@salsa.debian.org:med-team/libsys-info-perl.git
>
> Somehow these names ring a bell …
>
> Ah yes:
>
> https://salsa.debian.org/perl-team/modules/packages?utf8=%E2%9C%93=libsys-info
> vs.
> https://salsa.debian.org/med-team?filter=libsys-info
>
> And tracker:
> https://tracker.debian.org/pkg/libsys-info-perl
> "ITP: Someone is planning to reintroduce this package."
> #948330
>
> https://tracker.debian.org/pkg/libsys-info-driver-linux-perl
> "ITP: Someone is planning to reintroduce this package."
> #948329
>
> > > Currently we patch around these for bowtie, but it would be nice to not
> > > have to.
> > Uploaded.
>
> Looking at the version in d/changelog in the 2 packages in the
> debian-med repos, the uploads will probably be rejected (as the
> perl-teams packages have higher versions)
>
> > However, I'd love to see these maintained by Debian Perl team
> > (in CC) - may be it can be moved there once ftpmaster might have accepted
> > and when the source-only upload will be done.
>
> Well, actually your wish is already fulfilled :)
>
>
> Cheers,
> gregor
>
> --
>  .''`.  https://info.comodo.priv.at -- Debian Developer
> https://www.debian.org
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649
> AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
> Europe
>`-   BOFH excuse #384:  it's an ID-10-T error
>


-- 
Michael R. Crusoe

Request for Sponsorship libsys-info{-driver-linux,}-perl

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/libsys-info-driver-linux-perl.git
gbp clone g...@salsa.debian.org:med-team/libsys-info-perl.git

Currently we patch around these for bowtie, but it would be nice to not
have to.

Thanks!
-- 
Michael R. Crusoe

Re: Request for sponsorship: libbio-featureio-perl

[Michael Crusoe]

Thank you, Andreas Tille!

On Tue, Jan 7, 2020 at 12:45 PM Michael Crusoe 
wrote:

> gbp clone g...@salsa.debian.org:med-team/libbio-featureio-perl.git
>
> Needed for bioperl-run
>
> Thanks!
> --
> Michael R. Crusoe
>


-- 
Michael R. Crusoe

Request for sponsorship: libbio-featureio-perl

[Michael Crusoe]

gbp clone g...@salsa.debian.org:med-team/libbio-featureio-perl.git

Needed for bioperl-run

Thanks!
-- 
Michael R. Crusoe

Re: RFS or upload privilages libbio-db-hts-perl_3.01-3

[Michael Crusoe]

Thank you Andreas Tille!

On Sat, Jan 4, 2020 at 12:57 PM Michael Crusoe 
wrote:

> The bioperl migration is almost complete!
>
> Can I get sponsorship or upload privileges for libbio-db-hts-perl?
>
> gbp clone g...@salsa.debian.org:med-team/libbio-db-hts-perl
> or
> dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow
> libbio-db-hts-perl
>
> Thanks,
>
> --
> Michael R. Crusoe
>


-- 
Michael R. Crusoe

RFS or upload privilages libbio-db-hts-perl_3.01-3

[Michael Crusoe]

The bioperl migration is almost complete!

Can I get sponsorship or upload privileges for libbio-db-hts-perl?

gbp clone g...@salsa.debian.org:med-team/libbio-db-hts-perl
or
dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow
libbio-db-hts-perl

Thanks,

-- 
Michael R. Crusoe

Re: libbio-db-ncbihelper-perl_1.7.4-1_amd64.changes REJECTED

[Michael Crusoe]

Thanks, also, Thorsten, for this :-)

Andreas, likewise, this has been fixed and uploaded:

gbp clone g...@salsa.debian.org:med-team/libbio-db-ncbihelper-perl.git

On Thu, Jan 2, 2020 at 9:13 PM Thorsten Alteholz <
ftpmas...@ftp-master.debian.org> wrote:

>
> Hi Michael,
>
> please mention the copyright holder of
>  Bio-DB-NCBIHelper-1.7.4/bin/bp_biofetch_genbank_proxy
> in your debian/copyright.
>
> Thanks!
>  Thorsten
>
>
>
> ===
>
> 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.
>
>

-- 
Michael R. Crusoe

Re: libbio-variation-perl_1.7.4-1_amd64.changes REJECTED

[Michael Crusoe]

Thorsten,

Thanks for catching that.

Andreas, I've fixed this and it is ready for re-sponsoring:

gbp clone g...@salsa.debian.org:med-team/libbio-variation-perl.git

On Thu, Jan 2, 2020 at 9:13 PM Thorsten Alteholz <
ftpmas...@ftp-master.debian.org> wrote:

>
> Hi Michael,
>
> please also mention Stan Nelson in your debian/copyright.
>
> Thanks!
>  Thorsten
>
>
>
>
> ===
>
> 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.
>
>

-- 
Michael R. Crusoe

Re: RFS or upload permissions for python-pomegranate

[Michael Crusoe]

Thank you Dylan Aïssi !

--
Michael R. Crusoe

On Thu, Jan 2, 2020, 09:46 Michael Crusoe  wrote:

> Hello,
>
> I've got a fix for the python-pomegranate package, which is otherwise in
> danger of removal from testing (along with cnvkit)
>
> dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow
> python-pomegranate
>
> or
>
> gbp clone
> https://salsa.debian.org/python-team/modules/python-pomegranate.git
>
> Thanks!
>
> --
> Michael R. Crusoe
>

RFS or upload permissions for python-pomegranate

[Michael Crusoe]

Hello,

I've got a fix for the python-pomegranate package, which is otherwise in
danger of removal from testing (along with cnvkit)

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow
python-pomegranate

or

gbp clone
https://salsa.debian.org/python-team/modules/python-pomegranate.git

Thanks!

-- 
Michael R. Crusoe

request for upload permissions libbio-db-swissprot-perl

[Michael Crusoe]

This is a package I started :-)

dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow
libbio-db-swissprot-perl

Many thanks to Andreas and Steffen for their previous permissions
throughout 2019!

On Wed, Jan 1, 2020 at 1:34 PM Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:

>
>
> ACL dm: not allowed to upload source package 'libbio-db-swissprot-perl'
>
>
>
> ===
>
> 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.
>
>

-- 
Michael R. Crusoe