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
unsupportable codec.
The reason in mumble's case is interoperability, for this fairly
widely used program, with at least our downstream ecosystem and
perhaps others.
> 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.
Ian.
Reply to: