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 <jav...@jasp.net <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
Bug#798248: [pulseaudio-discuss] [PATCH] Fix test-suite failure on Alpha
On 2015-09-15 06:45, Arun Raghavan wrote: On 9 September 2015 at 15:19, Michael Cree <mc...@orcon.net.nz> wrote: Pulseaudio fails to build on the Alpha architecture due to a failure in the volume-test of the test suite. I had reported this to the Debian bug tracker [1] but the maintainer has asked that I forward the patch to this mail list. The failure in volume-test occurs because it is compiled with -ffast-math which implies -ffinite-math-only of which the gcc manual states that it optimizes for floating-point arithmetic with the assumption that arguments and results are not NaNs or +/-infinity, and futher notes that it may result in incorrect output. On the Alpha platform that is somewhat an understatement as the use of non-finite floating-point arithmetic with -ffinite-math-only results in a floating-point exception and the termination of the program. The volume-test converts volumes into decibels (so a zero volume becomes a negative infinity) and proceeds to add two volumes (in decibels), thus does arithmetic with non-finite floating point numbers despite being compiled with -ffast-math! I attach a patch that protects against the arithmetic with non-finite numbers for your consideration. With that patch the test-suite passes on Alpha. Cheers Michael. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248 Thanks for the fix! I've pushed this out to our next branch (since we're frozen for the 7.0 release, it'll only make it out in 8.0). Hi Arun, Thanks for picking it up, but I think this is a typical example of a bug fix that should go in 7.0 even though we're frozen. Not merging it only leads to more buggy 7.0 release, and more distro patching for downstreams. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
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 david.hennings...@canonical.com
---
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 pbd/abstract_ui.cc /* instantiate the template */
+template class AbstractUIGtkmm2ext::UIRequest;
+
UI::UI (string namestr, int *argc, char ***argv)
: AbstractUIUIRequest (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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 david.hennings...@canonical.com
---
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 pbd/abstract_ui.cc /* instantiate the template */
+template class AbstractUIGtkmm2ext::UIRequest;
+
UI::UI (string namestr, int *argc, char ***argv)
: AbstractUIUIRequest (namestr, true)
{
--
1.8.3.2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709991: False Original-maintainer warning
Package: dpkg Version: 1.16.10 Hi! A lot of Ubuntu packages emit this warning on build: dpkg-deb: warning: 'package/DEBIAN/control' contains user-defined field 'Original-Maintainer' dpkg-deb: warning: ignoring 1 warning about the control file(s) In Ubuntu we encourage the use of XSBC-Original-Maintainer, thus we shouldn't warn about it. I thought this was Ubuntu specific, but was told that I should file a bug upstream for inclusion instead. So I'm sending a patch to add Original-Maintainer as a known header field in debian/control. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709991: [PATCH] dpkg-deb: Don't warn on 'Original-Maintainer'
A lot of Ubuntu packages have this warning on build:
dpkg-deb: warning: 'package/DEBIAN/control' contains user-defined field
'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)
This warning should be removed as Original-Maintainer is
encouraged in Debian derivatives.
---
dpkg-deb/build.c |1 +
1 file changed, 1 insertion(+)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 348e01e..b8aa6fa 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -297,6 +297,7 @@ static const char *arbitrary_fields[] = {
Installer-Menu-Item,
Homepage,
Tag,
+ Original-Maintainer,
NULL
};
--
1.7.9.5
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701498: [alsa-devel] Bug#701498: hda: Internal mic does not work on Thinkpad T420s (CX20590 codec)
On 02/24/2013 08:59 PM, Ben Hutchings wrote: On Sat, 2013-02-23 at 20:42 +0100, Adrian Lang wrote: Package: src:linux Version: 3.2.35-2 Severity: normal There are two microphones in alsamixer and Gnome 3 audio settings (i. e., pulseaudio), but I can't get any sound using either of them. I think that's the same problem as reported to [openSUSE] and [Ubuntu]. The problem persists with 3.7 (3.7.8-1~experimental.1) from experimental. [openSUSE] http://forums.opensuse.org/english/get-technical-help-here/laptop/469210-opensuse-12-1-cannot-get-internal-mic-work-lenovo-g770-laptop.html [Ubuntu] https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/938644 These are different bugs as they concern different hardware. I happen to have a Thinkpad T420 with the same audio codec, and the internal mic works fine. (There does seem to be a problem with external mics, now that I check, but let's ignore that for now.) So this is more board-specific, not chip-specific, behaviour. Ok. For the internal mic, this could be the cancelling out problem; see the Inverted Internal Mic section of this blog post [1] for more information. ...as these bugs can sometimes be very specific - when the factory finally assembles the laptop, they might select a different component just for the DMIC, that has this problem. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic [1] http://voices.canonical.com/david.henningsson/2012/05/22/three-audio-bugs-in-12-04/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700602: speex: Build with floating point/asm optimization on armhf.
On 02/18/2013 01:09 PM, Luke Yelavich wrote: On Fri, Feb 15, 2013 at 07:54:48AM GMT, Ron wrote: You realise that's _not_ actually what your patch does, right? In Ubuntu, the attached patch was applied to achieve the following: * Build with float on armhf (LP: #1125295) Can you share with us the results of the benchmarking you did that actually demonstrates this improves performance in speex, since I don't see any indication of that being done in the LP achievement you refer to? Sorry, i am just the patch forwarder. I am CCing David Henningssen who wrote the patch. David, mind explaining how you came to doin what you did in the patch to get what we wanted with speex? My problem is not performance related, and not PulseAudio related either. The problem is that using fixed point completely disables some libspeex functions, such as automatic gain control. Without working AGC, mumble do not function correctly. I e, in mumble there is no sound at all (and a long stream of error messages) if you build libspeex with fixed point. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700230: [Pkg-alsa-devel] Bug#700230: Bug#700230: Requires sys/types.h, but doesn't explicitly include it
On 02/12/2013 11:00 AM, Elimar Riesebieter wrote: * Adam Conrad adcon...@debian.org [2013-02-10 02:27 -0700]: [...] In Ubuntu, the attached patch was applied to achieve the following: * sys_types_include.patch: Explicitly include sys/types.h (LP: #1109298) Patch attached to svn. Will be upload to sid after wheezy release. A little background: in glibc 2.17, fcntl.h stopped depending on sys/types.h, but some software was using types from types.h while only transitively pulling it in via fcntl.h, alsa is one such piece of software. This fixes it to explicitly include the header (as it always should have done, since it references it directly), and should probably also be pushed upstream, if it isn't already there. It is now pushed upstream: http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=3e7dc283ed2d3ed2341f0657811c588f4dbcba6d -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)
On 06/11/2012 02:40 AM, Andres Cimmarusti wrote: On Sun, Jun 10, 2012 at 8:25 PM, Andres Cimmarusti acimmaru...@gmail.com wrote: Andres, do you know of relevant commit ids? Can you describe the difference in behavior between 3.2.19-1 and 3.4.1-1~experimental.1 and whether it's worth backporting these changes? I will try the kernel from experimental and let you know if the changes are worth while. Unfortunately I have not tracked the relevant commits. But it looks like you probably found them. We can probably contact David Henningsson from Canonical, since he was heavily involved in it and provided a lot of guidance to solve this issue. I just tried kernel 3.4.1-1~experimental.1. I could see NO benefit at all in using that kernel. I still had to choose from a long list of advertised HDMI interfaces in pavucontrol before finding the correct one that produced sound on the TV speakers. On my laptop at least, I saw NO automatic jack detection benefit whatsoever. Is there anything else that needs to change? Perhaps David Henningsson can comment? You're correct; even if the information is there, it isn't advertised in pavucontrol. I should probably implement that... (If you're using Ubuntu 12.04, you will have a new sound settings UI that hides unavailable devices. For upstreaming of this UI please see the gnome-cc list.) What you'll get is instead what the module-switch-on-port-available module provides. When you plug your headphones in, the selected port will switch (you should be able to notice this in pavucontrol I think), which means your media keys / sound indicator / etc would control your headphone's volume instead of your speaker's volume. For the multi HDMI case - if you have selected the wrong HDMI interface, and then activate your HDMI screen, module-switch-on-port-available should automatically switch to the correct one. This is all assuming you're running PulseAudio 2.0 - earlier versions of PulseAudio do not have this functionality. Should you be interested in backporting the jack detection kernel patches, I'll be happy to point you to the Ubuntu kernel's git tree, where I did the same thing. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
On 03/16/2012 04:03 PM, Andres Cimmarusti wrote: Hello again, On Sat, Mar 3, 2012 at 9:43 PM, David Henningsson david.hennings...@canonical.com wrote: On 03/04/2012 12:36 AM, Andres Cimmarusti wrote: There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to probe multiple hdmi devices for Intel and NVidia), and the main reason it took until now to upstream that patch, was the decision to switch jack detection method from input devices to kcontrols. Thank you for all the references you provided and your work in fixing this issue for all users. I just looked at the git repository for the source code of pulseaudio, but I see your patches have not been included yet. Do you have any estimate of when they will be merged? if so, do you think they'll be included in the next release (do you know when this will be?) ? I hope they'll be in PulseAudio 2.0, as they are currently waiting for review. For next release, see [2], but judging from the PulseAudio 1.0 release process - no, I don't know when this will be ;-) I'm considering reassigning this bug to pulseaudio in debian and asking them to include the appropriate patches. Which ones would actually be needed (say, to apply them to pulseaudio 1.1)? would your 6 patches announced on the mailing list in February be enough? If you want them to apply to PulseAudio 1.1, you can have a look at [1]. The patches currently posted apply to git head. You'll need all of the 06* patches (as well as Linux 3.3 for the kcontrols). It looks like your patches have been merged: http://cgit.freedesktop.org/pulseaudio/pulseaudio/log/ That is correct. (but correct me if I'm wrong). However, I think Debian has decided to go with 3.2 kernel for the next stable release. This means no kcontrols. How is this being handled in Ubuntu 12.04 LTS, since it will also be based on kernel 3.2 For Ubuntu 12.04, I've backported the jack detection patches from 3.3 and applied them to the Ubuntu 12.04 LTS kernel. A more light-weight version could be what I did in Ubuntu 11.04, where there was no jack detection, but I just exposed all four devices in PulseAudio and let the user choose manually, like this [4]. (I later renamed that file from nvidia.conf to extra-hdmi.conf, and added the same file to be used for Intel chips.) Can this still be done in the scenario were Debian has pulseaudio 2.0 with your patches, but kernel 3.2? Sorry for the basic questions. I just found out that the release of pulseaudio 2.0 is imminentand I want to push for its adoption in Debian, but with a fix for this HDMI issue. So, with PA 2.0 but without jack detection support in the kernel, you would essentially get three or four HDMI devices showing up in your GUI, and the user would have to try them all manually to check which one is the right one. So, better than changing PA configuration files, but not as elegant as with the jack detection (where the right one is selected automatically), of course. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
On 03/04/2012 12:36 AM, Andres Cimmarusti wrote: There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to probe multiple hdmi devices for Intel and NVidia), and the main reason it took until now to upstream that patch, was the decision to switch jack detection method from input devices to kcontrols. Thank you for all the references you provided and your work in fixing this issue for all users. I just looked at the git repository for the source code of pulseaudio, but I see your patches have not been included yet. Do you have any estimate of when they will be merged? if so, do you think they'll be included in the next release (do you know when this will be?) ? I hope they'll be in PulseAudio 2.0, as they are currently waiting for review. For next release, see [2], but judging from the PulseAudio 1.0 release process - no, I don't know when this will be ;-) I'm considering reassigning this bug to pulseaudio in debian and asking them to include the appropriate patches. Which ones would actually be needed (say, to apply them to pulseaudio 1.1)? would your 6 patches announced on the mailing list in February be enough? If you want them to apply to PulseAudio 1.1, you can have a look at [1]. The patches currently posted apply to git head. You'll need all of the 06* patches (as well as Linux 3.3 for the kcontrols). A more light-weight version could be what I did in Ubuntu 11.04, where there was no jack detection, but I just exposed all four devices in PulseAudio and let the user choose manually, like this [4]. (I later renamed that file from nvidia.conf to extra-hdmi.conf, and added the same file to be used for Intel chips.) Let me also push for the hda-jack-retask [2] application, which is an easy-to-use GUI for creating these types of firmware files. I advertised it here a while ago [3] but it seems to have gone unnoticed. This sounds like a good tool for making this happen. I will submit a Request For Package in Debian... but this can take time. Would you consider packaging it there? then it would easily flow into Ubuntu. Certainly, if there is interest from the Debian side to have it. I would also not mind if it became a part of upstream ALSA, I think it would make a nice addition to the hda-analyzer, hda-verb etc tool set. I've encountered other hardware with the same issue recently. It's an NVIDIA card HDA MCP89 on a Macbook Pro 7,1. Is there a method I can follow for crafting my own patches? I'm afraid I don't understand how to find the appropriate HEX values that need to go in the [codec] and [pincfg] section. I think the easiest way is just to download the hda-jack-retask application and build it yourself. Otherwise, [3]. Thanks all for your help. You're welcome. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.precise/files/head:/debian/patches/ [2] http://pulseaudio.org/wiki/ReleasePlanning [3] http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt [4] http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.natty/view/head:/debian/patches/0001-alsa-mixer-Add-separate-profile-for-Nvidia.patch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
On 02/23/2012 01:01 AM, Andres Cimmarusti wrote: If the new two pins can be never used, i.e. physically unreachable, we may disable these pins by giving the proper default pin-config values. Usually it's a job of BIOS. But if BIOS doesn't do it, user need to do it manually. Build your kernel with CONFIG_SND_HDA_HWDEP=y, CONFIG_SND_HDA_RECONFIG=y, CONFIG_SND_HDA_PATCH_LOADER=y. I guess most of distro kernels are built with them. Then create a file containing below in /lib/firmware, such as, /lib/firmware/ibx-hdmi: [codec] 0x80862804 0x80860101 3 [pincfg] 0x04 0x41f0 0x06 0x41f0 Now pass this file to patch module option for snd-hda-intel. For example, create a file in /etc/modprobe.d/, e.g. /etc/modprobe.d/50-hdmi.conf, containing the line options snd-hda-intel patch=ibx-hdmi Then reload the driver or reboot. This will disable pins 0x04 and 0x06 so that only the pin 0x05 will be used. I've tested this workaround and it works well. I don't suppose this could be added as a quirk to the kernel for this particular device? (when and only if there's only one physically accessible HDMI connector). Stephen, could you comment on this? Are we guaranteed a certain board configuration (i e which pins are physically connected or not) given a PCI SSID, or anything else that can be used as a key to a quirk table? I think I've asked you before and that the answer was no, but my memory could be failing me. There are ways to configure pulseaudio to allow the user to select which PCM device to use on a given sound card. David Henningsson made this work for NVIDIA GPUs at least in Ubuntu, and I imagine the same technique could be applied to Intel devices too. Mmm.. just in Ubuntu? was this work submitted upstream? It appears there are some related fixes shown in the Ubuntu pulseaudio changelog: http://changelogs.ubuntu.com/changelogs/pool/main/p/pulseaudio/pulseaudio_1.1-0ubuntu9/changelog I found a thread related to this issue here: http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07433.html Started by yourself Stephen Warren! but it doesn't seem like it got anywhere... As Takashi mentions, from a kernel perspective, this isn't really a regression at all, but simply exposing all the features of the HW that were previously hidden. Without that change, others can't use some HW usefully at all. Unfortunately, pulseaudio makes some rather simplistic assumptions about how HW works by default, and can be confused by the additional features that are exposed. Agreed. But in the case of laptops, I don't think I've ever seen one that actually has more than one physical connector. I'm a little puzzled as to how all these outputs (in my case 3) make sense for my hardware... Even if there is only one HDMI output, it's it not that uncommon, actually. Many DVI outputs can output HDMI audio as well (when connected through an HDMI monitor through DVI-HDMI adapter), and DisplayPort also has audio support. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
On 02/22/2012 08:44 AM, Takashi Iwai wrote: At Wed, 22 Feb 2012 01:43:44 -0500, Andres Cimmarusti wrote: [1text/plain; UTF-8 (7bit)] Dear Mr. Warren, I recently upgraded my laptop to Debian testing (from Debian stable + the longterm stable 3.0.x kernel). The newer kernel 3.2.x came with a regression that git bisect has traced down to one of your commits in the early 3.1.x kernel development stage (git bisect output and git bisect log attached). Under kernel 3.0.x HDMI sound works out-of-the-box as tested with pulse audio (choosing the option Digital Stereo (HDMI) Output) and by the command: $ aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Center.wav Alsa's device list reveals: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 Unfortunately with kernel 3.2.x and 3.1.x I get no sound out choosing the same configuration in pulseaudio. Device is advertised correctly but there's a bizarre multiplicity advertised: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 Using aplay with device 3 says device is busy. Device 7 works correctly (but is not available in pulseaudio unless forced by default, which then renders internal speakers disabled) and device 8 produces no sound out. This appears to be a regression in the kernel about this device, advertising non-physically connected HDMI sound devices that cause pulse audio to get confused (Pulseaudio only seems to be able to handle one HDMI output by default device 0,3). The biggest problem is that PA checks only the first HDMI device. In that sense, this is no regression in the kernel side, although I know it's annoying. There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to probe multiple hdmi devices for Intel and NVidia), and the main reason it took until now to upstream that patch, was the decision to switch jack detection method from input devices to kcontrols. If the new two pins can be never used, i.e. physically unreachable, we may disable these pins by giving the proper default pin-config values. Usually it's a job of BIOS. But if BIOS doesn't do it, user need to do it manually. Build your kernel with CONFIG_SND_HDA_HWDEP=y, CONFIG_SND_HDA_RECONFIG=y, CONFIG_SND_HDA_PATCH_LOADER=y. I guess most of distro kernels are built with them. Then create a file containing below in /lib/firmware, such as, /lib/firmware/ibx-hdmi: [codec] 0x80862804 0x80860101 3 [pincfg] 0x04 0x41f0 0x06 0x41f0 Now pass this file to patch module option for snd-hda-intel. For example, create a file in /etc/modprobe.d/, e.g. /etc/modprobe.d/50-hdmi.conf, containing the line options snd-hda-intel patch=ibx-hdmi Then reload the driver or reboot. This will disable pins 0x04 and 0x06 so that only the pin 0x05 will be used. Let me also push for the hda-jack-retask [2] application, which is an easy-to-use GUI for creating these types of firmware files. I advertised it here a while ago [3] but it seems to have gone unnoticed. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-February/012872.html [2] http://voices.canonical.com/david.henningsson/2011/11/29/turn-your-mic-jack-into-a-headphone-jack/ [3] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/046778.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536659: closed by Rémi Denis-Courmont r...@remlab.net (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-Courmontr...@remlab.net. 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-Courmontr...@remlab.net 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591318: [PATCH] alsa-lib: Fix typo in comment in surround71.conf
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From f79d99c91f9ed1408220aa7dc12e2ebd31339e9a Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Tue, 19 Apr 2011 08:05:08 +0200
Subject: [PATCH] Fix typo in comment in surround71.conf
BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591318
Reported-by: Ariel asdeb...@dsgml.com
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/conf/pcm/surround71.conf |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/conf/pcm/surround71.conf b/src/conf/pcm/surround71.conf
index eb2360b..076a97d 100644
--- a/src/conf/pcm/surround71.conf
+++ b/src/conf/pcm/surround71.conf
@@ -7,8 +7,8 @@
#chn3 - rear right
#chn4 - center
#chn5 - lfe
-#chn7 - side left
-#chn8 - side right
+#chn6 - side left
+#chn7 - side right
#
pcm.!surround71 {
--
1.7.4.1
Bug#619842: pacmd: no way to leave w/o killing server?
On 2011-03-27 20:21, arne anka wrote: Package: pulseaudio-utils Version: 0.9.21-4 Severity: normal apparently, there's no way to leave pacmd w/o killing the pulseaudio server. that's rather ridiculous since the idea of pacmd is obviously to configure a server -- once it it is killed, all settings done in pacmd are gone again. it's easy to end up in the pacmd shell by mistake, so there should be anon-destructive way back. I usually use Ctrl-C to exit from the pacmd shell, and that works without killing the daemon. You can also supply a single pacmd command on the command line, e g pacmd help will output help information and then return to the shell immediately. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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=fluidsynthsuite=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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 module 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477106: PPA available
Before seeing this ITP bug, I did a simple packaging of codecgraph that is available at https://launchpad.net/~diwic/+archive/ppa Feel free to reuse the packaging if you like. // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560380: closed by Guido Günther a...@sigxcpu.org (Re: [Debian-ha-maintainers] Bug#560380: Openais lacks ais-keygen)
On Thu, Dec 10, 2009 at 08:09:29PM +0100, David Henningsson wrote: Severity: important Package: openais Version: 1.1.0-3 The Openais package's man page (openais.conf) suggests that you use ais-keygen to generate a key, this is necessary to get things up and running. Yet ais-keygen is only available in openais-legacy, which conflicts with openais. It seems to me like ais-keygen, and perhaps more files as well, should be included in the openais package. I think you're looking for corosync-keygen? -- Guido Then I assume that a bug should be filed against the openais_overview [1] man page, which mentions ais-keygen, but does not mention corosync at all? Perhaps it is so outdated we should consider not shipping that man page at all? // David [1] Not the openais.conf man page as stated earlier, sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560380: Openais lacks ais-keygen
Severity: important Package: openais Version: 1.1.0-3 The Openais package's man page (openais.conf) suggests that you use ais-keygen to generate a key, this is necessary to get things up and running. Yet ais-keygen is only available in openais-legacy, which conflicts with openais. It seems to me like ais-keygen, and perhaps more files as well, should be included in the openais package. // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553756: replacing libreadline5-dev build dependency with libreadline-dev
Matthias Klose wrote: Both libreadline-dev (= 6.0) and libreadline6-dev are now available in unstable and testing. If possible, please replace the libreadline5-dev build dependency with libreadline-dev, so that in future changes of the libreadline soname binNMU's can be used for this kind of update. Thanks for your bug report. I know that a new version of FluidSynth is about to be released, so I plan to fix this bug with the new upstream release; a new packaged release should be available in unstable before the end of November. If this is more urgent, let me know. Just to double-check - the current dependency on libreadline5-dev should be replaced with libreadline-dev (= 5), right? Is there anything in libreadline6 (especially non-backwards-compatible changes), that I should be aware of when testing the new packaging? // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549432: Freepats claims to be the only DFSG, but there is also fluid-soundfont-gm
Henrique de Moraes Holschuh skrev: On Sat, 03 Oct 2009, David Henningsson wrote: Package: freepats Version: 20060219-1 Severity: minor Freepats claims, in its debian/control description, that it is the sole DFSG-compliant patch set in existence so far. But package fluid-soundfont-gm is a patch set and must be DFSG, or it wouldn't be in Debian's main repository. So the claim seems false to me. Thanks for the report. However, if fluid is working well, wouldn't it make more sense to outright remove freepats from the archive? Can you give me your impression about freepats and fluid? Is there any situation where one should prefer freepats over fluid? Because if there isn't one, I think we should remove freepats. Well, freepats is 32 MB where fluid-soundfont is 145 MB, so it could make sense to keep it where hard disk space is desirable. But I believe your question is valid, it seems like freepats is not really updated anymore and it is not really complete either, so over time perhaps it could be replaced by a trimmed version of fluid-soundfont. Fluid-soundfont is in sf2 format though, and perhaps not all of the programs depending on freepats are ready to switch from pat to sf2. To fix this issue we could do a one-time conversion from sf2 to pat (via a commercial program such as Awave studio), but then we'll lose some quality as sf2 allows for more features than pat does (such as multi-layering). // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549432: Freepats claims to be the only DFSG, but there is also fluid-soundfont-gm
Package: freepats Version: 20060219-1 Severity: minor Freepats claims, in its debian/control description, that it is the sole DFSG-compliant patch set in existence so far. But package fluid-soundfont-gm is a patch set and must be DFSG, or it wouldn't be in Debian's main repository. So the claim seems false to me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546415: Depend on liblash instead of ladcca
Package: fluidsynth-dssi Version: 0.9.1-3 Now that FluidSynth has started to depend on liblash instead of ladcca, it makes sense that FluidSynth-dssi should do the same. Actually failing to do so lead to a FTBFS in Ubuntu, I haven't tested if the same is true for unstable. An example debdiff to fix this can be found at https://bugs.launchpad.net/ubuntu/+source/fluidsynth-dssi/+bug/428298 // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536659: Please enable midi support by depending on libfluidsynth1
Package: vlc Version: 0.9.9a-2 VLC now uses fluidsynth for midi file playback, but it needs to be enabled at compile time (this can probably be fixed by build-depending on libfluidsynth1), and then properly configured. See more information here: http://lists.gnu.org/archive/html/fluid-dev/2009-07/msg00024.html Thanks, // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531579: A new fluidsynth package is being prepared
Hello Julian, a while ago you reported debian bug #531579. I have prepared a new version of the fluidsynth package, where I believe this bug is fixed. Would you like to test the new version to confirm that the bug is fixed? The new version is currently available at: http://mentors.debian.net/debian/pool/main/f/fluidsynth/ Thanks, David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528701: About bug #528701
Hello wzab, a while ago you reported debian bug #528701. I have prepared a new version of the fluidsynth package, where I believe this bug is fixed. Would you like to test the new version to confirm that the bug is fixed? The new version is currently available at: http://mentors.debian.net/debian/pool/main/f/fluidsynth/ Thanks, David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528701: Fixed upstream
found 528701 1.0.9+dfsg-1.1 tag 528701 + confirmed upstream fixed-upstream stop It's fixed in upstream SVN, but I would prefer some upstream testing before considering patching the current version. In the meantime, you can try it manually by applying this diff. http://fluidsynth.resonance.org/trac/changeset/192/trunk/fluidsynth/src?format=diffnew=192 // David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462837: Is bug 462837 present in later versions?
Hello Remi, A long while ago you reported that FluidSynth had memory leaks when loading/unloading a soundfont, and that it was probably fixed in 1.0.8. Now 1.0.8 has been out there for a while and 1.0.9 is on its way out in unstable. I'm trying to reproduce it in 1.0.9 and while loading/unloading a large soundfont results in some additional memory usage, that seems to level out after a while, so it could just be an effect of memory fragmentation. Could you please try 1.0.8 or 1.0.9 too see if the problem is actually fixed or whether it persists? Thank you! Regards, David Henningsson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528701: Ticket created upstream
I can confirm that the bug is present in the latest version of fluidsynth upstream, and I have created a ticket upstream as well. You can follow this bug report here: http://fluidsynth.resonance.org/trac/ticket/45 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524066: Bug fixed in mentor's repository
A fixed version has been available for a while now, and it is waiting for a sponsor. The fixed version can be found at: http://mentors.debian.net/debian/pool/main/f/fluidsynth/ If you want to see this bug fixed, please consider testing and/or sponsoring this upload. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527832: fluidsynth: FTBFS: cp: cannot stat `/usr/share/libtool/ltmain.sh': No such file or directory
Lucas Nussbaum skrev: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. There is a fixed version available here: http://mentors.debian.net/debian/pool/main/f/fluidsynth/ If you want to help out, please consider testing and/or sponsoring this upload. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524566: Non-DFSG files distributed in fluidsynth package
Hello Release team, while working on adopting my first package (fluidsynth), non-DFSG files were discovered in all releases of fluidsynth, both unstable, testing, stable and oldstable. (bug: #524566) The non-DFSG files is a soundfont and some documentation, and is only included in the upstream tarball, so no binary packages are affected. I could use some advice on how to proceed, and possibly some assistance as well. Thanks, David Henningsson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524566: doc/example.sf2 tainted as well
It seems like doc/example.sf2 is ripped from VintageWavesDreams-v2.sf2. This makes this problem worse since 1) This is not allowed according to VintageWavesDreams-v2.sf2's license 2) doc/example.sf2 is distributed as a part of the binary package libfluidsynth-dev Reference: http://lists.gnu.org/archive/html/fluid-dev/2009-04/msg00081.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524566: fluidsynth: sf2/COPYRIGHT is not DFSG
Bart Martens skrev: Package: fluidsynth Version: 1.0.8-2 Severity: serious The file fluidsynth_1.0.8.orig.tar.gz in Debian contains these files: sf2/VintageDreamsWaves-v2.sf2 sf2/Makefile.in sf2/Makefile.am sf2/COPYRIGHT The license in sf2/COPYRIGHT contains It is not altered, edited, modified, ripped, or converted to other formats, except for private use only. In addition, the fluidsynth-v10-devdoc.xml is licensed under the Creative Commons Attribution License, which is non-DFSG according to http://wiki.debian.org/DFSGLicenses -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
