Dear mentors,
I am looking for reviews of my package "chromaprint".
* Package name: chromaprint
Version : 0.6-1
Upstream Author : Lukas Lalinsky
* URL : http://wiki.acoustid.org/wiki/Chromaprint
* License : LGPL-2.1+
Section : libs
It builds th
* Simon Chopin , 2011-12-26, 15:19:
http://mentors.debian.net/package/chromaprint
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/c/chromaprint/chromaprint_0.6-1.dsc
Here's my review:
+- The python bindings
Hi Jakub,
Thanks for taking the time to review my work.
On Thu, Dec 29, 2011 at 11:22:08AM +0100, Jakub Wilk wrote:
> * Simon Chopin , 2011-12-26, 15:19:
> > http://mentors.debian.net/package/chromaprint
> >
> >Alternatively, one can download the package with dget using this command:
> >
> > dget
* Simon Chopin , 2012-01-03, 16:38:
+libchromaprint.so.0 libchromaprint0 #MINVER#
[c++ symbols]
It's slightly worrisome that these symbols are exported in the first
place. OTOH I don't know if there's a simple and upstreamable way to
hide them. (Upstream is using cmake.)
Yep, I've looked aroun
On Wed, Jan 04, 2012 at 01:53:02AM +0100, Jakub Wilk wrote:
> * Simon Chopin , 2012-01-03, 16:38:
> >>+libchromaprint.so.0 libchromaprint0 #MINVER#
> >[c++ symbols]
> >>It's slightly worrisome that these symbols are exported in the
> >>first place. OTOH I don't know if there's a simple and
> >>upst
* Simon Chopin , 2012-01-07, 10:10:
But anyway, on i386 I get this lintian error:
E: libchromaprint0: symbols-file-contains-current-version-with-debian-revision
on symbol
_ZNSt6vectorIdSaIdEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPdS1_EEjRKd@Base
and 2 others
I added a specific symbol
On Sun, Jan 08, 2012 at 06:01:39PM +0100, Jakub Wilk wrote:
[...]
>
> As a side note, for extra safety it'd be good to make sure that if
> ever these symbols are used, the generated dependency is either
> unsatisfiable or strictly versioned. Unfortunately, the latter
> option is currently a bit di
* Simon Chopin , 2012-01-09, 13:38:
As a side note, for extra safety it'd be good to make sure that if
ever these symbols are used, the generated dependency is either
unsatisfiable or strictly versioned. Unfortunately, the latter option
is currently a bit difficult to implement; see bug #615940
On Mon, Jan 09, 2012 at 02:07:42PM +0100, Jakub Wilk wrote:
> * Simon Chopin , 2012-01-09, 13:38:
> >>As a side note, for extra safety it'd be good to make sure that
> >>if ever these symbols are used, the generated dependency is
> >>either unsatisfiable or strictly versioned. Unfortunately, the
>
9 matches
Mail list logo
