Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
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 ?
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
The reason in mumble's case is interoperability, for this fairly
widely used program, with at least our downstream ecosystem and
> Additionally the Mumble client in 1.2.3-349-g315b5f5-2 will not use
> the CELT library even if it is installed, which means that the
> mumble package will require [un]patching for this as well if CELT
> support is to be made available again.
If we decide to reintroduce celt for the benefit of mumble then yes we
will have to do that too.
> > 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 ?
> 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.
> 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 ?
> 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.
> Lintian warnings:
Thanks. I think none of these are important at the moment.