I saw that there was something wrong with the CI of libmurmurhash but
didn't have the time to look into it, yet. Thanks to Matthias for the
patch and to Andreas for releasing a new version so quickly.
Best,
Fabian
Hi Andreas,
On 07.02.19 14:58, Andreas Tille wrote:
There are also build issues of libmurmurhash on some architectures[2]
Any idea what to do next?
[2] https://buildd.debian.org/status/package.php?p=libmurmurhash&suite=sid
I hope to have fixed the build issues upstream. Have pushed a new—and
Hi,
On 07.02.19 16:00, Andreas Tille wrote:
> I've obviously missed that part of your mail. It is fixed now and I'll
> re-upload.
No worries. The alternative would have been to create a separate set of
unit tests for the 32bit architectures.
>
> Meanwhile I've fixed the symbols file in Git. P
On 07.02.19 14:58, Andreas Tille wrote:
Unfortunately the -DARCH32 flag (which is set according to the build log[1])
does
not help on i386 architecture:
./mash info -d test/reads.msh > test/reads.json
diff test/genomes.json test/ref/genomes.json
7c7
< "hashType" : "MurmurHash3_x86_32",
---
Hi Andreas,
On 07.02.19 08:10, Andreas Tille wrote:
Unfortunately it does not pass its build time tests any more now that I
rebuild it for uploading.
I had a look and could trace the failure to two issues. 1) The test
should run sequentially; can be fixed via a simple override. 2) The
previ
Hi Andreas,
So I improved the upstream libmurmurhash, adapted the package and filed
an ITP (#921353). I even managed to locally build mash against the new
package. So hereby I kindly ask you to fix the last lintian issue about
NMU which I don't fully understand and then maybe sponsor an upload
As promised, I pushed my packaging attempt. However, I didn't manage to
create a repository under med-team, thus it is under my account [1].
Best
Fabian
1: https://salsa.debian.org/kloetzl-guest/libmurmurhash
Hi Andreas,
I started a new project `libmurmurhash` which should fix the problem of
code duplication [1]. However, I could not yet check whether my code
produces the correct result on big endian systems without crashing. On
x64 it works fine and I also produced a working package locally. I could
c
Hi,
There are 162 packages in Debian containing the string MurmurHash. Some
of them use an implementation called PMurHash which fixes the endianess
issue.
On 07.01.19 16:42, Andreas Tille wrote:
> It seems to be time to package MurmurHash3 separately, isn't it?
Yeah, I think it makes sense to cr
forwarded 918566 https://github.com/marbl/Mash/issues/106
thanks
mash internally uses MurmurHash 3 which is sensitive to the endianess.
There is a note in the source [1], but no preventive measures are taken.
I will forward this upstream and might even have a go at this myself.
(In theory this should not be a big issue expect for slightly
inaccurate/differe
forwarded 912235 https://github.com/rambaut/figtree/issues/128
I agree, using Java 8 is the easy solution, not the nice one. Even with
the hot-of-the-press version 1.4.4 the problem exists, so I opened an
issue upstream [1]. I will continue looking into this even if Java is
not my strength.
Thank you for reporting. I added a fix to the repo. Will get resolved
with the next upload.
Best
Fabian
On 11.09.2018 15:58, Adrian Bunk wrote:
Control: reopen -1
Some builds were still running into #897876 due to the buildd chroots
only regenerated twice per week (which is not something you should be
worried about), but the armhf/i386 and ppc64el FTBFS look more like
actual problems that need f
Hi Andreas,
On 10.09.18 13:59, Andreas Tille wrote:
> /usr/bin/gcc -O3 -ffast-math -fstrict-aliasing -funroll-loops
> -fomit-frame-pointer -Wall -Werror -pedantic -std=c99 -Wno-unused-result
> -Wformat-truncation=0 -pthread -c logistic_dist.c
> logistic_dist.c: In function 'evallogisticML':
> l
Thanks for reporting. There were plenty of string related errors. Fixed
in git repo.
Hi all,
This bug is easily fixed by forcing mauve to use the native getopt. A
half-hearted fix is pushed. However, I have trouble removing the
unnecessary files from the orig tarball, because the pristine-tar branch
contains only a .delta and a .id file?
Any help would be appreciated.
Best
Fabia
Just pushed the fix.
Fabian
Hi Andreas,
While I am fixing this bug, could you please push your changes? There is
a 0.7.0-5 in the archives but not in the git repo.
See also https://qa.debian.org/cgi-bin/vcswatch?package=opensurgsim
Best,
Fabian
Hi,
Above one of the failing tests is a peculiar comment:
// TODO(bert): There is some Eigen flag that causes matrices and vectors
to be
// initialized after all! We should check for that here.
So I am guessing that the authors knew that their test was flaky and
thus we should be save deactiv
Hi Andreas,
On 02.09.2017 14:54, Andreas Tille wrote:
> The htslib issue remains the same but I have no idea how to fix it.
The problem is that Allele.h defines a friend function called `json`
residing in global namespace. However, hts.h already defined a value of
an enum with the same name, thus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 06.08.2015 08:32, Andreas Tille wrote:
> Hi Fabian,
>
> I hope you read the mailing list
> debian-med-packag...@lists.alioth.debian.org or at least have
> subscribed this package in the Debian Package Tracker. If not
> please do either of on
22 matches
Mail list logo
