avldrums.lv2 - DD upload

[Jaromír Mikeš]

2017-06-26 15:26 GMT+02:00 James Cowgill <jcowgill at debian.org>:

> Hi,
>
> On 26/06/17 12:20, Jaromír Mikeš wrote:
> > 2017-06-26 11:26 GMT+02:00 James Cowgill <jcowgill at debian.org
> > <mailto:jcowgill at debian.org>>:
> >> override_dh_auto_install:
> >>       $(MAKE) install \
> >>               DESTDIR=$(CURDIR)/debian/tmp \
> >>               PREFIX=/usr
> >>
> >> And "dh_auto_install" here.
> >
> > Done!
>
> Sorry, when I said that I meant do the same thing as you have done for
> dh_auto_build with dh_auto_install here. Like this:
>
> override_dh_auto_install:
>         dh_auto_install -- DESTDIR=$(CURDIR)/debian/tmp
>

Ok ... Fixed!


>
> > I have discussed this with upstream before ...
> > here is answer ... (  same might go for robtk? )
> > ------------------
> >
> >> Is there some way use rather system-wide fluidsynth lib?
> >
> > No (same with Ardour btw). It's a stripped down and patched dedicated
> > version and statically linked with hidden symbols.
> >
> > Pro Audio Plugins should be self-contained and not rely on any system
> > libs except for libc (and libX11/xcb which needs to match the X11 server
> > ABI).
> >
> > There are too many things that can go wrong otherwise (calf is the prime
> > example). e.g. update fftw or mix some random pango/cairo/pixman or even
> > just freetype version and you'll throw thread safety out of the window.
> > Any lib that uses a lock to maintain some global cache will void
> > realtime safety as well.  default fluidsynth falls in that category as
> > well:  .sf2 files are cached globally and a lock is used.
> >
> > Remember, plugins are loaded in the same memory space as the host, which
> > may also use those libs. They're not standalone process separated apps.
> > Ideally plugins are self-contained and don't share any libs with the
> host.
> >
> > If 2 unrelated plugins were to use the same shared libfludsynth various
> > edge cases can happen since the plugins don't know about each other.
> >
> > Also related is exception handling in this case (setjmp/longjmp). At
> > least for rolling distros (e.g. debian/testing) where a library can be
> > compiled with a different compiler version than the plugin and host.
> > --------------
>
> Unfortunately this isn't how Debian works. In my opinion it is
> unacceptable for avldrums.lv2 to be compiled against its own bundled
> version of freetype.
>
> WRT fluidsynth's real-time safety. Upstream may have a point here but
> from reading the fluidsynth source, it seems all the locks are not part
> of the global state, but part of the fluid_synth_t type. This should
> ensure that other plugins sharing fluidsynth cannot interfere with one
> another.
>
> I don't think the .sf2 cache is a very good point, since surely loading
> .sf2 files is not realtime anyway because it requires disk access? The
> fact that it uses a lock is insignificant.
>
> There is no use of setjmp / longjump in either avldrums or fluidsynth so
> that point is irrelevant (and I don't understand how compiler version
> would interfere with this anyway).
>
> >     Building in git:
> >     > Version: debian/0.2.2-1-9 -> debian/0-9 debian/2-9 debian/2-9
> >     debian/1-9
> >     > expr: non-integer argument
> >     > git2lv2.mk:37 <http://git2lv2.mk:37>: *** "Cannot extract required
> >     LV2 minor-version parameter".  Stop.
> >
> >     While this only happens when using git, it is very frustrating. I
> think
> >     you should override the "avldrums_VERSION" variable to fix it.
> >
> > Can you elaborate here? I am not sure how to fix this :(
>
> It was a guess, but it looks like the Makefile uses git to load a
> default into "avldrums_VERSION". Inside the Debian packaging it's going
> to read the Debian tags which are then misparsed. If you override that
> variable with the upstream version, then it should work.
>

Fixed!

mira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170626/adebf579/attachment.html>