On Fri, Feb 08, 2019 at 04:54:28PM +0100, Fabian Klötzl wrote:
> >
> > [2] https://buildd.debian.org/status/package.php?p=libmurmurhash=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 will
>
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=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.
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
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
> >
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
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.
> >
Control: block -1 by 921353
COntrol: tags -1 pending
On Mon, Feb 04, 2019 at 05:26:08PM +0100, Fabian Klötzl
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
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
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
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
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
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
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
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
21 matches
Mail list logo
