Bug#556392: jackeq does not start

[Felipe Sateler]

Adrian Knoth wrote:
> On Mon, Nov 16, 2009 at 12:07:25PM -0300, Felipe Sateler wrote:
> 
>>> The generic fix is to recompile jackeq against new jackd package. Since
>>> we know the entire set of jackified apps, I see no point in
>>> reintroducing this 0.100.0 thing, it would bite us in jackd2 again.
>> (Is jack2 API and ABI compatible with jack1?)
> 
> Yes, it's a drop-in replacement, and users can decide whether they want
> to use jack1 or jack2. They also keep the command line syntax in sync.

Cool. Maybe it is possible to start a jack2 branch for experminental? 
(Actually 2, one for upstream and another for the packaging).

> 
>>> For keeping our packages simple and clean, I suggest to recompile. 
>> True. But I think the transition has been less smooth than it could have  
>> been (my bad, I didn't think there were apps that old, apparently). The  
> 
> I still wonder how this bug got triggered. We already had a binNMU for
> jackeq, but the poster is using the old one (probably linked against
> libjackd-0.100). (the lenny version).

The etch version, actually. The lenny version correctly references 
libjack.so.0.

> 
> The jackd version in lenny is 0.109, so we must be talking about some
> mixed system configuration, that is, a jackd version from
> unstable/testing and jackeq from lenny. (Daniel, please clarify)

Indeed, armel is the only version with jackeq not binNMUed.

> 
> With jackeq from unstable/testing, there's no bug. With jackd from
> lenny, there's no bug.
> 
> 
> You also had the compat symlinks for a while:
> 
>    http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=commitdiff;h=a90b2dada36e66e3faf2dcfc769a8ff0967f01a0
> 
> 
> Though it's not that hard to re-enable these two lines, I think we made
> everything right. I don't think we support mixed lenny/testing
> environments, we focus on squeeze. And for squeeze, we're done. ;)

Not quite. We need to binNMU every package that has not been built since 
etch (if there are any). Does anyone know an easy recipe for checking 
this? And make libjack0 Breaks: the old version of those packages so 
that a mixed upgrade is not possible. We don't seem to have any of 
those, but I might be mistaken. And a list of packages already rebuilt 
would be useful too, to add those packages to the Breaks line too.

>> thing is that now a mixed upgrade of jack and friends can leave  
>> applications in a broken state.
> 
> If you think we should support this scenario, I'd second your proposal
> of re-adding the 0.100 compat link.

I agree with Fabian, maybe it is better to add Breaks: for older than 
the rebuilt packages.

-- 
Saludos,
Felipe Sateler