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.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971#101
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
developer.
> > 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
Chris.Knadle@coredump.us
Reply to: