Re: Bits from the Release Team: What should go into squeeze?

2010-03-18 Thread Fabian Greffrath

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:


(A<>B)>C>F

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?

2010-03-18 Thread Reinhard Tartler
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 jack1&jack2 in squeeze
 F) further discussion

With such an fictional ballot, I'd vote:

A>B>F>C


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?

2010-03-18 Thread Adrian Knoth
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?

2010-03-18 Thread Christophe Mutricy

> 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?

2010-03-17 Thread David Henningsson
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


Re: Bits from the Release Team: What should go into squeeze?

2010-03-17 Thread Jonas Smedegaard

On Wed, Mar 17, 2010 at 04:53:48PM -0300, Felipe Sateler wrote:

On Wed, Mar 17, 2010 at 15:56, Jonas Smedegaard  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.


Ah. I got it now (and understand the problems you described).

Thanks for clarifying :-)


 - 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?

2010-03-17 Thread Felipe Sateler
On Wed, Mar 17, 2010 at 15:56, Jonas Smedegaard  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?

2010-03-17 Thread Jonas Smedegaard

On Wed, Mar 17, 2010 at 03:24:19PM -0300, Felipe Sateler wrote:

On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard  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?

2010-03-17 Thread Felipe Sateler
On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard  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  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?

2010-03-17 Thread Jonas Smedegaard

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  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?

2010-03-17 Thread Jonas Smedegaard

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  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?

2010-03-17 Thread Eric Dantan Rzewnicki
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  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?

2010-03-17 Thread Eric Dantan Rzewnicki
On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote:
> On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard  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?

2010-03-17 Thread Jonas Smedegaard

On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote:

On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard  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?

2010-03-17 Thread Reinhard Tartler
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?

2010-03-17 Thread Felipe Sateler
On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard  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?

2010-03-17 Thread Jonas Smedegaard

On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote:

On Wed, Mar 17, 2010 at 12:55, 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.


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.


Yeah - it lowers the bar of using "pro" audio.

One part of the "pro" is that it is too complex to get started for 
ordinary humans - like a school music teacher and her pupils.  Would be 
terrific if they could get going more easily - even if "too old" for 
actual music professionals.




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.


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.



 - 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?

2010-03-17 Thread Felipe Sateler
On Wed, Mar 17, 2010 at 12:55, Adrian Knoth  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?

2010-03-17 Thread Eric Dantan Rzewnicki
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?

2010-03-17 Thread Adrian Knoth
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.

> 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.

I wrote a small client that can run on TOP of pulseaudio, but it's just
proof of concept and doesn't support recording. And nobody cares about
this idea. ;)

> 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... ;)


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?

2010-03-17 Thread Fabian Greffrath

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?

2010-03-17 Thread Adrian Knoth
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?

2010-03-17 Thread Felipe Sateler
On Wed, Mar 17, 2010 at 10:54, Adrian Knoth  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?

2010-03-17 Thread Fabian Greffrath

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?

2010-03-17 Thread Reinhard Tartler
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?

2010-03-17 Thread Reinhard Tartler
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?

2010-03-17 Thread Adrian Knoth
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?

2010-03-17 Thread Fabian Greffrath

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?

2010-03-17 Thread Reinhard Tartler
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