control: forwarded -1 https://github.com/seqan/needle/issues/128
They are different programs, with different interfaces, alas.
So a workaround will be needed: probably we should rename the binary
`seqan-needle` and provide a directory with a regular `needle` that can be
added to a user's `PATH`.
control: forwarded -1 https://github.com/seqan/needle/issues/128
They are different programs, with different interfaces, alas.
So a workaround will be needed: probably we should rename the binary
`seqan-needle` and provide a directory with a regular `needle` that can be
added to a user's `PATH`.
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
That's great news, please go for it!
--
Michael R. Crusoe ; he/him
https://orcid.org/-0002-2961-9670
CWL Project Leader, Software Freedom Conservancy, Common Workflow Language
project
Promovendus, VU Amsterdam, Computer Systems & Bioinformatics
Project Leader FAIR Service Architecture in ELIXI
That's great news, please go for it!
--
Michael R. Crusoe ; he/him
https://orcid.org/-0002-2961-9670
CWL Project Leader, Software Freedom Conservancy, Common Workflow Language
project
Promovendus, VU Amsterdam, Computer Systems & Bioinformatics
Project Leader FAIR Service Architecture in ELIXI
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 ab
I made myself a personal package of the head of upstream, which worked for
me.
It is based off of
https://github.com/DisplayLink/evdi/commit/b0b2c80eb63f9b858b71afa772135f434aea192a
https://people.debian.org/~crusoe/evdi/
Cheers,
On Fri, Oct 1, 2021 at 11:54 AM Hanno Stock
wrote:
> Thanks, I
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 fil
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 n
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 &#
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
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 fa
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 trul
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/me
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
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 avail
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
>
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
aro
On Fri, 15 Jan 2021 at 11:22, Andreas Tille wrote:
> On Fri, Jan 15, 2021 at 11:16:48AM +0100, Michael Crusoe wrote:
> > bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used,
> so
> > try with clearing out LD_PRELOAD first
>
> Ahhh, this makes perfectly
On Fri, 15 Jan 2021 at 11:22, Andreas Tille wrote:
> On Fri, Jan 15, 2021 at 11:16:48AM +0100, Michael Crusoe wrote:
> > bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used,
> so
> > try with clearing out LD_PRELOAD first
>
> Ahhh, this makes perfectly
bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used, so
try with clearing out LD_PRELOAD first
bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used, so
try with clearing out LD_PRELOAD first
bowtie2 segfaults for me if eatmydata and/or cowbuilder are being used, so
try with clearing out LD_PRELOAD first
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/
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/
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 branc
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 branc
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 ea
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 ea
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
d
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
d
box 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 pushed a commit that works around the _mm_malloc / xmmintrin.h issue ,
but there is usage of the rdtsc assembly operand that I don't have an arm64
analogue for.
On Sat, 5 Dec 2020 at 21:07, Andreas Tille wrote:
> Hi Steve,
>
> On Sat, Dec 05, 2020 at 04:18:53PM +, Steve McIntyre wrote:
> >
I pushed a commit that works around the _mm_malloc / xmmintrin.h issue ,
but there is usage of the rdtsc assembly operand that I don't have an arm64
analogue for.
On Sat, 5 Dec 2020 at 21:07, Andreas Tille wrote:
> Hi Steve,
>
> On Sat, Dec 05, 2020 at 04:18:53PM +, Steve McIntyre wrote:
> >
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
-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 thi
icard 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 pic
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 pb
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 pa
Thank Berhard for this patch.
Also the autopkgtests do not yet patch with i386 (at least):
Testing bedtools shuffle:
shuffle.t1...1,10c1,10
< chr2 34697611 34698079 trf 789
< chr4 97373990 97374163 trf 346
< chr1 211569500 211569740 trf 434
< chr15 100895645 100895867 trf 273
< chr10 79193410
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
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.mak
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.mak
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
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
re
at 11:52:16AM +0200, Michael Crusoe wrote:
> > Reply from upstream
> >
> > https://gitter.im/seqan/Lobby?at=5f1e97ece9066820051dc93e
> >
> > > You can fix that reported error by specifying `cmake
> > -DCMAKE_CXX_FLAGS="-std=c++17 -fconcepts" <...>`
at 11:52:16AM +0200, Michael Crusoe wrote:
> > Reply from upstream
> >
> > https://gitter.im/seqan/Lobby?at=5f1e97ece9066820051dc93e
> >
> > > You can fix that reported error by specifying `cmake
> > -DCMAKE_CXX_FLAGS="-std=c++17 -fconcepts" <...>`
Reply from upstream
https://gitter.im/seqan/Lobby?at=5f1e97ece9066820051dc93e
> You can fix that reported error by specifying `cmake
-DCMAKE_CXX_FLAGS="-std=c++17 -fconcepts" <...>`
Reply from upstream
https://gitter.im/seqan/Lobby?at=5f1e97ece9066820051dc93e
> You can fix that reported error by specifying `cmake
-DCMAKE_CXX_FLAGS="-std=c++17 -fconcepts" <...>`
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 w
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
[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.or
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 t
Sure, I'll add this to my queue
On Sun, May 31, 2020 at 7:54 AM Andreas Tille wrote:
> Hi Michael,
>
> On Sat, May 23, 2020 at 11:10:37PM +0300, Adrian Bunk wrote:
> > Source: hyphy
> > Version: 2.2.7+dfsg-1
> > Severity: serious
> >
> > https://buildd.debian.org/status/package.php?p=hyphy
> >
>
Sure, I'll add this to my queue
On Sun, May 31, 2020 at 7:54 AM Andreas Tille wrote:
> Hi Michael,
>
> On Sat, May 23, 2020 at 11:10:37PM +0300, Adrian Bunk wrote:
> > Source: hyphy
> > Version: 2.2.7+dfsg-1
> > Severity: serious
> >
> > https://buildd.debian.org/status/package.php?p=hyphy
> >
>
Attached is a fix , also available at
https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/3 for
the convenience of the maintainers
On Fri, May 29, 2020 at 7:51 AM Adrian Bunk wrote:
> Source: obs-studio
> Version: 25.0.8+dfsg1-1
> Severity: serious
> Tags: ftbfs
>
> https://bui
Attached is a fix , also available at
https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/3 for
the convenience of the maintainers
On Fri, May 29, 2020 at 7:51 AM Adrian Bunk wrote:
> Source: obs-studio
> Version: 25.0.8+dfsg1-1
> Severity: serious
> Tags: ftbfs
>
> https://bui
Attached is a fix , also available at
https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/3 for
the convenience of the maintainers
On Fri, May 29, 2020 at 7:51 AM Adrian Bunk wrote:
> Source: obs-studio
> Version: 25.0.8+dfsg1-1
> Severity: serious
> Tags: ftbfs
>
> https://bui
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 no
oe
> 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 incorpo
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 a
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 knowledg
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
[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
That's fine by me
--
Michael R. Crusoe
On Thu, May 7, 2020, 09:53 Andreas Tille wrote:
> Hi Michael,
>
> this bug continuously creates noise on the testing removal front. I'd
> really love to ask for removal the failing arches for the moment.
>
> What do you think?
>
> Kind regards
>
> An
That's fine by me
--
Michael R. Crusoe
On Thu, May 7, 2020, 09:53 Andreas Tille wrote:
> Hi Michael,
>
> this bug continuously creates noise on the testing removal front. I'd
> really love to ask for removal the failing arches for the moment.
>
> What do you think?
>
> Kind regards
>
> An
r 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
> >>> l
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.
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 modif
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 modif
This looks like something I can fix for all architectures and still respect
the baselines with SIMDe, yes.
On Sat, Apr 18, 2020 at 6:26 PM Andreas Tille wrote:
> Hi Adrian,
>
> recently Michael Crusoe injected simde which should solve the SSE issue
> in a more elegant way. Michae
This looks like something I can fix for all architectures and still respect
the baselines with SIMDe, yes.
On Sat, Apr 18, 2020 at 6:26 PM Andreas Tille wrote:
> Hi Adrian,
>
> recently Michael Crusoe injected simde which should solve the SSE issue
> in a more elegant way. Michae
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 v
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 v
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/
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
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
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
>
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
>
There is lots of other AFL 2.1 and AFL 3.0 code already in Debian,
including subversion
https://sources.debian.org/src/subversion/1.10.4-1/debian/copyright/?hl=55#L56
Full list:
https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+AFL
--
Michael R. Crusoe
Co-founder & Lead,
Common Wo
--
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 instal
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:
> &g
gbp clone g...@salsa.debian.org:med-team/simde.git
Thanks!
--
Michael R. Crusoe
On Tue, Mar 31, 2020 at 1:19 PM Andreas Tille wrote:
> Hi Michael,
>
> On Tue, Mar 31, 2020 at 11:12:45AM +0200, Matthias Klose wrote:
> > Package: src:bedtools
> > Version: 2.29.2+dfsg-3
> > Severity: serious
> > Tags: sid bullseye
> >
> > bedtools ftbfs, failing tests on armel, armhf, i386, mip
On Tue, Mar 31, 2020 at 1:19 PM Andreas Tille wrote:
> Hi Michael,
>
> On Tue, Mar 31, 2020 at 11:12:45AM +0200, Matthias Klose wrote:
> > Package: src:bedtools
> > Version: 2.29.2+dfsg-3
> > Severity: serious
> > Tags: sid bullseye
> >
> > bedtools ftbfs, failing tests on armel, armhf, i386, mip
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
Hello,
While looking at updating ruaml.yaml I discovered that the recent releases
need a separate package: ruamel.yaml.clib
gbp clone g...@salsa.debian.org:misterc-guest/ruamel.yaml.clib.git
Please push this to
https://salsa.debian.org/python-team/modules/ruamel.yaml.clib (I lack the
necessary p
gbp clone g...@salsa.debian.org:science-team/routine-update.git
Thanks!
--
Michael R. 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*
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
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
>
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.
Th
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 inspire
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 Cru
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
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.
&
[ 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 LI
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 a
gbp clone g...@salsa.debian.org:med-team/libbio-alignio-stockholm-perl.git
Thanks!
--
Michael R. 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.
1 - 100 of 2690 matches
Mail list logo
