avldrums.lv2 - DD upload

James Cowgill jcowgill at debian.org
Mon Jun 26 13:26:34 UTC 2017


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

> 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.

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170626/103a2dd4/attachment.sig>


More information about the pkg-multimedia-maintainers mailing list