Jack inclusion in Main
In Bug #416778 ( https://bugs.launchpad.net/bugs/416778 ) Loïc Minier has requested further public discussion on the subject of Jack Audio Server http://jackaudio.org/ being included in the Main repositories. I was told this list would be the best place for that discussion. I am also CCing the ubuntu-studio-de...@lists.ubuntu.com because the Ubuntu Studio team has been the driving force behind this inclusion request and are extremely knowledgeable in regards to JACK. Here are a couple of my thoughts on the matter as to why Jack should be included in Main. - Many bugs have been filed against various audio servers currently in Main (xine, alsa, portaudio, pulseaudio) requesting that the JACK bridge/plugin/output/etc... be turned on or compiled into the package - this is not possible without the inclusion of Jack in Main. Bugs #152487, #84900, #109659, and #360590 (this may not be a complete list, and duplicates of most of these have been filed). - The libffado drivers for firewire soundcards ( http://www.ffado.org ) are only supported by the Jack driver. This makes these common, pro, semi-pro, and hobbyist audio cards inaccessible for most applications without the previous audio server bridges/plugins/outputs to jack available. Owners of these cards must recompile major audio drivers in order to get basic Ubuntu sound. - Jack is an audio server designed specifically for professional reliable audio signals. This is not a duplicate server clogging up the audio mess, which some people believe exists in Linux, it is a specialty tool for musicians, audio engineers, and anyone using Linux for professional audio. (In-fact if anything, allowing the aforementioned bugs to get fixed would clean up a large chunk of the audio mess which some believe exists. It would at least stop a large segment of people from griping so loudly about and attempting to remove PulseAudio.) Please voice your opinion on the matter. -Eric Hedekar -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Stripped ld.so in karmic libc6 breaks valgrind
Duncan Sands [2009-08-24 16:52 +0200]: In karmic, ld.so is stripped of debug symbols. This will prevent the upcoming 3.5.0 release of valgrind from working. While this can be worked around by installing libc6-dbg, it does mean that valgrind won't work out of the box. Is there any chance of not stripping ld.so for the karmic release? We could also add a Depends: libc6-dbgsym | libc6-dbg to valgrind, which is better IMHO. It doesn't make the libc6 package bigger on the CDs, and people who use valgrind, debuggers, and that stuff probably want the full symbols anyway. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Bug#541842: libcloog-ppl-dev: Missing development headers
seen as well in the gcc-snapshot build. Looks like the configure test doesn't pass -DCLOOG_PPL_BACKEND for the cloog version check. When I built and installed libcloog on hpux11.11, an additional header was installed that defined CLOOG_PPL_BACKEND. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Processed: Re: Bug#541842: libcloog-ppl-dev: Missing development headers
Processing commands for cont...@bugs.debian.org: reassign 541842 gcc-snapshot Bug #541842 [libcloog-ppl-dev] libcloog-ppl-dev: Missing development headers Bug reassigned from package 'libcloog-ppl-dev' to 'gcc-snapshot'. Bug No longer marked as found in versions cloog-ppl/0.15-2. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Bug#541842: libcloog-ppl-dev: Missing development headers
On 18.08.2009 19:06, John David Anglin wrote: seen as well in the gcc-snapshot build. Looks like the configure test doesn't pass -DCLOOG_PPL_BACKEND for the cloog version check. When I built and installed libcloog on hpux11.11, an additional header was installed that defined CLOOG_PPL_BACKEND. which one? At least the header which is included by GCC doesn't define this macro and the configury seems to take care of this, if the configure option is used. See the thread starting at http://gcc.gnu.org/ml/gcc/2009-08/msg00296.html -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Bug#541842: libcloog-ppl-dev: Missing development headers
On 19.08.2009 16:03, John David Anglin wrote: When I built and installed libcloog on hpux11.11, an additional header was installed that defined CLOOG_PPL_BACKEND. which one? At least the header which is included by GCC doesn't define this /* include/cloog/cloog-config.h. Generated by configure. */ /* include/cloog/cloog-config.h.in. Generated from configure.in by autoheader. */ * Use the PPL backend */ #define CLOOG_PPL_BACKEND 1 ... hmm, the Debian package doesn't build this file. We have sources with an cloog.h.in, which reads: #ifndef CLOOG_H #define CLOOG_H #ifdef CLOOG_PPL_BACKEND # define GNUMP # includecloog/ppl_backend.h #else # include polylib/@cl_cv_poly...@.h # includecloog/polylib_backend.h #endif [...] The header cloog.h included it as follows: #ifndef CLOOG_H #define CLOOG_H #include cloog-config.h #ifdef CLOOG_PPL_BACKEND ... macro and the configury seems to take care of this, if the configure option is used. See the thread starting at http://gcc.gnu.org/ml/gcc/2009-08/msg00296.html It may be that defining CLOOG_PPL_BACKEND in the configure machinary is sufficient, but that's not clear as the define may affect the way cloog was built. Dave -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Bug#541842: libcloog-ppl-dev: Missing development headers
When I built and installed libcloog on hpux11.11, an additional header was installed that defined CLOOG_PPL_BACKEND. which one? At least the header which is included by GCC doesn't define this /* include/cloog/cloog-config.h. Generated by configure. */ /* include/cloog/cloog-config.h.in. Generated from configure.in by autoheader. */ * Use the PPL backend */ #define CLOOG_PPL_BACKEND 1 ... The header cloog.h included it as follows: #ifndef CLOOG_H #define CLOOG_H #include cloog-config.h #ifdef CLOOG_PPL_BACKEND ... macro and the configury seems to take care of this, if the configure option is used. See the thread starting at http://gcc.gnu.org/ml/gcc/2009-08/msg00296.html It may be that defining CLOOG_PPL_BACKEND in the configure machinary is sufficient, but that's not clear as the define may affect the way cloog was built. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Stripped ld.so in karmic libc6 breaks valgrind
In karmic, ld.so is stripped of debug symbols. This will prevent the upcoming 3.5.0 release of valgrind from working. While this can be worked around by installing libc6-dbg, it does mean that valgrind won't work out of the box. Is there any chance of not stripping ld.so for the karmic release? Here are some comments by Julian on the valgrind developers list. It's not the stripping of libc.so that's a problem, only of ld.so. And then it's only that we need to see the entry point for ld.so's private strlen function, and perhaps a couple of others (strcmp?) Valgrind hasn't worked on ppc32-linux on openSUSE for a while, because of this problem. At some point we may end up in the position where Valgrind doesn't work on any distro that ships a stripped ld.so. AFAICT the Fedora people are aware of this, and ship a non-stripped ld.so, so no problem there. But Ubuntu, openSUSE and others are potentially problematic. Best wishes, Duncan. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Stripped ld.so in karmic libc6 breaks valgrind
In karmic, ld.so is stripped of debug symbols. This will prevent the upcoming 3.5.0 release of valgrind from working. While this can be worked around by installing libc6-dbg, it does mean that valgrind won't work out of the box. Is there any chance of not stripping ld.so for the karmic release? Here are some comments by Julian on the valgrind developers list. It's not the stripping of libc.so that's a problem, only of ld.so. And then it's only that we need to see the entry point for ld.so's private strlen function, and perhaps a couple of others (strcmp?) Valgrind hasn't worked on ppc32-linux on openSUSE for a while, because of this problem. At some point we may end up in the position where Valgrind doesn't work on any distro that ships a stripped ld.so. AFAICT the Fedora people are aware of this, and ship a non-stripped ld.so, so no problem there. But Ubuntu, openSUSE and others are potentially problematic. Best wishes, Duncan. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Please backport a fix for Canon MP730
Julien et al Please see my report at http://waddles.org/content/rebuilding-sane-canon-pixma-mp730-ubuntu showing how to get a Canon MP730 working again. It really only requires Nicolas' patch to sanei/sanei_usb.c which is already committed in the SANE git repo. Can you please consider including that patch as a backport to sane-backends? Both 1.0.19 and 1.0.20 would benefit from it. My only concern is that it makes a dependency on libusb, but I don't understand why it would not already be a dependency. Thanks in advance, Wade. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Please backport a fix for Canon MP730
Wade Fitzpatrick wade.fitzpatr...@gmail.com wrote: Hi, Please see my report at http://waddles.org/content/rebuilding-sane-canon-pixma-mp730-ubuntu showing how to get a Canon MP730 working again. It really only requires Nicolas' patch to sanei/sanei_usb.c which is already committed in the SANE git repo. If it's already in the git tree upstream, I have no problem backporting the fix to the current 1.0.20 package in Debian. I'll look into it, and if everything looks good, it'll be in my next upload. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Stripped ld.so in karmic libc6 breaks valgrind
In karmic, ld.so is stripped of debug symbols. This will prevent the upcoming 3.5.0 release of valgrind from working. While this can be worked around by installing libc6-dbg, it does mean that valgrind won't work out of the box. Is there any chance of not stripping ld.so for the karmic release? Here are some comments by Julian on the valgrind developers list. It's not the stripping of libc.so that's a problem, only of ld.so. And then it's only that we need to see the entry point for ld.so's private strlen function, and perhaps a couple of others (strcmp?) Valgrind hasn't worked on ppc32-linux on openSUSE for a while, because of this problem. At some point we may end up in the position where Valgrind doesn't work on any distro that ships a stripped ld.so. AFAICT the Fedora people are aware of this, and ship a non-stripped ld.so, so no problem there. But Ubuntu, openSUSE and others are potentially problematic. Best wishes, Duncan. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Jack inclusion in Main
[Adding ubuntu-devel@, apologies for resulting cross-posts]
Hi Eric,
On Mon, Aug 24, 2009 at 4:06 AM, Eric Hedekaraftertheb...@gmail.com wrote:
In Bug #416778 ( https://bugs.launchpad.net/bugs/416778 ) Loïc Minier has
requested further public discussion on the subject of Jack Audio Server
http://jackaudio.org/ being included in the Main repositories. I was told
Thanks for reviving the discussion!
Other than the jack-audio-connection-kit source itself, JACK in main
touches the following source packages: celt, libffado, libfreebob,
pulseaudio, and xine-lib. The first three are build-deps of JACK; the
last two are targets for enabling the JACK backend (i.e., improving
the experience of people who want PA-JACK functionality) and for
shrinking the Ubuntu source package delta to Debian's.
In terms of increased disc space use, this latter case for PA and
xine-lib really is a non-issue; those additional binary packages for
PA and xine-lib won't be shipped on Ubuntu, Kubuntu, or Xubuntu discs.
In other words, the size of main would grow from the addition of
source for jack-audio-connection-kit, celt, libffado, and libfreebob
and the addition of binaries for libjack{0,-dev}, libcelt{0,-dev},
libffado{0,-dev}, and libfreebob{0,-dev}, but the generated plugins
for PA and xine-lib would be in universe. For both PA and xine-lib,
simply not shipping the respective -jack plugins prevents JACK from
being used as a backend and therefore avoids disturbing the default
user experience. For Ubuntu, Kubuntu, and Xubuntu, there is zero
impact in a default install.
While there is valid concern about continuing the confusion of Linux
audio subsystems, both upstreams for PA and JACK voice their support
for largely separate use cases and are working actively to coordinate
control of audio devices via D-Bus. Furthermore, distro teams
(loosely, Ubuntu, Kubuntu, and Ubuntu Studio here, since they
represent the users of PA, ALSA directly, and JACK, respectively)
realistically focus on what's shipped by default; the community
(slight blurring in terms of Ubuntu Studio) tends to offer assistance
to people who, e.g., customise PA on Kubuntu or Ubuntu Studio.
Thanks,
Dan
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Fwd: Jack inclusion in Main
-- Forwarded message -- From: tto...@ttoine.net tto...@ttoine.net Date: Mon, Aug 24, 2009 at 12:22 PM Subject: Re: Jack inclusion in Main To: Ubuntu Studio Development Technical Discussion ubuntu-studio-de...@lists.ubuntu.com Eric Hedekar a écrit : In Bug #416778 ( https://bugs.launchpad.net/bugs/416778 ) Loïc Minier has requested further public discussion on the subject of Jack Audio Server http://jackaudio.org/ being included in the Main repositories. I was told this list would be the best place for that discussion. I am also CCing the ubuntu-studio-de...@lists.ubuntu.com mailto:ubuntu-studio-de...@lists.ubuntu.com because the Ubuntu Studio team has been the driving force behind this inclusion request and are extremely knowledgeable in regards to JACK. Here are a couple of my thoughts on the matter as to why Jack should be included in Main. - Many bugs have been filed against various audio servers currently in Main (xine, alsa, portaudio, pulseaudio) requesting that the JACK bridge/plugin/output/etc... be turned on or compiled into the package - this is not possible without the inclusion of Jack in Main. Bugs #152487, #84900, #109659, and #360590 (this may not be a complete list, and duplicates of most of these have been filed). - The libffado drivers for firewire soundcards ( http://www.ffado.org ) are only supported by the Jack driver. This makes these common, pro, semi-pro, and hobbyist audio cards inaccessible for most applications without the previous audio server bridges/plugins/outputs to jack available. Owners of these cards must recompile major audio drivers in order to get basic Ubuntu sound. - Jack is an audio server designed specifically for professional reliable audio signals. This is not a duplicate server clogging up the audio mess, which some people believe exists in Linux, it is a specialty tool for musicians, audio engineers, and anyone using Linux for professional audio. (In-fact if anything, allowing the aforementioned bugs to get fixed would clean up a large chunk of the audio mess which some believe exists. It would at least stop a large segment of people from griping so loudly about and attempting to remove PulseAudio.) Please voice your opinion on the matter. -Eric Hedekar I agree with Eric. Inclusion of Jack in main will solve a lot of problem with audio applications, sound servers, etc... Missing Jack in main is a great problem too for packagers. Toine -- Ubuntu-Studio-devel mailing list ubuntu-studio-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel -- ___ http://greyrockstudio.blogspot.com -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
