David Henningsson escrigué:
dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided
if "debian/fluidsynth/usr/bin/fluidsynth" were not uselessly linked
against it (they use none of its symbols).
Since "ldd fluidsynth" displays a dependency on libpthread this issue
seems to be inherited from upstream. Is this a problem that can be fixed
by editing the autotools files? Josh, perhaps you know how to fix that?
The fact is that libfluidsynth has to be linked but not the fluidsynth
executable. It seems like something that has to be tweaked in the
autotools files but since I'm not fond on that I can't help you. I guess
it should be easy for someone that knows. Before wasting more time on
this I would ask in the DD list how important is this and how to fix it.
DD are used to dealing with these things.
I can't install the -dev package since it depends on libjack0.100.0-dev,
this is a dummy transitional package, you should depend on libjack-dev
instead.
Ok, noticed. But can't you just install libjack0.100.0-dev then? It is
present in sid.
I know I can install it that way while the dummy exists but I think
there's no point in depending on dummies, that's just for old packages.
Now that we're at it, QSynth is orphaned, aren't you interested on
maintaining it too? ;)
Given the boring copyright work I had to do for fluidsynth, I'm not
interested at the moment. After all, fluidsynth 1.0.9 is not even
uploaded to unstable yet. :( If you or anyone else want to help out, you
can do so by verifying that there are no copyright violations in
fluidsynth, in particular, checking
1) that the alsa driver has not borrowed any code from Ardour (which is
currently released under GPL).
2) that the code borrowed from the music-dsp code archive (or list) was
used with permission.
// David
That's hard to do, but it's something that Josh or any of the old
developers could know. In case there's no information available I would
follow Linus approach, guess there's nothing wrong until someone proves
to the contrary.
After all, we're not talking about big chunks of code, and it might be
impossible to know for sure where every bit of code came from. This is
the only practical way to do it, unless you can talk with every
developer that ever contributed to FS and they remember their contribution.
--
Bernat Arlandis i Mañó
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
