Re: RFS: libmurmurhash 1.3
I had a look on the build logs and at least mips and s390x keep
on failing (some archs are not yet build).
Sorry for keeping you busy with this
On Mon, Feb 11, 2019 at 05:28:32PM +0100, Andreas Tille wrote:
> On Mon, Feb 11, 2019 at 04:53:16PM +0100, Fabian Klötzl wrote:
> > > Could you be more verbose about what you did and what lintian error was
> > > issued? Normally you do not simply remove symbols vrom the .symbols
> > > file manually. You should rather declare the interface private inside
> > > the code and update the symbols file.
> > Long Description: PMurHash comes with a few functions e.g.
> > "PMurHash32_Process" which I use internally, but I don't want to support.
> > The true API of libmurmurhash consists of six functions "prefixed with lmmh_
> > or MurmurHash3_. Only these functions appear in the header supplied by the
> > -dev package. As they are the public interface, only they should appear in
> > the symbols file, right?
> > > So my advise to upstream is:
> > >
> > > 1. Declare the private functions really private
> > Got it; managed to define the PMurHash with visibility hidden. Will create a
> > new upstream version with bumped soname some time.
> > > 2. Use Automake
> > I leave it to Lennart Poettering to describe the madness that are the
> > autotools: „Das ist ein Perlskript, das ein m4-Skript generiert, das ein
> > Shellskript generiert, was ein Makefile generiert.“  Even though I know
> > automake, I am a bit reluctant to add it to libmurmurhash, because I think
> > that for such a small project a simple makefile should suffice. (And it
> > works just fine on Arch Linux *cough*)
> You try to use the method "proof by authority" to make your point? ;-P
> Well, I did not added the patch since I have to much spare time. As
> far as I remember your package had three issues:
> 1. No multiarch triplet installation
> 2. Static lib in wrong place.
> 3. No pkg-config support
> So I had the choice to move things around manually to use d-shlibs or to
> write some Makefile creating system. I'm less educated with cmake thus
> I cut-n-pasted some existing automake patches we have for other libs.
> The point is that you need to write only a few lines of code to solve
> all three issues above and in the end it might help other distributors
> as well. If you prefer cmake (or whatever you authority suggest ;-))
> that's perfectly fine for me. To quote another authority: "Everything
> should be made as simple as possible, but not simpler." (A. Einstein)
> I regard the simple Makefile as to simple for the intended purpose.
> > > 3. Bump SONAME if the resulting lib has changed / removed symbols
> > >
> > > Please note: Bumping SONAME also means changing the package name and
> > > thus trying another round inside new queue. While currently ftpmaster
> > > is incredibly quick I've seen relion sitting there for longer than
> > > expected due to the same reason (admittedly way more complex code to
> > > review). In any case the tour via new queue has a non-predictable delay
> > > time and may be we wait until mash has migrated to testing before doing
> > > this.
> > Fully agree on this one; Let's take one step after the other, first
> > libmurmurhash, then mash, then our other packages, and, maybe if we want to
> > and the API/ABI is stable, other debian packages.
> Fine. So we have some time to decide.
> Kind regards and thanks a lot for your work on that lib in any case
> > 1: https://cre.fm/cre209-das-linux-system?t=15:53