On Fri, Feb 08, 2019 at 04:54:28PM +0100, Fabian Klötzl wrote:
> >
> > [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
> hopefully working—version to salsa. Could you sponsor another upload? I w
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
Hi Fabian,
On Thu, Feb 07, 2019 at 03:11:49PM +0100, Fabian Klötzl wrote:
>
> > ./mash info -d test/reads.msh > test/reads.json
> > diff test/genomes.json test/ref/genomes.json
> > 7c7
> > < "hashType" : "MurmurHash3_x86_32",
> > ---
> > > "hashType" : "MurmurHash3_x64_128",
>
> mash uses two
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",
---
On Thu, Feb 07, 2019 at 01:41:54PM +0100, Andreas Tille wrote:
> On Thu, Feb 07, 2019 at 12:03:46PM +0100, Fabian Klötzl wrote:
> > 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 previous commit
> > (ARCH32
On Thu, Feb 07, 2019 at 12:03:46PM +0100, Fabian Klötzl wrote:
> 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 previous commit
> (ARCH32) doesn't work as expected [1]. Building on AMD64 will still have the
>
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,
On Wed, Feb 06, 2019 at 01:20:48PM +0100, Andreas Tille wrote:
> On Mon, Feb 04, 2019 at 05:26:08PM +0100, Fabian Klötzl wrote:
> > 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
Processing control commands:
> block -1 by 921353
Bug #918566 [src:mash] mash FTBFS on big endian: test failures
918566 was not blocked by any bugs.
918566 was not blocking any bugs.
Added blocking bug(s) of 918566: 921353
> tags -1 pending
Bug #918566 [src:mash] mash FTBFS on big endian: test fai
Control: block -1 by 921353
COntrol: tags -1 pending
On Mon, Feb 04, 2019 at 05:26:08PM +0100, Fabian Klötzl wrot
Hi Fabian,
On Mon, Feb 04, 2019 at 05:26:08PM +0100, Fabian Klötzl wrote:
> 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.
Thanks a lot - that's really cool.
> So hereby I kindly ask you to
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
Another comment: For libsmithwaterman I added a patch for automake including
pkg-config input. I'd consider it more flexible than a fixed Makefile.
On Mon, Feb 04, 2019 at 12:02:37PM +0100, Fabian Klötzl wrote:
> As promised, I pushed my packaging attempt. However, I didn't manage to
> create a r
Hi Fabian,
thanks a lot. I've moved it to med-team and fixed Vcs fields.
If you issue an ITP I can sponsor the package immediately.
Thanks for your work on this
Andreas.
On Mon, Feb 04, 2019 at 12:02:37PM +0100, Fabian Klötzl wrote:
> As promised, I pushed my packaging attempt. However,
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
Thanks again, Andreas.
On Sun, Feb 03, 2019 at 10:16:22AM +0100, Fabian Klötzl wrote:
> 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 system
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 Fabian,
do you have any progress on this? I do not want to be impatient but we
are approaching the freeze and if not we should somehow fix the issue
for mash.
Kind regards
Andreas.
On Tue, Jan 08, 2019 at 01:56:03PM +0100, Andreas Tille wrote:
> Cool. Thanks a lot, Andreas.
>
> On
Cool. Thanks a lot, Andreas.
On Tue, Jan 08, 2019 at 12:56:55PM +0100, Fabian Klötzl wrote:
> 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 w
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
Hi Fabian,
On Mon, Jan 07, 2019 at 02:27:58PM +0100, Fabian Klötzl wrote:
> mash internally uses MurmurHash 3 which is sensitive to the endianess. There
we have (at least):
med-team/centrifuge/third_party/MurmurHash3.cpp
med-team/centrifuge/third_party/MurmurHash3.h
med-t
Processing commands for cont...@bugs.debian.org:
> forwarded 918566 https://github.com/marbl/Mash/issues/106
Bug #918566 [src:mash] mash FTBFS on big endian: test failures
Set Bug forwarded-to-address to 'https://github.com/marbl/Mash/issues/106'.
> thanks
Stopping processing here.
Please contact
Hi,
FYI I have already opened an issue upstream for something that might be
related:
https://github.com/marbl/Mash/issues/104
I suspect that some of these failures are connected to the update of
Cap'n Proto to 0.7.0, the issues only started after the dependency was
upgraded in in unstable.
Ch
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
Source: mash
Version: 2.1-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/package.php?p=mash
...
diff test/genomes.dist test/ref/genomes.dist
1,3c1,3
< genome1.fna reads 0.12827 1.02947e-18035/1000
< genome2.fna reads 0.1296046.13708e-17534/1000
< genome3.
27 matches
Mail list logo
