[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal

On Thursday, July 19, 2012 08:03:54, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal"):
> > Additionally if we plan to re-introduce the CELT library,
> > maintainers that had packages using CELT need contacting if an
> > opportunity is to be given for those packages to be [un]patched to
> > re-add CELT support again desired.  This would naturally depend on
> > getting CELT uploaded and accepted, which is where having a DD take
> > over maintainership and upload would save time.
> Which _other_ packages besides mumble are we thinking of here ?

It's not clear -- I'll try to find an answer.

> I think we should consider these questions on a package-by-package
> basis.  I sympathise with Ron's worry that we will be perpetuating an
> unsupportable codec.

I share that concern.

> The reason in mumble's case is interoperability, for this fairly
> widely used program, with at least our downstream ecosystem and
> perhaps others.

Debian and Debian derivatives might be the only ones shipping celt 0.7.1 as a 
_library_, but Nicos Gollan stated specifically that 0.7.1 is a base 
assumption by Mumble servers, so my understanding is that it's a general 
dependency for Mumble.


So perhaps only Mumble requires the 0.7.1 version of celt.  The testing I had 
done had showed that the client when connected to non-Debian derivative 
servers didn't function without celt 0.7.1 support.

> > > I assume it would be possible to reintroduce a celt package which was
> > > very similar to the one recently removed, so as to avoid risking
> > > unnecessary bugs.
> > 
> > It looks like that would probably work.
> Was there any possibility that it might not ?  Did the old celt
> package have other serious bugs ?

No, none that I'm aware of.  The reason I was skeptical was because of the 
problems that came up with Mumble with gcc 4.7.

> > The current celt source package uses individual debhelper calls with
> > compat level 5 and is not multi-arch aware;
> These are not release-critical problems.  Nothing should now be
> changed in wheezy other than to fix release-critical problems.

Got it.

> > I'm wondering if multi-arch support is something worth considering
> > at this stage.  The current celt source package from Wheezy (via
> > apt-get source) builds and seems to function correctly, appears to
> > be piuparts clean, but has some lintian warnings to look into [see
> > below] -- and some autoconf related files are left behind after a
> > cleanup of the build.
> See Neil's response, which I agree with.  Reengineering or `tidying
> up' the package, at this stage of the wheezy release, is entirely out
> of the question.  Surely that must be obvious ?

It wasn't, due to solely my lack of experience as a potential Debian 

> >  Curiously the associated celt git repo will not build when tag
> > 
> > v0.7.1-1 is checked out (the same version in Wheezy), even when the
> > associated source tarballs are in place, and I'm not sure why that
> > is yet.
> I think this means that we should suspect the git repo of being out of
> date or incomplete and base any re-upload into wheezy on the previous
> version from sid/wheezy.

I agree.

> > Lintian warnings:
> Thanks.  I think none of these are important at the moment.

That's good.

  -- Chris

Chris Knadle

Reply to: