Re: Bits from the Release Team: What should go into squeeze?
What is our status regarding squeeze? From a VideoLANish point of view: * It seems unlikely that VLC 1.1 will be release on time for inclusion in squeeze * It would be good to have a new libdvbpsi. But I need to twist upstream's arm so that they release at last. (Will require binNMU of vlc and dvblast) -- Xtophe ___ 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?
On Thu, Mar 18, 2010 at 02:24:49AM +0100, David Henningsson 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. This is what I was talking about. It's device reservation via D-Bus, and it requires jackdbus from the jackd2 package to work. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ 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?
On Thu, Mar 18, 2010 at 14:25:12 (CET), Adrian Knoth wrote: On Thu, Mar 18, 2010 at 02:24:49AM +0100, David Henningsson 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. This is what I was talking about. It's device reservation via D-Bus, and it requires jackdbus from the jackd2 package to work. From this discussion, I gather the following options: A) stick with jack1 B) have jack2 in squeeze C) have both jack1jack2 in squeeze F) further discussion With such an fictional ballot, I'd vote: ABFC If you care to comment on this issue, please participate in the vote, so that we can assemble a report for the release team quickly. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ 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?
Am 18.03.2010 15:35, schrieb Reinhard Tartler: If you care to comment on this issue, please participate in the vote, so that we can assemble a report for the release team quickly. I am indifferent between A and B, just because I am lacking knowledge about jack internals. But either of both is IMHO better than maintaining both packages, which will require a lot of new infrastructure and redundant work and further discussion only slows things down even more. So my vote is: (AB)CF My vote should not be decisive for the choice between jack1 and jack2. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ 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?
On Sun, Mar 14, 2010 at 21:42:58 (CET), Philipp Kern wrote: It would be great if every team on track could send us a short mail to debian-rele...@lists.debian.org What is our status regarding squeeze? AFAIUI ffmpeg is done, and I'm not aware of similar pending library transitions, read: no ffmpeg 0.6 for squeeze. How is the state of affairs wrt jack? If we want jack2 for squeeze, we should communicate this ASAP! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ 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?
Am 17.03.2010 14:42, schrieb Reinhard Tartler: What is our status regarding squeeze? For the packages that I have my hands in, I'd recommend to upload a52dec ASAP to get rid of two minor but annoying bugs (#566385 and #570508). Also, I have prepared packages for the new upstream version of libquicktime, which I consider ready for upload. Both don't bring transitions, it's just meant as a reminder. AFAIUI ffmpeg is done, and I'm not aware of similar pending library transitions, read: no ffmpeg 0.6 for squeeze. Are there any concrete plans on upstream's side to release 0.6 in some time anyway? If not, I agree we should stay with the latest stable release. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ 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?
On Wed, Mar 17, 2010 at 02:42:04PM +0100, Reinhard Tartler wrote: Hi! How is the state of affairs wrt jack? If we want jack2 for squeeze, we should communicate this ASAP! Let's put it this way: we know that jackd1 is stable, so it qualifies for a release. If we vote against jackd2, we're missing SMP enabled audio processing and jackdbus. Nothing really important, but users might want to use it in a few months, e.g. for ladish. If we go for jackd2, I still have to push some FFADO changes to jackd2's firewire backend and fix the manpage issue. Simple stuff, one hour of work. I don't have strong feelings for either version. From the amount of testing, I'd vote for jackd1, from a feature perspective, I'd go for jackd2. So whoever is concerned, please share your opinion. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ 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?
On Wed, Mar 17, 2010 at 14:48:30 (CET), Fabian Greffrath wrote: Am 17.03.2010 14:42, schrieb Reinhard Tartler: What is our status regarding squeeze? For the packages that I have my hands in, I'd recommend to upload a52dec ASAP to get rid of two minor but annoying bugs (#566385 and #570508). Also, I have prepared packages for the new upstream version of libquicktime, which I consider ready for upload. Both don't bring transitions, it's just meant as a reminder. I'll make a note to upload them soon. AFAIUI ffmpeg is done, and I'm not aware of similar pending library transitions, read: no ffmpeg 0.6 for squeeze. Are there any concrete plans on upstream's side to release 0.6 in some time anyway? If not, I agree we should stay with the latest stable release. we are waiting on some remaining vorbis improvements and will be creating the 0.6 branch soon. Still, I don't think we should try to switch. E.g. I know that current mplayer rc3 will not work with ffmpeg 0.6, and I have no idea what else might break. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ 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?
On Wed, Mar 17, 2010 at 14:54:12 (CET), Adrian Knoth wrote: From the amount of testing, I'd vote for jackd1, from a feature perspective, I'd go for jackd2. So whoever is concerned, please share your opinion. ;) What are other distros doing? What are the plans for fedora, gentoo and opensuse? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ 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?
Am 17.03.2010 15:21, schrieb Reinhard Tartler: I'll make a note to upload them soon. Thanks. Still, I don't think we should try to switch. E.g. I know that current mplayer rc3 will not work with ffmpeg 0.6, and I have no idea what else might break. Alright, fine with me. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ 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?
On Wed, Mar 17, 2010 at 10:54, Adrian Knoth a...@drcomp.erfurt.thur.de wrote: On Wed, Mar 17, 2010 at 02:42:04PM +0100, Reinhard Tartler wrote: Hi! How is the state of affairs wrt jack? If we want jack2 for squeeze, we should communicate this ASAP! Let's put it this way: we know that jackd1 is stable, so it qualifies for a release. If we vote against jackd2, we're missing SMP enabled audio processing and jackdbus. Nothing really important, but users might want to use it in a few months, e.g. for ladish. If we go for jackd2, I still have to push some FFADO changes to jackd2's firewire backend and fix the manpage issue. Simple stuff, one hour of work. I don't have strong feelings for either version. From the amount of testing, I'd vote for jackd1, from a feature perspective, I'd go for jackd2. So whoever is concerned, please share your opinion. ;) I would think that at this stage of Linux audio, trying to do pro audio with a stable release of debian is nuts. On the other hand, for casual use of jack, a more stable version would be preferred over a more featureful one. So I would go with jack1 for squeeze. -- Saludos, Felipe Sateler ___ 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?
On Wed, Mar 17, 2010 at 03:23:11PM +0100, Reinhard Tartler wrote: From the amount of testing, I'd vote for jackd1, from a feature perspective, I'd go for jackd2. So whoever is concerned, please share your opinion. ;) What are other distros doing? What are the plans for fedora, gentoo and opensuse? Fedora-Devel has 0.118, so jackd1. CCRMA (Fedora's pro-audio derivative) uses jackd2. Gentoo has jackd1, Gentoo's pro-audio overlay has jackd2. Opensuse has jackd1. I have absolutely no idea about their plans. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ 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?
Am 17.03.2010 16:15, schrieb Adrian Knoth: I have absolutely no idea about their plans. ;) So maybe we should also stick to jack1 for queeze, make jack2 the default post-squeeze and kindly ask the backports team to provide jack2 packages for squeeze afterwards. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ 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?
On Wed, Mar 17, 2010 at 04:41:08PM +0100, Fabian Greffrath wrote: Am 17.03.2010 16:15, schrieb Adrian Knoth: I have absolutely no idea about their plans. ;) So maybe we should also stick to jack1 for queeze, make jack2 the default post-squeeze and kindly ask the backports team to provide jack2 packages for squeeze afterwards. Can we do this ourselves? -edrz ___ 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?
On Wed, Mar 17, 2010 at 12:55, Adrian Knoth a...@drcomp.erfurt.thur.de wrote: On Wed, Mar 17, 2010 at 11:20:17AM -0300, Felipe Sateler wrote: So whoever is concerned, please share your opinion. ;) I would think that at this stage of Linux audio, trying to do pro audio with a stable release of debian is nuts. Not really. ardour-2.8.7, calf-plugins and ffado will be part of squeeze, this equals 98% of my daily work. I'll dare predict you won't be saying the same a few months from now. Either new interfaces won't be supported by ffado, or some annoying bugs will be fixed, or some new feature in the stack will prove very useful, or whatever. 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. In the jackd1 case, the user needs to shutdown pulseaudio or any other application blocking the soundcard. d. Ah, that is a good for jack2. So I would go with jack1 for squeeze. I'm completely undecided. Whenever I write Ok, let's stick to jackd1 and upgrade in squeeze-and-a-half if need be, I remember that at least Free, Jonas and me are using jackd2 for quite some time, so why not switch immediately... ;) Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. -- Saludos, Felipe Sateler ___ 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?
On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. A metapackage depending on jackd1 | jackd2 would work, though. -- Saludos, Felipe Sateler ___ 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?
On Wed, Mar 17, 2010 at 17:13:14 (CET), Eric Dantan Rzewnicki wrote: On Wed, Mar 17, 2010 at 04:41:08PM +0100, Fabian Greffrath wrote: Am 17.03.2010 16:15, schrieb Adrian Knoth: I have absolutely no idea about their plans. ;) So maybe we should also stick to jack1 for queeze, make jack2 the default post-squeeze and kindly ask the backports team to provide jack2 packages for squeeze afterwards. Can we do this ourselves? sure, anyone is allowed to contribute to backports.org if the package follows the backports.org policy. (mainly, needs to be in 'testing' and doesn't require excessive new other infrastructure) -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ 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?
On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. Ah, good point. A metapackage depending on jackd1 | jackd2 would work, though. I find a metapackage an inelegant approach. My suggestion is then to keep jackd as-is for now but a) introduce a new jackd2 (hopefully ready for inclusion with Squeeze), b) try to get rid of versioned dependencies on jackd (maybe not finished before freeze of squeeze), and when both are done then c) rename jackd to jackd1 and provide virtual jackd (probably post-squeeze). How does that sound? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ 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?
On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. A metapackage depending on jackd1 | jackd2 would work, though. I would personally prefer this approach to the backports option. istr, we discussed this previously and there were some objections to having both. -edrz ___ 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?
On Wed, Mar 17, 2010 at 06:24:10PM +0100, Jonas Smedegaard wrote: On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. Ah, good point. A metapackage depending on jackd1 | jackd2 would work, though. I find a metapackage an inelegant approach. My suggestion is then to keep jackd as-is for now but a) introduce a new jackd2 (hopefully ready for inclusion with Squeeze), It is already in experimental (as jackd 1.9.4+svn3842-2). -edrz ___ 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?
On Wed, Mar 17, 2010 at 01:24:43PM -0400, Eric Dantan Rzewnicki wrote: On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. A metapackage depending on jackd1 | jackd2 would work, though. I would personally prefer this approach to the backports option. istr, we discussed this previously and there were some objections to having both. Could someone remembering that past discussion enlighten newcomers like me some more, or perhaps point to that particular discussion in mailinglists or similar? Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ 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?
On Wed, Mar 17, 2010 at 01:29:31PM -0400, Eric Dantan Rzewnicki wrote: On Wed, Mar 17, 2010 at 06:24:10PM +0100, Jonas Smedegaard wrote: On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. Ah, good point. A metapackage depending on jackd1 | jackd2 would work, though. I find a metapackage an inelegant approach. My suggestion is then to keep jackd as-is for now but a) introduce a new jackd2 (hopefully ready for inclusion with Squeeze), It is already in experimental (as jackd 1.9.4+svn3842-2). The code, yes. But with source package name identical to older code so cannot coexist with older jackd in same distribution release. What I propose is to ship the new code as a separate source package and a separate binary package. The binary package will conflict with the similar binary package provided by the older code (at least at first), and probably no binary library packages will be provided either. My proposal is to package jackd2 _distributable_ in parallel to existing stable jackd1 but not _installable_ in parallel. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ 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?
On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:29:31PM -0400, Eric Dantan Rzewnicki wrote: On Wed, Mar 17, 2010 at 06:24:10PM +0100, Jonas Smedegaard wrote: On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard d...@jones.dk wrote: On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote: Also, if my understanding is correct, jack2 is ABI compatible with jack1, so no library transition is needed. That was my impression too. If so, why don't we ship *both*? Let's rename jackd → jackd1, package jackd2, and let both binary packages provide jackd as a virtual package. There are a bunch of packages depending on jackd (= something), so this approach would break those apps. Ah, good point. A metapackage depending on jackd1 | jackd2 would work, though. I find a metapackage an inelegant approach. My suggestion is then to keep jackd as-is for now but a) introduce a new jackd2 (hopefully ready for inclusion with Squeeze), It is already in experimental (as jackd 1.9.4+svn3842-2). The code, yes. But with source package name identical to older code so cannot coexist with older jackd in same distribution release. What I propose is to ship the new code as a separate source package and a separate binary package. The binary package will conflict with the similar binary package provided by the older code (at least at first), and probably no binary library packages will be provided either. My proposal is to package jackd2 _distributable_ in parallel to existing stable jackd1 but not _installable_ in parallel. There is a problem, though. The library names collide, so one would have to have libjack1-0 and libjack2-0. This would mean that the shlibs files would have to provide alternative dependencies (like ffmpeg is doing for the unstripped variants), which would require a binNMU run to change the dependencies, and finally then jack2 could be uploaded. Oh and take steps to make sure jackd1 depends on libjack1-0 only (and same for jack2). I think this is much too complicated. -- Saludos, Felipe Sateler ___ 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?
On Wed, Mar 17, 2010 at 03:24:19PM -0300, Felipe Sateler wrote: On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard d...@jones.dk wrote: What I propose is to ship the new code as a separate source package and a separate binary package. The binary package will conflict with the similar binary package provided by the older code (at least at first), and probably no binary library packages will be provided either. My proposal is to package jackd2 _distributable_ in parallel to existing stable jackd1 but not _installable_ in parallel. There is a problem, though. The library names collide, so one would have to have libjack1-0 and libjack2-0. This would mean that the shlibs files would have to provide alternative dependencies (like ffmpeg is doing for the unstripped variants), which would require a binNMU run to change the dependencies, and finally then jack2 could be uploaded. Oh and take steps to make sure jackd1 depends on libjack1-0 only (and same for jack2). I think this is much too complicated. Oh, you mean both use unversioned soname? Yes, that complicates things. Then how about simply doing the switch now? What are the actual expected risks of using jackd2? Adrian mentioned FFADO changes and manpage updates. Any other known risks, beyond the general not well tested? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ 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?
On Wed, Mar 17, 2010 at 15:56, Jonas Smedegaard d...@jones.dk wrote: There is a problem, though. The library names collide, so one would have to have libjack1-0 and libjack2-0. This would mean that the shlibs files would have to provide alternative dependencies (like ffmpeg is doing for the unstripped variants), which would require a binNMU run to change the dependencies, and finally then jack2 could be uploaded. Oh and take steps to make sure jackd1 depends on libjack1-0 only (and same for jack2). I think this is much too complicated. Oh, you mean both use unversioned soname? Yes, that complicates things. It is not an unversioned soname. Both versions are ABI compatible, thus have the same soname. -- Saludos, Felipe Sateler ___ 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
