On Tue, 2009-04-14 at 08:38 +1000, Luke Yelavich wrote: > On Tue, Apr 14, 2009 at 04:31:00AM EST, Albert Santoni wrote: > > Hi all/Luke, > > > > This just showed up in my inbox: > > https://bugs.launchpad.net/ubuntu/+source/portaudio/+bug/360590 > > > > You might recall the nightmare that PortAudio not being compiled with > > JACK support caused in Gutsy for Mixxx users: > > https://bugs.launchpad.net/mixxx/+bug/183011 > > > > I just dug the changelog on the Ubuntu package to find out what > > happened: > > http://changelogs.ubuntu.com/changelogs/pool/main/p/portaudio19/portaudio19_19+svn20071207-0ubuntu7/changelog > > > > Specifically: > > =================== > > portaudio19 (19+svn20071207-0ubuntu6) jaunty; urgency=low > > > > * Really disable jack this time. Forgot to work around this package's > > weird > > dependency generation for binaries. > > > > -- Luke Yelavich <[email protected]> Mon, 16 Feb 2009 08:10:34 +1100 > > > > portaudio19 (19+svn20071207-0ubuntu5) jaunty; urgency=low > > > > * Remove jack support again (hopefully temporarily till jack is in main), > > so portaudio v19 can be moved back into main. > > > > -- Luke Yelavich <[email protected]> Tue, 10 Feb 2009 18:01:31 +1100 > > ================== > > > > On the bright side, the PortAudio non-mmap patch for PulseAudio > > compatibility has been applied in Jaunty (I'm still poking upstream > > about this). But for now, a lot of our users are going to be wondering > > where JACK support went. > > May I suggest you guys code jack support directly into your app? > Appart from always having jack as an available option, you will likely > get better latency when used with jack directly, and not going via > portaudio. > > As for where jack support went, it was disabled because portaudio v19 > was moved back to the main component, as it was needed for something > else in main, and jack is not currently in main.
No, we cannot code JACK support directly into our application due to the cost of maintaining platform-specific code. I'm reporting to you that there's been a regression in a package that you maintain that is going to affect a large number of Mixxx users, and you've basically told us to make non-trivial modifications our upstream code to accommodate it. What was the process that allowed you to disable JACK in PortAudio and move it to main? Was there any impact analysis done before this happened? Is there a mechanism that allows the maintainers/upstream developers of dependent packages like Mixxx to be notified when something like this is on the table? I want to stress once again that this is an Ubuntu-specific packaging issue, which means it does not require a change to our codebase to solve. I don't know if the solution is making a separate portaudio-universe package with JACK support or something like that, but I do know that it's entirely within your domain, not ours. > > > P.S. How do we stop regressions like this? Is it up to Mixxx to test > > upstream Ubuntu beta versions each release? > > As above, code in jack support directly, and don't rely on a package > that can be built with or without extra options eg portaudio v19 and > no jack. While we're at it, why don't we just draw straight on the framebuffer so when Ubuntu breaks Qt, that doesn't affect us too? Maybe this is why Audacity maintains a fork of PortAudio in their source tree, which is included in their Ubuntu package. Every time I've talked to MOTU people downstream, they've harassed us about having libraries inside our tree. Is that what we should do, since you're saying that we can't rely on your downstream PortAudio-v19 package being compiled with the correct build flags? The whole point of PortAudio is that it provides access to ALSA, OSS, and JACK through a single API. Removing JACK takes away 1/3 of the functionality for us, and will cripple Mixxx for many users. Luke, you've helped me on IRC with the Mixxx package before, and I have a lot of respect for the work that you and the rest of the MOTU team do, but I think you're being unreasonable with your request here. I realize we won't be able to do anything about this for the Jaunty release, but I would like try to solve this after-the-fact (be it through a backport or other means) and find a solution to the fault in the packaging process that lead us to this situation. Thanks, Albert ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
