Bug#859793: fluidsynth: Package has infringed GPL
Hi. This came as a surprise for me. What's worse, it seems like none of the maintainers are currently active in Fluidsynth, and AFAIK none of us have time to either rewrite fluid_chorus.c, or track down all contributors to it since 1998. What makes things slightly easier for us as upstream is that FluidSynth is released under LGPL rather than GPL. LGPL allows linking to custom licenses. Thus, my suggestion for us as upstream is that we clearly document (in readme files etc) that we have one file that is not LGPL. That I can do. Perhaps Debian has the time/manpower required to track down contributors? FWIW, In the event that I should hold any copyright in fluid_chorus.c, I'm happy to allow these to be relicensed under GNU LGPL 2.0+. Regards, David Henningsson On 2017-04-07 20:01, Jaromír Mikeš wrote: 2017-04-07 14:16 GMT+02:00 Javier Serrano Polo <mailto:jav...@jasp.net>>: Source: fluidsynth Version: 1.1.6-4 Severity: wishlist fluid_chorus.c is under a custom license, granting the following: This source code is freely redistributable and may be used for any purpose. Hi fluidsynth devs, we serious licensing issue in debian in fluid_chorus.c file. Is there any chance to relicense this file with some GPL friendly license? Full bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859793 best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#713713: [PATCH] Explicitly instantiate AbstractUI template
On 10/04/2013 06:07 PM, Adrian Knoth wrote:
> On 10/01/13 15:24, David Henningsson wrote:
>
>> This fixes a build failure on Debian/Ubuntu.
>>
>> BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713713
>> Signed-off-by: David Henningsson
>> ---
>> libs/gtkmm2ext/gtk_ui.cc | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> I'm not a C++ template expert, so I'm not sure this is the most
>> elegant fix,
>> but at least it builds now. I found it on git trunk too (2.0-ongoing
>> branch),
>> so I'm including Paul Davis as well.
>>
>> diff --git a/libs/gtkmm2ext/gtk_ui.cc b/libs/gtkmm2ext/gtk_ui.cc
>> index 291740c..0894b07 100644
>> --- a/libs/gtkmm2ext/gtk_ui.cc
>> +++ b/libs/gtkmm2ext/gtk_ui.cc
>> @@ -63,6 +63,8 @@ BaseUI::RequestType Gtkmm2ext::AddTimeout =
>> BaseUI::new_request_type();
>>
>> #include /* instantiate the template */
>>
>> +template class AbstractUI;
>> +
>> UI::UI (string namestr, int *argc, char ***argv)
>> : AbstractUI (namestr, true)
>> {
>>
>
> Thanks for the patch, confirmed to work. Will upload in a second.
>
>
>
> Cheers
>
While you're at it, you might also be intersted in the bug below - not
sure it hits Debian too because you run 2.8.16 instead of 2.8.14 though.
https://bugs.launchpad.net/ubuntu/+source/ardour/+bug/1234866 (Linker
errors when starting ardour)
https://bugs.launchpad.net/ubuntu/+source/ardour/+bug/1234866/+attachment/3857945/+files/0001-Add-boost-linking-to-tranzport-and-generic-midi-surf.patch
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#713713: [PATCH] Explicitly instantiate AbstractUI template
This fixes a build failure on Debian/Ubuntu.
BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713713
Signed-off-by: David Henningsson
---
libs/gtkmm2ext/gtk_ui.cc | 2 ++
1 file changed, 2 insertions(+)
I'm not a C++ template expert, so I'm not sure this is the most elegant fix,
but at least it builds now. I found it on git trunk too (2.0-ongoing branch),
so I'm including Paul Davis as well.
diff --git a/libs/gtkmm2ext/gtk_ui.cc b/libs/gtkmm2ext/gtk_ui.cc
index 291740c..0894b07 100644
--- a/libs/gtkmm2ext/gtk_ui.cc
+++ b/libs/gtkmm2ext/gtk_ui.cc
@@ -63,6 +63,8 @@ BaseUI::RequestType Gtkmm2ext::AddTimeout =
BaseUI::new_request_type();
#include /* instantiate the template */
+template class AbstractUI;
+
UI::UI (string namestr, int *argc, char ***argv)
: AbstractUI (namestr, true)
{
--
1.8.3.2
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#713488: Fixed in Ubuntu
Hi, It looks like Ubuntu has fixed this issue, see: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/qsynth/saucy/revision/17/debian/patches/1002_libx11_underlinkage.patch Not sure if that's the right or most elegant solution though, as I'm not a build system guru (yet!). -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug report on fluidsynth: fluidsynth crashes with exit status 139
On 06/26/2013 07:42 PM, Alexandre Rebert wrote: Hi, We found a crash in fluidsynth contained in the fluidsynth package. You are being contacted because your are listed as one of the maintainer of fluidsynth. Thanks for your report - this has now been fixed upstream: http://sourceforge.net/p/fluidsynth/code/463/ We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. I didn't give it much thinking if this could be exploited somehow, as I'm not a security expert. But by posting this email to a public mailinglist (pkg-multimedia-maintainers), you have already publicly disclosed it yourself, so I figured the best thing would be to fix the bug and release that fix. The bug report that will be submitted to the bug tracker is available at the following url: http://www.forallsecure.com/bug-reports/1963a97d53881360fc37b15d8d1187699e74936c/ This email is part of a mass bug reporting campain comprising 1,182 bugs. You might have received multiple emails from us concerning different programs. More information about the mass bug reporting is available on the debian-devel mailing list: http://lists.debian.org/debian-devel/2013/06/msg00720.html Regards, The Mayhem Team Cylab, Carnegie Mellon University ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FTBFS for jackd2?
On 02/21/2013 06:41 PM, Adrian Knoth wrote: On 02/18/13 10:58, David Henningsson wrote: Hi, Hi! When I'm compiling jackd2 (on Ubuntu 13.04) I get an FTBFS - and since there are no Ubuntu specific changes to jackd2 and I don't understand much of the waf build system I'm asking for your help. I thought we've fixed all of them upstream, but feel free to double-check: https://github.com/jackaudio/jack2/commit/48180257390d13588563e4f90190a0ff3ad92a7b Indeed this one I was missing. Thanks for helping out! -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
FTBFS for jackd2?
Hi, When I'm compiling jackd2 (on Ubuntu 13.04) I get an FTBFS - and since there are no Ubuntu specific changes to jackd2 and I don't understand much of the waf build system I'm asking for your help. The full build log is here: http://paste.ubuntu.com/1676307/ and it ends with: 10:24:45 runner ['/usr/bin/gcc', 'example-clients/server_control.cpp.2.o', '-o', '/tmp/jackd2-1.9.8~dfsg.4+20121110git67ac4440/build/example-clients/jack_server_control', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-Lcommon', '-ljackserver', '-lpthread', '-lrt', '-ldl', '-lm'] /usr/bin/ld.bfd.real: example-clients/server_control.cpp.2.o: undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3' /usr/bin/ld.bfd.real: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO /usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command line /usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid operation As you can see, there's no "-lstdc++", which I assume should be added, but I don't understand how to do it. (Btw, I also tried pkg-multimedia/jackd2.git to see if it was fixed, but it fails even earlier with a "./waf: Command not found" error.) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#656910: Group "audio" is used for two incompatible things
On 01/23/2012 12:31 PM, Adrian Knoth wrote: On Sun, Jan 22, 2012 at 09:02:00PM +0100, David Henningsson wrote: Package: jackd2 The "audio" group has a special meaning in standard desktop usage - as defined in udev rules, it gives access to sound devices to users in that group, thereby overriding/complementing Consolekit's automatic permission assignment (which allows the current logged in user to have sound card access). Nothing wrong about that so far, I'd say. Though I have to admit I don't know what Consolekit does under the hood to grant access to sound cards. Does it change permissions? Does it change ownership of the audio device? It sets ACL file permissions on the sound device nodes. A while ago, I wrote a little more of background information/conclusions here: https://wiki.ubuntu.com/Audio/TheAudioGroup (though I didn't add the word "Debian" there, that was done by somebody else) As a result, it is normally not recommended to let a user be a part of the audio group. How do you arrive at this conclusion? Who gave this recommendation? I believe it to be the conclusion of both PulseAudio developers, and Ubuntu audio developers team. I consider myself to be part of both those teams. Assume, for example, that user A is in the audio group, logged in, and playing music. User B wants the computer temporarily, so they switch users (via fast-user-switching, without user A logging out). Since A can still use the sound card, A's music will continue to play and user B can't access the sound card (regardless of whether B is in the audio group or not). However, jackd2 uses the same group name for a different purpose: it enables (if user activates it on installation) the users in the audio group to run processes with rt priority and unlimited memory locking. Exactly. This is problematic; as a reasonably common use case would be to actually make use of RT priority, but at the same time use ConsoleKit's built-in device assignment. I'm not sure if I understand your paragraph correctly, but do you want to say that nowadays people are usually not in the audio group, so the mechanism of (ab)using @audio in /etc/security/limits.d/audio.conf will no longer work? Worse; making a user part of the audio group will lead to the problem described above (changed behaviour of fast-user-switching). There might be times where this is desired, but let's reserve the "audio" group for those cases - without implying that on everybody who wants to run RT prio processes. My suggestion is to rename "audio" to something else in jackd2. Let's assume we change it to "foo", then the user needs to be part of group "foo". Where's the advantage? Hopefully the explanations above answer this question as well? Side note: "in jackd2" is only half of the story, there's also "jackd1" with the same magic. We intend to refactor this into jack-common one day. Ok, good point. I didn't check jackd1. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#656910: Group "audio" is used for two incompatible things
Package: jackd2 Severity: normal Version: 1.9.8~dfsg.1-1 The "audio" group has a special meaning in standard desktop usage - as defined in udev rules, it gives access to sound devices to users in that group, thereby overriding/complementing Consolekit's automatic permission assignment (which allows the current logged in user to have sound card access). As a result, it is normally not recommended to let a user be a part of the audio group. However, jackd2 uses the same group name for a different purpose: it enables (if user activates it on installation) the users in the audio group to run processes with rt priority and unlimited memory locking. This is problematic; as a reasonably common use case would be to actually make use of RT priority, but at the same time use ConsoleKit's built-in device assignment. My suggestion is to rename "audio" to something else in jackd2. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#536659: closed by Rémi Denis-Courmont (Already fixed)
On 2011-05-17 12:54, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the vlc package: #536659: Please enable midi support by depending on libfluidsynth1 It has been closed by Rémi Denis-Courmont. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Rémi Denis-Courmont by replying to this email. Hi Remi and thanks for your answer. I'm a FluidSynth developer myself and not aware of any current memory leak issues, and AFAIK it hasn't been reported on the fluid-dev mailinglist or ticket system, and does not seem to affect other users of libfluidsynth (or I assume we would have heard about it). In what form would you prefer we work together to resolve this memory leak issue? // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Libsoundtouch{0,1}-dev?
On 2011-02-02 22:35, Miguel Colon wrote: So looks like a "transition" to me, and we probably need to readjust ardour's build dependency (to libsoundtouch-dev). I can take care of this if agreed upon. Hello, yes it's a transition I was the one that made renamed it. Perhaps Alessio wants to provide further clarification. Last time I spoke with Alessio about it from what I understood and remember he was waiting for post-squeeze. But better to wait for an official response since I might have misunderstood. Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? The source packages affected are: Package: ardour Package: audacity Package: djplay Package: freecycle Package: gst-plugins-bad0.10 Package: ihu Package: ocaml-soundtouch Package: rezound Package: yatm In addition: - liquidsoap just needs to be rebuilt whenever ocaml-soundtouch get updated since it depends on libsoundtouch-ocaml-dev and not libsoundtouch directly. - mixx just needs to be rebuilt since it depends on libsoundtouch-dev so it should be fine after a binary upload or something. I basically got this information by adding sid/experimental source repos to the source.list and doing: grep-dctrl -FBuild-Depends libsoundtouch -sPackage /var/lib/apt/lists/*Sources | sort | uniq and confirming with apt-cache rdepends (not sure if there was a better way or if doing it with these 2 commands is not exhaustive enough) I locally recompiled all the packages in a clean chroot when I made the initial rename and what I just posted are my notes from that time. Also, from what I wrote down, all packages except ocaml-soundtouch and liquidsoap worked with just renaming the build dependency but as luck would have it ardour is the only package that I forgot to document the changes I made to it so it would build. Finally I remember Alessio uploading a new version of audacity and freecycle to experimental using the renamed library so the transition on those 2 I assume is done or started. Hope I made some sense. Yes, thanks. I just wanted to raise the issue. I looked at djplay and ihu - should I just file FTBFS bugs against them to tell the maintainer to change the build-depend? Unstable seems to be unchanged, there is nothing in experimental (as of packages.debian.org), and it's not under pkg-multimedia's umbrella. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Libsoundtouch{0,1}-dev?
Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#597977: fluidsynth: FTBFS on kfreebsd-*: fluid_rtkit.c: error: storage size unknown
On 2010-09-24 22:15, Cyril Brulebois wrote: Source: fluidsynth Version: 1.1.2-1 Severity: serious Justification: FTBFS User: debian-...@lists.debian.org Usertags: kfreebsd Hi, your package no longer builds on kfreebsd-*: | cd /build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/obj-x86_64-kfreebsd-gnu/src&& /usr/bin/gcc -Dlibfluidsynth_EXPORTS -DHAVE_LASH -DHAVE_CONFIG_H -g -O2 -fPIC -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/obj-x86_64-kfreebsd-gnu -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/drivers -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/synth -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/rvoice -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/midi -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/utils -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/sfloader -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/bindings -I/build/buildd-fluidsynth_1 .1 .2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/include -I/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/obj-x86_64-kfreebsd-gnu/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/lash-1.0 -o CMakeFiles/libfluidsynth.dir/bindings/fluid_rtkit.c.o -c /build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/bindings/fluid_rtkit.c | /build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/bindings/fluid_rtkit.c: In function 'fluid_rtkit_make_realtime': | /build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/bindings/fluid_rtkit.c:336: error: storage size of 'old_limit' isn't known | /build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/src/bindings/fluid_rtkit.c:336: error: storage size of 'new_limit' isn't known | make[3]: *** [src/CMakeFiles/libfluidsynth.dir/bindings/fluid_rtkit.c.o] Error 1 | make[3]: Leaving directory `/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/obj-x86_64-kfreebsd-gnu' | make[2]: *** [src/CMakeFiles/libfluidsynth.dir/all] Error 2 | make[2]: Leaving directory `/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/obj-x86_64-kfreebsd-gnu' | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/build/buildd-fluidsynth_1.1.2-1-kfreebsd-amd64-S6AiKT/fluidsynth-1.1.2/obj-x86_64-kfreebsd-gnu' | dh_auto_build: make -j1 returned exit code 2 Full build logs: https://buildd.debian.org/status/package.php?p=fluidsynth&suite=experimental I don't know much about kfreebsd, but the problem is likely that "struct rlimit" does not exist on this kernel. The easiest way out at this point is to build without DBUS_SUPPORT on kfreebsd, because there wouldn't be any realtimekit on kfreebsd support anyway, and DBUS isn't used for anything else at the moment. Actually, looking at it now, it seems like realtimekit is not even packaged for Debian (only exists in Ubuntu). -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fluidsynth 1.1.2
On 2010-09-12 12:32, Alessio Treglia wrote: Hi David, it's good to see this new release! Thanks! Just to clarify, I'm also an upstream developer of FluidSynth and was the release manager for 1.1.2. I'm doing both that, and the current packaging update, in my spare time (so it's not sponsored by Canonical). You might want to know that --enable-ladspa causes a build error in 1.1.2. It is fixed in trunk, and I'm considering rolling a patch release, but I wanted to see if there was any difficulties packaging it first, so if there was, I would catch those as well in the patch release. Things are going pretty well (nothing committed to alioth yet), but I noticed that the CMake build system no longer has generates an .a file. I'm not a linking expert, so - does this matter? This means that upstream has decided to not compile static libraries anymore. It's fine for me, I don't have any objection. Okay, good to know. dpkg-buildpackage: full upload; Debian-native package (full source is included) Now running lintian... W: fluidsynth source: debian-watch-file-in-native-package W: fluidsynth source: native-package-with-dash-version How do I avoid that? By switching to format 3.0 (quilt) [1], which allows us to strip upstream's debian directory without repacking the original tarball. Hmm, upstream (as in the original 1.1.2 tarball) does not have a debian directory...? Second theory, can this be related to that I never updated the changelog? I was unsure of how to that with git-dch and all these semi-automatic tools expecting things to be in a certain way. (will "dch -i" do?) Third, Squeeze is now frozen. Can this version still go into unstable, or does it have to go into experimental? I see several changes, so experimental would be the right place [2]. There are several changes, although seen from my perspective, 1.1.2 contain quite important bug fixes, and I find it both more stable and more tested than 1.1.1. Commenting on Launchpad bug #636473, I'm all for having 1.1.2 in Maverick. [1] http://wiki.debian.org/Projects/DebSrc3.0#Advantagesofnewformats [2] http://sourceforge.net/apps/trac/fluidsynth/wiki/ChangeLog1_1_2 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Fluidsynth 1.1.2
FluidSynth 1.1.2 was released a week ago and I thought of trying to package it. For this version, CMake is the new recommended build system, so I am trying to switch to it. Things are going pretty well (nothing committed to alioth yet), but I noticed that the CMake build system no longer has generates an .a file. I'm not a linking expert, so - does this matter? Programs seem to link fine with the .so anyway. Second, git-buildpackage seems to believe it is a native package: dpkg-buildpackage: full upload; Debian-native package (full source is included) Now running lintian... W: fluidsynth source: debian-watch-file-in-native-package W: fluidsynth source: native-package-with-dash-version How do I avoid that? Should I change the current directory from .../fluidsynth to /fluidsynth-1.1.2? Doesn't that contradict the git packaging paradigm? Third, Squeeze is now frozen. Can this version still go into unstable, or does it have to go into experimental? // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#595252: vlc: Says "Please update alsa-lib"
2010-09-02 15:47, Nigel Horne skrev: > Package: vlc > Version: 1.1.3-1 > Severity: normal > > No audio comes out of an audio CD. I get the mesage > > Potential ALSA version problem: > VLC failed to initialize your sound output device (if any). > Please update alsa-lib to version 1.0.23-2-g8d80d5f or higher to try to > fix this issue. > > But when I try "aptitude install alsa-lib", I get > > Couldn't find any package whose name or description matched "alsa-lib" Under Debian and derivatives, alsa-lib is called "libasound2". -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594568: ListIRQInfo and more needs to be in ffado-tools
Package: ffado-tools Version: 2.0.1+svn1856-1 Severity: important Running ffado-diag without having ffado-mixer-qt4 installed results in the following: Traceback (most recent call last): File "/usr/bin/ffado-diag", line 29, in from listirqinfo import IRQ,SoftIRQ,IRQInfo ImportError: No module named listirqinfo I found this in Ubuntu, but looking at the delta it seems like it is present in Debian as well. BugLink: http://launchpad.net/bugs/624514 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#585555: Please don't set the default audio output in /etc/mplayer/mplayer.conf
On 2010-06-11 19:31, Andres Mejia wrote: > severity 58 wishlist > tags 58 wontfix > thanks > > Considering the integration of pulseaudio by many distributions and projects, > and considering the fact that Debian's gnome package ultimitely depends on > pulseaudio through it's dependencies, it's reasonable to assume that > pulseaudio will be installed on a user's machine, for the majority case. > > Also, I think having the sound device taken over by one program, leaving > other > programs with no sound, is a bigger issue than waiting a few seconds for > mplayer to start playback. > > On Friday 11 June 2010 12:13:36 Pascal Gervais wrote: >> Package: mplayer >> Version: 2:1.0~rc3+svn20100502-3 >> Severity: normal >> >> Hi >> >> Since the update from version 2:1.0~rc3+svn20090426 to version >> 2:1.0~rc3+svn20100502 in May 2010, mplayer takes six to seven seconds >> before starting to play any video and audio, trying to find pulseaudio >> on a system where pulseaudio is not installed. >> >> So, can you please let ao=pulse,alsa,sdl:aalib commented in >> /etc/mplayer/mplayer.conf and add in README.Debian that pulseaudio >> users should use ao=pulse in ~/.mplayer/config or specify the '-ao >> pulse' option on their command line. >> >> Thanks Wouldn't it be a better solution to try to troubleshoot why it takes so long for the pa driver to detect that PA is not installed? // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [OT] External audio interface recommendations?
On 2010-05-25 02:26, Felipe Sateler wrote: > I'm looking for an external audio interface, something that is not > crap like the Intel HDA that comes with my laptop :p. Do you have any > recommendations of interfaces that work well with Linux? I do not need > lots of channels, I just need 2 ins and 2 outs, so nothing really > fancy. I've found my Indigo IO work well so far, it needs alsa-firmware though, and echomixer (packaged in alsa-tools). It has the advantage of that since you just plug it in the cardbus slot, it stays in there (instead of FW and USB where you have move two pieces of hardware around, both the laptop and the soundcard). And the quality is quite good also, according to my ears as well as the specs (IIRC). // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack...
Gabriel M. Beddingfield wrote: > > > On Sat, 17 Apr 2010, Jonas Smedegaard wrote: > >>> stop right here. >>> the library and the daemon are tied together. >>> the protocol between jackd and libjack is NOT fixed. >>> >>> (basically i consider it a mistake to even have libjack and jackd in >>> different packages) but it might make sense to have that. >> >> The separation of library and daemon is so that an application can >> link against the library without forcing the daemon to be installed: >> the JACK support might be optional for that application (without it >> being a plugin that can be packaged separately from the main application. > > When you register with libjack, it will start the daemon if it is not > already running. So, you can't have the library without the daemon.[*] >From a distribution point of view - and just to clarify what I think Jonas is trying to say - a lot of people will need the library but not the daemon. E g FluidSynth (and many other applications) can use both ALSA and JACK backends, so Debian ships FluidSynth with bindings to libjack, although many users will just use the ALSA backend. These users will have to install libjack but not the daemon. And just linking to libjack doesn't cause jackd to start. // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4
Reinhard Tartler wrote: > I guess other VCS systems like hg or bzr at least try something in that > directions (although I have to admit that I didn't follow the latest > developments there). As for bzr, you might find this recent thread interesting: https://lists.ubuntu.com/archives/ubuntu-devel/2010-March/030507.html Long story short, they're planning to transform quilt patches into commits[1], and the other way around. I would personally prefer that, compared to encapsulating quilt patches inside VCS commits which seems to be the common case today. // David [1] To be accurate, it's bazaar "pipes". ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Real-life meeting
Adrian Knoth wrote: > Hi! > > A while ago, there was a proposal for a real-life team meeting. In the > end, we decided to have IRC meetings, first. > > If you think it's worth to have a real-life session, then it's probably > a good idea to meet before releasing squeeze. > > AFAIK, Debian will sponsor food, accommodation and travelling for such a > team meeting. > > > Who's interested? Proposals for time and place? I have already decided to participate in the Linux Audio Conference, see http://lac.linuxaudio.org/2010/ I'm hoping to see some of you there as well. // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#561996: Fixed in testing
notfound 1.3.6-1 This was fixed in version 1.3.6. I'm not sure whether Debian has it available in a backports repository, but I have a packaged version for Ubuntu Hardy here: https://launchpad.net/~diwic/+archive/ppa It should compile without changes on Lenny. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bits from the Release Team: What should go into squeeze?
Adrian Knoth wrote: > On Wed, Mar 17, 2010 at 11:20:17AM -0300, Felipe Sateler wrote: >> On the other hand, for casual use of jack, a more stable version would >> be preferred over a more featureful one. > Unfortunately, this is only half of the story. For the occasional use of > jack, jackd2 is easier to use, because it can suspend pulseaudio. Let me add a third half to the story then :-) Lennart (as in the PulseAudio developer) came up with an idea of reserving / letting go of audio devices via calls over D-Bus. This is not implemented in jack1. I haven't tested jackd2, but I believe it is implemented there. I don't think any of them actually *suspends* PulseAudio. > In the jackd1 case, the user needs to shutdown pulseaudio or any other > application blocking the soundcard. PulseAudio will release the soundcard after a few seconds of no sound playing. So all you have to do is wait a few seconds, then you're free to start jackd. An alternative is to call "pasuspender", so that should be quite simple if you run it from the command line. Somewhat related is that Ubuntu has a wrapper script, that suspends PulseAudio when starting qjackctl. Whether this is a good idea or not can be debated, especially as PulseAudio has a jack module... // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#516692: Patch is already in Debian
The patch enabling Pulseaudio via ALSA has been in Audacity's portaudio
tree since 1.3.6-1. If the ALSA:pulse device does not show up, it is a
configuration issue.
The following in your .asoundrc should do it:
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
In Ubuntu this is enabled by default, but I'm unsure if it does in Debian.
// David
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: RFS: FluidSynth 1.1.1
Alessio Treglia wrote: > Hello folks, > > On Mon, Jan 4, 2010 at 11:23 PM, Reinhard Tartler wrote: >> I feel uncomfortable with sponsoring that package because there seems no >> on else in the team supporting it. Perhaps collab-maint would be a >> better home for it? > > I'm interested in co-maintaining it, so please, let it remain in > pkg-multimedia's git area. That's most welcome and I'm happy to have someone to poke when I need an upload! ;-) I see you did some work on the packaging and also released 1.1.1-1 to unstable, which is also very welcome. Btw, I saw you enabled ladspa support; have you tried it and found it to be working? The reason it is not enabled by default, is that (as I've been told from reading upstream's ML) long time ago it was reported to be buggy and since then nobody ever did something to repair it. However, if we do not use it we should remove the build-dependency on ladspa-sdk (which I see now has been left there by my mistake). What do you think? // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
RFS: FluidSynth 1.1.1
FluidSynth 1.1.1 has now been available at http://git.debian.org/?p=pkg-multimedia/fluidsynth.git;a=summary for over a week. I was hoping that the "Debian Multimedia Team"-ifying of FluidSynth would lead to that a DD would step up and sponsor it, both now and in the future. Should no DD be willing to do so, I would like my git repository to be removed again and I will go out in the blistering cold and search for a sponsor in other ways. // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FluidSynth 1.1.1
Fabian Greffrath wrote: > Am 22.12.2009 15:43, schrieb David Henningsson: >> 3) In addition to the above, I start to use git as with most other >> projects here, in that case I'll need some admin to make the initial >> setup, or push (I assume?). > > I'd also suggest to go this way. Please get an account on alioth.d.o and > apply for the pkg-multimedia team. I (or any other admin) will add you > as soon as possible. Ok, there is now a fluidsynth.git available at git.debian.org. It should be ready for releasing to unstable. // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
FluidSynth 1.1.1
Hi, FluidSynth upstream has finally released version 1.1.1 and I've almost done the packaging. FluidSynth has not been a part of Debian Multimedia historically, but it sure fits in nicely with Rosegarden, Jack and the other packages we maintain here. So, I see three options now: 1) I continue to maintain FluidSynth by myself, in that case I'll need a sponsor, hopefully one of you DD's can help me out? 2) As above, but I update the maintainer to be Debian Multimedia Maintainers and make myself an uploader instead. 3) In addition to the above, I start to use git as with most other projects here, in that case I'll need some admin to make the initial setup, or push (I assume?). As I will probably, in practice, maintain it myself for the foreseeable future, I don't really see the need for the git overhead. But I'll adhere to your requirements if necessary ;-) // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#560919: Expat issues update
Michael Gilbert wrote: > Hi all, > > In order to guarantee that the system expat is used, the > '--with-expat=sys' configure argument must be used. If you think > your package is already using the system expat, or if you are updating > your package to use the system expat, please check to make sure that > this option is being used. Thanks. Audacity debian/rules uses '--with-expat=system', which seems to me like the correct way for configuring audacity (see line 367 in configure.in of audacity for reference). Can you please explain why this isn't good enough for you? // David ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
