Debian Bug report logs - #682010
[mumble] Communication failures due to CELT codec library removal

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Chris.Knadle@coredump.us

Date: Wed, 18 Jul 2012 16:48:01 UTC

Severity: normal

Done: Don Armstrong <don@debian.org>

Bug is archived. No further changes may be made.

Forwarded to http://git.donarmstrong.com/?p=debian-ctte.git;a=blob;f=682010_celt_and_mumble/682010_celt_and_mumble.org

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 18 Jul 2012 16:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
New Bug report received and forwarded. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 18 Jul 2012 16:48:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: submit@bugs.debian.org
Subject: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 18 Jul 2012 12:44:44 -0400
[Message part 1 (text/plain, inline)]
Package: tech-ctte
Severity: normal


Greetings to the technical committee.

This refers to Bug #675971 (which is severity grave, and currently closed)
against the Mumble VoIP package, which is also affected by Bug #674650
concerning the removal of the CELT library.  This evening we also just
discovered the existence of Bug #674634 which concerns the CELT library
removal as well, and which may have more of the technical story.


Summary of the technical dispute
================================

Point of view of bug reporters (text via collaboration of two reporters):

  Background:
  ----------

- Mumble upstream uses and requires a particular baseline audio codec
  (CELT 0.7.1, a fairly old version), the availability of which is a
  base assumption used by most Mumble servers.

- CELT's upstream has a planned transition to the standardized Opus
  codec, and Mumble plans to follow suit, but that transition won't
  complete until all clients and servers support Opus, and that will take
  a while.  (Also, current upstream support for Opus remains a work in
  progress, and they don't have a released version with non-buggy
  support for Opus yet; the current version in Debian has some
  cherry-picked patches from upstream's VCS, but that doesn't help
  non-Debian users.)

- CELT audio Codec library has been removed from Debian by the maintainer,
  which with Mumble today is causing audio to fail outright for many public
  servers as well as several prior versions of mumble-server from Debian.
  [This has also been a problem for several other audio packages and
   maintainers.]

- On newer Mumble server versions, the audio connection fails if another
  client connects that requires using CELT, because all connected clients
  require using a common Codec.

- The newest -2 upload contains this issue.  [Mentioned because the
  maintainer reported that the -2 upload fixes the bug.]

- There is no warning in the NEWS.Debian file to warn users of the
  package that only the Opus Codec is usable and how that impacts the
  usability of the package

- The bug is repeatedly being closed by the maintainer if it was fixed,
  without discussion.  [Josh Triplett has since tagged the bug "wontfix",
  which is at least an improvement, but this RC-level bug remains closed
  as is being forced by the maintainer, which will presumably allow the -2
  package with this issue to migrate to Wheezy and release with Stable.]

  Desired:
  -------

- From the point of view of the bug reporters, what we want is a
  package that inter-operates with other Mumble clients and servers,
  if possible.  To do this today would require reintroducing the celt
  source package again, which is rumored to have potential security issues.
  [We have not seen any details on this yet.]

  Note: this evening we think we have found a security expert who is
  willing to audit the CELT 0.7.1 codec for issues and possibly provide
  patches, assuming this is reasonably feasible.

- Assuming an inter-operable package is not possible, as a backup what
  we want is for the bug to be handled correctly in some way, and that
  users of the package have an opportunity to be notified of what
  limitations the package has.

  Possible options:
  ----------------

- Leave mumble out of testing and wheezy, keep it in either unstable
  or experimental (as we would for any client-server software with an
  unstable protocol that we can't support for the lifetime of a stable
  release), reintroduce CELT library for use with Mumble with security
  warnings in the description and NEWS.Debian concerning potential issues.

- Let mumble 1.2.3-349-g315b5f5-2 migrate to testing and release with
  wheezy without the CELT library, with compatibility warnings in
  NEWS.Debian. Possibly reintroduce (or at least allow the use of) a CELT
  codec library for Mumble in Unstable or Experimental which could allow
  users to use the CELT codec library with Mumble, with a warning in
  NEWS.Debian for the celt package to warn of potential issues.

- Similar to the item above, but with the CELT library in an external
  repository.

- Some other alternative we haven't thought of.



Point of view of the maintainer (as understood by reporters thus far, as
  no reply was given in several days in query for this summary):

- Someone the maintainer trusts said the CELT library contains code that
  could potentially be a crash vulnerability, among other unfixed issues

- Nobody is committing to maintaining and taking responsibility for celt
  0.7.1, or has sufficient spare time and/or the requisite knowledge to
  fully investigate this further.

- It was decided to remove the CELT library as to not burden the security
  team, and it has been an effort to get the library removed

- The mumble client that we currently have will only inter-operate with
  clients that have Opus support

- Upstream is eventually planning on dropping CELT anyway

- This isn't a bug, so it should be closed, and there is no need to warn
  users of the package

================================



I've subscribed to the tech-ctte mailing list, so I don't need to be CCed.
We're prepared to accept any possible outcome the TC deems appropriate.

Thanks.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 18 Jul 2012 23:45:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 18 Jul 2012 23:45:16 GMT) Full text and rfc822 format available.

Message #10 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Thu, 19 Jul 2012 00:15:01 +0100
Chris Knadle writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> Package: tech-ctte
> Severity: normal
...
> This refers to Bug #675971 (which is severity grave, and currently closed)
> against the Mumble VoIP package, which is also affected by Bug #674650
> concerning the removal of the CELT library.  This evening we also just
> discovered the existence of Bug #674634 which concerns the CELT library
> removal as well, and which may have more of the technical story.

Thanks for this, including the clear summary.

> - From the point of view of the bug reporters, what we want is a
>   package that inter-operates with other Mumble clients and servers,
>   if possible.  To do this today would require reintroducing the celt
>   source package again, which is rumored to have potential security issues.
>   [We have not seen any details on this yet.]
> 
>   Note: this evening we think we have found a security expert who is
>   willing to audit the CELT 0.7.1 codec for issues and possibly provide
>   patches, assuming this is reasonably feasible.

This sounds like a good option to me.  I will write to the security
team and ask them for their opinion about CELT.

From what you say I think:

 - We should try to address the security problems, if any, in the celt
   0.7.1 codec.  An audit would be very good.

 - This is a serious problem for mumble at least and is arguably RC.

Do you have people who are willing to be the maintainer(s) and (if
necessary) sponsor(s) for the celt package ?

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.

Ian.



Added indication that bug 682010 blocks 675971 Request was from Chris Knadle <Chris.Knadle@coredump.us> to control@bugs.debian.org. (Thu, 19 Jul 2012 02:00:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 09:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 09:48:03 GMT) Full text and rfc822 format available.

Message #17 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: #682010 re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 19:08:47 +0930
Hi Ian,

Being cc'd on this would have been nice, so apologies in advance if I
messed up any quoting by pasting stuff in.

On Thu, Jul 19, 2012 at 12:26:01AM +0100, Ian Jackson wrote:
> >   Note: this evening we think we have found a security expert who is
> >   willing to audit the CELT 0.7.1 codec for issues and possibly provide
> >   patches, assuming this is reasonably feasible.
> 
> This sounds like a good option to me.  I will write to the security
> team and ask them for their opinion about CELT.
> 
> >From what you say I think:
> 
>  - We should try to address the security problems, if any, in the celt
>    0.7.1 codec.  An audit would be very good.

You understand this is a fairly arbitrary 'daily' snapshot of an
experimental research codec, from ~2.5 years ago, that nobody has
looked at since that day, that nobody has committed to maintaining,
that its author has explicitly said he has no interest in maintaining,
that has had large parts completely rewritten since for all manner of
reasons, and is bitstream incompatible with every other snapshot that
was ever released, right?

And that its successor code has been reviewed in detail by some of the
brightest minds of the IETF, prior to accepting that code as being the
normative part of a proposed standard (which has now occurred) - and
without exception, all of them said "this is way too deep for me,
I'm going to have to take the WG report on faith that it's sufficiently
debugged now" ...


If skilled people have time for auditing, I'd love to see the code from
the RFC pass under their eyes as a better, more enduring, use of their
time.  But this isn't something people are likely to find high school
programming errors in from a quick read through or automated scan, or
are likely to shake things out of just with simple fuzz testing.

On the contrary, I fully expect mumble to have also EOL'd this long
before anyone else, except perhaps the most dedicated blackhats, have
understood even half of what goes on in this code, or the astronomical
number of state transitions that are possible within it.  And they have
a 2.5 year head start on anyone who might try starting from today.


>  - This is a serious problem for mumble at least and is arguably RC.

Yes, mumble has a serious problem, that is arguably RC.
In fact it has several of them aside from this corner that people
have painted themselves into with it ...

 - Its primary author, who is also a DD and comaint of the package,
   is currently MIA with a new job that has consumed pretty much
   every minute of his time for the last 2 years or so now.

   The people who remain that are hacking on it, can't even do a
   formal new release at present, because he is the only one with
   access to the systems they need to do that, and is not available
   to do so.

   They are all busy too, so there is very much a culture of
   "close your eyes and pretend it's all ok" there at present.

 - It has other deps in the distro aside from this one that appear
   to be near enough to completely unmaintained too.  Have a look
   at the code for zeroc-ice, and the ABI breaking patch that was
   blindly applied for gcc 4.7 and then left unfixed until Svedrin
   and I got stuck with the job of unscrewing that, and share in
   our tears ...

 - It has a small subset of users who would rather risk everyone's
   systems, than simply update their most ancient servers and tell
   their friends that it's time for a security update too.
   Which is all it takes to 'fix' this.

   FWIW, even the original poster of the bug in question later agreed
   in calmer discussion on IRC that the Right Thing for mumble to do
   is to release 1.3 and accelerate the migration, and that is only
   being delayed now by the first point above.


This particular problem being raised here was entirely avoidable.
Only a lack of foresight that the primary author of this software was
going to be taken by the rapture, and a subsequent failure to plan
for that loss by migrating to options that actually have maintainers
ahead of the crunch date, have left us in the situation we are in
today.  These aren't things I usually associate with the idea of
something being viable stable release candidate software ...

If I'd known that Thorvald was not going to be here to manage this
transition for Wheezy, I'd have never agreed to shipping libcelt in
the Squeeze release either, and would have instead kept it in sid
only.  If I'd known that his plan to have all other distros ship
the 0.7.1 release as a temporary interoperability snapshot would
fail as dismally as it did (no other distro shipped this version
except debian derivatives who took it from us), I'd have similarly
vetoed the idea of shipping this as a public library in the last
stable release too.

Mumble already ships this as an embedded private library on every
system other than direct Debian derivatives.


> 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.

I see that this proposal has already resulted in Chris skating down
the slippery slope of "let's re-enable it for everything else too".
And we'll get people with no experience or prior involvement to
maintain it, and we'll enable multi-arch too, and ...

So I really hope that it's actually clear to the people presiding
over the tech-ctte, that the *whole point* of a codec is that it
lets you *interoperate* with others.  Which this snapshot does not.

Continuing public releases of an obsolete experimental snapshot, that
will only create confusion with a now published internet standard,
is not the way to encourage users that they really do have viable
alternatives to patent encumbered codecs.  Doing this would make
us our own worst enemy to the causes and philosophy that we say we
stand for.  They'll have a bad experience, and maybe blow out their
speakers, and then blame the codec, and its authors and everything
they touch - not the people who should never have shipped it and
who were explicitly advised not to.

If people really want to do this for mumble, then it really ought
to be done as a private implementation detail, like it is for every
other platform - not by setting traps in public for the unsuspecting
and otherwise uninformed.  If we ship celt publicly, we are sending
the message that people should use it.  That's the wrong message
for an obsolete, unmaintained codec, and there is no reason to tie
'being pragmatic' about the mumble screwup to making an even bigger
mistake.  That's not 'avoiding risk', it's "not avoiding risk".
And one that is really, really trivial to avoid.


Anyhow, this is already too long, and it's still not even half the
full story - but I have paying customers, who do trust my judgement,
that have work which needs to be done - and I don't expect anybody
is really going to digest the full implications here if I do just
write more, so I'll open the floor to intelligent questions.


My general feeling is that mumble is currently in an awkward state
which really doesn't make it a good release candidate for Wheezy,
and we'd probably be best served by simply dropping it from testing,
fixing this in sid as the fixes come or are needed, and then pushing
snapshots to bpo as we have reasonable candidates for that.

That was my original recommendation to the release team, but Phil
offered to cut us some slack with letting things in if I did try
to salvage it for Wheezy proper, so Svedrin and I put in the effort
to make that as possible as it might be.

Maybe that really was a mistake.  I don't mind taking full
responsibility for my mistakes - but being bullied into making
even bigger mistakes, by people who didn't understand the set
that created the problem in the first place, is not in my usual
definition of wisdom, and the crux of my disagreement with the
crusade that Chris has embarked on here.

Since he didn't bother to wait for Josh and I to discuss that
further, now we're here ...

 Sorry,
 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 11:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 11:57:03 GMT) Full text and rfc822 format available.

Message #22 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>
Cc: 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: #682010 re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 12:55:59 +0100
Ron writes ("Re: #682010 re celt and mumble referred to the TC"):
> You understand this is a fairly arbitrary 'daily' snapshot of an
> experimental research codec, from ~2.5 years ago, that nobody has
> looked at since that day, that nobody has committed to maintaining,
> that its author has explicitly said he has no interest in maintaining,
> that has had large parts completely rewritten since for all manner of
> reasons, and is bitstream incompatible with every other snapshot that
> was ever released, right?

However, it appears that some other distros have chosen to ship this
particular version.  For example at least Ubuntu are still
distributing it.

> >  - This is a serious problem for mumble at least and is arguably RC.
> 
> Yes, mumble has a serious problem, that is arguably RC.
> In fact it has several of them aside from this corner that people
> have painted themselves into with it ...
> 
>  - Its primary author, who is also a DD and comaint of the package,
>    is currently MIA with a new job that has consumed pretty much
>    every minute of his time for the last 2 years or so now.
> 
>    The people who remain that are hacking on it, can't even do a
>    formal new release at present, because he is the only one with
>    access to the systems they need to do that, and is not available
>    to do so.

I'm not convinced by this complaint.  The whole point of free software
is that it is possible to carry on without needing the cooperation or
involvement of one's upstreams.

Also, are you saying you think mumble should be removed ?  Now is a
bit late to be deciding this.

> If I'd known that Thorvald was not going to be here to manage this
> transition for Wheezy, I'd have never agreed to shipping libcelt in
> the Squeeze release either, and would have instead kept it in sid
> only.  If I'd known that his plan to have all other distros ship
> the 0.7.1 release as a temporary interoperability snapshot would
> fail as dismally as it did (no other distro shipped this version
> except debian derivatives who took it from us), I'd have similarly
> vetoed the idea of shipping this as a public library in the last
> stable release too.

I think interoperability with the ecosystem of our derivatives is
sufficiently important that it's worth preserving.

> Mumble already ships this as an embedded private library on every
> system other than direct Debian derivatives.

I'm not sure exactly what you mean.  Do you mean they support some
other version of the celt codec ?  Or are you just talking about how
they manage the packaging ?

I certainly think it's better to have the celt codec, even if it's an
unreleased and now-unmaintained-upstream snapshot, in a separate
package, than in an embedded library.

> I see that this proposal has already resulted in Chris skating down
> the slippery slope of "let's re-enable it for everything else too".
> And we'll get people with no experience or prior involvement to
> maintain it, and we'll enable multi-arch too, and ...

Your message has too much personal animosity in it.

> So I really hope that it's actually clear to the people presiding
> over the tech-ctte, that the *whole point* of a codec is that it
> lets you *interoperate* with others.  Which this snapshot does not.

It lets you interoperate with Ubuntu, and with users running squeeze.

> If people really want to do this for mumble, then it really ought
> to be done as a private implementation detail, like it is for every
> other platform - not by setting traps in public for the unsuspecting
> and otherwise uninformed.  If we ship celt publicly, we are sending
> the message that people should use it.  That's the wrong message
> for an obsolete, unmaintained codec, and there is no reason to tie
> 'being pragmatic' about the mumble screwup to making an even bigger
> mistake.  That's not 'avoiding risk', it's "not avoiding risk".
> And one that is really, really trivial to avoid.

Just to be clear, you seem to be suggesting that while reintroducing
libcelt as a package is a bad thing, it would be fine to reintroduce
it as an embedded library in mumble ?

> My general feeling is that mumble is currently in an awkward state
> which really doesn't make it a good release candidate for Wheezy,
> and we'd probably be best served by simply dropping it from testing,
> fixing this in sid as the fixes come or are needed, and then pushing
> snapshots to bpo as we have reasonable candidates for that.

I don't think this is a good approach.  But I'm pleased to see that
you agree that this is probably an RC problem.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 12:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 12:27:03 GMT) Full text and rfc822 format available.

Message #27 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org, Ron <ron@debian.org>
Subject: Re: #682010 re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 08:00:11 -0400
On Thursday, July 19, 2012 05:38:47, Ron wrote:
...
> >  - This is a serious problem for mumble at least and is arguably RC.
> 
> Yes, mumble has a serious problem, that is arguably RC.
> In fact it has several of them aside from this corner that people
> have painted themselves into with it ...

[…]
>    FWIW, even the original poster of the bug in question later agreed
>    in calmer discussion on IRC that the Right Thing for mumble to do
>    is to release 1.3 and accelerate the migration, and that is only
>    being delayed now by the first point above.

I don't disagree, but I'm wondering how the migration could be (or could have 
been) accelerated.

[…]
> If I'd known that Thorvald was not going to be here to manage this
> transition for Wheezy, I'd have never agreed to shipping libcelt in
> the Squeeze release either, and would have instead kept it in sid
> only.  If I'd known that his plan to have all other distros ship
> the 0.7.1 release as a temporary interoperability snapshot would
> fail as dismally as it did (no other distro shipped this version
> except debian derivatives who took it from us), I'd have similarly
> vetoed the idea of shipping this as a public library in the last
> stable release too.

This was definitely not clear; if it had been I wouldn't have considered re-
enabling it as a potential solution.

> Mumble already ships this as an embedded private library on every
> system other than direct Debian derivatives.

Just for clarification: does the Mumble client as shipped with Debian also 
contain the embedded private library?
 
> > 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.
> 
> I see that this proposal has already resulted in Chris skating down
> the slippery slope of "let's re-enable it for everything else too".
> And we'll get people with no experience or prior involvement to
> maintain it, and we'll enable multi-arch too, and ...

In terms of re-enabling CELT, I was simply looking upon this as a matter of 
fairness to other maintainers.  If it's decided only Mumble requires an 
exception to use CELT 0.7.1 (which right now doesn't sound like the right 
thing to do), I'm fine with that.

[…]
> My general feeling is that mumble is currently in an awkward state
> which really doesn't make it a good release candidate for Wheezy,
> and we'd probably be best served by simply dropping it from testing,
> fixing this in sid as the fixes come or are needed, and then pushing
> snapshots to bpo as we have reasonable candidates for that.
> 
> That was my original recommendation to the release team, but Phil
> offered to cut us some slack with letting things in if I did try
> to salvage it for Wheezy proper, so Svedrin and I put in the effort
> to make that as possible as it might be.
> 
> Maybe that really was a mistake.  I don't mind taking full
> responsibility for my mistakes - but being bullied into making
> even bigger mistakes, by people who didn't understand the set
> that created the problem in the first place, is not in my usual
> definition of wisdom, and the crux of my disagreement with the
> crusade that Chris has embarked on here.

The disagreement was that I wanted a working Mumble, or a warning in 
NEWS.Debian concerning the compatability issues.  That's not a crusade, so I 
object to this mischaracterization.

> Since he didn't bother to wait for Josh and I to discuss that
> further, now we're here ...

There was no indication of any kind that the discussion was going to continue, 
otherwise I would have delayed the summary to the TC.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 12:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 12:39:07 GMT) Full text and rfc822 format available.

Message #32 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us, 682010@bugs.debian.org
Cc: Ron <ron@debian.org>
Subject: Re: Bug#682010: #682010 re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 13:37:03 +0100
Chris Knadle writes ("Bug#682010: #682010 re celt and mumble referred to the TC"):
> There was no indication of any kind that the discussion was going to
> continue, otherwise I would have delayed the summary to the TC.

I think you were right to escalate this to the TC when you did.  The
longer we get into the wheezy freeze, the more difficult it becomes to
fix this for wheezy.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 12:45:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 12:45:08 GMT) Full text and rfc822 format available.

Message #37 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org, Ron <ron@debian.org>
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 08:40:28 -0400
On Thursday, July 19, 2012 08:00:11, Chris Knadle wrote:
> On Thursday, July 19, 2012 05:38:47, Ron wrote:

[…]
> > If I'd known that Thorvald was not going to be here to manage this
> > transition for Wheezy, I'd have never agreed to shipping libcelt in
> > the Squeeze release either, and would have instead kept it in sid
> > only.  If I'd known that his plan to have all other distros ship
> > the 0.7.1 release as a temporary interoperability snapshot would
> > fail as dismally as it did (no other distro shipped this version
> > except debian derivatives who took it from us), I'd have similarly
> > vetoed the idea of shipping this as a public library in the last
> > stable release too.
> 
> This was definitely not clear; if it had been I wouldn't have considered
> re- enabling it as a potential solution.

... except that Nicos Gollan stated that mumble servers have a base assumption 
that clients have the CELT 0.7.1 codec available.  :-/  Is that correct?

[…]
> > I see that this proposal has already resulted in Chris skating down
> > the slippery slope of "let's re-enable it for everything else too".
> > And we'll get people with no experience or prior involvement to
> > maintain it, and we'll enable multi-arch too, and ...
> 
> In terms of re-enabling CELT, I was simply looking upon this as a matter of
> fairness to other maintainers.  If it's decided only Mumble requires an
> exception to use CELT 0.7.1 (which right now doesn't sound like the right
> thing to do), I'm fine with that.

I mixed up the last sentence above; I was trying to say that I was fine with 
only Mumle using CELT 0.7.1 if it requires it, rather than any package that 
could theoretically use it.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 14:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicos Gollan <gtdev@spearhead.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 14:21:06 GMT) Full text and rfc822 format available.

Message #42 received at 682010@bugs.debian.org (full text, mbox):

From: Nicos Gollan <gtdev@spearhead.de>
To: 682010@bugs.debian.org
Cc: Chris.Knadle@coredump.us
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 16:11:38 +0200
Hi,

On Thursday 19 July 2012 14:40:28 Chris Knadle wrote:
> ... except that Nicos Gollan stated that mumble servers have a base
> assumption that clients have the CELT 0.7.1 codec available.  :-/  Is that
> correct?

If a client does not report any CELT versions, the server assumes that (only) 
0.7.1 is available for that client. If a client reports a number of supported 
versions, and 0.7.1 is not among them, the server will _not_ make the 
assumption, but of course such clients also risk being unable to communicate.

For details, see the implementations of:

* Server::msgAuthenticate()
* Server::recheckCodecVersions()

Newer git versions of the server will send upon login a warning to clients 
which are either missing CELT support on a "normal" server, or OPUS support on 
an OPUS-only server.

Regards,
Nicos



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 17:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 17:27:06 GMT) Full text and rfc822 format available.

Message #47 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Nicos Gollan <gtdev@spearhead.de>, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 13:24:02 -0400
On Thursday, July 19, 2012 10:11:38, Nicos Gollan wrote:
> Hi,
> 
> On Thursday 19 July 2012 14:40:28 Chris Knadle wrote:
> > ... except that Nicos Gollan stated that mumble servers have a base
> > assumption that clients have the CELT 0.7.1 codec available.  :-/  Is
> > that correct?
> 
> If a client does not report any CELT versions, the server assumes that
> (only) 0.7.1 is available for that client. If a client reports a number of
> supported versions, and 0.7.1 is not among them, the server will _not_
> make the assumption, but of course such clients also risk being unable to
> communicate.
> 
> For details, see the implementations of:
> 
> * Server::msgAuthenticate()
> * Server::recheckCodecVersions()
> 
> Newer git versions of the server will send upon login a warning to clients
> which are either missing CELT support on a "normal" server, or OPUS support
> on an OPUS-only server.

I'd just like to again give you my sincere thanks for providing this 
information. 

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Message sent on to Chris.Knadle@coredump.us:
Bug#682010. (Thu, 19 Jul 2012 17:36:07 GMT) Full text and rfc822 format available.

Message #50 received at 682010-submitter@bugs.debian.org (full text, mbox):

From: Patrick Matthäi <pmatthaei@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: debian-ctte@lists.debian.org, Thorvald Natvig <thorvald@debian.org>, lion@lion.leolix.org, ron@debian.org, 682010-submitter@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Thu, 19 Jul 2012 17:27:36 +0200
Am 19.07.2012 18:59, schrieb Ian Jackson:
> The context is the problems with mumble and celt, which have been
> referred to the Technical Committee (of which I'm a member).

Thanks for taking care of it.

>
> Ian Jackson writes ("Re: mumble and celt, #682010, TC"):
>> So in summary, the conclusion seems to be:
>>
>>   * If we cannot find a maintainer for celt who looks like they'll be
>>     able to handle it for the lifetime of wheezy then we need to allow
>>     the current mumble (and perhaps other rdepends) in sid to propagate
>>     and will then be able to remove celt from wheezy.
>
> Thorvald: you are listed as the maintainer for mumble, along with Ron.
> Patrick: you seem to have been involved in mumble recently.

I were the maintainer, with Thorvald, since mumble is included in Debian 
and declined this job, since I were personaly attacked by some of our 
DDs. I also talked with our leader about this situation.

Philipp and I *wanted* to continue the maintenance of celt for the 
lifetime of wheezy, but for this idea Philipp and I just get more and 
more personal insults, with the side effects that:
1) Philipp gave up *all* his efforts on Debian
2) I also wanted to resign, didn't done it but sorry now I have got a 
fu....... opinion about this

> Ron evidently has no interest in maintaining celt in wheezy, and we

Well known and he did everything so that nobody wants to do this job, 
that - with the insults from some other DDs - is the only reason why I 
do not want to do this job, anymore, but thanks for asking.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatthaei@debian.org
        patrick@linux-dev.org
*/



Message sent on to Chris.Knadle@coredump.us:
Bug#682010. (Thu, 19 Jul 2012 18:21:10 GMT) Full text and rfc822 format available.

Message #53 received at 682010-submitter@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: pmatthaei@debian.org
Cc: debian-ctte@lists.debian.org, Thorvald Natvig <thorvald@debian.org>, lion@lion.leolix.org, ron@debian.org, 682010-submitter@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Thu, 19 Jul 2012 19:18:31 +0100
Patrick Matthäi writes ("Re: mumble and celt, #682010, TC"):
> I were the maintainer, with Thorvald, since mumble is included in Debian 
> and declined this job, since I were personaly attacked by some of our 
> DDs. I also talked with our leader about this situation.
> 
> Philipp and I *wanted* to continue the maintenance of celt for the 
> lifetime of wheezy, but for this idea Philipp and I just get more and 
> more personal insults, with the side effects that:
> 1) Philipp gave up *all* his efforts on Debian
> 2) I also wanted to resign, didn't done it but sorry now I have got a 
> fu....... opinion about this

I'm sorry you feel this way.

> > Ron evidently has no interest in maintaining celt in wheezy, and we
> 
> Well known and he did everything so that nobody wants to do this job, 
> that - with the insults from some other DDs - is the only reason why I 
> do not want to do this job, anymore, but thanks for asking.

If you had the support of the Technical Committee, would it help ?

Thanks for your reply, in any case.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 18:33:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 18:33:10 GMT) Full text and rfc822 format available.

Message #58 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: #682010 re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 03:53:31 +0930
On Thu, Jul 19, 2012 at 12:55:59PM +0100, Ian Jackson wrote:
> Ron writes ("Re: #682010 re celt and mumble referred to the TC"):
> > You understand this is a fairly arbitrary 'daily' snapshot of an
> > experimental research codec, from ~2.5 years ago, that nobody has
> > looked at since that day, that nobody has committed to maintaining,
> > that its author has explicitly said he has no interest in maintaining,
> > that has had large parts completely rewritten since for all manner of
> > reasons, and is bitstream incompatible with every other snapshot that
> > was ever released, right?
> 
> However, it appears that some other distros have chosen to ship this
> particular version.  For example at least Ubuntu are still
> distributing it.

I don't want to niggle over words here, but "chosen" would imply that
somebody actually exercised some conscious judgement in that decision.

Which there doesn't really seem to be a whole lot of evidence for.
Nobody from Ubuntu has ever spoken to me or upstream about this, and
the version they are shipping appears to simply have been auto-imported
from Debian with no changes or human intervention.  There are open bugs
in launchpad like:

 - LibCelt Package Breaking Apt-Get
 - package libcelt0-0 0.7.1-1 failed to install/upgrade:

Which nobody has commented on or triaged.

So the only rational conclusion there is that Ubuntu will do whatever
we do - and naturally they will then lag somewhat.  If we are to insist
on not changing things until they do, then we're going to be deadlocked
shipping obsolete, unmaintained, code for a long time ...

If they *had* asked, they would have got the same advice on offer here.

(and yes, those are almost surely bogus bugs - but that just reinforces
the point that not even minimal attention is being paid to this there)


However if this list is any indication:
https://bugs.launchpad.net/ubuntu/+source/mumble

Then the old version of mumble that Ubuntu is shipping looks long overdue
for an update anyway, since there's a long list of reasons there why its
users can't communicate with anyone at all, none of which have anything
to do with celt ...


> > >  - This is a serious problem for mumble at least and is arguably RC.
> > 
> > Yes, mumble has a serious problem, that is arguably RC.
> > In fact it has several of them aside from this corner that people
> > have painted themselves into with it ...
> > 
> >  - Its primary author, who is also a DD and comaint of the package,
> >    is currently MIA with a new job that has consumed pretty much
> >    every minute of his time for the last 2 years or so now.
> > 
> >    The people who remain that are hacking on it, can't even do a
> >    formal new release at present, because he is the only one with
> >    access to the systems they need to do that, and is not available
> >    to do so.
> 
> I'm not convinced by this complaint.  The whole point of free software
> is that it is possible to carry on without needing the cooperation or
> involvement of one's upstreams.

Sure, but in order for that possibility to be real, someone has to
collapse the waveform and step up to do the work.  So far nobody has
stepped in to fill Thorvald's shoes.  I only stepped up to help with
the packages because I consider him to be a friend (and indeed I also
advocated him to NM because I consider him a prolific and talented
programmer - they aren't easy shoes to fill by a part time dabbler).

And I don't want to sound like I'm taking potshots at Ubuntu here
(because absolutely I am not) but this seems directly relevant to
your first point above, because maintenance of mumble there appears
to have completely stopped dead in its tracks when Thorvald vanished
off there scene there too, and they haven't yet replaced him either.


The important question for the release is reality, not theoretical
possibilities.  The simple reality is, he's not easy to replace, and
so far hasn't been.  And the result of that is clearly showing.


> Also, are you saying you think mumble should be removed ?  Now is a
> bit late to be deciding this.

I'm saying that what I've seen in the short time since I stepped into
this tarpit, along with the rush of RC bugs like #675955 and #676816
and things like #628847, #615492, #673602 -- all of which have nothing
to do with anything I changed -- don't exactly inspire confidence in
its release readiness to me.

I'm not saying they can't be fixed.  But given that #676816 was a
guaranteed crasher since the day it was introduced in March 2010 and
only just noticed in the last month - I'm not terribly confident that
we've seen the last of this sort of thing.

I talked through this with people from the release team as the freeze
deadline loomed -- deciding to remove it earlier would have been
premature.  But you're quite correct about the 'lateness' in the cycle
limiting our choices.


> > If I'd known that Thorvald was not going to be here to manage this
> > transition for Wheezy, I'd have never agreed to shipping libcelt in
> > the Squeeze release either, and would have instead kept it in sid
> > only.  If I'd known that his plan to have all other distros ship
> > the 0.7.1 release as a temporary interoperability snapshot would
> > fail as dismally as it did (no other distro shipped this version
> > except debian derivatives who took it from us), I'd have similarly
> > vetoed the idea of shipping this as a public library in the last
> > stable release too.
> 
> I think interoperability with the ecosystem of our derivatives is
> sufficiently important that it's worth preserving.

We don't need an 'exclusive to us' version of celt to have that.

> > Mumble already ships this as an embedded private library on every
> > system other than direct Debian derivatives.
> 
> I'm not sure exactly what you mean.  Do you mean they support some
> other version of the celt codec ?  Or are you just talking about how
> they manage the packaging ?

I mean mumble embeds something like seven mutually incompatible versions
of celt, all of which it provides as private implementation libraries
on every platform except Debian - because nobody else provides the version
that we do.  And we only provide that version because upstream tagged the
current head on a random day when Thorvald and I said, "if we're going to
do this, we need it today".

The idea was, he was going to try to get everyone else to use it too.
But that failed completely, so all we have now is this random Debian-
specific snapshot, that nothing and nobody else uses or interoperates
with, and which mumble has to embed anyway for every other user.

It really is time to just admit that was a mistake, and correct it.


> I certainly think it's better to have the celt codec, even if it's an
> unreleased and now-unmaintained-upstream snapshot, in a separate
> package, than in an embedded library.

If there were other things that should be using it, I'd agree.
But there are not, and they very much should not.

I was shocked at the number of people who had no idea what celt was
or what it did, or that it broke bitstream (and usually API) on every
release, and was purely a research codec -- who had blindly added
support for it "just because it was there".  They were all genuinely
stunned when I told them there were no compatibility guarantees being
made about it until the research phase was over.  The first I'd ever
hear from them was when it did break their code and they reported
that as a bug ...

As a general rule, I'm all for letting people shoot themselves in the
feet as a path to learning -- but there are very good reasons why
libraries hide private symbols, and applications hide private libraries,
and this is exactly one of them.

Exposing this for another whole release when we don't need to, and gain
nothing useful from doing so, doesn't make any sense now.

If I ever upload another experimental codec, it will definitely be
handled very differently to how this one was.  There are lessons to
be learned here that won't be forgotten easily.



> > I see that this proposal has already resulted in Chris skating down
> > the slippery slope of "let's re-enable it for everything else too".
> > And we'll get people with no experience or prior involvement to
> > maintain it, and we'll enable multi-arch too, and ...
> 
> Your message has too much personal animosity in it.

I don't see where you read that here?  (though I don't deny my frustration
at being called upon to repeat the same things over and over leaked out
badly in a few places in the other bug)  Or had you not actually read his
message at the time you replied to mine?

The above seems like a fairly simple summary of fact, and indeed the
release team independently quickly converged on consensus horror at
precisely those three elements shortly after I hit send, and before
anyone there had the chance to see my message bemoaning them ...

I'll not niggle over words if you have a more PC way you'd like to say
that too, but the facts as stated still remain ...  and those were bad
ideas layered on bad ideas.  Sorry.  But this is exactly the sort of
thing that I expect to ensure

I can put my hand on my heart and say all I care about is getting to
the bottom of the technical questions here, as quickly as possible.
We have a release to get out.  There is lots of Real Work still to do.


> > So I really hope that it's actually clear to the people presiding
> > over the tech-ctte, that the *whole point* of a codec is that it
> > lets you *interoperate* with others.  Which this snapshot does not.
> 
> It lets you interoperate with Ubuntu, and with users running squeeze.

We don't need an 'exclusive to us' version of celt to have that.

> > If people really want to do this for mumble, then it really ought
> > to be done as a private implementation detail, like it is for every
> > other platform - not by setting traps in public for the unsuspecting
> > and otherwise uninformed.  If we ship celt publicly, we are sending
> > the message that people should use it.  That's the wrong message
> > for an obsolete, unmaintained codec, and there is no reason to tie
> > 'being pragmatic' about the mumble screwup to making an even bigger
> > mistake.  That's not 'avoiding risk', it's "not avoiding risk".
> > And one that is really, really trivial to avoid.
> 
> Just to be clear, you seem to be suggesting that while reintroducing
> libcelt as a package is a bad thing, it would be fine to reintroduce
> it as an embedded library in mumble ?

No, I'm not saying that would be 'fine', otherwise I'd have done it
already.  I think it's a terrible idea.

All I'm saying is that if you are going to use the big hammer and
insist on celt being reintroduced, despite all of the clouds hanging
over it - this would be the least stupid way of doing something stupid,
that exposes the least number of people to it.  (no personal animosity
intended here either, but it seemed like your first instinct in your
first reply was to lean that way, so this was simply a damage mitigation
suggestion if you weren't going to be swayed from that line of thought)

I know I definitely won't be exposing any system I own to celt 0.7.1
traffic - and I would consider it quite irresponsible for Debian to
expose its users in that way too for the life of another release.

What people choose to do for themselves, is their choice and they
are free to make it as they please.  But if we ship this, we are
saying "we believe it's ok".  And I don't believe that is true.

I've been lurking among the people who developed celt for many many
years now -- so if somebody wants to try to convince me that they have
both the technical expertise and the time to audit and maintain this,
then that would be most wonderful - we have a small mountain of other
challenging codec work we'd love to put you to work at too!

But I don't honestly believe that is actually going to happen beyond
lip service.  All the people I know who I would trust to do this are
already very very busy working on things that actually do have some
sort of real future still ...  All the people with an actual vested
interest in maintaining this for mumble I've asked, and they've all
been very explicit in their refusal to take on the responsibility of
being its maintainer beyond "we'll apply a patch if someone else does
all of the work".

This isn't something you can just fuzz test and go "oh it's fine".
We were only a few bits in the bitstream away from being able to
produce the test vectors with a PRNG.  Almost any sequence is a
'valid' bitstream, but the permutations of code path and state are
vast.  The crashers that have been found have all been found through
intimate knowledge of how to set up a very precise chain of events.
Nobody has gone back to analyse the 0.7.1 code with them in mind,
because nobody actually cares to maintain it, and we were racing
forward to get a frozen bitstream out.  When the people who did that
work tell me they think there are unfixed issues in that version,
I'm not going to be fool enough to handwave them away.  I've seen
first hand how rarely they tend to be wrong about these things.


Given how easy this really is to fix without creating that kind of
exposure, I'm a bit lost for words at the push back it seems to be
getting from some quarters ...


> > My general feeling is that mumble is currently in an awkward state
> > which really doesn't make it a good release candidate for Wheezy,
> > and we'd probably be best served by simply dropping it from testing,
> > fixing this in sid as the fixes come or are needed, and then pushing
> > snapshots to bpo as we have reasonable candidates for that.
> 
> I don't think this is a good approach.  But I'm pleased to see that
> you agree that this is probably an RC problem.

It doesn't sound ideal to me either, but if mumble is going to need
updates more often than we make point releases, and with code changes
larger than can reasonably reviewed for that - then I'm not really
sure what other realistic options we have.

I'm open to ideas which might actually fly though.

 Cheers,
 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 18:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 18:42:03 GMT) Full text and rfc822 format available.

Message #63 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: debian-ctte@lists.debian.org
Subject: Re: Bug#682010: #682010 re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 19:39:37 +0100
Ron writes ("Bug#682010: #682010 re celt and mumble referred to the TC"):
> I don't want to niggle over words here, but "chosen" would imply that
> somebody actually exercised some conscious judgement in that decision.
> 
> Which there doesn't really seem to be a whole lot of evidence for.
> Nobody from Ubuntu has ever spoken to me or upstream about this, and
> the version they are shipping appears to simply have been auto-imported
> from Debian with no changes or human intervention.  There are open bugs
> in launchpad like:
> 
>  - LibCelt Package Breaking Apt-Get
>  - package libcelt0-0 0.7.1-1 failed to install/upgrade:

You are implying that the package does not work in Ubuntu.  However I
have personally witnessed Ubuntu users using it.  You seem to be
grasping at straws.

> So the only rational conclusion there is that Ubuntu will do whatever
> we do - and naturally they will then lag somewhat.  If we are to insist
> on not changing things until they do, then we're going to be deadlocked
> shipping obsolete, unmaintained, code for a long time ...

Alternatively we could wait until the new opus codec is widely
deployed.  Mumble upstream do have a transition plan.  I don't think
"pull the plug on celt" is a transition plan.

> > I'm not convinced by this complaint.  The whole point of free software
> > is that it is possible to carry on without needing the cooperation or
> > involvement of one's upstreams.
> 
> Sure, but in order for that possibility to be real, someone has to
> collapse the waveform and step up to do the work.  So far nobody has
> stepped in to fill Thorvald's shoes.  I only stepped up to help with
> the packages because I consider him to be a friend (and indeed I also
> advocated him to NM because I consider him a prolific and talented
> programmer - they aren't easy shoes to fill by a part time dabbler).

I have spoken privately to people who are involved in mumble upstream
and they seem to be keen to continue.

> Given how easy this really is to fix without creating that kind of
> exposure, I'm a bit lost for words at the push back it seems to be
> getting from some quarters ...

Your plan for a "fix" is total incompatibility with other deployed
installations.

Ian.



Message sent on to Chris.Knadle@coredump.us:
Bug#682010. (Thu, 19 Jul 2012 18:57:11 GMT) Full text and rfc822 format available.

Message #66 received at 682010-submitter@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: pmatthaei@debian.org, debian-ctte@lists.debian.org, Thorvald Natvig <thorvald@debian.org>, lion@lion.leolix.org, ron@debian.org, 682010-submitter@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Thu, 19 Jul 2012 19:56:06 +0100
Ian Jackson writes ("Re: mumble and celt, #682010, TC"):
> Patrick Matthäi writes ("Re: mumble and celt, #682010, TC"):
> > I were the maintainer, with Thorvald, since mumble is included in Debian 
> > and declined this job, since I were personaly attacked by some of our 
> > DDs. I also talked with our leader about this situation.
> > 
> > Philipp and I *wanted* to continue the maintenance of celt for the 
> > lifetime of wheezy, but for this idea Philipp and I just get more and 
> > more personal insults, with the side effects that:
> > 1) Philipp gave up *all* his efforts on Debian
> > 2) I also wanted to resign, didn't done it but sorry now I have got a 
> > fu....... opinion about this
> 
> I'm sorry you feel this way.
...
> > Well known and he did everything so that nobody wants to do this job, 
> > that - with the insults from some other DDs - is the only reason why I 
> > do not want to do this job, anymore, but thanks for asking.
> 
> If you had the support of the Technical Committee, would it help ?

I have spoken to Patrick Matthaei on irc and he has informed me that,
unfortunately, he does not want to get involved in this situation
again, because of the abuse he has received.

Now, both Philippe and Patrick have alleged abuse; unfortunately, I am
told, this was in private mainly via irc.  There apparently aren't any
appropriate logs.

I would like to emphasise that personal abuse and insults along the
lines described informally to me by Patrick are wholly unacceptable
from one participant in Debian to another.

In future, I would encourage anyone who is on the receiving end of
abusve behaviour to immediately contact, in private, someone in a
position of authority in the project; you should give a complete irc
transcript or the full text of relevant emails, etc.  If your irc
client does not have logging enabled then a screenshot is good.
(Please try to avoid publicly post your accusations of abuse, naming
the accused, if you can.)

I'm sure that members of the TC, the Project Leader, former DPLs, and
the suchlike would be happy to help anyone who is the victim of such
abuse.  Part of our responsibility is to use our positions of
influence to make sure that abuse does not continue.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 19:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 19:54:03 GMT) Full text and rfc822 format available.

Message #71 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: #682010 re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 05:20:32 +0930
On Thu, Jul 19, 2012 at 07:39:37PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: #682010 re celt and mumble referred to the TC"):
> > I don't want to niggle over words here, but "chosen" would imply that
> > somebody actually exercised some conscious judgement in that decision.
> > 
> > Which there doesn't really seem to be a whole lot of evidence for.
> > Nobody from Ubuntu has ever spoken to me or upstream about this, and
> > the version they are shipping appears to simply have been auto-imported
> > from Debian with no changes or human intervention.  There are open bugs
> > in launchpad like:
> > 
> >  - LibCelt Package Breaking Apt-Get
> >  - package libcelt0-0 0.7.1-1 failed to install/upgrade:
> 
> You are implying that the package does not work in Ubuntu.  However I
> have personally witnessed Ubuntu users using it.  You seem to be
> grasping at straws.

mumble hasn't been updated in Ubuntu in its last 4 releases.
Are you saying the list of bugs in launchpad that are fixed in Debian
are not real?  And that it isn't actually unmaintained there?

> > So the only rational conclusion there is that Ubuntu will do whatever
> > we do - and naturally they will then lag somewhat.  If we are to insist
> > on not changing things until they do, then we're going to be deadlocked
> > shipping obsolete, unmaintained, code for a long time ...
> 
> Alternatively we could wait until the new opus codec is widely
> deployed.  Mumble upstream do have a transition plan.  I don't think
> "pull the plug on celt" is a transition plan.

Firefox has it enabled in their beta, which will ship as stable in
something like 6 weeks time.  How much more widely deployed than 30%
of the world did you have in mind?

All the name brand distros are already shipping it.

The "plug" was pulled on celt a long time ago.


> > > I'm not convinced by this complaint.  The whole point of free software
> > > is that it is possible to carry on without needing the cooperation or
> > > involvement of one's upstreams.
> > 
> > Sure, but in order for that possibility to be real, someone has to
> > collapse the waveform and step up to do the work.  So far nobody has
> > stepped in to fill Thorvald's shoes.  I only stepped up to help with
> > the packages because I consider him to be a friend (and indeed I also
> > advocated him to NM because I consider him a prolific and talented
> > programmer - they aren't easy shoes to fill by a part time dabbler).
> 
> I have spoken privately to people who are involved in mumble upstream
> and they seem to be keen to continue.

I have spoken to them publicly.  All of them refused to take any
responsibility for actually maintaining celt beyond "we'll apply
a patch if you give us one".  If they had committed to that we
wouldn't be having this discussion.

But yes, other than that they were quite keen for us to just close
our eyes and keep shipping it until news of the disaster hit /.

They also recommended we just ignore the zeroc-ice ABI breakage and
pretend it didn't happen too.

Oh, and they also removed support for speex in the last couple of
weeks, which otherwise was a baseline for interop that is still
maintained.

Is this the kind of technical excellence you want to overrule a
maintainer to achieve?


> > Given how easy this really is to fix without creating that kind of
> > exposure, I'm a bit lost for words at the push back it seems to be
> > getting from some quarters ...
> 
> Your plan for a "fix" is total incompatibility with other deployed
> installations.

And your alternate plan is "make everyone insecure" rather than propagating
a security fix release?

How long do you really think it will take for that to be rolled out?

Alternatively, you could send me a patch to restore speex support.
I'll gladly apply that if incompatibility is your actual concern.


 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 20:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 20:12:06 GMT) Full text and rfc822 format available.

Message #76 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Fri, 20 Jul 2012 05:40:05 +0930
On Thu, Jul 19, 2012 at 07:56:06PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: mumble and celt, #682010, TC"):
> > Patrick Matthäi writes ("Re: mumble and celt, #682010, TC"):
> > > I were the maintainer, with Thorvald, since mumble is included in Debian 
> > > and declined this job, since I were personaly attacked by some of our 
> > > DDs. I also talked with our leader about this situation.
> > > 
> > > Philipp and I *wanted* to continue the maintenance of celt for the 
> > > lifetime of wheezy, but for this idea Philipp and I just get more and 
> > > more personal insults, with the side effects that:
> > > 1) Philipp gave up *all* his efforts on Debian
> > > 2) I also wanted to resign, didn't done it but sorry now I have got a 
> > > fu....... opinion about this
> > 
> > I'm sorry you feel this way.
> ...
> > > Well known and he did everything so that nobody wants to do this job, 
> > > that - with the insults from some other DDs - is the only reason why I 
> > > do not want to do this job, anymore, but thanks for asking.
> > 
> > If you had the support of the Technical Committee, would it help ?
> 
> I have spoken to Patrick Matthaei on irc and he has informed me that,
> unfortunately, he does not want to get involved in this situation
> again, because of the abuse he has received.
> 
> Now, both Philippe and Patrick have alleged abuse; unfortunately, I am
> told, this was in private mainly via irc.  There apparently aren't any
> appropriate logs.
> 
> I would like to emphasise that personal abuse and insults along the
> lines described informally to me by Patrick are wholly unacceptable
> from one participant in Debian to another.
> 
> In future, I would encourage anyone who is on the receiving end of
> abusve behaviour to immediately contact, in private, someone in a
> position of authority in the project; you should give a complete irc
> transcript or the full text of relevant emails, etc.  If your irc
> client does not have logging enabled then a screenshot is good.
> (Please try to avoid publicly post your accusations of abuse, naming
> the accused, if you can.)
> 
> I'm sure that members of the TC, the Project Leader, former DPLs, and
> the suchlike would be happy to help anyone who is the victim of such
> abuse.  Part of our responsibility is to use our positions of
> influence to make sure that abuse does not continue.

I think I might actually have logs of the ALL CAPS screaming abuse I
received from Patrick Matthäi ...

But I'm not going to be so childish as to think that posting them
publicly or to others will actually make anything about that better.

The irony was amusing for a nanosecond though.

 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 20:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 20:21:05 GMT) Full text and rfc822 format available.

Message #81 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 16:17:28 -0400
[Message part 1 (text/plain, inline)]
On Thursday, July 19, 2012 14:23:31, Ron wrote:
> On Thu, Jul 19, 2012 at 12:55:59PM +0100, Ian Jackson wrote:
> > Ron writes ("Re: #682010 re celt and mumble referred to the TC"):

[…]
> > > Mumble already ships this as an embedded private library on every
> > > system other than direct Debian derivatives.
> > 
> > I'm not sure exactly what you mean.  Do you mean they support some
> > other version of the celt codec ?  Or are you just talking about how
> > they manage the packaging ?
> 
> I mean mumble embeds something like seven mutually incompatible versions
> of celt, all of which it provides as private implementation libraries
> on every platform except Debian - because nobody else provides the version
> that we do.  And we only provide that version because upstream tagged the
> current head on a random day when Thorvald and I said, "if we're going to
> do this, we need it today".
> 
> The idea was, he was going to try to get everyone else to use it too.
> But that failed completely, so all we have now is this random Debian-
> specific snapshot, that nothing and nobody else uses or interoperates
> with, and which mumble has to embed anyway for every other user.

When I test the version in Wheezy that uses celt I'm able to interoperate with 
any public server, whether it be a Debian platform, Gentoo, Fedora, Windows, 
FreeBSD, but I often cannot with the version in Sid.  :-/

> It really is time to just admit that was a mistake, and correct it.

However as I said I also don't disagree with this.

An alternative I've been thinking about would be an additional text file in 
the Mumble package (FAQ.txt, PROBLEMS.txt -- whatever filename seems logical) 
which could contain information concerning removal of the CELT codec and the 
reasons why -- dead upstream, security concerns, etc.  Enough information 
(such as that you've already provided) that's easy enough to find so that 
there's at least a chance for users to find it, or something to point them to 
if they open a bug report ... and then we suffer for a bit until Opus support 
gets more widespread.

What I'm really looking to try avoid are repeat events of someone installing 
Mumble, finding or opening a bug report, and receiving back [this is not an 
accusation] "this isn't a bug <closed>" because the users lack the 
information, and it being too exasperating for any maintainer to give the long 
explanation repeatedly.

This is why I've been asking whether an entry in NEWS.Debian makes sense.  Or 
perhaps both makes sense: a NEWS.Debian entry for "please read FAQ.txt in 
/usr/share/docs/mumble relating to why some audio connections fail currently" 
or something to that effect.


Not optimal of course, but no solution to bug ever will be.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 20:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 20:30:06 GMT) Full text and rfc822 format available.

Message #86 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: debian-ctte@lists.debian.org, Thorvald Natvig <thorvald@debian.org>, 682010@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Fri, 20 Jul 2012 05:57:00 +0930
On Thu, Jul 19, 2012 at 07:18:31PM +0100, Ian Jackson wrote:
> Thorvald Natvig writes ("Re: mumble and celt, #682010, TC"):
> > For now, the easiest is probably to re-enable Mumble to build the
> > embedded CELT, something it currently does not do. That way it is just a
> single package, and we can deal with problems as they come up.
> 
> Since Ron is listed as co-maintainer for mumble do you feel you have
> the authority to do this ?  I imagine Ron would object, so you would
> in any case need a TC ruling to arbitrate between you.

*sigh*  Why would you imagine this?

I already told you I have the utmost faith in Thorvald, and this is *his*
software for pitysake.  I also already suggested exactly this as the
least-worst option, and you shot me down ...

Now you think it's a great idea?

Why on earth do you think I would need someone else to arbitrate with
someone I actually respect?

I would love nothing more than for Thorvald to find the time to come back
on the scene and take care of this for Wheezy.

If you have no objection to that, then I guess it's all settled.
You can put down the Dad Knows Best hat, and leave it to Thorvald and I
to sort out the details.

Done Deal?

 Ron





Message sent on to Chris.Knadle@coredump.us:
Bug#682010. (Thu, 19 Jul 2012 21:36:03 GMT) Full text and rfc822 format available.

Message #89 received at 682010-submitter@bugs.debian.org (full text, mbox):

From: Patrick Matthäi <pmatthaei@debian.org>
To: ron@debian.org, 682010-submitter@bugs.debian.org
Cc: debian-ctte@lists.debian.org, Thorvald Natvig <thorvald@debian.org>, lion@lion.leolix.org
Subject: Re: mumble and celt, #682010, TC
Date: Thu, 19 Jul 2012 23:33:40 +0200
[Message part 1 (text/plain, inline)]
I just have got some realy short questions to you Ron:


1) I already tried some research, but wasn't successful: what are the
actual known security risks with celt?

2) If there are no known critical security risks - preventing a release
- what should speak against "just" release it with Wheezy and if some
critical security bug appears just drop it from Wheezy if no good fix
appears (such removals were also done in the past)?

3) Why would you prefer using the embedded celt version instead of the
packaged one with wheezy?

4) If celt was just a big experiment, why did you packaged it?

5) .. and why didn't you open a thread where some applications - in this
case mumble - switched to it?

6) Regarding to Throrvald's answers, does it realy help to safely
migrate mumble to opus/whatever if every other distribution still relies
on mumble with celt?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatthaei@debian.org
        patrick@linux-dev.org
*/

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 19 Jul 2012 23:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 19 Jul 2012 23:09:03 GMT) Full text and rfc822 format available.

Message #94 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Chris Knadle <Chris.Knadle@coredump.us>
Cc: Thorvald Natvig <thorvald@debian.org>, debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 08:37:52 +0930
Ok, so I've just had a long overdue catch-up with Thorvald, and we think
we have a plan that really covers all the bases ...

We can re-enable speex support in the client, which was only just recently
dropped (so only the client currently in unstable is affected by that),
and since all the clients well back in pre-history should support that
just fine, we can jigger things so that it will be the baseline interop
if celt is not present, and use the existing threshold setting on the
servers to let people select the point at which the number of users with
opus support triggers switching to that.

Which means we basically get the best of all worlds, we have interop with
existing old clients, we get to drop celt support and so don't have to
worry about getting burned by it, and people will automatically switch to
the wonders of opus (and get lower bandwidth and better quality) as soon
as enough of the connected parties have support for it.

There's a few things that need testing, but we're reasonably confident
this can fly, and meet all the concerns of almost everyone.


There are only two small catches:

 - catch 1.  He's about to fly out and will be afk for a week, so he
   won't be able to look at this until he gets back.  (which is why
   I'm writing this now instead of letting him do it)

 - catch 2.  The version of murmur currently in testing is completely
   broken again due to the zeroc-ice screwup.  That wouldn't have
   happened if the -2 upload of mumble had transitioned as planned,
   but well, you all know the story there ...


So ...   Chris, since you're currently the major objector, and opened
this bug with the TC, this question is mainly for you ...

What we'd like to do in the meantime, is let the mumble version from
unstable transition to testing now.  That will:

 - Unbreak the server for everyone, which currently won't work at all.
 - Break the client for people using ancient servers, and who are
   talking to people without opus support.  ie.  not everyone, but a
   fair number of people who haven't yet moved, or who can't convince
   their friends to move yet.  You know the deal there.
 - Most importantly though: minimise the diff that -release need to
   review when Thorvald gets back and we have a new upload to make
   once again.

We tossed up which way to go with this (the alternative being to not
let it migrate and inflict the bigger diff on -release and broken
server on everyone) - but this seems to be the lesser evil, since it
will let people get some more testing miles on opus, and people who
would really be put out by that can just put it on hold for a short
time.

Once Thorvald gets back and we re-add speex, this should all work again
for everyone, and we don't have to kick it out of testing, don't have
to embed a suspect lib, and shouldn't have to leave anyone feeling
hard done by ...


Does that sound ok for you?

If it does, I'll bump the severity of your bug back down to something
not RC (but not close it yet, we'll let the speex enabling upload do
that), and request the release team unblock it.  And if there is no
further complaint to discuss, then I guess you can tell -ctte you
have the pound of flesh you sought :)

Otherwise ...  well, then I don't know what ...  you'll have to
suggest a plan B all your own, because this is the best we have ...

All Thorvald asked is that people stay calm, so he can actually worry
about working on the code rather than being stressed by the drama :)


I'll make this happen if I get your ACK that it works for you too.


 Best,
 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 00:27:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 00:27:09 GMT) Full text and rfc822 format available.

Message #99 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>
Cc: debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Thu, 19 Jul 2012 20:25:13 -0400
[Message part 1 (text/plain, inline)]
On Thursday, July 19, 2012 19:07:52, Ron wrote:
> Ok, so I've just had a long overdue catch-up with Thorvald, and we think
> we have a plan that really covers all the bases ...
> 
> We can re-enable speex support in the client, which was only just recently
> dropped (so only the client currently in unstable is affected by that),
> and since all the clients well back in pre-history should support that
> just fine, we can jigger things so that it will be the baseline interop
> if celt is not present, and use the existing threshold setting on the
> servers to let people select the point at which the number of users with
> opus support triggers switching to that.
> 
> Which means we basically get the best of all worlds, we have interop with
> existing old clients, we get to drop celt support and so don't have to
> worry about getting burned by it, and people will automatically switch to
> the wonders of opus (and get lower bandwidth and better quality) as soon
> as enough of the connected parties have support for it.

This sounds great.

> There's a few things that need testing, but we're reasonably confident
> this can fly, and meet all the concerns of almost everyone.
> 
> 
> There are only two small catches:
> 
>  - catch 1.  He's about to fly out and will be afk for a week, so he
>    won't be able to look at this until he gets back.  (which is why
>    I'm writing this now instead of letting him do it)
> 
>  - catch 2.  The version of murmur currently in testing is completely
>    broken again due to the zeroc-ice screwup.  That wouldn't have
>    happened if the -2 upload of mumble had transitioned as planned,
>    but well, you all know the story there ...

Let's just call it the results from a communication breakdown.  I appologize 
for my side of that.

> So ...   Chris, since you're currently the major objector, and opened
> this bug with the TC, this question is mainly for you ...

This sounds like a very good compromise to me, and I thank both you and 
Thorvald for the effort in coming up with it. .. And thanks for talking to me 
again.

> What we'd like to do in the meantime, is let the mumble version from
> unstable transition to testing now.  That will:
> 
>  - Unbreak the server for everyone, which currently won't work at all.

... And I can verify that this is the case, as I just attempted to upgrade the 
version of mumble-server I was running on a server, which results in an error 
message on every attempted startup:

/usr/sbin/murmurd: symbol lookup error: /usr/sbin/murmurd: undefined symbol: 
_ZN3Ice6upCastEPNS_10ConnectionE

Whereby I upgraded to mumble-server from Sid, which works fine.  (Thank you 
for dealing with the zero-ice difficulties, and I'm glad that work will be put 
to good use.)

>  - Break the client for people using ancient servers, and who are
>    talking to people without opus support.  ie.  not everyone, but a
>    fair number of people who haven't yet moved, or who can't convince
>    their friends to move yet.  You know the deal there.

Minorly sucks but I see no reasonable alternative.

>  - Most importantly though: minimise the diff that -release need to
>    review when Thorvald gets back and we have a new upload to make
>    once again.
>
> We tossed up which way to go with this (the alternative being to not
> let it migrate and inflict the bigger diff on -release and broken
> server on everyone) - but this seems to be the lesser evil, since it
> will let people get some more testing miles on opus, and people who
> would really be put out by that can just put it on hold for a short
> time.
> 
> Once Thorvald gets back and we re-add speex, this should all work again
> for everyone, and we don't have to kick it out of testing, don't have
> to embed a suspect lib, and shouldn't have to leave anyone feeling
> hard done by ...
> 
> 
> Does that sound ok for you?

Yes it does.  Best suggestion I've heard yet.

> If it does, I'll bump the severity of your bug back down to something
> not RC (but not close it yet, we'll let the speex enabling upload do
> that), and request the release team unblock it.  And if there is no
> further complaint to discuss, then I guess you can tell -ctte you
> have the pound of flesh you sought :)

I appreciate your humor.  ;-)
No objection to the plan.

> Otherwise ...  well, then I don't know what ...  you'll have to
> suggest a plan B all your own, because this is the best we have ...
> 
> All Thorvald asked is that people stay calm, so he can actually worry
> about working on the code rather than being stressed by the drama :)
> 
> 
> I'll make this happen if I get your ACK that it works for you too.

ACK.

Thanks very, very much.

I'll give the security researcher working to audit the celt 0.7.1 codec a 
heads up that Debian is planning to EOL celt altogether, and thank him very 
much for his offer of support.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 05:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 05:51:03 GMT) Full text and rfc822 format available.

Message #104 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>
Cc: debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 01:47:21 -0400
[Message part 1 (text/plain, inline)]
On Thursday, July 19, 2012 19:07:52, Ron wrote:
...
> What we'd like to do in the meantime, is let the mumble version from
> unstable transition to testing now.  That will:
> 
>  - Unbreak the server for everyone, which currently won't work at all.
>  - Break the client for people using ancient servers, and who are
>    talking to people without opus support.  ie.  not everyone, but a
>    fair number of people who haven't yet moved, or who can't convince
>    their friends to move yet.  You know the deal there.

I'm still not opposed to the plan (because I still think it's the best option 
discussed), but I think it might hurt a bit more than perhaps we anticipated 
in the very-short-term before the version of the Mumble client with the Speex 
codec is available.

Test:
   - installed -2 mumble-server from Sid on the server  (this was likely a
     one-way operation, because the version I was previously running is gone
     from the repos)
   - upgraded to the -2 client from Sid on my laptop
   - connected to the server, Opus codec was chosen
   - friend connected from his laptop using Windows Mumble client 1.2.3a
     and was shown an error message stating lack of Opus support, so he
     couldn't talk nor hear.
   - I had the friend upgrade to the developer snapshot 1.2.3-361-ga2a3836
     from the Mumble website and try again -- same message.  So right now
     there is no version of the Mumble client available for Windows (at
     least on the front page of the Mumble website) that supports Opus, or
     if it does it's not compatable with the version of Opus in the -2
     Mumble package in Sid.

   - I disconnected from the server (-2 client) and closed Mumble
   - I reinstalled Mumble from Wheezy (the "348" version of the client that
     is impossible to build today)
   - Connected to the server again and communication works via CELT codec

From this test I draw the following conclusions:
   - the -2 version of mumble-server is safe to migrate to Wheezy,
     no problem there
   - in terms of the mumble client, we'll be relying on getting the
     version with Speex support tested and into Wheezy.  We knew this
     already, but now it's more clear that this will be important even
     for /newer/ versions of the Mumble client.
   - Once -2 of the Mumble client is migrated to Testing we will be
     fully committed to the plan
   - There's some element of time risk involved because Thorvald is
     going to be afk for a week.

I have faith that this will work out, and I also think it's important to 
report these findings so we can all try to understand the scope of the 
problem.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 07:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 07:24:03 GMT) Full text and rfc822 format available.

Message #109 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org
Cc: Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 03:20:24 -0400
[Message part 1 (text/plain, inline)]
On Friday, July 20, 2012 01:47:21, Chris Knadle wrote:
[…]
> From this test I draw the following conclusions:
[…]
>    - Once -2 of the Mumble client is migrated to Testing we will be
>      fully committed to the plan

Update: scratch the above, the "348" version of Mumble in Wheezy as it is now 
won't build anyway, so there's no harm in migrating -2 from Sid

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 07:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicos Gollan <gtdev@spearhead.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 07:39:03 GMT) Full text and rfc822 format available.

Message #114 received at 682010@bugs.debian.org (full text, mbox):

From: Nicos Gollan <gtdev@spearhead.de>
To: 682010@bugs.debian.org
Cc: debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 09:38:00 +0200
Hi,

On Friday 20 July 2012 01:07:52 Ron wrote:
> Once Thorvald gets back and we re-add speex, this should all work again
> for everyone,

The problem with re-enabling speex is that it will not solve the communication 
issue, except under very special circumstances.

That codec was only used in low-bandwidth situations, when a client or the 
server limits bandwidth to ≤32Kb/s, and is not part of the codec selection 
mechanism. That means a client can not advertise speex-only support. Any 
"mainstream" client will still use the baseline codec, a higher CELT version, 
or Opus, if the bandwidth permits. Due to the baseline assumption, speex-only 
clients would again be unable to listen (they would be able to talk though, 
but I'm not sure that kind of one-way communication helps anyone).

Effectively, it would cause a very similar problem, just with a slightly 
different technical background.

Regards,
Nicos



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 11:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 11:45:06 GMT) Full text and rfc822 format available.

Message #119 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>
Cc: debian-ctte@lists.debian.org, Thorvald Natvig <thorvald@debian.org>, 682010@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Fri, 20 Jul 2012 12:41:29 +0100
Ron writes ("Re: mumble and celt, #682010, TC"):
> On Thu, Jul 19, 2012 at 07:18:31PM +0100, Ian Jackson wrote:
> > Since Ron is listed as co-maintainer for mumble do you feel you have
> > the authority to do this ?  I imagine Ron would object, so you would
> > in any case need a TC ruling to arbitrate between you.
> 
> *sigh*  Why would you imagine this?

I imagined you would object because it would amount to undoing a
change that you yourself had made.

Clearly a respectful co-maintainer would not simply undo a change made
by one of their colleagues, at least without discussion.  Particularly
not in a difficult and controversial situation.

> If you have no objection to that, then I guess it's all settled.
> You can put down the Dad Knows Best hat, and leave it to Thorvald and I
> to sort out the details.

Please stop being so rude.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 11:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 11:51:02 GMT) Full text and rfc822 format available.

Message #124 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>
Cc: Chris Knadle <Chris.Knadle@coredump.us>, Thorvald Natvig <thorvald@debian.org>, debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 12:49:03 +0100
Ron writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> If it does, I'll bump the severity of your bug back down to something
> not RC (but not close it yet, we'll let the speex enabling upload do
> that), and request the release team unblock it.

For the avoidance of any doubt:

Please do not take any action intended to move the current version of
mumble in sid to testing, until the TC has concluded its discussions.

In the meantime, I have asked the release team not to accept an
unblock request.

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 11:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 11:57:03 GMT) Full text and rfc822 format available.

Message #129 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us
Cc: Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>, debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 12:54:21 +0100
Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> On Thursday, July 19, 2012 19:07:52, Ron wrote:
> ...
> > What we'd like to do in the meantime, is let the mumble version from
> > unstable transition to testing now.  That will:
> > 
> >  - Unbreak the server for everyone, which currently won't work at all.
> >  - Break the client for people using ancient servers, and who are
> >    talking to people without opus support.  ie.  not everyone, but a
> >    fair number of people who haven't yet moved, or who can't convince
> >    their friends to move yet.  You know the deal there.
> 
> I'm still not opposed to the plan (because I still think it's the
> best option discussed), but I think it might hurt a bit more than
> perhaps we anticipated in the very-short-term before the version of
> the Mumble client with the Speex codec is available.

I'm not sure I follow this conversation but it seems to be a plan to
switch to yet a different codec.

How will this interact with mumble in other distros, who are
presumably following mumble upstream's advice to use celt 0.7.1 as a
baseline ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 12:18:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 12:18:06 GMT) Full text and rfc822 format available.

Message #134 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>, 682010@bugs.debian.org
Cc: debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 08:14:48 -0400
[Message part 1 (text/plain, inline)]
On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the 
TC"):
> > On Thursday, July 19, 2012 19:07:52, Ron wrote:
> > ...
> > 
> > > What we'd like to do in the meantime, is let the mumble version from
> > > 
> > > unstable transition to testing now.  That will:
> > >  - Unbreak the server for everyone, which currently won't work at all.
> > >  - Break the client for people using ancient servers, and who are
> > >  
> > >    talking to people without opus support.  ie.  not everyone, but a
> > >    fair number of people who haven't yet moved, or who can't convince
> > >    their friends to move yet.  You know the deal there.
> > 
> > I'm still not opposed to the plan (because I still think it's the
> > best option discussed), but I think it might hurt a bit more than
> > perhaps we anticipated in the very-short-term before the version of
> > the Mumble client with the Speex codec is available.
> 
> I'm not sure I follow this conversation but it seems to be a plan to
> switch to yet a different codec.

Yes, one that used to be supported in Mumble until recently in low-bandwidth 
situations.

> How will this interact with mumble in other distros, who are
> presumably following mumble upstream's advice to use celt 0.7.1 as a
> baseline ?

According to Nicos in his last email, not well.  The problem with the idea is 
that Speex is not part of the codec selection mechanism in existing clients, 
and will thus cause similar issues.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 12:27:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 12:27:08 GMT) Full text and rfc822 format available.

Message #139 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Chris Knadle <Chris.Knadle@coredump.us>
Cc: debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 21:54:07 +0930
On Fri, Jul 20, 2012 at 01:47:21AM -0400, Chris Knadle wrote:
> I'm still not opposed to the plan (because I still think it's the best option 
> discussed), but I think it might hurt a bit more than perhaps we anticipated 
> in the very-short-term before the version of the Mumble client with the Speex 
> codec is available.
> 
>    - I had the friend upgrade to the developer snapshot 1.2.3-361-ga2a3836
>      from the Mumble website and try again -- same message.  So right now
>      there is no version of the Mumble client available for Windows (at
>      least on the front page of the Mumble website) that supports Opus, or
>      if it does it's not compatable with the version of Opus in the -2
>      Mumble package in Sid.

Making a binary release for windows users is bottlenecked behind Thorvald too
right now.  The problem goes something like this:

 - It can't be installed on windows unless it's been digitally signed by
   some MSFT endorsed signing key.

 - Thorvald is the only person with access to the VM and signing key
   needed for that.

He was going to see if he could find time to whip one of those out before
he left, but otherwise this is about a week away from happening too.

There may be some way that people can build their own from source or
override the 'security' feature on their windows machine to install
one from someone else, but someone who actually uses windows will
probably have to answer that if you need more details.

 Ron


[We might want to avoid cc'ing Thorvald on all of these, unless it's
 actually *really* important for him to see ...  if he has a mountain
 of mail to get through when he gets back, that might not be helpful
 for getting to the code as quickly as he otherwise might ...]




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 12:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 12:33:03 GMT) Full text and rfc822 format available.

Message #144 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Chris Knadle <Chris.Knadle@coredump.us>
Cc: 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 22:02:01 +0930
On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote:
> On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> > Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the 
> TC"):
> > > On Thursday, July 19, 2012 19:07:52, Ron wrote:
> > > ...
> > > 
> > > > What we'd like to do in the meantime, is let the mumble version from
> > > > 
> > > > unstable transition to testing now.  That will:
> > > >  - Unbreak the server for everyone, which currently won't work at all.
> > > >  - Break the client for people using ancient servers, and who are
> > > >  
> > > >    talking to people without opus support.  ie.  not everyone, but a
> > > >    fair number of people who haven't yet moved, or who can't convince
> > > >    their friends to move yet.  You know the deal there.
> > > 
> > > I'm still not opposed to the plan (because I still think it's the
> > > best option discussed), but I think it might hurt a bit more than
> > > perhaps we anticipated in the very-short-term before the version of
> > > the Mumble client with the Speex codec is available.
> > 
> > I'm not sure I follow this conversation but it seems to be a plan to
> > switch to yet a different codec.
> 
> Yes, one that used to be supported in Mumble until recently in low-bandwidth 
> situations.

Yes, it's not a *different* codec.  it is one that was also always supported
prior to that support being removed upstream in the last few weeks.

But I already said this.  Ian, did you not actually read what I already wrote?

> > How will this interact with mumble in other distros, who are
> > presumably following mumble upstream's advice to use celt 0.7.1 as a
> > baseline ?
> 
> According to Nicos in his last email, not well.  The problem with the idea is 
> that Speex is not part of the codec selection mechanism in existing clients, 
> and will thus cause similar issues.

Nicos hasn't talked to Thorvald yet.  The solution to that problem is what
Thorvald will be implementing when he gets back, and he thinks he can do it
in a way that will be backward compatible for all clients.

 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 12:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 12:51:03 GMT) Full text and rfc822 format available.

Message #149 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ron <ron@debian.org>
Cc: 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 08:49:54 -0400
On Friday, July 20, 2012 08:32:01, Ron wrote:
> On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote:
> > On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
[…] 
> > > How will this interact with mumble in other distros, who are
> > > presumably following mumble upstream's advice to use celt 0.7.1 as a
> > > baseline ?
> > 
> > According to Nicos in his last email, not well.  The problem with the
> > idea is that Speex is not part of the codec selection mechanism in
> > existing clients, and will thus cause similar issues.
> 
> Nicos hasn't talked to Thorvald yet.  The solution to that problem is what
> Thorvald will be implementing when he gets back, and he thinks he can do it
> in a way that will be backward compatible for all clients.

Okay.

In his previous email, Nicos pointed me to two functions,

* Server::msgAuthenticate()
* Server::recheckCodecVersions()

Which I'm studying to see if I can figure out what Thorvald might have in 
mind.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 13:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 13:33:03 GMT) Full text and rfc822 format available.

Message #154 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Chris Knadle <Chris.Knadle@coredump.us>
Cc: 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 22:57:56 +0930
On Fri, Jul 20, 2012 at 08:49:54AM -0400, Chris Knadle wrote:
> On Friday, July 20, 2012 08:32:01, Ron wrote:
> > On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote:
> > > On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> […] 
> > > > How will this interact with mumble in other distros, who are
> > > > presumably following mumble upstream's advice to use celt 0.7.1 as a
> > > > baseline ?
> > > 
> > > According to Nicos in his last email, not well.  The problem with the
> > > idea is that Speex is not part of the codec selection mechanism in
> > > existing clients, and will thus cause similar issues.
> > 
> > Nicos hasn't talked to Thorvald yet.  The solution to that problem is what
> > Thorvald will be implementing when he gets back, and he thinks he can do it
> > in a way that will be backward compatible for all clients.
> 
> Okay.
> 
> In his previous email, Nicos pointed me to two functions,
> 
> * Server::msgAuthenticate()
> * Server::recheckCodecVersions()
> 
> Which I'm studying to see if I can figure out what Thorvald might have in 
> mind.

Yes, this is why I noted previously that the absence of Thorvald due to
his other commitments was a major concern that led me to believe we may
be better off with this in bpo, where slow but regular fixes could
continue to trickle in as needed over the life of the release.

It took him about 10 minutes to see a solution that all the other people
currently committing changes upstream couldn't or didn't want to see
over the last few months of discussing this with them.


Anyhow, what are we going to do here now?  The package currently in
testing is 100% unusable for anyone with a server, and Ian is asserting
that he'd rather it stay that way until this yak is fully shaved ...

But I don't see any hair left on it.  We have plan, that seems acceptable
to everyone, and that doesn't actually block any of the Worse Plans from
being dusted off again later if something Really Unexpected again foils
us from the end goal.

What's left to stop us from moving forward with this again now?

 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 14:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 14:24:03 GMT) Full text and rfc822 format available.

Message #159 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us
Cc: Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>, debian-ctte@lists.debian.org, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 15:20:28 +0100
Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> Test:

Thanks.

This:

>    - I had the friend upgrade to the developer snapshot 1.2.3-361-ga2a3836
>      from the Mumble website and try again -- same message.  So right now
>      there is no version of the Mumble client available for Windows (at
>      least on the front page of the Mumble website) that supports Opus, or
>      if it does it's not compatable with the version of Opus in the -2
>      Mumble package in Sid.
> 
>    - I disconnected from the server (-2 client) and closed Mumble
>    - I reinstalled Mumble from Wheezy (the "348" version of the client that
>      is impossible to build today)
>    - Connected to the server again and communication works via CELT codec

Does not appear to be consistent with this:

> From this test I draw the following conclusions:
>    - the -2 version of mumble-server is safe to migrate to Wheezy,
>      no problem there

Since if I read you correctly the -1 .deb works with your friend's
Windows version and the -2 .deb doesn't.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 14:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 14:24:05 GMT) Full text and rfc822 format available.

Message #164 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us
Cc: debian-ctte@lists.debian.org, Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 15:21:17 +0100
Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> On Friday, July 20, 2012 01:47:21, Chris Knadle wrote:
> […]
> > From this test I draw the following conclusions:
> […]
> >    - Once -2 of the Mumble client is migrated to Testing we will be
> >      fully committed to the plan
> 
> Update: scratch the above, the "348" version of Mumble in Wheezy as
> it is now won't build anyway, so there's no harm in migrating -2
> from Sid

Why won't it build ?  It won't build in sid because sid is missing
celt but it will build in wheezy.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 14:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 14:27:03 GMT) Full text and rfc822 format available.

Message #169 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Chris Knadle <Chris.Knadle@coredump.us>, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 15:25:00 +0100
Ron writes ("Bug#682010: re celt and mumble referred to the TC"):
> Making a binary release for windows users is bottlenecked behind Thorvald too
> right now.  The problem goes something like this:

This is not relevant to the discussion here in front of the TC.
Whatever upstream do about Windows binaries, it will take some time
for the deployed base (on Windows and other Free platforms) to be
updated.

We need to ship, in wheezy, a version which is compatible with the
existing deployed base.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 14:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 14:51:06 GMT) Full text and rfc822 format available.

Message #174 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Ron <ron@debian.org>, Thorvald Natvig <thorvald@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 10:46:06 -0400
[Message part 1 (text/plain, inline)]
On Friday, July 20, 2012 10:20:28, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the 
TC"):
> > Test:
> Thanks.
> 
> This:
> >    - I had the friend upgrade to the developer snapshot
> >    1.2.3-361-ga2a3836
> >    
> >      from the Mumble website and try again -- same message.  So right now
> >      there is no version of the Mumble client available for Windows (at
> >      least on the front page of the Mumble website) that supports Opus,
> >      or if it does it's not compatable with the version of Opus in the
> >      -2 Mumble package in Sid.
> >    
> >    - I disconnected from the server (-2 client) and closed Mumble
> >    - I reinstalled Mumble from Wheezy (the "348" version of the client
> >    that
> >    
> >      is impossible to build today)
> >    
> >    - Connected to the server again and communication works via CELT codec
> 
> Does not appear to be consistent with this:
> > From this test I draw the following conclusions:
> >    - the -2 version of mumble-server is safe to migrate to Wheezy,
> >    
> >      no problem there
> 
> Since if I read you correctly the -1 .deb works with your friend's
> Windows version and the -2 .deb doesn't.

Negative.  Let me try to make this clear.

 - the -2 mumble-server from Sid was in use in all cases of this test.
   [And BTW it seems after doing so it is not possible to downgrade
    mumble-server to the version in Squeeze.]

 - the difference as to whether my friend could speak after he
   installed the developer snapshot was whether *I* was using the
   Mumble *client* from Wheezy on my laptop, or the -2 version from Sid.
   The "348" client from Wheezy has CELT support, the -2 client in
   Sid does not.  The -2 "349" version of the client in Sid has Opus
   support (only), the Windows developer snapshot my friend loaded
   does not.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 15:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 15:03:04 GMT) Full text and rfc822 format available.

Message #179 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 682010@bugs.debian.org, Chris Knadle <Chris.Knadle@coredump.us>, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Sat, 21 Jul 2012 00:27:55 +0930
On Fri, Jul 20, 2012 at 03:25:00PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: re celt and mumble referred to the TC"):
> > Making a binary release for windows users is bottlenecked behind Thorvald too
> > right now.  The problem goes something like this:
> 
> This is not relevant to the discussion here in front of the TC.
> Whatever upstream do about Windows binaries, it will take some time
> for the deployed base (on Windows and other Free platforms) to be
> updated.
> 
> We need to ship, in wheezy, a version which is compatible with the
> existing deployed base.

You know, this is getting really frustrating Ian.  If you aren't going
to actually read anything that I write, then perhaps we should find
some other member of the -ctte that isn't so blinkered into arguing
their *own* position, and is more able to absorb and balance the facts
that are being presented here.

The windows release has *nothing* to do with solving the problem here,
that was a simple answer to Chris about why his friend's system did
not yet have Opus support in the binary he downloaded.

The existing deployed base *has* speex support.  The only version
missing that is upstream code from the last few weeks, which is what
Thorvald is going to remedy when he gets back.  That is what we plan
to ship in Wheezy.  That will be compatible with the existing base.

We're not relying on anybody to do anything with windows binaries.

There is nothing here that I have not already said in previous mail,
and you are arguing a straw man now.  Chris, Thorvald and I have
agreed on a plan.  You have, and are, trying to veto that, but have
offered no explanation of your *technical* objection to it.

Please either tell me what your real problem is, or step out of the
way and let us do what is needed to prepare a sane release.

 Thank You,
 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 15:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 15:06:04 GMT) Full text and rfc822 format available.

Message #184 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>
Cc: 682010@bugs.debian.org, Chris Knadle <Chris.Knadle@coredump.us>, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 16:02:04 +0100
Ron writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> You know, this is getting really frustrating Ian.  If you aren't going
> to actually read anything that I write, then perhaps we should find
> some other member of the -ctte that isn't so blinkered into arguing
> their *own* position, and is more able to absorb and balance the facts
> that are being presented here.

Please stop being so rude.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 15:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 15:12:03 GMT) Full text and rfc822 format available.

Message #189 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>
Cc: Chris Knadle <Chris.Knadle@coredump.us>, 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 16:09:43 +0100
Ron writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> What's left to stop us from moving forward with this again now?

Also, please stop trying to bounce us into a decision and other people
into action.  The reason I am insisting on delay is because we (the
TC) want to be sure, before we see people act, that those actions do
not make matters worse.

Just for the avoidance of doubt I would also appreciate it if no-one
would make any uploads of the relevant packages to sid.

In the meantime if we (TC members) don't precisely understand
everything, or sometimes misunderstand your messages, I'm afraid we
will have to ask you to bear with us.

While we are tasked with making decisions in disputed situations, we
are not experts in this (or many other) areas.  So it's going to take
a bit of time.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 15:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 15:21:09 GMT) Full text and rfc822 format available.

Message #194 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, 682010@bugs.debian.org
Cc: Ron <ron@debian.org>
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 11:19:39 -0400
[Message part 1 (text/plain, inline)]
On Friday, July 20, 2012 10:21:17, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the 
TC"):
> > On Friday, July 20, 2012 01:47:21, Chris Knadle wrote:
> > […]
> > 
> > > From this test I draw the following conclusions:
> > […]
> > 
> > >    - Once -2 of the Mumble client is migrated to Testing we will be
> > >    
> > >      fully committed to the plan
> > 
> > Update: scratch the above, the "348" version of Mumble in Wheezy as
> > it is now won't build anyway, so there's no harm in migrating -2
> > from Sid

I'm going to reverse the order of your two questions below.

> It won't build in sid because sid is missing celt but it will build
> in wheezy.

Negative.  It builds fine in Sid, without celt being required.  But because it 
does not use the celt library (regardless of whether it is installed) clients 
cannot voice communicate with any server with connected clients that require 
using anything other than Opus.  Text communication always works.

> Why won't it build ?  

The mumble source pacakge will not build in Wheezy on amd64 due to Wheezy 
getting an upgrade to gcc 4.7 in relation with zero-ice.

Phillip Kern sent the following link to (Bug #675971, msg #131):

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54

On i386 the package does build, but due to ABI breakage in zero-ice, mumble-
server is unable to start and spits out an error on every invocation.

I'm working on getting you a build log from a Wheezy amd64 VM.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 15:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 15:30:03 GMT) Full text and rfc822 format available.

Message #199 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us
Cc: debian-ctte@lists.debian.org, 682010@bugs.debian.org, Ron <ron@debian.org>
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 16:27:08 +0100
Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> On Friday, July 20, 2012 10:21:17, Ian Jackson wrote:
> > Why won't it build ?  
> 
> The mumble source pacakge will not build in Wheezy on amd64 due to Wheezy 
> getting an upgrade to gcc 4.7 in relation with zero-ice.

Oh, right.  This is related to the other changes from -1 to -2.

I assume that we could make, in principle, a -3 which was like -2 but
with celt 0.7.1 reenabled.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 15:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 15:45:03 GMT) Full text and rfc822 format available.

Message #204 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Chris Knadle <Chris.Knadle@coredump.us>, 682010@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Sat, 21 Jul 2012 01:10:51 +0930
On Fri, Jul 20, 2012 at 04:09:43PM +0100, Ian Jackson wrote:
> Ron writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> > What's left to stop us from moving forward with this again now?
> 
> Also, please stop trying to bounce us into a decision and other people
> into action.

The only people who need to take action here are Thorvald and myself.
And we agree on and know what needs to be done.

Which "other people" are you talking about?

>  The reason I am insisting on delay is because we (the
> TC) want to be sure, before we see people act, that those actions do
> not make matters worse.
> 
> Just for the avoidance of doubt I would also appreciate it if no-one
> would make any uploads of the relevant packages to sid.
> 
> In the meantime if we (TC members) don't precisely understand
> everything, or sometimes misunderstand your messages, I'm afraid we
> will have to ask you to bear with us.

I'm well into the second day of 'donating' company time to help you
understand here.

If there are things that you don't understand, please phrase them
as clear questions that can be answered.  That's all I asked.

Without that, I don't really know what we are 'discussing' still,
and you still didn't answer my question about what it is that you
don't understand.

> While we are tasked with making decisions in disputed situations, we
> are not experts in this (or many other) areas.  So it's going to take
> a bit of time.

The 'situation' is no longer disputed afaics.  Everyone except you has
agreed on the best way forward.

I'm serious about it being frustrating that you have taken it upon
yourself to prolong this 'dispute', when everyone else now agrees.

That doesn't seem like the role of an 'arbitrator' to me ...

If you find that rude, then I'm sorry for you.  I find wasting my
time rude too - so please, if there is a chase still to be cut to,
let's cut to it.  The package in testing remains broken for every
extra day we delay this, and there is nothing here that cannot
still be fixed later if we spot a problem in the proposed solution,
or a new problem arises, or a better solution is devised.

 Politely,
 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 16:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 16:15:03 GMT) Full text and rfc822 format available.

Message #209 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 682010@bugs.debian.org, Ron <ron@debian.org>, debian-ctte@lists.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 12:10:21 -0400
[Message part 1 (text/plain, inline)]
On Friday, July 20, 2012 11:27:08, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the 
TC"):
> > On Friday, July 20, 2012 10:21:17, Ian Jackson wrote:
> > > Why won't it build ?
> > 
> > The mumble source pacakge will not build in Wheezy on amd64 due to Wheezy
> > getting an upgrade to gcc 4.7 in relation with zero-ice.
>
> Oh, right.  This is related to the other changes from -1 to -2.

I might be forgetting some facts, but that sounds right.

Build just finished and erred as expected.  I'll give you the tail of the 
file, just let me know if you'd like the entirety.

------------------------------------------

/usr/include/Ice/Handle.h: In instantiation of 
‘IceInternal::Handle<T>::Handle(T*) [with T = Ice::Communicator]’:
/usr/include/Ice/OutgoingAsync.h:49:16:   required from here
/usr/include/Ice/Handle.h:66:13: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the 
point of instantiation [-fpermissive]
compilation terminated due to -Wfatal-errors.
make[3]: *** [release/MurmurIce.o] Error 1
make[3]: Leaving directory `/home/cknadle/src/mumble/mumble-1.2.3-348-
g317f5a0/src/murmur'
make[2]: *** [release] Error 2
make[2]: Leaving directory `/home/cknadle/src/mumble/mumble-1.2.3-348-
g317f5a0/src/murmur'
make[1]: *** [sub-src-murmur-sub_Release_ordered] Error 2
make[1]: Leaving directory `/home/cknadle/src/mumble/mumble-1.2.3-348-
g317f5a0'
make: *** [build-arch-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

------------------------------------------

> I assume that we could make, in principle, a -3 which was like -2 but
> with celt 0.7.1 reenabled.

I should probably examine the Git history, but in priciple I believe it should 
be possible to either make a "348" -2 with backported zero-ice ABI fixes and 
hardcoding use of gcc 4.6, or a "349" -3 with added libcelt support.

However if we decide to go in this direction while upstream plans to re-enable 
Speex, we should probably also consider whether to try to re-enable Speex for 
interoperability.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 16:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicos Gollan <gtdev@spearhead.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 16:54:03 GMT) Full text and rfc822 format available.

Message #214 received at 682010@bugs.debian.org (full text, mbox):

From: Nicos Gollan <gtdev@spearhead.de>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: re celt and mumble referred to the TC
Date: Fri, 20 Jul 2012 18:51:52 +0200
Hi,

On Friday 20 July 2012 17:40:51 Ron wrote:
> The 'situation' is no longer disputed afaics.  Everyone except you has
> agreed on the best way forward.

No. There may be a solution that Thorvald/slicer supposedly came up with. If 
it turns out to work, super. It would make the debian-supplied client 
compatible with everyone else (probably at the cost of degrading audio quality 
for everyone happening to talk to one, but we are talking about less than a 
percent of the userbase here, so the chance of that happening is pretty slim).

Until that solution has been presented and validated, nothing can be decided. 
IMAO, the sane way forward would be to wait for said solution to emerge. There 
are now several people, including the main upstream contributor, who are 
curious how it will work.

Regards,
Nicos



Summary recorded from message bug 682010 message 215 Request was from Don Armstrong <don@debian.org> to control@bugs.debian.org. (Fri, 20 Jul 2012 18:54:08 GMT) Full text and rfc822 format available.

Set Bug forwarded-to-address to 'http://git.donarmstrong.com/?p=debian-ctte.git;a=blob;f=682010_celt_and_mumble/682010_celt_and_mumble.org'. Request was from Don Armstrong <don@debian.org> to control@bugs.debian.org. (Fri, 20 Jul 2012 18:54:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 19:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 19:00:03 GMT) Full text and rfc822 format available.

Message #223 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 682010@bugs.debian.org
Cc: Chris.Knadle@coredump.us, Ron <ron@debian.org>, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 11:50:16 -0700
summary 682010 0
forwarded 682010 http://git.donarmstrong.com/?p=debian-ctte.git;a=blob;f=682010_celt_and_mumble/682010_celt_and_mumble.org
thanks

* Issue #682010
** Mumble in unstable/testing currently cannot interact with other clients and servers
   + Due to the removal of celt 0.7.1 (?)
* Possible solutions
** Include celt 0.7.1 as a convenience copy
   + Security Issues with embedded copies
   + Unspecified possible security issues
** Upload a celt 0.7.1 package
   + No maintainer desires to deal with this (apparently?)
   + Unspecified possible security issues
** Use speex instead
   + Server (and clients?) do not select speex as an option unless bandwidth is low
** Use only opus
   + Not yet (?) released upstream
   + May not communicate with non-opus clients
* Open questions
** Can speex be made to be an option?
** Is a convenience copy acceptable, assuming mumble is the only thing with it?
** What are the other clients that we want to make sure the mumble servers can communicate with?
* Involved parties
** Chris.Knadle@coredump.us, Ron <ron@debian.org>, 682010@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>

The above is my current understanding of this bug. Please correct
anything that I've gotten wrong or misunderstood or missed.


Don Armstrong

-- 
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

http://www.donarmstrong.com              http://rzlab.ucr.edu



Removed summary Request was from Don Armstrong <don@debian.org> to control@bugs.debian.org. (Fri, 20 Jul 2012 20:15:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 20:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 20:57:05 GMT) Full text and rfc822 format available.

Message #230 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: 682010@bugs.debian.org, Chris.Knadle@coredump.us, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sat, 21 Jul 2012 06:24:38 +0930
Thanks Don,

I've dropped Thorvald from the CC list, because he's on VAC for a week,
and wasn't looking forward to coming back to a mailbox full of stress.
If others would be good enough to do the same, I'm sure he can more
quickly come up to speed with whatever summary we've got when he's back.
It's all in the BTS log if he needs to dig deeper than that.


On Fri, Jul 20, 2012 at 11:50:16AM -0700, Don Armstrong wrote:
> summary 682010 0
> forwarded 682010 http://git.donarmstrong.com/?p=debian-ctte.git;a=blob;f=682010_celt_and_mumble/682010_celt_and_mumble.org
> thanks
> 
> * Issue #682010
> ** Mumble in unstable/testing currently cannot interact with other clients and servers
>    + Due to the removal of celt 0.7.1 (?)

     Due to Debian and the Xiph authors dropping celt,
     and mumble dropping speex in the unstable version.

> * Possible solutions
> ** Include celt 0.7.1 as a convenience copy
>    + Security Issues with embedded copies
>    + Unspecified possible security issues

     Embedding a copy doesn't add to the baseline risk here, since mumble
     is the only thing with any excuse at all to still be using celt today.
     It actually minimises the risk, because then only mumble can be exposed.

     This was the original plan we (Thorvald and I) made before the squeeze
     release, since celt being obsoleted by a final bitstream stable codec
     for all other users was a known future at that time.  Mumble also
     planned to drop it too, but that was going to take longer to do, so
     this was the transition period solution for it.

     What stopped that plan from going to plan was the advice received about
     a potential remote crasher, and the total absence of anyone prepared to
     take responsibility for continuing 'upstream' maintenance of celt.

> ** Upload a celt 0.7.1 package
>    + No maintainer desires to deal with this (apparently?)
>    + Unspecified possible security issues

     It's not so much a "lack of desire" as an explicit (and reasonable IMO)
     request from the celt authors that we no longer distribute this obsolete
     version in a way that might cause confusion about whether it should be
     used by new or current projects (which it should not, since it is
     bitstream and API incompatible with versions shipped by all other distros).

     The only thing with a valid reason to still use it at all is mumble,
     because it specified it as the default high bandwidth codec for use
     in its private protocol, and is not required to be interoperable
     with any other application.  As the only user, it doesn't need a
     public dev package, or separate lib for this.  On every other distro
     except Debian, mumble already builds using its own embedded version
     (since no other distro shipped 0.7.1 or a version compatible with it).

> ** Use speex instead
>    + Server (and clients?) do not select speex as an option unless bandwidth is low

     Speex (and Opus) are much lower bandwidth codecs than celt.  If the
     configured bitrate is above 32kb/s then pre-opus mumble will prefer
     to use celt.  This limitation is what Thorvald thinks he can remove
     when he gets back, in a way that will be backward compatible for all
     clients.  If that works as expected, then speex is a viable (and also
     maintained) baseline codec for people without Opus.

> ** Use only opus
>    + Not yet (?) released upstream
>    + May not communicate with non-opus clients

     Just in case the distinction isn't clear, Opus itself is released.
     (since there was some FUD earlier about that).  A good summary of
     its current status can be found here:
     http://hacks.mozilla.org/2012/07/firefox-beta-15-supports-the-new-opus-audio-format/

     The code to enable using Opus is available in mumble's git repo.
     A formal release of that is bottlenecked behind Thorvald being
     available, but he said he plans to do that when he gets back
     next week too.  That's mostly only an issue for windows users.

     All clients need Opus in this case.  There are released servers that
     already support this (since the server doesn't need explicit codec
     support, only some protocol tweaks which were done a while back)
     but the server version in squeeze is apparently too old for that.

> * Open questions
> ** Can speex be made to be an option?
> ** Is a convenience copy acceptable, assuming mumble is the only thing with it?
> ** What are the other clients that we want to make sure the mumble servers can communicate with?
> * Involved parties
> ** Chris.Knadle@coredump.us, Ron <ron@debian.org>, 682010@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>
> 
> The above is my current understanding of this bug. Please correct
> anything that I've gotten wrong or misunderstood or missed.


I think that's roughly right.  If there's anything more people need
clarified or answered, just ask.

The plan from yesterday, which seemed to have agreement from everyone
but Ian is here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#94

And I'm still not quite clear what his objection was, because the
response I got was:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124

And I wasn't able to elicit what else he was actually concerned about,
but if there is something we missed, I do really want to know about it.


  Cheers,
  Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 21:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 21:42:02 GMT) Full text and rfc822 format available.

Message #235 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Subject: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 17:37:59 -0400
[Message part 1 (text/plain, inline)]
Diff for summary attached.

Thanks to Don Armstrong

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[682010_celt_and_mumble.org (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 21:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 21:51:06 GMT) Full text and rfc822 format available.

Message #240 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 682010@bugs.debian.org
Cc: Ron <ron@debian.org>, Chris.Knadle@coredump.us, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 14:48:07 -0700
I've updated the summary with the suggested changes (at the end).

On Sat, 21 Jul 2012, Ron wrote:
> I think that's roughly right. If there's anything more people need
> clarified or answered, just ask.

[...]

> And I'm still not quite clear what his objection was, because the
> response I got was:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124

The objection is that the issue has been raised before the CTTE, so it
needs to be resolved first before action is taken. From what I
understand now, while we could fix up some of the RC issues with the
client/server in testing and unstable, we'd need yet another upload of
mumble to unstable with propagation to testing in order to actually
fix the client inter-operation bug.

From what I can tell now, the ideal solution is to wait until Thorvald
has a chance to enable speex for all bandwidths. If that is
impractical/impossible then we get to choose between a convenience
copy of celt, not releasing mumble, or releasing with opus. Is that
the understanding of everyone else?


* Issue http://bugs.debian.org/682010 http://bugs.debian.org/675971
** Mumble in unstable/testing currently cannot interact with other clients and servers
   + Due to the removal of celt http://bugs.debian.org/676592 and disabling of celt compilation options
   + Mumble dropping speex in unstable and speex not being selected at higher bandwidths
   + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971#51
   + Interoperation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971#61
* Possible solutions
** Use speex instead
   + Server (and clients?) do not select speex as an option unless bandwidth is low
     + May be resolved by Thorvald Natvig with a hack
   + Clients cannot currently report speex version during codec selection process
   + Requires code modification for selection process and re-enabling speex
** Include celt 0.7.1 as a convenience copy
   + Security Issues with embedded copies
     + Mitigated as mumble would have the only copy
   + Unspecified possible security issues
     + Potential remote crasher
   + -348 is currently this way in testing
** Do not release with mumble
   + Unsatisfactory to users of mumble
** Upload a celt 0.7.1 package
   + No maintainer desires to deal with this (apparently?)
   + Upstream do not wish additional packages to use celt; wish transition to opus
   + Unspecified possible security issues
   + Proliferates celt library downstream
   + Deprecated upstream
** Use only opus
   + Opus itself released upstream
   + Code to enable opus in mumble has not been released
   + Will not communicate with non-opus clients or servers
   + Unlikely to be RM acceptable at this point
* Open questions
** Can speex be made to be an option?
   + Thorvald thinks so; no patch as of yet (off for a week?)
** Is a convenience copy acceptable, assuming mumble is the only thing with it?
   + Possible remote crasher bug is the primary objection to allowing this
** What are the other clients that we want to make sure the mumble servers can communicate with?
|--------------------+----------------------+----------------+-----------+-----------|
| client/server      | Deb 1.2.2-6+squeeze1 | Deb 1.2.3-2+b2 | Deb "348" | Deb "349" |
|--------------------+----------------------+----------------+-----------+-----------|
| Deb. Client "348"  | Yes                  | Yes            | Yes       | Yes       |
| Deb. Client "349"  | No                   | No             | Yes       | Yes       |
| Win. Client 1.2.3a | Yes                  | Yes            | Yes       | Yes       |
| Win. Client "361"  | Yes                  | Yes            | Yes       | Yes       |
| Mac  Client 1.2.2  | Yes                  | Yes            | Yes       | Yes       |
|--------------------+----------------------+----------------+-----------+-----------|
* Resolutions
* Involved parties
** Chris.Knadle@coredump.us, Ron <ron@debian.org>, 682010@bugs.debian.org, 675971@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>


Don Armstrong

-- 
Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 22:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 22:15:05 GMT) Full text and rfc822 format available.

Message #245 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Don Armstrong <don@debian.org>
Cc: 682010@bugs.debian.org, Ron <ron@debian.org>, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 18:12:43 -0400
On Friday, July 20, 2012 17:48:07, Don Armstrong wrote:
> I've updated the summary with the suggested changes (at the end).

Please note that the table I had previously published to the original bug is 
informative for when "server loopback" works when there is only a *single* 
client connected.  It doesn't take into account situations when an opus-only 
client and an non-opus client are both connected, in which case [audio] 
communication always fails for one or more parties, depending on which codec 
the server decides all clients must use.  [It would be helpful to make a note 
of this above or below the table in the summary.  Thanks.]

> On Sat, 21 Jul 2012, Ron wrote:
> > I think that's roughly right. If there's anything more people need
> > clarified or answered, just ask.
> 
> [...]
> 
> > And I'm still not quite clear what his objection was, because the
> > response I got was:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124
> 
> The objection is that the issue has been raised before the CTTE, so it
> needs to be resolved first before action is taken. From what I
> understand now, while we could fix up some of the RC issues with the
> client/server in testing and unstable, we'd need yet another upload of
> mumble to unstable with propagation to testing in order to actually
> fix the client inter-operation bug.

Additionally I think it's best to show respect and use patience.  It's a 
difficult and complicated problem that we're all trying to help each other 
with.

> From what I can tell now, the ideal solution is to wait until Thorvald
> has a chance to enable speex for all bandwidths. If that is
> impractical/impossible then we get to choose between a convenience
> copy of celt, not releasing mumble, or releasing with opus. Is that
> the understanding of everyone else?

I believe this is correct.  Thats 4 options, each of which have their own set 
of issues.


Re: summary:

Two lines are duplicated:

[…]
11  + Clients cannot currently report speex version during codec selection 
process
[…]
14 + Clients cannot currently report speex version during codec selection 
process



Additional items:
  "348" package in Wheezy will not build on amd64; zero-ice + gcc 4.7
       http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54
  "348" mumble-server will not start due to zero-ice ABI breakage



Otherwise it looks good to me.
Thanks a lot, Don.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 23:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 23:15:05 GMT) Full text and rfc822 format available.

Message #250 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: 682010@bugs.debian.org, Chris.Knadle@coredump.us, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sat, 21 Jul 2012 08:41:10 +0930
On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
> I've updated the summary with the suggested changes (at the end).
> 
> On Sat, 21 Jul 2012, Ron wrote:
> > I think that's roughly right. If there's anything more people need
> > clarified or answered, just ask.
> 
> [...]
> 
> > And I'm still not quite clear what his objection was, because the
> > response I got was:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124
> 
> The objection is that the issue has been raised before the CTTE, so it
> needs to be resolved first before action is taken.

That part I understand.  It was the what still needs to be resolved if
all the parties agreed on a solution part that I was still in the dark
about mostly ...

> From what I
> understand now, while we could fix up some of the RC issues with the
> client/server in testing and unstable, we'd need yet another upload of
> mumble to unstable with propagation to testing in order to actually
> fix the client inter-operation bug.

Yes, that's correct.  Whatever Thorvald comes up with will require
another upload.

> From what I can tell now, the ideal solution is to wait until Thorvald
> has a chance to enable speex for all bandwidths. If that is
> impractical/impossible then we get to choose between a convenience
> copy of celt, not releasing mumble, or releasing with opus. Is that
> the understanding of everyone else?

Yes, that's pretty much how I see what our choices are, unless Thorvald
thinks of something entirely different again when he looks into the
first option.  We only got to talk through this very briefly before he
had to leave, but he was fairly confident, and he's on the short list
of people whose ability and confidence I've found tend to be fairly
reliably well correlated, so we'll see ...


Which really only leaves me with the question of what do we do today.

Right now the server in testing is completely broken if we don't let
the unstable version which fixes that migrate.  If that stays blocked
until we have Thorvald's fix, we're looking at it being broken for
a week until he gets back, a few days to a week until he has a patch
he's happy with, 10 days before it's eligible to transition, and a
bigger patch for -release to review before they consider unblocking it.

So it will be broken for somewhere from a couple of weeks to a month,
depending on who works how fast and whether -release would be willing
to age it in faster.

If we let the current unstable version transition today, we mitigate
those two things, and it doesn't change anything about our ability
to fall back to the plan B set, if that turns out to be needed.


I'm not too fussed either way to be honest.  It's extra work and
inconvenience for people _other_ than me if it isn't allowed to
migrate now.  But whether it can is out of my hands at present,
since TC put a block on the RMs unblocking it, and I haven't asked
the RMs for their preference yet because of the TC stop work order.

I'm fine with this issue being left open with the TC until its
final resolution independently of that though.  I don't see these
things as being tightly order dependent.  Either way there is work
and uploads to be done before we have our final answers for Wheezy.


One very last thing then, before I hopefully stop bothering you
for a while (:

> ** Use speex instead
>    + Clients cannot currently report speex version during codec selection process

I don't understand where that issue came from?
Speex has been API and bitstream compatible since, like 2006, or maybe before.

Maybe I totally misunderstand what that's saying, but anything relying on
a "speex version" is almost surely Doing It Wrong.

It's probably not important, I'm just not sure who is actually confused there.


  Thanks Much!
  Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 20 Jul 2012 23:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 20 Jul 2012 23:27:06 GMT) Full text and rfc822 format available.

Message #255 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Ron <ron@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 16:24:17 -0700
On Sat, 21 Jul 2012, Ron wrote:
> One very last thing then, before I hopefully stop bothering you for
> a while (:
> 
> > ** Use speex instead
> >    + Clients cannot currently report speex version during codec selection process
> 
> I don't understand where that issue came from?
> Speex has been API and bitstream compatible since, like 2006, or maybe before.
> 
> Maybe I totally misunderstand what that's saying, but anything relying on
> a "speex version" is almost surely Doing It Wrong.

Chris asked for this to be added IIRC; I believe[1] that this should
really be "currently report speex support" rather than "speex
version".
 

Don Armstrong

1: Hopefully I'll be corrected if I'm wrong; it's likely that I
introduced the incorrect wording too.
-- 
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

http://www.donarmstrong.com              http://rzlab.ucr.edu



Message sent on to Chris.Knadle@coredump.us:
Bug#682010. (Fri, 20 Jul 2012 23:45:18 GMT) Full text and rfc822 format available.

Message #258 received at 682010-submitter@bugs.debian.org (full text, mbox):

From: Patrick Matthäi <pmatthaei@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Thorvald Natvig <thorvald@natvig.com>, debian-ctte@lists.debian.org, 682010-submitter@bugs.debian.org
Subject: Re: mumble and celt, #682010, TC
Date: Sat, 21 Jul 2012 01:33:54 +0200
Am 20.07.2012 13:38, schrieb Ian Jackson:
> Thorvald Natvig writes ("Re: mumble and celt, #682010, TC"):
>> Judging from what little I can find of discussions and changelogs, I do
>> find it likely Ron will object to being forced to re-enable CELT when he
>> strongly believes it should be disabled. At that point, this boils down
>> more to a resource question than a "who is right" question; I have
>> severely limited spare time for new next few months, and if Patrick has
>> already withdrawn from this package, the only remaining short-term
>> maintainer is Ron, meaning his decision will stand as he is the one
>> actually doing things.

That is right Thorvald and I am sorry about this situation, but..

>
> I think this version of mumble is not fit for release, and I think the
> RMs agree.

At the current stage I also would suggest to remove it from Wheezy, as 
Ian and Chris suggested.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sat, 21 Jul 2012 01:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 21 Jul 2012 01:39:03 GMT) Full text and rfc822 format available.

Message #263 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sat, 21 Jul 2012 11:05:56 +0930
On Fri, Jul 20, 2012 at 06:12:43PM -0400, Chris Knadle wrote:
> On Friday, July 20, 2012 17:48:07, Don Armstrong wrote:
> > I've updated the summary with the suggested changes (at the end).
> 
> Please note that the table I had previously published to the original bug is 
> informative for when "server loopback" works when there is only a *single* 
> client connected.  It doesn't take into account situations when an opus-only 
> client and an non-opus client are both connected, in which case [audio] 
> communication always fails for one or more parties, depending on which codec 
> the server decides all clients must use.  [It would be helpful to make a note 
> of this above or below the table in the summary.  Thanks.]

Sorry to keep this going with one more message, but since it seems apropos
to the question of building an accurate table of where we might expect
compatibility, and the earlier question of what people use on Ubuntu and
other derivatives:


06:44 < HTT-Bird> I have Mint 9 LTS (based on Ubuntu 10.04 LTS) on this computer
                  and Mumble 1.2.3 (from a PPA), but Ubuntu doesn't provide a CELT
                  version newer than 0.7.1 and I am trying to connect to a Mumble
                  server that requires 0.11.0
06:44 < HTT-Bird> what am I to do?
06:46 <@pcgod> rebuild the client with bundled-celt enabled...
06:48 < HTT-Bird> pcgod: *sigh* :< (I have built things from source, but cluttering up
                  what isn't supposed to be a devbox with -dev packages isn't so hot)


So it would appear that shipping with celt 0.7.1 support is actually
not sufficient on its own for people to communicate with the existing
deployed base, and this is the advice people are given in those cases,
by the developer who disabled the speex support ...

That was an exchange from today, which I only saw just now.


 Like this wasn't complicated enough already,
 Ron  :/





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sat, 21 Jul 2012 02:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 21 Jul 2012 02:24:03 GMT) Full text and rfc822 format available.

Message #268 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Don Armstrong <don@debian.org>, 682010@bugs.debian.org
Cc: Ron <ron@debian.org>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 22:20:37 -0400
On Friday, July 20, 2012 19:24:17, Don Armstrong wrote:
> On Sat, 21 Jul 2012, Ron wrote:
> > One very last thing then, before I hopefully stop bothering you for
> > 
> > a while (:
> > > ** Use speex instead
> > > 
> > >    + Clients cannot currently report speex version during codec
> > >    selection process
> > 
> > I don't understand where that issue came from?
> > Speex has been API and bitstream compatible since, like 2006, or maybe
> > before.
> > 
> > Maybe I totally misunderstand what that's saying, but anything relying on
> > a "speex version" is almost surely Doing It Wrong.
> 
> Chris asked for this to be added IIRC; I believe[1] that this should
> really be "currently report speex support" rather than "speex
> version".

Yes I think the above wording is better.  I was reading code where several 
versions of CELT are reported and versions compared -- and since there isn't 
any code for reporting speex availability, I made an assumption as to how that 
would theoretically be handled.

> Don Armstrong
> 
> 1: Hopefully I'll be corrected if I'm wrong; it's likely that I
> introduced the incorrect wording too.

With a list of complications this long, something will end up being worded 
wrong.  ;-)

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information stored :
Bug#682010; Package tech-ctte. (Sat, 21 Jul 2012 02:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and filed, but not forwarded. (Sat, 21 Jul 2012 02:27:03 GMT) Full text and rfc822 format available.

Message #273 received at 682010-quiet@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ron <ron@debian.org>
Cc: 682010-quiet@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 22:01:00 -0400
On Friday, July 20, 2012 19:11:10, Ron wrote:
> On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
[…]
> One very last thing then, before I hopefully stop bothering you
> 
> for a while (:
> > ** Use speex instead
> > 
> >    + Clients cannot currently report speex version during codec selection
> >    process
> 
> I don't understand where that issue came from?
> Speex has been API and bitstream compatible since, like 2006, or maybe
> before.

I added this based on Nicos's comments in msg #114.  I agree I misworded it; I 
had been looking at code concerning available CELT versions, and mentally 
merged those two things when I wrote the blurb.  The original statement:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#114

> Maybe I totally misunderstand what that's saying, but anything relying on
> a "speex version" is almost surely Doing It Wrong.
> 
> It's probably not important, I'm just not sure who is actually confused
> there.

Well now you know.  ;-)

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sat, 21 Jul 2012 06:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 21 Jul 2012 06:51:03 GMT) Full text and rfc822 format available.

Message #278 received at 682010@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 682010@bugs.debian.org, Ron <ron@debian.org>, Chris.Knadle@coredump.us, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Fri, 20 Jul 2012 23:42:43 -0700
[Message part 1 (text/plain, inline)]
On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
> I've updated the summary with the suggested changes (at the end).

From the BTS, it doesn't look to me like this summary has taken?

> On Sat, 21 Jul 2012, Ron wrote:
> > I think that's roughly right. If there's anything more people need
> > clarified or answered, just ask.

> > And I'm still not quite clear what his objection was, because the
> > response I got was:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124

> The objection is that the issue has been raised before the CTTE, so it
> needs to be resolved first before action is taken.

If the original petitioner is satisfied with the solution and no longer
feels the need to involve the TC, I don't see any reason for the TC to
remain involved.  Certainly historically, we have considered our job done
once there's no longer a dispute that someone wants escalated to the
committee.  It's not at all our charter to fix all the bad bugs, only to
adjudicate when consensus can't be reached on its own.  If Chris and Ron
*are* working together now towards an agreed solution, I'd much prefer that
we let them get on with it.

It may be that it's Ian's intention to take up this issue in Chris's stead
because he himself thinks there's a problem that he wants to put before the
TC.  That's fine too, but I think in that case, Ian, you should state this
explicitly (and, logically, recuse yourself from voting on it under 6.1.2,
6.1.3, or 6.1.4 since you're then a party to the disagreement).

> From what I understand now, while we could fix up some of the RC issues
> with the client/server in testing and unstable, we'd need yet another
> upload of mumble to unstable with propagation to testing in order to
> actually fix the client inter-operation bug.

> From what I can tell now, the ideal solution is to wait until Thorvald
> has a chance to enable speex for all bandwidths. If that is
> impractical/impossible then we get to choose between a convenience
> copy of celt, not releasing mumble, or releasing with opus. Is that
> the understanding of everyone else?

From what I've read here, I don't think there are *any* ideal solutions.  We
cannot retroactively cause all deployed clients on other OSes (or on other
versions of our own OS) be willing to negotiate a codec they don't already
negotiate; all clients on a given server must use the same codec to talk to
each other; and the set of codecs supported by all clients appears to be the
empty set, unless we want to all agree to use an obsolete experimental codec
which suffers from serious non-theoretical security issues.

So I'm really not sure why it's useful for the TC to be debating which of
the bad options we consider least bad.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sat, 21 Jul 2012 19:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 21 Jul 2012 19:51:03 GMT) Full text and rfc822 format available.

Message #283 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Steve Langasek <vorlon@debian.org>, 682010@bugs.debian.org, Ron <ron@debian.org>, Nicos Gollan <gtdev@spearhead.de>, Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sat, 21 Jul 2012 15:46:34 -0400
[Message part 1 (text/plain, inline)]
On Saturday, July 21, 2012 02:42:43, Steve Langasek wrote:
> On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
> > I've updated the summary with the suggested changes (at the end).
> 
> From the BTS, it doesn't look to me like this summary has taken?
> 
> > On Sat, 21 Jul 2012, Ron wrote:
> > > I think that's roughly right. If there's anything more people need
> > > clarified or answered, just ask.
> > > 
> > > And I'm still not quite clear what his objection was, because the
> > > response I got was:
> > > 
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124
> > 
> > The objection is that the issue has been raised before the CTTE, so it
> > needs to be resolved first before action is taken.
> 
> If the original petitioner is satisfied with the solution and no longer
> feels the need to involve the TC, I don't see any reason for the TC to
> remain involved.  Certainly historically, we have considered our job done
> once there's no longer a dispute that someone wants escalated to the
> committee.  It's not at all our charter to fix all the bad bugs, only to
> adjudicate when consensus can't be reached on its own.  If Chris and Ron
> *are* working together now towards an agreed solution, I'd much prefer that
> we let them get on with it.

The issue I have now is that The Plan that Ron and Thorvald have come up with 
Will Not Work, depending what the _goal_ is.  If the goal is to be able to 
interoperate with the existing *server* base [which was exactly why this came 
to the TC in the first place], that won't be possible -- because the Speex 
codec up to this point is not part of the selection process in the existing 
servers.  [1]  [Special thanks goes to Nicos for watching our backs here.]  In 
terms of existing servers, this would in effect be equal to the "only use 
Opus" option that currently exists in Sid right now, which is unable to 
interoperate _at all_ with every available version of the client on at least 
one platform.  I'm pretty sure it's not a viable option.

So while I was initially enamored with The Plan, I'm now back to being 
concerned after looking at the code Nicos pointed me to. [2]  I think it's 
clear now that we need to explicitly check with him on the proposed solutions, 
because he's consistently given sage technical advice in this matter.

So I wish we were done with the TC, but I don't think we are -- this is a 
really tough problem.  Right now I think if we want to be fully interoperable, 
we're going to require embedded celt -- I don't like this alternative either, 
but AFAIK it's what the other distros are doing, and the alternative of 
continuing to use the celt 0.7.1 library is likely to be deemed just too 
heinous and evil because we really need to stop proliferating it if at all 
possible.

Nicos -- let me know what you think.

> It may be that it's Ian's intention to take up this issue in Chris's stead
> because he himself thinks there's a problem that he wants to put before the
> TC.  That's fine too, but I think in that case, Ian, you should state this
> explicitly (and, logically, recuse yourself from voting on it under 6.1.2,
> 6.1.3, or 6.1.4 since you're then a party to the disagreement).

I think Ian saw that I was too enthralled and that I jumped to conclusions, 
and put things on hold to give time for a sanity check.  I commend him for 
doing that as I think that's generally wise, especially where the author for 
the solution was going to be away for a week.  Additionally as Ian took the 
lead on this problem, I really don't want to commit to go off and take action 
without his input -- that definitely wouldn't seem right to me.

> > From what I understand now, while we could fix up some of the RC issues
> > with the client/server in testing and unstable, we'd need yet another
> > upload of mumble to unstable with propagation to testing in order to
> > actually fix the client inter-operation bug.
> > 
> > From what I can tell now, the ideal solution is to wait until Thorvald
> > has a chance to enable speex for all bandwidths. If that is
> > impractical/impossible then we get to choose between a convenience
> > copy of celt, not releasing mumble, or releasing with opus. Is that
> > the understanding of everyone else?
> 
> From what I've read here, I don't think there are *any* ideal solutions. 
> We cannot retroactively cause all deployed clients on other OSes (or on
> other versions of our own OS) be willing to negotiate a codec they don't
> already negotiate; all clients on a given server must use the same codec
> to talk to each other; and the set of codecs supported by all clients
> appears to be the empty set, unless we want to all agree to use an
> obsolete experimental codec which suffers from serious non-theoretical
> security issues.
> 
> So I'm really not sure why it's useful for the TC to be debating which of
> the bad options we consider least bad.

There isn't much choice, as lack of interoperability was why the matter was 
brought to the TC, and the action chosen directly affects interoperability.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#114

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#42

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sun, 22 Jul 2012 08:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 22 Jul 2012 08:39:03 GMT) Full text and rfc822 format available.

Message #288 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sun, 22 Jul 2012 18:05:00 +0930
On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
> The issue I have now is that The Plan that Ron and Thorvald have come up with 
> Will Not Work, depending what the _goal_ is.  If the goal is to be able to 
> interoperate with the existing *server* base [which was exactly why this came 
> to the TC in the first place], that won't be possible -- because the Speex 
> codec up to this point is not part of the selection process in the existing 
> servers.

I am 110% certain that Thorvald is not going to accept any solution that he
thinks can't be made to work for the vast majority of users.  That was the
crux of our conversation last week, and something which he has always been
unwavering about.  We have had many such conversations in the past, trying to
reconcile the, uh, idiosyncrasies, of gamers with best practice for Debian.

What you seem to have failed to note, or that Nicos has failed to tell you,
is that Speex is not included in the server side negotiation because it is
assumed axiomatically that *every* client has speex decoding ability.  So
it does not need to be negotiated.  You can send it at any time, and it will
work, without needing to be announced in advance, or the server needing to
do anything.

That point is currently still true.  Every existing client has the ability
to *decode* speex if speex packets arrive.

The only thing removed from recent clients was the ability to encode them.
This is what we need to restore.


> [Special thanks goes to Nicos for watching our backs here.]

Just to be clear here, because at some point Ian described Nicos as being
"a mumble developer", and you have now declared him a "sage" ...

$ git log master | wc -l
30363

$ git log master | grep Nicos | wc -l
12

And all of those commits afaics relate to GUI overlay stuff for games,
nothing at all to do with the protocol negotiation we are talking about
here ...   So I think I'd still rather put my trust in the the opinion
of Thorvald about what can be made to work, than in someone who has said
repeatedly, "Debian should just remove this, nobody cares because nobody
uses Debian anyhow".  Which is also clearly quite incorrect, or we wouldn't
be having this discussion at all.


The current facts are:

 - The server is currently 100% broken in testing, and will remain so
   for our users for as long as this is blocked here.

 - Thorvald has a plan that nobody here had thought of or considered
   previously.  We can't assess that until he gets back and implements
   it - but second guessing him here in the meantime is only going to
   waste his time with more mail to read before he gets to doing that.
   And his time is already very limited.

 - If that plan doesn't work, we have other plans we can weigh up
   falling back to.

 - If we have to fall back to those plans, and -ctte wants to assert
   that it would rather Debian ship an unmaintained codec, which nobody
   has spent more than a couple of hours quickly auditing for obvious
   problems, but which does have a real suspicion of deep problems ...

   Then provided we have a clear public record of the people wanting
   that putting *their* own heads on the block, and taking the full
   responsibility for any fall out or required remedy -- then I have
   clean hands, and someone to point at who is completely to blame for
   an action I advised against in the event it goes Horribly wrong.

   If the people wanting that can get the consensus of the TC (and
   I would much rather see this as an even informal consensus than
   than as a formal but narrowly won vote), then I'll set my own
   objection aside and we'll let history and fate be the judge.

Worrying about things that we aren't precluding as fallback options
before we've confirmed we do need to fall back to them doesn't seem
particularly productive to me though.  I think Steve pretty accurately
spotted there are _no_ ideal solutions here.  Hopefully mumble will
improve on these things too and this will be less of a problem for
Wheezy+1, but in the meantime I think we need to balance the amount
of inconvenience some users might experience (which seems unavoidable
whatever we do) against the amount of risk we are prepared to expose
them to (which seems quite avoidable).


The weekend here is nearly over, and I can't keep stealing time from
my Work customers to keep discussing this in circles next week (and
I'm sure many others here are in the same position).

The longer we draw this out, the less testing any of it is going to
have, the less time is going to be available to fix any shortcomings
that we haven't so far seen, and the poorer the result that we are
ultimately going to end up with.

 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sun, 22 Jul 2012 22:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 22 Jul 2012 22:36:03 GMT) Full text and rfc822 format available.

Message #293 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Cc: debian-ctte@lists.debian.org, Ron <ron@debian.org>, Nicos Gollan <gtdev@spearhead.de>, Thorvald Natvig <thorvald@natvig.com>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sun, 22 Jul 2012 18:31:27 -0400
[Message part 1 (text/plain, inline)]
On Sunday, July 22, 2012 04:35:00, Ron wrote:
> On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
...
> > [Special thanks goes to Nicos for watching our backs here.]
> 
> Just to be clear here, because at some point Ian described Nicos as being
> "a mumble developer", and you have now declared him a "sage" ...

You've misquoted me.  I said "he's consistently given us sage technical 
advice".

> $ git log master | wc -l
> 30363
> 
> $ git log master | grep Nicos | wc -l
> 12
> 
> And all of those commits afaics relate to GUI overlay stuff for games,
> nothing at all to do with the protocol negotiation we are talking about
> here ... 

Nicos is the only one that has hinted to how the protocol negotiation works; 
being judgmental about his commits isn't going to help.  If you know more 
about how the selection algorithm works, that would be good, but I haven't yet 
heard you discuss the subject when it has come up.

> So I think I'd still rather put my trust in the the opinion
> of Thorvald about what can be made to work, than in someone who has said
> repeatedly, "Debian should just remove this, nobody cares because nobody
> uses Debian anyhow".  Which is also clearly quite incorrect, or we wouldn't
> be having this discussion at all.

I'm quite willing to discuss Thorvald's plan when he comes back.

> The current facts are:
> 
>  - The server is currently 100% broken in testing, and will remain so
>    for our users for as long as this is blocked here.

The current -2 is also undistributable, so this doesn't really matter.  You'll 
see why.

I just found something out about the Opus-only client and the codec selection 
by the server.

This test involves four Mumble clients: 
  - "348" client from Wheezy (has Opus and CELT)
  - "1.2.2-6+squeeze1" client from Stable (lacks Opus)
  - "361" Windows developer snapshot (lacks Opus)
  - "349" client from Sid (has Opus only)

And the server version is again -2 from Sid.

Steps:
  1.  "361" Windows client connects (Codec CELT)
  2.  I connected the "1.2.2-6_squeeze1" client; doesn't show which
      codec is use, but it's CELT
  3.  I connect my "348" client, connection shows Codec CELT
  4.  Talk a while -- everything works
  5.  I connect the "349" client from Sid, shows Codec OPUS
  6.  All audio connections for everybody DO NOT WORK from here on.
      "348" client still shows Codec CELT.
      As long as the "349" client from Sid is connected, disconnecting
      and reconnecting any other client gets a message from the server
      "Warning: Your client doesn't support the Opus codec, you won't
       be able to talk or hear anyone.  Please upgrade to a client with
       Opus support."
  7.  Disconnect the "349" client
      Audio connections still do not work.
  8.  In order to get the audio connection to work again between the
      clients that have CELT, one of them must disconnect and then
      reconnect in order to get the server to renegotiate which codec
      is used.

This is 100% repeatable.

This means that the Opus-only client ruins the audio connection for everybody 
else that's connected, at least in this case.

From seeing this I really think releasing a client that only has the Opus 
codec available is a directly detrimental plan.

It also implies that the current version of the server seems to choose using 
Opus over everything else, regardless of whether the other clients have it.

[…]
>    Then provided we have a clear public record of the people wanting
>    that putting *their* own heads on the block, and taking the full
>    responsibility for any fall out or required remedy -- then I have
>    clean hands, and someone to point at who is completely to blame for
>    an action I advised against in the event it goes Horribly wrong.

Quit the social engineering.

[…]
> The weekend here is nearly over, and I can't keep stealing time from
> my Work customers to keep discussing this in circles next week (and
> I'm sure many others here are in the same position).
> 
> The longer we draw this out, the less testing any of it is going to
> have, the less time is going to be available to fix any shortcomings
> that we haven't so far seen, and the poorer the result that we are
> ultimately going to end up with.

Since you're low on time I'll cut to the chase.
As far as I'm concerned I now think we're down to three distinct options.

   1) Fix up "348" from Wheezy so it compiles and uses the CELT
      codec library [very undesirable]
   2) Same as 1) but with embedded CELT (would need testing)
   3) drop mumble from Wheezy

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 02:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 02:15:03 GMT) Full text and rfc822 format available.

Message #298 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org
Cc: 682010@bugs.debian.org, Ron <ron@debian.org>, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Sun, 22 Jul 2012 22:10:01 -0400
[Message part 1 (text/plain, inline)]
On Sunday, July 22, 2012 18:31:27, Chris Knadle wrote:
> On Sunday, July 22, 2012 04:35:00, Ron wrote:
> > On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:

[…]
> Steps:
>   1.  "361" Windows client connects (Codec CELT)
>   2.  I connected the "1.2.2-6_squeeze1" client; doesn't show which
>       codec is use, but it's CELT
>   3.  I connect my "348" client, connection shows Codec CELT
>   4.  Talk a while -- everything works
>   5.  I connect the "349" client from Sid, shows Codec OPUS
>   6.  All audio connections for everybody DO NOT WORK from here on.
>       "348" client still shows Codec CELT.
>       As long as the "349" client from Sid is connected, disconnecting
>       and reconnecting any other client gets a message from the server
>       "Warning: Your client doesn't support the Opus codec, you won't
>        be able to talk or hear anyone.  Please upgrade to a client with
>        Opus support."

I got curious as to which platforms supported Opus.  It just so happens my 
girlfriend is a Mac user, and also has an iPad.  [Not my thing for obvious 
reasons, but... to each their own.]

Opus support
------------
 Windows 1.2.3a               *no*
 Windows "361" dev snapshot   *no*
 iOS 1.1                      *no*
 Mac OSX 1.2.3a               *no*
 Mac OSX "409" dev snapshot   *yes*
   ("409" is brand new within the last couple of days)

Debian specifically
-------------------
1.2.2-6+squeeze1              *no*
"348" in Wheezy               *no*
"349" in Sid                  *yes, only*


So who /exactly/ can the Debian -2 version of Mumble talk to?

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 08:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicos Gollan <gtdev@spearhead.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 08:57:07 GMT) Full text and rfc822 format available.

Message #303 received at 682010@bugs.debian.org (full text, mbox):

From: Nicos Gollan <gtdev@spearhead.de>
To: 682010@bugs.debian.org
Cc: Chris.Knadle@coredump.us
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 10:52:29 +0200
Hi,

On Monday 23 July 2012 00:31:27 Chris Knadle wrote:
> This means that the Opus-only client ruins the audio connection for
> everybody else that's connected, at least in this case.

That happens because the maintainer patch "20-add-opus-threshold-option" sets 
the threshold variable default to 1, which is a pretty nonsensical value in 
most situations. It only really makes sense to set it to 0 or 100, unless you 
want to fabricate some really weird behaviour in codec negotiation…

In that case, any client with Opus support should trigger the issue, no matter 
if it supports CELT.

Just for completeness' sake, this is _not_ an upstream issue, the value is 
initialised to 100 there.

I guess manually setting "opusthreshold=100" in your murmur.ini would restore 
sane behaviour on the server side, but I'm not inclined to dig through the 
other maintainer patches to see what else is interfering at this point.

Regards,
Nicos



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 14:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 14:36:05 GMT) Full text and rfc822 format available.

Message #308 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Philipp Kern <pkern@debian.org>
Cc: Ron <ron@debian.org>, Chris Knadle <Chris.Knadle@coredump.us>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 15:34:28 +0100
Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> >    1) Fix up "348" from Wheezy so it compiles and uses the CELT
> >       codec library [very undesirable]
> >    2) Same as 1) but with embedded CELT (would need testing)
> >    3) drop mumble from Wheezy

Of these 2. would seem to be the best option.  

Mumble is pretty widely used in some communities and I certainly think
we should try to have software in wheezy which can (i) provide a
server for mumble clients (ii) talk to mumble servers (iii) is
generally compatible with the existing deployed base (both inside and
outside Debian).

Personally I don't think there is much to prefer between 1 and 2.  Is
all that's stopping us from fixing this is overcoming our resistance
to an embedded library copy ?  If so I think we should just go ahead.

The difference in security supportability of a single embedded library
copy versus a separately library package with a rdep isn't very
great.  The difference mostly consists of the discoverability of the
embedded copy - and after this conversation I think we can reasonably
hope that everyone will know that mumble needs attention for security
bugs in celt 0.7.1.

We should confirm this with the security team but I don't imagine
they'll have an objection.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 14:42:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 14:42:07 GMT) Full text and rfc822 format available.

Message #313 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 15:38:44 +0100
Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> That point is currently still true.  Every existing client has the ability
> to *decode* speex if speex packets arrive.
> 
> The only thing removed from recent clients was the ability to encode them.
> This is what we need to restore.

I'm afraid I don't recall, and I don't seem to be able to find in the
email thread, the answers to two questions related to this:

These `recent' clients which can't encode speex are where ?  Have they
been released by upstream ?  Are they in Debian ?

And presumably there is some reason why upstream don't like speex.
What is that reason ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 17:06:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 17:06:07 GMT) Full text and rfc822 format available.

Message #318 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Philipp Kern <pkern@debian.org>, Ron <ron@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 13:02:43 -0400
[Message part 1 (text/plain, inline)]
On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal"):
> > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > >    1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > >    
> > >       codec library [very undesirable]
> > >    
> > >    2) Same as 1) but with embedded CELT (would need testing)
> > >    3) drop mumble from Wheezy
> 
> Of these 2. would seem to be the best option.

I agree.

Pros:
  - Solution should work for both Wheezy and Sid
    (-2 in Sid currently has no celt support, and celt is the most widely
     used codec in mumble on the 'net)
  - Would use celt 0.7 as well as 0.11
  - Celt library can be removed, which a lot of effort has gone into
Cons:
  - Larger diff in mumble
  - Would greatly irritate mumble maintainer

> Mumble is pretty widely used in some communities and I certainly think
> we should try to have software in wheezy which can (i) provide a
> server for mumble clients (ii) talk to mumble servers (iii) is
> generally compatible with the existing deployed base (both inside and
> outside Debian).
> 
> Personally I don't think there is much to prefer between 1 and 2.  Is
> all that's stopping us from fixing this is overcoming our resistance
> to an embedded library copy ?  If so I think we should just go ahead.

Pros:
  - Smaller diff in mumble
Cons:
  - Only uses celt 0.7
  - Proliferates library that upstream requested removal of
  - No DD found to maintain celt 0.7 library (yet)
  - Would somewhat irritate mumble maintainer

> The difference in security supportability of a single embedded library
> copy versus a separately library package with a rdep isn't very
> great.  The difference mostly consists of the discoverability of the
> embedded copy - and after this conversation I think we can reasonably
> hope that everyone will know that mumble needs attention for security
> bugs in celt 0.7.1.

Right.

> We should confirm this with the security team but I don't imagine
> they'll have an objection.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 17:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 17:12:03 GMT) Full text and rfc822 format available.

Message #323 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Chris.Knadle@coredump.us
Cc: Philipp Kern <pkern@debian.org>, Ron <ron@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 18:09:05 +0100
Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures due to 
> CELT codec library removal"):
> > > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > > >    1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > > >    
> > > >       codec library [very undesirable]
> > > >    
> > > >    2) Same as 1) but with embedded CELT (would need testing)
> > > >    3) drop mumble from Wheezy
> > 
> > Of these 2. would seem to be the best option.
> 
> I agree.
> 
> Pros:
>   - Solution should work for both Wheezy and Sid
>     (-2 in Sid currently has no celt support, and celt is the most widely
>      used codec in mumble on the 'net)
>   - Would use celt 0.7 as well as 0.11

I'm not sure I follow this.  Are you saying that enabling the embedded
celt would necessarily involve enabling /two/ versions of celt ?  (And
you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
so I'm confused about that too.)

Surely we want to avoid having multiple different versions if at all
possible.  Is it essential to support anything other than 0.7.1 ?
I thought upstream had declared 0.7.1 to be a baseline so that would
be sufficient.

And if 0.7.1 is sufficient, can it be done using an embedded copy
right now with a build system change, or would we have to dump a
special copy of celt 0.7.1 into the mumble source package ?

> Cons:
>   - Larger diff in mumble

Is it in fact a substantial diff ?  I thought it was essentially a
configure option.

>   - Would greatly irritate mumble maintainer

Rather than consider someone's emotional state, I'd rather focus on
their views.  That is, if this is a bad idea according to the mumble
maintainers then I'd like to hear why they think so.

> > Personally I don't think there is much to prefer between 1 and 2.  Is
> > all that's stopping us from fixing this is overcoming our resistance
> > to an embedded library copy ?  If so I think we should just go ahead.
> 
> Pros:
>   - Smaller diff in mumble
> Cons:
>   - Only uses celt 0.7

See above.

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 17:27:03 GMT) Full text and rfc822 format available.

Message #328 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 02:46:55 +0930
On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> > That point is currently still true.  Every existing client has the ability
> > to *decode* speex if speex packets arrive.
> > 
> > The only thing removed from recent clients was the ability to encode them.
> > This is what we need to restore.
> 
> I'm afraid I don't recall, and I don't seem to be able to find in the
> email thread, the answers to two questions related to this:

I don't think we got to these specific points, so I don't think you missed
previous discussion on them (or if you did, then I did too ;)

> These `recent' clients which can't encode speex are where ?  Have they
> been released by upstream ?  Are they in Debian ?

The last formal release of mumble was 1.2.3 in Feb 2011.

The commit to "Remove Speex encoding code" was done in mid May 2012.
I had thought the -349 snapshot from git uploaded to debian was the only
one that contained this change (that's the one still blocked in unstable),
but from the git history, the -348 release in testing may have this change
too.  348 was uploaded to debian on the 24th May 2012, a couple of days
after the changes which added Opus support and removed speex support
happened upstream.

The 1.2.3-2 that Ubuntu has been shipping definitely doesn't have this
change, so it should only be anything pulled from Debian in the last
month or two that might be affected here.


> And presumably there is some reason why upstream don't like speex.
> What is that reason ?

The reason the upstream people who've been pushing back at this have
been giving me is that they think "it sucks" for audio quality.

Which to be honest I don't really understand, and I haven't yet been
able to elicit a clear explanation of what they think qualitatively
falls down about it for this particular use.

From the purely technical side of things:

Speex is a speech coder, which means it's very efficient at coding
speech signals, it requires very little bandwidth to transmit them
with much better than toll quality telephone fidelity (I'm talking
good land-lines here, not mobile phone quality) - but it's not so
hot at things like full-band complex music.

Celt on the other hand, was designed for low-latency interactive
music.  So it requires much more bandwidth, but you could wire a
remote orchestra together with a good conductor, and have them all
play together.  [1]


So for simple conversational speech, speex should be more or less
indistinguishable from raw PCM audio for many people.  You can try
this yourself with speexenc/speexdec from the speex package on some
recorded speech to hear what I mean.  The only situation I imagine
where that would degrade notably would be if you have lots of loud
and complex background noise, to the degree where conversational
speech would be challenging in its own right.

Maybe that is true for the gamers, but when I asked I didn't get
any confirmation that this was what the problem they saw was - so
I'm guessing a bit here, based mostly on the knowledge of what the
codecs themselves are capable of.

I am actually likewise curious to understand this better if that's
not the reason.  It's not surprising celt can sound better, but it
is quite surprising if speex actually sounds Bad.  And for people
just talking, and who pay for their traffic by the MB, or who only
have a low bandwidth pipe, celt may not be the best choice for them
at all anyway.


In the discussion I had with Thorvald, he noted that when they first
switched to celt, they'd assumed that nobody using this would mind
spending more than 40kbs to send audio (since most of them were
playing online games using much more bandwidth than that) - but that
apparently wasn't completely true, and many people did still want the
lower bandwidth option of speex.  So I'm not quite sure what triggered
the recent motivation to remove encoding it completely either.


 Ron

[1] - and just to complete the spectrum here, Opus is a hybrid codec
      which implements a speech coder that is more efficient and better
      quality than speex, along with the later evolution of celt for
      full band music, so you'll get both better quality and lower
      bandwidth than either of the other options provide.





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 17:30:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 17:30:05 GMT) Full text and rfc822 format available.

Message #333 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Chris Knadle <Chris.Knadle@coredump.us>
Cc: Ron <ron@debian.org>, 682010@bugs.debian.org, 675971@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 10:26:57 -0700
On Mon, 23 Jul 2012, Chris Knadle wrote:
> On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > Of these 2. would seem to be the best option.
> 
> I agree.
> 

[...]

I believe in order to actually evaluate any of these solutions,
someone is going to have to prepare binaries, and do an table showing
the tested (not theoretical) compatibility of with multiple different
clients (and servers?) to their solution's server and client.

I propose that whoever wants to see a particular solution actually sit
down and do the work for their particular solution, with sources,
binaries, interdiffs, and compatibility table conveniently available in
some public location.

FWICT, Ron and Thorvald feel that speex will be their favored solution
and will have a version of it available no sooner than a week from
now, so there's at least a week for other people to do the work. [And
if no one wants to do the work for a solution, then there's no point
in even considering it.]

Feel free to coordinate using this bug or privately, but I don't
believe that further theoretical discussions of client/server
compatibility are useful. [At least, I'm personally not going to vote
to override a maintainer without an actual tested solution that is
technically superior, and I suspect that other CTTE members share that
opinion.]


Don Armstrong

-- 
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behavior, I have not yet achieved a state of
nirvana.
 -- Manoj Srivastava in 87n04pzhmh.fsf@glaurung.internal.golden-gryphon.com

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 18:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 18:15:03 GMT) Full text and rfc822 format available.

Message #338 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, 682010@bugs.debian.org
Cc: Philipp Kern <pkern@debian.org>, Ron <ron@debian.org>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 14:12:59 -0400
[Message part 1 (text/plain, inline)]
On Monday, July 23, 2012 13:09:05, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due to 
CELT codec library removal"):
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures
> > > due to
> > 
> > CELT codec library removal"):
> > > > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > > > >    1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > > > >    
> > > > >       codec library [very undesirable]
> > > > >    
> > > > >    2) Same as 1) but with embedded CELT (would need testing)
> > > > >    3) drop mumble from Wheezy
> > > 
> > > Of these 2. would seem to be the best option.
> > 
> > I agree.
> > 
> > Pros:
> >   - Solution should work for both Wheezy and Sid
> >   
> >     (-2 in Sid currently has no celt support, and celt is the most widely
> >     
> >      used codec in mumble on the 'net)
> >   
> >   - Would use celt 0.7 as well as 0.11
> 
> I'm not sure I follow this.  Are you saying that enabling the embedded
> celt would necessarily involve enabling /two/ versions of celt ?

Yes AFAIK.

> (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
> so I'm confused about that too.)

The mumble source package seems to contain celt 0.11.0 and 0.7.0.  The celt 
library contains celt 0.7.1.  

> Surely we want to avoid having multiple different versions if at all
> possible.  Is it essential to support anything other than 0.7.1 ?

AFAIK, no.

> I thought upstream had declared 0.7.1 to be a baseline so that would
> be sufficient.

That was my understanding too, but upstream seem to be using 0.7.0 from what I 
can tell.  [As such I'm likewise asking the same questions you are.]

> And if 0.7.1 is sufficient, can it be done using an embedded copy
> right now with a build system change, or would we have to dump a
> special copy of celt 0.7.1 into the mumble source package ?

I'm working on the assumption that celt 0.7.0 in the source package can be 
embedded using a build system change.

> > Cons:
> >   - Larger diff in mumble
> 
> Is it in fact a substantial diff ?  I thought it was essentially a
> configure option.

Source-wise it's likewise my assumption also, but I was also considering the 
"binary diff", if you will.

> >   - Would greatly irritate mumble maintainer
> 
> Rather than consider someone's emotional state, I'd rather focus on
> their views.  That is, if this is a bad idea according to the mumble
> maintainers then I'd like to hear why they think so.

Likewise -- I'm just trying to take the maintainer's wishes into account.

> > > Personally I don't think there is much to prefer between 1 and 2.  Is
> > > all that's stopping us from fixing this is overcoming our resistance
> > > to an embedded library copy ?  If so I think we should just go ahead.
> > 
> > Pros:
> >   - Smaller diff in mumble
> > 
> > Cons:
> >   - Only uses celt 0.7
> 
> See above.

Celt 0.7.1 in the celt library.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 18:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 18:33:06 GMT) Full text and rfc822 format available.

Message #343 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Nicos Gollan <gtdev@spearhead.de>
Cc: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 14:30:48 -0400
On Monday, July 23, 2012 04:52:29, Nicos Gollan wrote:
> Hi,
> 
> On Monday 23 July 2012 00:31:27 Chris Knadle wrote:
> > This means that the Opus-only client ruins the audio connection for
> > everybody else that's connected, at least in this case.
> 
> That happens because the maintainer patch "20-add-opus-threshold-option"
> sets the threshold variable default to 1, which is a pretty nonsensical
> value in most situations. It only really makes sense to set it to 0 or
> 100, unless you want to fabricate some really weird behaviour in codec
> negotiation…

Yes I see that opusthreshold is commented out, and iOpusThreshold = 1.
I've verified that this patch doesn't exist in the "348" version in Wheezy -- 
nor does it contain patches in relation to Opus.

> In that case, any client with Opus support should trigger the issue, no
> matter if it supports CELT.
> 
> Just for completeness' sake, this is _not_ an upstream issue, the value is
> initialised to 100 there.
> 
> I guess manually setting "opusthreshold=100" in your murmur.ini would
> restore sane behaviour on the server side, but I'm not inclined to dig
> through the other maintainer patches to see what else is interfering at
> this point.

When it comes to the -2 version in Sid I hope it will only be necessary to get 
the build fixes required to build "348" -1 in Wheezy.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 18:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 18:39:05 GMT) Full text and rfc822 format available.

Message #348 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 14:38:19 -0400
On Monday, July 23, 2012 13:16:55, Ron wrote:
> On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
[…]
> Maybe that is true for the gamers, but when I asked I didn't get
> any confirmation that this was what the problem they saw was - so
> I'm guessing a bit here, based mostly on the knowledge of what the
> codecs themselves are capable of.
> 
> I am actually likewise curious to understand this better if that's
> not the reason.  It's not surprising celt can sound better, but it
> is quite surprising if speex actually sounds Bad.  And for people
> just talking, and who pay for their traffic by the MB, or who only
> have a low bandwidth pipe, celt may not be the best choice for them
> at all anyway.

I seem to recall that the early versions of Mumble that I used defaulted to 
using Speex.  I seem to remember it sounding sort of like "a so-so cellphone 
connection", sort of like the person(s) on the other side sounded like they 
might be slightly underwater.  i.e. "works but not great", whereas CELT sounds 
very clear [as does Opus].  I can't be positive about this though because I 
might be mixing this memory up with my memories of other VoIP packages I've 
used over the years, so I'm likewise curious to hear what Speex sounds like 
again.


  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 18:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 18:48:05 GMT) Full text and rfc822 format available.

Message #353 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Don Armstrong <don@debian.org>, 682010@bugs.debian.org
Cc: Ron <ron@debian.org>, 675971@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 14:43:55 -0400
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
> On Mon, 23 Jul 2012, Chris Knadle wrote:
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Of these 2. would seem to be the best option.
> > 
> > I agree.
> 
> [...]
> 
> I believe in order to actually evaluate any of these solutions,
> someone is going to have to prepare binaries, and do an table showing
> the tested (not theoretical) compatibility of with multiple different
> clients (and servers?) to their solution's server and client.
> 
> I propose that whoever wants to see a particular solution actually sit
> down and do the work for their particular solution, with sources,
> binaries, interdiffs, and compatibility table conveniently available in
> some public location.

That sounds reasonable.  I might need occasional advice but otherwise I think 
I can handle this.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 19:27:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 19:27:08 GMT) Full text and rfc822 format available.

Message #358 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Chris.Knadle@coredump.us, Philipp Kern <pkern@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 04:55:17 +0930
On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures due to 
> > CELT codec library removal"):
> > > > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > > > >    1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > > > >    
> > > > >       codec library [very undesirable]
> > > > >    
> > > > >    2) Same as 1) but with embedded CELT (would need testing)
> > > > >    3) drop mumble from Wheezy
> > > 
> > > Of these 2. would seem to be the best option.
> > 
> > I agree.
> > 
> > Pros:
> >   - Solution should work for both Wheezy and Sid
> >     (-2 in Sid currently has no celt support, and celt is the most widely
> >      used codec in mumble on the 'net)
> >   - Would use celt 0.7 as well as 0.11
> 
> I'm not sure I follow this.  Are you saying that enabling the embedded
> celt would necessarily involve enabling /two/ versions of celt ?  (And
> you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
> so I'm confused about that too.)

This is absolutely not _necessary_, and not at all what I had in mind
in the previous discussions of this option.

It is _possible_ for mumble to embed many versions of celt simultaneously,
and perhaps Nicos and Chris had discussed this privately, but this is not
what we should be doing here.  If we take this option at all, then we
should use precisely the same celt code we have been using before now,
the 0.7.1 release.

> Surely we want to avoid having multiple different versions if at all
> possible.

Absolutely.
Anything else only increases our exposure surface to unmaintained code.

> Is it essential to support anything other than 0.7.1 ?

No.  We have never shipped a version that supported anything else.

> I thought upstream had declared 0.7.1 to be a baseline so that would
> be sufficient.

Correct.  (well, ostensibly correct, that's what upstream declared, but
apparently there are live servers in existence which don't respect this
and want to force other arbitrary versions of celt too).

For decoding speex actually appears to be the only baseline that we
really can trust all clients will have and all servers will support.


> And if 0.7.1 is sufficient, can it be done using an embedded copy
> right now with a build system change, or would we have to dump a
> special copy of celt 0.7.1 into the mumble source package ?

I'll have to look at exactly what has been included in the recent
tarballs, the upstream git repo is a bit of a hodge-podge of git
sub-modules, embedding various versions of various external libs,
all of which we currently do not use at all.  There will be some
diff, but I haven't looked at how big in detail yet.

> > Cons:
> >   - Larger diff in mumble
> 
> Is it in fact a substantial diff ?  I thought it was essentially a
> configure option.

That will depend on the above, but if it's "substantial" it should
be fairly much limited to a single subdirectory adding the celt code.

I'm not concerned about our ability to do this correctly should we
choose to, only about the advisability of continuing to use celt
at all.

> >   - Would greatly irritate mumble maintainer
> 
> Rather than consider someone's emotional state, I'd rather focus on
> their views.

Amen.

> That is, if this is a bad idea according to the mumble
> maintainers then I'd like to hear why they think so.

My primary concern is with the fact we would be shipping very complicated
code, that only about 3 people in the world really understand, and which
has no committed ongoing maintainer from among them or anyone else.

If there is a consensus among the members of the TC and the security
team that the risk of doing that is justified by other factors, then
I'll consider the peer decision making process to have worked as it
should, and quite the opposite of being 'irritated', I'll be quite
relieved that this decision and its possible consequences do not fall
on my head alone.

I was not comfortable unilaterally making the decision to continue
shipping celt with the knowledge I have of its situation, and I wasn't
going to be browbeaten by users who shared no part in the risk they
wanted to expose others to.  That's very different to the TC putting
its judgement on the line, and the security team committing to do the
work should it come to that.

If they all agree this is our best option, then I have no problem with
deferring to that opinion.  As I said previously, it won't take a formal
vote to convince me if consensus is that this is the best thing to do.


I think I'd still like to see us explore the speex option.  But the
release clock is ticking, and I'd be lying if I said I wasn't anxious
about squandering what time we have left by not having real users
really out testing all this and reporting the bugs they find.

The bottom line on the compatibility matrix is that the *only* way to
ensure we really are compatible with all extant systems is to:

 - Ship with speex reenabled.
 - Ship with all seven or so versions of celt enabled.
 - Ship with opus enabled.

I think we can all quickly agree that shipping with more than one
version of celt is crazy-talk, and the only option we need to consider
there is 0.7.1.

Speex is our most certain baseline, because all clients support it,
and no server support is required.

Opus support we need, because we likewise have no guarantee that
Fedora or other distributions will not assess the celt risk to be
too great and ship their subsequent releases with only Opus and/or
speex enabled (just to pick one other distro out of the hat).
Either way it *will* be widespread long before the end of life of
wheezy, so not supporting it will just disadvantage our users,
and possibly put them right back in the situation we are presently
trying to avoid.  The new server does have an opus threshold option
and once critical mass of that is triggered, clients without opus
will not be able to talk or hear other users.  That will be released
upstream for all users when Thorvald gets back, whatever we do.


So ...  really the only decision I see to be made here, is will we
ship with celt 0.7.1 enabled or not.  If -ctte and -security weighs
up the risks and tells me they are happy doing that, then I'm happy
to make that happen with no further delay.

Is there anything I've still missed?

 Cheers,
 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 19:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 19:45:05 GMT) Full text and rfc822 format available.

Message #363 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 05:13:11 +0930
On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote:
> On Monday, July 23, 2012 13:16:55, Ron wrote:
> > On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
> […]
> > Maybe that is true for the gamers, but when I asked I didn't get
> > any confirmation that this was what the problem they saw was - so
> > I'm guessing a bit here, based mostly on the knowledge of what the
> > codecs themselves are capable of.
> > 
> > I am actually likewise curious to understand this better if that's
> > not the reason.  It's not surprising celt can sound better, but it
> > is quite surprising if speex actually sounds Bad.  And for people
> > just talking, and who pay for their traffic by the MB, or who only
> > have a low bandwidth pipe, celt may not be the best choice for them
> > at all anyway.
> 
> I seem to recall that the early versions of Mumble that I used defaulted to 
> using Speex.  I seem to remember it sounding sort of like "a so-so cellphone 
> connection", sort of like the person(s) on the other side sounded like they 
> might be slightly underwater.  i.e. "works but not great", whereas CELT sounds 
> very clear [as does Opus].  I can't be positive about this though because I 
> might be mixing this memory up with my memories of other VoIP packages I've 
> used over the years, so I'm likewise curious to hear what Speex sounds like 
> again.

That's the classic artifact introduced by an echo canceller hunting for
phase lock, which is exactly what causes it in cell phone connections
too.  It's not an artifact of the codec itself.

And unless you really are completely misremembering, really early versions
of mumble used speex 1.1, which is an inferior codec to what we have today,
but is still not responsible for introducing that effect.

 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 20:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Ziegler <diese-addy@funzt-halt.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 20:06:03 GMT) Full text and rfc822 format available.

Message #368 received at 682010@bugs.debian.org (full text, mbox):

From: Michael Ziegler <diese-addy@funzt-halt.net>
To: Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 21:55:37 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23.07.2012 19:16, Ron wrote:
> Celt on the other hand, was designed for low-latency interactive 
> music.

Fwiw, I've seen numerous people asking in #mumble how to stream music
over Mumble in a way that it sounds reasonable, so it might not be
*just* about speech here.

As you noted earlier, gamers are somewhat special when it comes to
what they do with stuff. :)

Cheers,
Michael


- -- 
Öffentlicher Schlüssel:         48F81543 - Michael Ziegler (Svedrin)
Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn
da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
gingen?                                            (Autor unbekannt)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQDaw5AAoJEEn0ejpI+BVDumEH/jnHQES0mlhl6xYWCuvUrWVL
qGaqXkE6Ifa08XFornBaPjaw6ny6eT0/ZvRP0jtjOf0kIbCr+sQLhmiTJGj0WwHa
WOGmkvoHhs3zF90Cio+50hEujcH+pMU9dYVkGA+bZEwIbJ8t8uMtpgz9Yd275mk1
6wt84lGhgb3tiG8Fly8N+Q5QmAUoijuQ0LyXqp50+keGN+x6hqh45cluuydI+ryG
gWaixIzm7Hi7DFBEdlD1BZDY9N4fWmgOJpQ7oOxbqGsif+A8CsCwj0zKA81IEXPS
v3jTXQEALKqoeAxc3fAvO86AzfA3s+dIeOg8HKIsuTeCFwxHenYCpX46oTvDJ70=
=LYkU
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 20:15:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 20:15:07 GMT) Full text and rfc822 format available.

Message #373 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, Philipp Kern <pkern@debian.org>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 16:11:39 -0400
[Message part 1 (text/plain, inline)]
On Monday, July 23, 2012 15:25:17, Ron wrote:
> On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote:
> > Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due 
to CELT codec library removal"):
> > > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures
> > > > due to
[…]  
> > >   - Would use celt 0.7 as well as 0.11
> > 
> > I'm not sure I follow this.  Are you saying that enabling the embedded
> > celt would necessarily involve enabling /two/ versions of celt ?  (And
> > you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
> > so I'm confused about that too.)
> 
> This is absolutely not _necessary_, and not at all what I had in mind
> in the previous discussions of this option.
> 
> It is _possible_ for mumble to embed many versions of celt simultaneously,
> and perhaps Nicos and Chris had discussed this privately, but this is not
> what we should be doing here.  If we take this option at all, then we
> should use precisely the same celt code we have been using before now,
> the 0.7.1 release.

I have no objection.
There has been no private discussion with any of the parties in the bug AFAIK.

The main reason I was considering the embedded version was because the celt 
library is removed in Sid.  The only possible benefit of using celt 0.11.0 is 
only if it somehow improves interoperability with other distros, that from 
what you mentioned used embedded celt -- but this is certainly /not/ a 
requirement.

> > Surely we want to avoid having multiple different versions if at all
> > possible.
> 
> Absolutely.
> Anything else only increases our exposure surface to unmaintained code.

I think I agree with that.

[…]
> > I thought upstream had declared 0.7.1 to be a baseline so that would
> > be sufficient.
> 
> Correct.  (well, ostensibly correct, that's what upstream declared, but
> apparently there are live servers in existence which don't respect this
> and want to force other arbitrary versions of celt too).
> 
> For decoding speex actually appears to be the only baseline that we
> really can trust all clients will have and all servers will support.

It will be good if a solution with Speex will work out such that celt can go 
away.  On that I think we're all on the same page, but I have my doubts if it 
will work with existing servers.  Hopefully it does.

[…]
> > That is, if this is a bad idea according to the mumble
> > maintainers then I'd like to hear why they think so.
> 
> My primary concern is with the fact we would be shipping very complicated
> code, that only about 3 people in the world really understand, and which
> has no committed ongoing maintainer from among them or anyone else.
> 
> If there is a consensus among the members of the TC and the security
> team that the risk of doing that is justified by other factors, then
> I'll consider the peer decision making process to have worked as it
> should, and quite the opposite of being 'irritated', I'll be quite
> relieved that this decision and its possible consequences do not fall
> on my head alone.
>
> I was not comfortable unilaterally making the decision to continue
> shipping celt with the knowledge I have of its situation, and I wasn't
> going to be browbeaten by users who shared no part in the risk they
> wanted to expose others to.

The term "browbeaten" is objectionable, as from our point of view mumble 
became completely unusable to talk to the rest of the world, there wasn't 
sufficient information available to understand the issue, and ... so on.  
Please just try to stick to the technical issues so I may do the same, because 
those are things we're much more likely to agree on.

> That's very different to the TC putting
> its judgement on the line, and the security team committing to do the
> work should it come to that.
> 
> If they all agree this is our best option, then I have no problem with
> deferring to that opinion.  As I said previously, it won't take a formal
> vote to convince me if consensus is that this is the best thing to do.

Cool.

> I think I'd still like to see us explore the speex option.  But the
> release clock is ticking, and I'd be lying if I said I wasn't anxious
> about squandering what time we have left by not having real users
> really out testing all this and reporting the bugs they find.
> 
> The bottom line on the compatibility matrix is that the *only* way to
> ensure we really are compatible with all extant systems is to:
> 
>  - Ship with speex reenabled.
>  - Ship with all seven or so versions of celt enabled.
>  - Ship with opus enabled.

Seven versions of celt?  No, I'm not looking to enable THAT.

> I think we can all quickly agree that shipping with more than one
> version of celt is crazy-talk, and the only option we need to consider
> there is 0.7.1.

No objection.

> Speex is our most certain baseline, because all clients support it,
> and no server support is required.
> 
> Opus support we need, because we likewise have no guarantee that
> Fedora or other distributions will not assess the celt risk to be
> too great and ship their subsequent releases with only Opus and/or
> speex enabled (just to pick one other distro out of the hat).
> Either way it *will* be widespread long before the end of life of
> wheezy, so not supporting it will just disadvantage our users,
> and possibly put them right back in the situation we are presently
> trying to avoid.  The new server does have an opus threshold option
> and once critical mass of that is triggered, clients without opus
> will not be able to talk or hear other users.  That will be released
> upstream for all users when Thorvald gets back, whatever we do.

I'm okay with shipping opus as long is it doesn't cause compatability 
problems, because support for it is just starting to be rolled out, but as 
there seem to be very few existing clients that support it today I'm also 
concerned that support for it isn't stable.  It'll require testing, and I'm 
willing to help with that.

> So ...  really the only decision I see to be made here, is will we
> ship with celt 0.7.1 enabled or not.  If -ctte and -security weighs
> up the risks and tells me they are happy doing that, then I'm happy
> to make that happen with no further delay.

Thanks

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 23 Jul 2012 20:21:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 23 Jul 2012 20:21:08 GMT) Full text and rfc822 format available.

Message #378 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ron <ron@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 23 Jul 2012 16:18:35 -0400
On Monday, July 23, 2012 15:43:11, Ron wrote:
> On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote:
> > On Monday, July 23, 2012 13:16:55, Ron wrote:
> > > On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
> > […]
> > 
> > > Maybe that is true for the gamers, but when I asked I didn't get
> > > any confirmation that this was what the problem they saw was - so
> > > I'm guessing a bit here, based mostly on the knowledge of what the
> > > codecs themselves are capable of.
> > > 
> > > I am actually likewise curious to understand this better if that's
> > > not the reason.  It's not surprising celt can sound better, but it
> > > is quite surprising if speex actually sounds Bad.  And for people
> > > just talking, and who pay for their traffic by the MB, or who only
> > > have a low bandwidth pipe, celt may not be the best choice for them
> > > at all anyway.
> > 
> > I seem to recall that the early versions of Mumble that I used defaulted
> > to using Speex.  I seem to remember it sounding sort of like "a so-so
> > cellphone connection", sort of like the person(s) on the other side
> > sounded like they might be slightly underwater.  i.e. "works but not
> > great", whereas CELT sounds very clear [as does Opus].  I can't be
> > positive about this though because I might be mixing this memory up with
> > my memories of other VoIP packages I've used over the years, so I'm
> > likewise curious to hear what Speex sounds like again.
> 
> That's the classic artifact introduced by an echo canceller hunting for
> phase lock, which is exactly what causes it in cell phone connections
> too.  It's not an artifact of the codec itself.
> 
> And unless you really are completely misremembering, really early versions
> of mumble used speex 1.1, which is an inferior codec to what we have today,
> but is still not responsible for introducing that effect.

That all sounds reasonable.  Back then I think I was using many of the default 
settings and as such could have been using echo cancelation.  These days I've 
turned that off because it can sometimes cause echo rather than canceling it.  
Speex 1.1 sounds familiar.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 24 Jul 2012 09:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicos Gollan <gtdev@spearhead.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 24 Jul 2012 09:03:05 GMT) Full text and rfc822 format available.

Message #383 received at 682010@bugs.debian.org (full text, mbox):

From: Nicos Gollan <gtdev@spearhead.de>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 10:59:29 +0200
On Saturday 21 July 2012 03:35:56 Ron wrote:
> Sorry to keep this going with one more message, but since it seems apropos
> to the question of building an accurate table of where we might expect
> compatibility, and the earlier question of what people use on Ubuntu and
> other derivatives:
> 
> [cut IRC log about Mint 9 having a client version without baseline client]
> 
> So it would appear that shipping with celt 0.7.1 support is actually
> not sufficient on its own for people to communicate with the existing
> deployed base, and this is the advice people are given in those cases,
> by the developer who disabled the speex support ...

Please cut the unsubtle trolling against what happens upstream in development 
versions for now, especially when the situation has been explained to you 
repeatedly and patiently by upstream developers.

If certain server or client versions do not support the baseline, then that 
was so far universally a problem of maintainers not understanding the baseline 
contract and insisting on exclusively using bitstream incompatible 
distribution packages of the CELT library (some other distributions that shall 
remain unnamed have also been repeat offenders), and catering to that is 
certainly not on anyone's list, since it would, indeed, be crazy.

And in another message, he wrote:
> Speex is our most certain baseline, because all clients support it,
> and no server support is required.

Support for speex was a hack around disabilities of CELT at low bandwidths, 
and it could easily be added because the decoder was already in the client, so 
it was a non-breaking change to have clients just send speex encoded audio and 
be universally understood. Still, there is no way for a client to make other 
clients use speex. I will, however, happily declare being wrong about that 
once the magic fix-all speex patch hits and actually works.

**Sidenote:** Discussion about the qualities of different codecs, what they 
were made for, or what people want to use Mumble for, is certainly out of 
scope for this issue. With the qualities of Opus, it would certainly make a 
worthwhile topic on the Mumble forum.

Regards,
Nicos



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 24 Jul 2012 12:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 24 Jul 2012 12:21:05 GMT) Full text and rfc822 format available.

Message #388 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>
Cc: Chris.Knadle@coredump.us, Philipp Kern <pkern@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 13:17:10 +0100
Ron writes ("Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> My primary concern is with the fact we would be shipping very complicated
> code, that only about 3 people in the world really understand, and which
> has no committed ongoing maintainer from among them or anyone else.

I don't think this is really a huge issue.  As I understand it the
code in the celt codec has been reused in the implementation of opus -
obviously not quite identically, but that means that it's not really
right to say that no-one understands this code and that it's dead
upstream.  It's been incorporated as a key part of opus, renamed and
developed.  So celt 0.7.11 is really best seen as an old, pre-release,
version of opus.

> If there is a consensus among the members of the TC and the security
> team that the risk of doing that is justified by other factors, then
> I'll consider the peer decision making process to have worked as it
> should, and quite the opposite of being 'irritated', I'll be quite
> relieved that this decision and its possible consequences do not fall
> on my head alone.

Well I asked this question of the security team, and while they
weren't particularly positive about it they did not object to the
inclusion in wheezy.

> So ...  really the only decision I see to be made here, is will we
> ship with celt 0.7.1 enabled or not.  If -ctte and -security weighs
> up the risks and tells me they are happy doing that, then I'm happy
> to make that happen with no further delay.

I don't speak for the whole TC, but my personal view at the moment is
that this tradeoff is worthwhile.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 24 Jul 2012 16:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 24 Jul 2012 16:54:03 GMT) Full text and rfc822 format available.

Message #393 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Chris.Knadle@coredump.us, Philipp Kern <pkern@debian.org>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 25 Jul 2012 02:21:33 +0930
On Tue, Jul 24, 2012 at 01:17:10PM +0100, Ian Jackson wrote:
> Ron writes ("Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> > My primary concern is with the fact we would be shipping very complicated
> > code, that only about 3 people in the world really understand, and which
> > has no committed ongoing maintainer from among them or anyone else.
> 
> I don't think this is really a huge issue.  As I understand it the
> code in the celt codec has been reused in the implementation of opus -
> obviously not quite identically, but that means that it's not really
> right to say that no-one understands this code and that it's dead
> upstream.

I understand your line of thinking there, and for 99% of the code in the
world, I'd be in complete agreement.  I'm not someone who is afraid of
code, or of getting my hands dirty in it, but we're not talking about
simple programming errors here - if and where there are problems, they
are in the boundary conditions of some very deep math that often still
confuses the people who created it until they stop and think very hard.

There's a simplified description of some of that here:
http://people.xiph.org/~xiphmont/demo/celt/demo.html

(be sure to mouse-over the block diagram too)

If there is anybody reading this who thinks they understand all the
concepts there enough to analyse code implementing them, then please
do put your hand up, we may need your expert attention at some point
in the future. (and we have other codecs we'd love you to help out
with too :)

For those who don't, I probably should note that was described as the
"lies for children" simplification by the people who wrote it.  Which
wasn't meant to be rude to anyone else, it just really does skip over
an enormous amount of the actual complexity that is really there, to
try and give ordinary people some broad idea of how it works, and
things to go research if they want to learn more.


I agree that saying "nobody" understands it is also an oversimplification
on my part, but I'm not aware of there being anybody at present in the
intersection set of "people who care about mumble using old celt" and
"people who do understand this".  If that wasn't an empty set, I'd also
be less concerned.  (and I did spend quite some time asking around to
try to find someone who might fill that void)

I have no reason to doubt that the upstream maintainers who said they
have no further interest in this codebase really do mean that.  I've
been involved with them long enough to see them move from one project
to the next before and it really will be "our problem, and our problem
alone" if we continue using this.


> It's been incorporated as a key part of opus, renamed and
> developed.  So celt 0.7.11 is really best seen as an old, pre-release,
> version of opus.

There is a sense in which you are 100% correct there.  But it is also
the same sense which gave us the aphorism:

 "This is Ned Kelly's original axe."
 (only the handle has been replaced 5 times and the head twice)

There's a 'spiritual' connection between these codebases, but so much
has been rewritten and reinvented so many times now, that backporting
anything from the new code to the old won't be a case of understanding
the code.  It will likely require reverse engineering the math and
then completely re-analysing the problem in a very different domain,
just to see if it still applies, let alone to figure out a fix.

If that wasn't the case, the problems identified in later code would
have already had fixes backported to the code we have.  As it is, nobody
has yet figured out how those things really map together, to confirm
or deny the old code is affected -- all the people who cared enough to
try got lost at the very first step.

For a more empirical clarification of how much has changed, see the
diffstat below.


> > If there is a consensus among the members of the TC and the security
> > team that the risk of doing that is justified by other factors, then
> > I'll consider the peer decision making process to have worked as it
> > should, and quite the opposite of being 'irritated', I'll be quite
> > relieved that this decision and its possible consequences do not fall
> > on my head alone.
> 
> Well I asked this question of the security team, and while they
> weren't particularly positive about it they did not object to the
> inclusion in wheezy.

Yes, I did see nion's earlier response to that:
http://lists.debian.org/debian-ctte/2012/07/msg00192.html


> > So ...  really the only decision I see to be made here, is will we
> > ship with celt 0.7.1 enabled or not.  If -ctte and -security weighs
> > up the risks and tells me they are happy doing that, then I'm happy
> > to make that happen with no further delay.
> 
> I don't speak for the whole TC, but my personal view at the moment is
> that this tradeoff is worthwhile.

I think I've made my concerns are clear as I can, so in my mind then,
if Don and Steve agree with your assessment, then I'm happy to consider
that a sufficient 'consensus' of the TC (since they have already been
following this, and it seems cruel and unnecessary to inflict reading
all of it on the rest of the -ctte members if they don't of their own
free will wish to do so and chime in with an opinion).

If Phil is ok with this from his perspective as SRM, then let's all
get beer and move on to the wrap party :)

 Best,
 Ron



Diffstat of celt 0.7.1 to opus 0.9.14 currently in Wheezy:

 _kiss_fft_guts.h     |  153 --
 arch.h               |  138 --
 bands.c              | 1790 +++++++++++++++----------
 bands.h              |   85 -
 c64_fft.c            |  344 ----
 c64_fft.h            |   58 
 celt.c               | 3513 ++++++++++++++++++++++++++++++++++-----------------
 celt.h               |  265 ---
 celt_header.h        |   70 -
 celt_lpc.c           |  188 ++
 celt_lpc.h           |   53 
 celt_types.h         |  140 --
 cwrs.c               |  515 +------
 cwrs.h               |   25 
 dump_modes.c         |  223 ---
 ecintrin.h           |   99 -
 entcode.c            |   54 
 entcode.h            |  132 +
 entdec.c             |  258 ++-
 entdec.h             |   87 -
 entenc.c             |  283 +++-
 entenc.h             |  108 -
 fixed_c5x.h          |   26 
 fixed_c6x.h          |   26 
 fixed_debug.h        |  383 ++++-
 fixed_generic.h      |   85 -
 float_cast.h         |  169 +-
 header.c             |  129 -
 kfft_double.h        |   79 -
 kfft_single.c        |   44 
 kfft_single.h        |   84 -
 kiss_fft.c           |  777 +++++------
 kiss_fft.h           |  158 +-
 kiss_fftr.c          |  165 --
 kiss_fftr.h          |   82 -
 laplace.c            |  168 +-
 laplace.h            |   26 
 match-test.sh        |   30 
 mathops.c            |  206 ++
 mathops.h            |  285 ----
 mdct.c               |  200 +-
 mdct.h               |   41 
 mfrngcod.h           |   18 
 mfrngdec.c           |  248 ---
 mfrngenc.c           |  236 ---
 modes.c              |  551 +++----
 modes.h              |   91 -
 opus_custom_demo.c   |  210 +++
 os_support.h         |   99 -
 pitch.c              |  326 +++-
 pitch.h              |   28 
 plc.c                |  136 -
 psy.c                |  211 ---
 psy.h                |   57 
 quant_bands.c        |  523 +++++--
 quant_bands.h        |   49 
 rangedec.c           |  210 ---
 rangeenc.c           |  209 ---
 rate.c               |  654 +++++++--
 rate.h               |  135 -
 stack_alloc.h        |   44 
 static_modes_fixed.h |  595 ++++++++
 static_modes_float.h |  599 ++++++++
 testcelt.c           |  209 ---
 vq.c                 |  396 +++--
 vq.h                 |   47 
 70 files changed, 9563 insertions(+), 9178 deletions(-)

And while that may not look like the most horrifyingly large diff that
has ever been sent to -release as a minimal 'harmless' proposed fix,
let's put it into perspective as a proportion of the total codebase:

 $ cat libcelt/*.[ch] | wc -l
 13441

I'll leave trying to understand and review the diff itself as an
exercise for the truly dedicated reader :)





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 24 Jul 2012 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 24 Jul 2012 17:27:03 GMT) Full text and rfc822 format available.

Message #398 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Chris.Knadle@coredump.us, Philipp Kern <pkern@debian.org>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 18:25:04 +0100
Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> I understand your line of thinking there, and for 99% of the code in the
> world, I'd be in complete agreement.  I'm not someone who is afraid of
> code, or of getting my hands dirty in it, but we're not talking about
> simple programming errors here - if and where there are problems, they
> are in the boundary conditions of some very deep math that often still
> confuses the people who created it until they stop and think very hard.

In order to support this in wheezy we do not need to be able to fix
general bugs in the codec or analyse and understand its signal
processing behaviour.

We have only to be able to fix security problems, and it is normally
possible to find and fix such security problems without needing to
understand the purpose of the signal processing algorithms; typically
they would occur (as with decompressors) in the handling of invalid
packets.

I have some experience of this as in a past life one of my
responsibilities was security audit and response for a manufacturer of
HSMs, so I have some idea of what's involved.

Looking at the code I agree with Nico that it's not marvellous.  And
it's rather too voluminous to audit.  But I don't think it's
significantly worse than other codecs.  In particular looking at the
opus code in sid it seems very similar in style and quality.  The only
difficulty is that it's different enough to make backporting changes
nontrivial.

Looking at some sample diffs there seem to be a lot of variable and
type name changes and so on, as well as the algorithmic differences,
so a diffstat doesn't give an accurate picture.

> If there is anybody reading this who thinks they understand all the
> concepts there enough to analyse code implementing them, then please
> do put your hand up, we may need your expert attention at some point
> in the future. (and we have other codecs we'd love you to help out
> with too :)

I don't think this is relevant.  Doing security support for this does
not need a degree in signal processing.  (And my first degree
contained an awful lot of signal processing and I have a background
and advanced degree in computer security, so I should know.)

> > It's been incorporated as a key part of opus, renamed and
> > developed.  So celt 0.7.11 is really best seen as an old, pre-release,
> > version of opus.
> 
> There is a sense in which you are 100% correct there.  But it is also
> the same sense which gave us the aphorism:
> 
>  "This is Ned Kelly's original axe."
>  (only the handle has been replaced 5 times and the head twice)

Having eyeballed some diffs I don't think this is a fair
characterisation at all.

> There's a 'spiritual' connection between these codebases, but so much
> has been rewritten and reinvented so many times now, that backporting
> anything from the new code to the old won't be a case of understanding
> the code.  It will likely require reverse engineering the math and
> then completely re-analysing the problem in a very different domain,
> just to see if it still applies, let alone to figure out a fix.

There is no need to backport anything other than security fixes.  As I
say, sorting out security fixes does not involve anyone having to
understand FFTs.

And I disagree that the code is so different that the connection is
`spiritual' as you put it.  Backporting a hypothetical security fix
from opus to celt 0.7.1 might well not be trivial (although depending
what it touched it might well be) but would also very likely be by no
means impossible.

> I'll leave trying to understand and review the diff itself as an
> exercise for the truly dedicated reader :)

It didn't seem to need that much dedication.  Although I haven't read
the whole diff, just eyeballed pieces chosen essentially at random.

> And while that may not look like the most horrifyingly large diff that
> has ever been sent to -release as a minimal 'harmless' proposed fix,
> let's put it into perspective as a proportion of the total codebase:

Currently celt 0.7.1 is in wheezy.  Its removal is blocked by the fact
that stripping it out introduces the RC bug in mumble.

The proposed fix involves moving the source code for celt 0.7.1 from
one source package to another, not introducing it newly into wheezy.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 24 Jul 2012 19:39:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 24 Jul 2012 19:39:15 GMT) Full text and rfc822 format available.

Message #403 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Ron <ron@debian.org>, 682010@bugs.debian.org, Chris.Knadle@coredump.us, Philipp Kern <pkern@debian.org>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 25 Jul 2012 05:07:51 +0930
On Tue, Jul 24, 2012 at 06:25:04PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> > I understand your line of thinking there, and for 99% of the code in the
> > world, I'd be in complete agreement.  I'm not someone who is afraid of
> > code, or of getting my hands dirty in it, but we're not talking about
> > simple programming errors here - if and where there are problems, they
> > are in the boundary conditions of some very deep math that often still
> > confuses the people who created it until they stop and think very hard.
> 
> In order to support this in wheezy we do not need to be able to fix
> general bugs in the codec or analyse and understand its signal
> processing behaviour.

I wasn't trying to imply that, and agree.

> We have only to be able to fix security problems, and it is normally
> possible to find and fix such security problems without needing to
> understand the purpose of the signal processing algorithms; typically
> they would occur (as with decompressors) in the handling of invalid
> packets.

This however is only 'trivial' if someone hands us a trigger stream
on a platter - and I don't believe that anyone is in the habit of
recording raw mumble protocol streams that their client receives.

Since nobody else is using this, our odds of a friendly agent stumbling
upon the problem first are greatly reduced, and in the event of such
a problem it would still require a sufficiently deep understanding to
avoid introducing new problems with any fix.

None of this is impossible, but nobody has volunteered to take on the
role of stewarding this.

> Looking at some sample diffs there seem to be a lot of variable and
> type name changes and so on, as well as the algorithmic differences,
> so a diffstat doesn't give an accurate picture.

Nobody has really been just renaming variables for fun and profit, so
I suspect you'll find most or all of those cases are also tied to some
semantic difference in meaning and/or use as the codec evolved.

> > > It's been incorporated as a key part of opus, renamed and
> > > developed.  So celt 0.7.11 is really best seen as an old, pre-release,
> > > version of opus.
> > 
> > There is a sense in which you are 100% correct there.  But it is also
> > the same sense which gave us the aphorism:
> > 
> >  "This is Ned Kelly's original axe."
> >  (only the handle has been replaced 5 times and the head twice)
> 
> Having eyeballed some diffs I don't think this is a fair
> characterisation at all.

Aside from the basic MDCT and PVQ, almost everything has changed at least
once, some things several times.  Things have been tried and discarded,
and new things have been added.  Though to be fair, surely not all those
things will be reflected in this single diff between two versions.

They are near the outer ends of all these changes though.  And the encoder
is _still_ evolving (since only the decoder and bitstream are normalised,
improvements in encoding are ongoing).  Again by way of mitigation though,
we will hopefully be mostly only concerned with the decoder, since that's
the obvious open vector for a remote exploit.


> There is no need to backport anything other than security fixes.  As I
> say, sorting out security fixes does not involve anyone having to
> understand FFTs.

Actually the FFTs need to go away entirely, just nobody has got around
to actually optimising that code yet (but that's a total aside :)


> > And while that may not look like the most horrifyingly large diff that
> > has ever been sent to -release as a minimal 'harmless' proposed fix,
> > let's put it into perspective as a proportion of the total codebase:
> 
> Currently celt 0.7.1 is in wheezy.  Its removal is blocked by the fact
> that stripping it out introduces the RC bug in mumble.
> 
> The proposed fix involves moving the source code for celt 0.7.1 from
> one source package to another, not introducing it newly into wheezy.

Yes, I wasn't implying this was the diff -release would need to review,
just that for people used to looking at half-million line diffs sent
requesting a freeze exception, it may not look very daunting on number
of lines changed alone.  This was solely directed to making it clear
that the maintained opus codebase was not just some minor incremental
change to celt 0.7.1.  It carried on the name for the MDCT coding mode,
but in most respects aside from a couple of fundamentals is actually
an entirely different codec altogether.


My current understanding is that the code given as celt 0.7.0 in the
current mumble source *is* in fact 0.7.1, though I need to diff that
against the upstream 0.7.1 to be absolutely certain still.  So the
diff for 'adding' this to the mumble package itself should be very
minimal.  Sorry if I wasn't totally clear about that bit here.

 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 24 Jul 2012 21:15:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 24 Jul 2012 21:15:16 GMT) Full text and rfc822 format available.

Message #408 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Ron <ron@debian.org>, 682010@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, Philipp Kern <pkern@debian.org>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 17:09:48 -0400
On Tuesday, July 24, 2012 15:37:51, Ron wrote:
> On Tue, Jul 24, 2012 at 06:25:04PM +0100, Ian Jackson wrote:
[…]
> My current understanding is that the code given as celt 0.7.0 in the
> current mumble source *is* in fact 0.7.1, though I need to diff that
> against the upstream 0.7.1 to be absolutely certain still.

At least in terms of what's in the "349" -2 in Sid and the celt 0.7.1 library 
in Wheezy, it looks to me like the code is exactly the same.

$ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt
Only in celt-0.7.1/libcelt: Makefile.in

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 25 Jul 2012 01:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 25 Jul 2012 01:54:03 GMT) Full text and rfc822 format available.

Message #413 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Nicos Gollan <gtdev@spearhead.de>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 24 Jul 2012 21:50:23 -0400
On Tuesday, July 24, 2012 04:59:29, Nicos Gollan wrote:
[…]
On Monday, July 23, 2012 15:25:17, Ron wrote:
> > Speex is our most certain baseline, because all clients support it,
> > and no server support is required.
> 
> Support for speex was a hack around disabilities of CELT at low bandwidths,
> and it could easily be added because the decoder was already in the client,
> so it was a non-breaking change to have clients just send speex encoded
> audio and be universally understood. Still, there is no way for a client
> to make other clients use speex. I will, however, happily declare being
> wrong about that once the magic fix-all speex patch hits and actually
> works.
> 
> **Sidenote:** Discussion about the qualities of different codecs, what they
> were made for, or what people want to use Mumble for, is certainly out of
> scope for this issue. With the qualities of Opus, it would certainly make a
> worthwhile topic on the Mumble forum.

The way you've described this, /if/ the trick with Speex does work, and the 
Debian version of Mumble ships without CELT, it would mean that if any Debian 
user shows up on a public server then all users would switch to using Speex.  
If that's the case, then the audio quality of Speex vs Celt and the latency 
each has matters to an extent.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 25 Jul 2012 07:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicos Gollan <gtdev@spearhead.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 25 Jul 2012 07:45:03 GMT) Full text and rfc822 format available.

Message #418 received at 682010@bugs.debian.org (full text, mbox):

From: Nicos Gollan <gtdev@spearhead.de>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 25 Jul 2012 09:40:52 +0200
Hi,

On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote:
> The way you've described this, /if/ the trick with Speex does work, and the
> Debian version of Mumble ships without CELT, it would mean that if any
> Debian user shows up on a public server then all users would switch to
> using Speex. If that's the case, then the audio quality of Speex vs Celt
> and the latency each has matters to an extent.

If "the trick with speex" works and is actually deemed necessary, then we're 
talking about a package providing the absolute minimum of interoperability 
without any ambition to providing quality. And yes, for it to work, it would 
need to switch all clients within hearing range to using speex with all the 
penalties in quality and latency that brings.

However, as suggested earlier, statistics also show that users on Linux 
platforms make up not quite 2% of the overall userbase, and users affected by 
the hack would be well below that (my guess would put them under one per mil). 
With that in mind, it would be easy for users to just kick the offending 
handful of clients worldwide off their servers if the need arises, since it 
would be a very rare occurrence. That makes the impact on the overall userbase 
absolutely negligible.

Regards,
Nicos



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 25 Jul 2012 11:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 25 Jul 2012 11:06:03 GMT) Full text and rfc822 format available.

Message #423 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Nicos Gollan <gtdev@spearhead.de>, 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 25 Jul 2012 07:02:02 -0400
On Wednesday, July 25, 2012 03:40:52, Nicos Gollan wrote:
> Hi,
> 
> On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote:
> > The way you've described this, /if/ the trick with Speex does work, and
> > the Debian version of Mumble ships without CELT, it would mean that if
> > any Debian user shows up on a public server then all users would switch
> > to using Speex. If that's the case, then the audio quality of Speex vs
> > Celt and the latency each has matters to an extent.
> 
> If "the trick with speex" works and is actually deemed necessary, then
> we're talking about a package providing the absolute minimum of
> interoperability without any ambition to providing quality. And yes, for
> it to work, it would need to switch all clients within hearing range to
> using speex with all the penalties in quality and latency that brings.

Yeah... I'm not liking the sound of that.  For instance one of the things that 
are common on public Mumble/Murmur servers are one or more "music channels" 
among the many other channels for teams of gamers.  Forcing all of that 
through a low-quality codec meant only for voice communication sounds very 
undesirable from the user perspective.

> However, as suggested earlier, statistics also show that users on Linux
> platforms make up not quite 2% of the overall userbase, and users affected
> by the hack would be well below that (my guess would put them under one
> per mil). With that in mind, it would be easy for users to just kick the
> offending handful of clients worldwide off their servers if the need
> arises, since it would be a very rare occurrence. That makes the impact on
> the overall userbase absolutely negligible.

[I'm sure you know the following, but I'm explaining this in more detail for 
those that may not be familiar with it.]

Normally users cannot kick nor ban another user off the server.  To kick an 
offending client off the server would require SuperUser priviliges in the 
Mumble/Murmur server, or for kick/ban priviliges to be delegated to specific 
users via Groups or ACL rules in the server.  After that, this would involve 
right-clicking on the suspected offending client and getting Information on 
the client version, *somehow* figuring out that that version of Mumble was 
causing the problem (i.e. "the Debian version of Mumble is a problem" from a 
web search), and then finding someone with kick/ban priviliges to get the 
offending client off.  Then presumably someone has to leave the server and 
return in order to get the server to renegotiate the codec used.

I wouldn't characterize the above as "easy" -- although it is easy in the 
sense that it doesn't require reconfiguring the host machine to do it.  It 
would be easier for users to text the offending client and ask that the user 
leave, but this would also involve understanding and explaining the situation.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 30 Jul 2012 20:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 30 Jul 2012 20:03:05 GMT) Full text and rfc822 format available.

Message #428 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Don Armstrong <don@debian.org>, 682010@bugs.debian.org
Cc: Ron <ron@debian.org>, 675971@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 30 Jul 2012 15:59:30 -0400
[Message part 1 (text/plain, inline)]
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
> On Mon, 23 Jul 2012, Chris Knadle wrote:
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Of these 2. would seem to be the best option.
> > 
> > I agree.
> 
> [...]
> 
> I believe in order to actually evaluate any of these solutions,
> someone is going to have to prepare binaries, and do an table showing
> the tested (not theoretical) compatibility of with multiple different
> clients (and servers?) to their solution's server and client.
> 
> I propose that whoever wants to see a particular solution actually sit
> down and do the work for their particular solution, with sources,
> binaries, interdiffs, and compatibility table conveniently available in
> some public location.

Attached is a patch for fixing the build on the "348" version of Mumble in 
Wheezy.  Two files, of which only one or the other is required: one is a 
standard diff which can be used to patch the "348" version as-is via "patch -
p1 < <diff file>" while in the source package directory.  The other is an mbox 
file for importing via 'git am <mbox file>' against the latest tagged version 
of "348", v1.2.3-348-g317f5a0-1.

The patch consists of cherry-picked git commits from the "349" version, plus 
one commit after doing a 'dch -i' to add a changelog entry [automatically 
marked as a .1 NMU, which for the moment I haven't changed].  This version 
still requires libcelt.  I'm currently testing this -1.1 on both client and 
server -- all seems well so far.  [Tables of compatability to follow.]  I 
think the "348" version includes the Speex codec, but I haven't been able to 
trigger its use yet experimentally.

Quick summary of changes:
  - Remove broken mumble-server-web package
  - Change maintainer from Debian VoIP team to Ron Lee
  - Remove Patrick Matthäi from Uploaders
  - Hardcode use of and add dependency on g++-4.6
  - Remove boot 1.46 dependency resolution
  - Remove libgl dependency resolution
  - Depend on ice34 and drop resolution via older versions



I'm also still working on how to do the embedded celt version; by default 
embedding CELT will enable both embedded 0.7.1 and 0.11.0 so enabling only 
0.7.1 will require a quilt patch to modify the original source build 
directives slightly.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[mumble-348-fixes.mbox (application/mbox, attachment)]
[mumble-348-fixes.diff (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 30 Jul 2012 20:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 30 Jul 2012 20:39:03 GMT) Full text and rfc822 format available.

Message #433 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 682010@bugs.debian.org, Ron <ron@debian.org>
Subject: Re: Bug#682010: Interoperability with speex patch
Date: Mon, 30 Jul 2012 13:36:34 -0700
One of the possible technical solutions to #682010 is the use of the
speex codex as a default. The CTTE would like to see the packages
which incorporate this solution and a table of client/server
compatibility so we can choose which solution is most desirable. If
you (Ron) could work with Nicos to prepare such packages and test
them, ideally within two weeks (say, before the 13th of August), that
would be greatly appreciated.


Don Armstrong

-- 
Leukocyte... I am your father.
 -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 30 Jul 2012 20:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 30 Jul 2012 20:45:02 GMT) Full text and rfc822 format available.

Message #438 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 682010@bugs.debian.org, Ron <ron@debian.org>
Subject: Re: Bug#682010: Interoperability with speex patch
Date: Mon, 30 Jul 2012 13:43:03 -0700
On Mon, 30 Jul 2012, Don Armstrong wrote:
> One of the possible technical solutions to #682010 is the use of the
> speex codex as a default. The CTTE would like to see the packages
> which incorporate this solution and a table of client/server
> compatibility so we can choose which solution is most desirable. If
> you (Ron) could work with Nicos to prepare such packages and test
> them, ideally within two weeks (say, before the 13th of August), that
> would be greatly appreciated.

Err, that should be "work with Thorvald", sorry.


Don Armstrong

-- 
Given that the odds of a miracle are one in one million, and events
which could be a miracle happen every second, the odds of not seeing a
miracle in a month are less than 8 in 100. Clearly miracles are not
all that miraculous.

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 01 Aug 2012 16:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 01 Aug 2012 16:21:05 GMT) Full text and rfc822 format available.

Message #443 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Don Armstrong <don@debian.org>, 682010@bugs.debian.org
Cc: Ron <ron@debian.org>, 675971@bugs.debian.org, Nicos Gollan <gtdev@spearhead.de>
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 1 Aug 2012 12:14:06 -0400
[Message part 1 (text/plain, inline)]
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
> On Mon, 23 Jul 2012, Chris Knadle wrote:
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Of these 2. would seem to be the best option.
> > 
> > I agree.
> 
> [...]
> 
> I believe in order to actually evaluate any of these solutions,
> someone is going to have to prepare binaries, and do an table showing
> the tested (not theoretical) compatibility of with multiple different
> clients (and servers?) to their solution's server and client.
> 
> I propose that whoever wants to see a particular solution actually sit
> down and do the work for their particular solution, with sources,
> binaries, interdiffs, and compatibility table conveniently available in
> some public location.

Attached is a patch for fixing the build for the "348" version of Mumble in 
Wheezy, which includes embedding celt 0.7.1 into the mumble package and 
removing the dependency on the celt library.  There are two versions attached: 
a diff that can be applied directly via 'patch -p1 < <diff>', and an mbox file 
that can be applied to the git repository via 'git am <mbox file>' against tag 
v1.2.3-348-g317f5a0-1.

Quick summary of changes:
  - Remove broken mumble-server-web package
  - Change maintainer from Debian VoIP team to Ron Lee
  - Remove Patrick Matthäi from Uploaders
  - Hardcode use of and add dependency on g++-4.6
  - Remove boost 1.46 dependency resolution
  - Remove libgl dependency resolution
  - Depend on ice34 and drop resolution via older versions
  - Build and embed celt 0.7.1 (and not celt 0.11.0)

One interesting difference when using the embedded version rather than the 
celt library is that Mumble reports using "Celt 0.7.0" in the Server -> 
Information screen, rather than "Celt 0.0.0" that is reported when using the 
external celt library.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
[mumble-348-fixes-embedded.diff (text/x-patch, attachment)]
[mumble-348-fixes-embedded.mbox (application/mbox, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Sun, 12 Aug 2012 18:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 12 Aug 2012 18:48:03 GMT) Full text and rfc822 format available.

Message #448 received at 682010@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Interoperability with speex patch
Date: Mon, 13 Aug 2012 04:06:34 +0930
Ok, where to begin ...  I guess first off, the IRC meeting was a big help
for me in getting a sense of what was already clear and what was not.
I fairly deliberately didn't lurk that because I was more interested in
listening to what other people were "thinking out loud" at this stage,
and it was a great window into that.  Keep doing those :)

There are some open questions from that which do have straightforward
answers, so I'll try to sort this from easy to Hard ...


 <dondelelcaro> and the server aparently isn't capable of transcoding or whatever
 <Diziet> dondelelcaro: AFAICT the server doesn't ever transcode so every client
          needs to send a codec everyone understands.

The server is basically just a packet amplifier, it takes whatever each
client sends, and forwards a copy to each other participant.  It doesn't
do much more than that.

Clients don't even need to be sending the with the same codec.  If you
configure your client bandwidth for <= 32kbs it will send Speex, and all
other clients will decode that fine.  But it's not symmetrical, so they
may still be sending you Celt at 96kbs, or Opus at any rate, regardless
of your own client configuration.

There isn't really any "negotiation" in the normal protocol sense of that
word, except when the client supports multiple versions of Celt, then the
server will indicate which version the connected clients have in common.


 <vorlon> Debian runs a public mumble server, easy enough to attack

Because of the above, the server itself isn't vulnerable to problems in
the codec code.  It may have its own problems, but I'm not aware of any
of those if they exist.  It's only the client code that's exposed here,
but anyone connecting to a server has a 'direct' connection to all of
the other clients there.


 <rra> In other words, we don't *know* of any security problems;
       we (for some value of we) just think the code is horrible.
 <Diziet> No.  "We" think the code is dead upstream, is the main point.
 <vorlon> my understanding was that someone concocted a proof of concept
          against later versions of the code, and that the opus code has
          been proofed against it

It's not that the code is even particularly horrible (as code written by
Heavy Math people goes :)  Mostly it's that there is nobody analysing the
problems found and corrected in later code, and/or backporting any needed
fixes to the version that mumble wants to continue using.

People are saying they want to keep using it, but nobody is taking on the
role of actually being responsible for it - or indicating anything other
than that they are explicitly _not_ prepared to take on that task so far.


 <Diziet> Not that it's horrible.  I haven't seen anyone claim the opus
          code is much better than the celt code from a security pov.

I'll make that claim unambiguously now (if I hadn't done so already :).

Celt was an entirely experimental codebase, each 'version' of it that
was tagged existed *only* for testing the quality of the audio that it
produced.  Next to no attention was paid to the normal "release issues"
of a piece of "production" software beyond what other people submitted
as patches.  Once the listening test results were in, code was changed,
the bitstream broken as/if needed, and audio quality testing continued.

Being free software, and an experiment conducted fully in the open,
people were free to do with it what they wished -- but if they did,
the onus was *entirely* on them to worry about release quality and
maintenance issues.  That's not something the upstream developers
devoted any real attention to at all before the bitstream freeze.

Opus by comparison has its C code as the normative part of an IETF
proposed standard.  An utterly insane number of hours went into
QA testing it for "release issues" after the final bitstream freeze,
and vetting it for precisely these sorts of problems (and that work
is still ongoing).  There are slides from one of the IETF meetings
documenting some of that process -- and there are things that should
be obvious from even a cursory look at the code - like Opus actually
has a test suite, with near complete code coverage, that fuzzes the
code intelligently on every run etc. etc.

I won't go so far as to claim it's completely bug free.  But people
actually care if there is even a hint that it isn't.  We're in an
entirely different phase of the development now, where release
polishing is at the forefront of What Matters to the maintainers.
No version of celt had that sort of attention, especially not one
as old as 0.7.1.


 <Diziet> What's weird is why don't we have references to this vuln ?

It's not really that weird.  As per the above Thorvald and I became
solely responsible for celt 0.7.1 when we decided to include it in
squeeze - so there is nobody else spending any time on this - and
you never before asked me, or apparently the mumble upstream people
you said you spoke to, for any such further detail :)

 <Diziet> If so we could see "can we apply the patch to celt" which
          might be interesting info.

The mumble upstream folk were given a (not exhaustive) list of commits
to look at when this first came to our attention - and I asked them
about their progress with those again last week.  I got the same reply
as I did initially though:

The patches don't directly apply to the older code, and far too much
had changed for there to be any trivial mapping back to it that they
were able to follow.  Which doesn't mean the problems don't exist in
the old code, just that the places where a fix was later applied did
not make this easy to answer with any confidence.

If somebody has time to volunteer to analyse this in more detail, then
I'm sure we can get them more information.  I'd be delighted if that
resulted in a plausible belief that the old code really is safe still,
or patches to make it so.  I just don't buy people telling me "pfft,
it's fine" when they haven't looked at all - after a person who had
done much of the insanely thorough testing of this code told me that
they thought it wasn't ...


 <rra> Backing up a little bit: Assume that we all decide that it's
       okay to reintroduce celt.  Do we actually have someone who is
       willing to do the work of reintroducing celt into the archive?
       I mean, is Ron willing to do that, or is someone else willing
       and capable to do it if Ron doesn't want to be stuck supporting
       it because he doesn't agree with it?

We don't really want to reintroduce celt as a public package whatever
is decided here.  There really is nothing except mumble with any excuse
to still be using this now.  So the main question is, are we comfortable
shipping mumble with it enabled as a private lib?

Simply uploading that is a no-brainer, anyone can do it, and I won't
refuse to do that if that's where consensus lands and Thorvald doesn't
have time to do so.

But I only committed to being responsible for celt 0.7.1 until we had a
bitstream frozen version to ship, which we now do, and Thorvald doesn't
appear to have the time to commit to that for another release cycle
either.  So my big concern is that we have nobody stepping in to fill
the gap of an "upstream" maintainer, who will diligently investigate
issues like this rather than just say "I'll worry about it when someone
else sends me a patch" ...


 <rra> vorlon: My understanding was that we were unsure whether the
       existing clients out there in the world that speak celt would
       actually negotiate speex.

As I mentioned above, there is no negotiation for this.  If you have a
client that can encode speex, it can just send it and any other client
will be able to decode it.  But that's kind of orthogonal to what they
will send you.  They could send you Opus in return, and if you don't
have a client that can decode Opus, then you won't be able to hear them.

The lack of real bi-directional negotiation is part of why this is such
a mess in the transition period, but that's sort of fundamental to the
way the server operates and can't trivially be fixed.


 <Diziet> But AIUI that would involve downgrading all the clients in
          a channel to speex which might well be unacceptable to the
          userbase effectively making our version of the mumble client
          unuseable in those contexts.

Talking about "downgrading" to speex is only meaningful when comparing
it to opus.  Celt isn't a speech coder, so it doesn't perform well under
conditions where speex does, and vice versa.  Neither is clearly "down"
from the other, at least not when comparing with celt 0.7.1.  They are
different tools, specialised for different jobs.

It would be just as valid to say that "downgrading to celt 0.7.1" would
have the effect you mention.  And that's empirically true because there
are already people blocking its use on their servers, and the number of
people doing that will only grow over the lifetime of Wheezy now that
they can do it just by setting opusthreshold instead of hacking at the
code to change the permitted celt versions.

Celt 0.7.1 gives poor results at bitrates where both opus and speex shine.


 <Diziet> dondelelcaro: I think we know that if we reenable the embedded
          celt it will work as intended with existing clients.

We do gain an extra possible dimension of interoperability.  Unfortunately
that's not enough on its own to ensure it will work with other existing
clients and servers - either at all, or with acceptable results.  And even
mumble upstream is hoping to be able to phase out all codecs other than
opus in a shorter time than the lifecycle of Wheezy.

I agree the backward compatibility issue is important.  But "existing
clients" is currently not a stationary target either.  If we lock this
into another stable release, we are likely to be the last ones left
carrying the hot potato alone, long after it stops actually being useful
to anyone.


 <vorlon> I want to see what actually happens when two clients connect
          to a server having only speex in common
 <vorlon> right now we don't have such a test

If you set the requested bandwidth in both clients to 32kbs or less,
then that's exactly what will happen (if you have old enough clients
to still have speex encoding support :)

Lying about the celt version so that clients thought they didn't have
anything else in common was the crux of the trick Thorvald thought we
could pull though as I understood it, yeah.


Of which I sadly have no new news at this stage ... :(

Thorvald is back, but the other mumble upstream folk and I only got to
talk to him for a couple of minutes before "Argh. Work. gotta go. bbl."
And he hasn't yet been back again ...


On the brighter side, he has got upstream snapshots rolling again, so
there are opus enabled clients getting around and more testing has been
happening on those.  And the other upstream folk and I have had some
reasonably productive discussions on mitigation and interop issues.

We're still talking about getting speex put back into the client, which
seems to be getting some agreement, but we're not quite all said and done
on that just yet.  There's a couple of things that still need looking at.

They've added a config option for the client now, which permits users to
disable celt - which at least gives people an option to turn it off fast
should that be needed faster than we can push code updates.

And the SECCOMP sandboxed version of celt has been pushed upstream now.
The guy who worked on that sounds like he's pretty happy with it, but I
looked at the code and do worry that it's probably too big a change to
push into a stable release without more live testing, and probably a
few other pairs of eyes auditing it.  It seems to be a good answer that
I don't totally want to take off the table, but probably not something
that could seriously be considered for wheezy proper without more people
taking an intense interest in it very soon.


So whichever way you slice it - we still don't have a one-true killer
solution here yet that's clearly without fault.  My gut feeling is
still kind of saying we should target bpo, where we can push upstream
fixes as fast as they come, since it looks like that is going to be
needed for a while - but that answer sucks for another group of people
too ...


Anyhow, way too many words, sorry about that - and there's still lots
I haven't covered - but I'm playing this with an open hand, so if
there's questions, do ask them, please.  And I'll try to give shorter
answers ...


 <rra> Damn, can't get someone else to do the work for us.  :)

That's kind of the perfect summary of the mess we're immersed in, yeah :)


 Ron





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 13 Aug 2012 20:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 13 Aug 2012 20:06:03 GMT) Full text and rfc822 format available.

Message #453 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Interoperability with speex patch
Date: Mon, 13 Aug 2012 16:02:39 -0400
[Message part 1 (text/plain, inline)]
On Sunday, August 12, 2012 14:36:34, Ron wrote:
[…]
> Celt was an entirely experimental codebase, each 'version' of it that
> was tagged existed *only* for testing the quality of the audio that it
> produced.  Next to no attention was paid to the normal "release issues"
> of a piece of "production" software beyond what other people submitted
> as patches.  Once the listening test results were in, code was changed,
> the bitstream broken as/if needed, and audio quality testing continued.
> 
> Being free software, and an experiment conducted fully in the open,
> people were free to do with it what they wished -- but if they did,
> the onus was *entirely* on them to worry about release quality and
> maintenance issues.  That's not something the upstream developers
> devoted any real attention to at all before the bitstream freeze.
> 
> Opus by comparison has its C code as the normative part of an IETF
> proposed standard.  An utterly insane number of hours went into
> QA testing it for "release issues" after the final bitstream freeze,
> and vetting it for precisely these sorts of problems (and that work
> is still ongoing).  There are slides from one of the IETF meetings
> documenting some of that process -- and there are things that should
> be obvious from even a cursory look at the code - like Opus actually
> has a test suite, with near complete code coverage, that fuzzes the
> code intelligently on every run etc. etc.
> 
> I won't go so far as to claim it's completely bug free.  But people
> actually care if there is even a hint that it isn't.  We're in an
> entirely different phase of the development now, where release
> polishing is at the forefront of What Matters to the maintainers.
> No version of celt had that sort of attention, especially not one
> as old as 0.7.1.

The web page for the Opus codec [1] shows that it's currently only a release 
candidate.  There isn't an official stable release yet; there are only 
development snapshots available.  That makes it seem as though Opus is still 
considered experimental at this stage.

[…]
>  <rra> Backing up a little bit: Assume that we all decide that it's
>        okay to reintroduce celt.  Do we actually have someone who is
>        willing to do the work of reintroducing celt into the archive?
>        I mean, is Ron willing to do that, or is someone else willing
>        and capable to do it if Ron doesn't want to be stuck supporting
>        it because he doesn't agree with it?
> 
> We don't really want to reintroduce celt as a public package whatever
> is decided here.  There really is nothing except mumble with any excuse
> to still be using this now.  So the main question is, are we comfortable
> shipping mumble with it enabled as a private lib?

Shipping Mumble with CELT as a private lib is what most of the non-Debian free 
distributions are doing.  Interestingly, all of the non-Debian free 
distributions also include an additional version of CELT over 0.7.1 as well.  
Usually 0.11.0 but two distributions ship a CELT lib that Mumble reports as 
"2.0.0" -- Fedora 17 and Magia 2.

>  <Diziet> But AIUI that would involve downgrading all the clients in
>           a channel to speex which might well be unacceptable to the
>           userbase effectively making our version of the mumble client
>           unuseable in those contexts.
> 
> Talking about "downgrading" to speex is only meaningful when comparing
> it to opus.  Celt isn't a speech coder, so it doesn't perform well under
> conditions where speex does, and vice versa.  Neither is clearly "down"
> from the other, at least not when comparing with celt 0.7.1.  They are
> different tools, specialised for different jobs.
> 
> It would be just as valid to say that "downgrading to celt 0.7.1" would
> have the effect you mention.  And that's empirically true because there
> are already people blocking its use on their servers, and the number of
> people doing that will only grow over the lifetime of Wheezy now that
> they can do it just by setting opusthreshold instead of hacking at the
> code to change the permitted celt versions.

If you're going to make the claim that people are blocking CELT then you need 
to state who you've found doing this, becasue I've now tested the top 25 free 
software distributions [as measured by distrowatch.com], and of the 
distributions that ship Mumble, they all ship with CELT.  Out of all of these, 
only the Debian Sid version of Mumble ships with support for Opus.

I did not try to test all those distros for their version of mumble-server, 
and I suspect there is not likely to be time before we need to make a decision 
to allow doing so.

> Celt 0.7.1 gives poor results at bitrates where both opus and speex shine.
> 
> 
>  <Diziet> dondelelcaro: I think we know that if we reenable the embedded
>           celt it will work as intended with existing clients.
> 
> We do gain an extra possible dimension of interoperability.  Unfortunately
> that's not enough on its own to ensure it will work with other existing
> clients and servers - either at all, or with acceptable results.

Of the 19 other distributions that ship Mumble, all of them are compatible 
with CELT 0.7.1 (or will be -- Magia 2 has a bug because of library name 
mangling, so even though they ship a CELT 0.7.1 bundled library Mumble can't 
find the file -- this is being worked on to fix it) and I tested that (all but 
Magia 2) are currently interoperable.

[…]
> And the SECCOMP sandboxed version of celt has been pushed upstream now.
> The guy who worked on that sounds like he's pretty happy with it, but I
> looked at the code and do worry that it's probably too big a change to
> push into a stable release without more live testing, and probably a
> few other pairs of eyes auditing it.  It seems to be a good answer that
> I don't totally want to take off the table, but probably not something
> that could seriously be considered for wheezy proper without more people
> taking an intense interest in it very soon.

I also saw that show up in the upstream repo a couple of days ago, and it 
looks interesting.  I've been too busy with Mumble testing to look at it 
closely, though.

[1] http://opus-codec.org/

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 14 Aug 2012 15:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 14 Aug 2012 15:39:06 GMT) Full text and rfc822 format available.

Message #458 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 14 Aug 2012 16:36:33 +0100
I think the rate at which we are gaining new reliable information has
reached diminishing returns.  I think it is time to dispose of this
issue.

I think the right answer for a TC decision looks something like this:

  Context:

  1. The questions surrounding the codecs in mumble, especially celt,
     have been referred to the Technical Committee.

  2. The mumble maintainers have stated their willingness to follow
     our advice (Constitution 6.1(5)).  This may or may not amount to
     a delegation to us of the decision (6.1(3)) but in any case we
     merely need to state our reasoning and conclusions and are not
     being asked to overrule the maintainer.

  Release Critical status of celt 0.7.1 in mumble:

  3. mumble is a useful and fairly widely-used voice chat program.

  4. Distributions of mumble (from other distros and upstream)
     currently implement the celt 0.7.1 codec as a baseline.  It does
     not appear to the TC that (in wheezy) the provision of any other
     codec obviates the need for mumble to support celt 0.7.1.

  4. Consequently, we consider the lack of celt 0.7.1 support in
     mumble a release-critical bug.

  Security risks from celt 0.7.1:

  5. While the upstream security support situation for celt 0.7.1 is
     not ideal, the TC does not consider that the security risks
     associated with celt 0.7.1 in mumble are intolerable.

  6. The Debian Security Team have stated that they have no objection
     to including celt 0.7.1 in mumble in wheezy.

  7. Consequently, mumble should remain in wheezy with celt 0.7.1
     (the alternative being to remove mumble as unfit for release).

  Packaging approach:

  7. There are no other packages intended for wheezy which ought to
     want this codec.

  8. Providing separate celt library in wheezy is undesirable because
     it might promote the use of a codec which we are planning to
     retire in the medium to long term.

  9. While embedded code copies are in general to be avoided because
     lead to proliferation of multiple versions, that therefore does
     not apply in this case.

  10. The upstream mumble source already contemplates building with
     various embedded versions of celt.

  11. There is no reason to support any other version of celt in
     mumble.

  12. Consequently, the mumble source package should be configured to
     use an embedded copy of celt 0.7.1.  (If necessary the embedded
     copy of celt in the source package should be updated to the
     actual 0.7.1.)

  We therefore recommend that:

  13. The mumble maintainers, with appropriate help from other
     interested parties, should prepare an upload of mumble for wheezy
     with
       - embedded celt 0.7.1 enabled
       - no other version of celt enabled
       - whatever other release-critical bugfixes they consider
          relevant (subject to any appropriate discussion with the
          release team as necessary)
       - closing #675971.

  14. #675971 should remain at an RC severity, be untagged wontfix,
     and maintained open until it is closed as discussed above.

  15. If the release team are content with the other changes
     in the new mumble package, the new version should be unblocked
     to propagate into wheezy.

  16. After that propagation, the separate celt packages should be
     removed from wheezy.  This should be requested by the celt
     maintainer filing a removal bug in the normal way, after mumble
     with embedded celt 0.7.1 has propagated to wheezy.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Tue, 14 Aug 2012 15:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 14 Aug 2012 15:48:03 GMT) Full text and rfc822 format available.

Message #463 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Tue, 14 Aug 2012 16:46:09 +0100
Ian Jackson writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
>   13. The mumble maintainers, with appropriate help from other
>      interested parties, should prepare an upload of mumble for wheezy
>      with

On rereading, "prepare an upload of mumble for wheezy" is wrong.  I
should say something like "upload to sid, intended for wheezy, a
version of mumble with".

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 16 Aug 2012 08:42:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 16 Aug 2012 08:42:13 GMT) Full text and rfc822 format available.

Message #468 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org, 675971@bugs.debian.org
Cc: Thorvald Natvig <thorvald@debian.org>
Subject: Tables of Mumble client compatability
Date: Thu, 16 Aug 2012 04:41:26 -0400
[Message part 1 (text/plain, inline)]
At the same time I tested the two proposed patches for the "348" version of 
Mumble in Wheezy, I also took the time to test the top 25 free software 
distributions [as per distrowatch.com] to check for interoperability and what 
support those distributions were including.

These tests used the "348"-1.1 patched mumble-server, and a amd64 Debian Sid 
host running "348"-1.1 patched for using bundled celt 0.7.1.  Distributions 
were loaded into a VirtualBox VM; "Interop" makred as "Y" indicates that audio 
output was heard from the VM through the host while Mumble in the host had the 
mic muted.

One notable oddity: the highest version of the CELT codec is 0.11.1, but 
Mumble reports CELT version 2.0.0 in Fedora 17 and Mageia 2, seemingly due to 
library filename renaming done in these distributions.

                                                Extra
                                          Celt  Celt                Server
Distro version (mumble version)           0.7.1 Vers.+ Opus Interop Loopback 
-----------------------------------------|-----|------|----|-------|--------|
*Mint Debian 201204 (1.2.3-3)            |  Y  |      |    |   Y   |    Y   |
*Linux Mint 13 (1.2.3-2ubuntu4)          |  Y  |      |    |   Y   |    Y   |
*Ubuntu 12.04 (1.2.3-2ubuntu4)           |  Y  |      |    |   Y   |    Y   |
Mageia 2 (1.2.3-2.mga2)               [3]|     | 2.0.0|    |       |   [1]  |
Fedora 17 (1.2.3-7.fc17.1)               |  Y  | 2.0.0|    |   Y   |    Y   |
openSUSE 12.1 (1.2.3-10.3.1)             |  Y  |0.11.0|    |   Y   |    Y   |
*Debian Sid (1.2.3-349-g315b5f5-2)       |     |      |  Y |       |   [4]  |
*Debian Wheezy (1.2.3-348-g317f5a0-1)    |  Y  |      |    |   Y   |    Y   |
*Debian Squeeze (1.2.2-6+squeeze1)       |  Y  |      |    |   Y   |    Y   |
Arch Linux 2012-08-04 (1.2.3-5)          |  Y  |0.11.0|    |   Y   |   [1]  |
*Ultimate 3.4 (1.2.3-2ubuntu4)           |  Y  |      |    |   Y   |   [2]  |
*Lubuntu 12.04 (1.2.3-2ubuntu4)          |  Y  |      |    |   Y   |   [2]  |
*Pear Linux 5 (1.2.3-2ubuntu4)           |  Y  |      |    |   Y   |    Y   |
Sabayon Linux 9 (1.2.3-r2~0)             |  Y  |0.11.0|    |   Y   |   [1]  |
*Zorin OS 6 (1.2.3-2ubuntu4)             |  Y  |      |    |   Y   |    Y   |
Chakra 2012.07 (1.2.3-3)                 |  Y  |0.11.0|    |   Y   |    Y   |
*Bodhi 2.0.1 (1.2.3-2ubuntu4)            |  Y  |      |    |   Y   |   [1]  |
*Snowlinux 2 "Ice" (1.2.2-6+squeeze1)    |  Y  |      |    |   Y   |    Y   |
*Snowlinux 2 "Cream" (1.2.3-2ubuntu4)    |  Y  |      |    |   Y   |    Y   |
Gentoo 12.1 (1.2.3-r2)                   |  Y  |0.11.0|    |  [6]  |   [1]  |
Vector Linux 7.0 (1.2.3-i586-2vl70)   [5]|  Y  |0.11.0|    |   Y   |    Y   |
*CrunchBang 10 (1.2.2-6+squeeze1)        |  Y  |      |    |   Y   |    Y   |
*SolusOS Eveline 1.1 (1.2.3-3solus1)     |  Y  |      |    |   Y   |    Y   |
*Knoppix 7.03 DVD (1.2.3-348-g317f5a0-1) |  Y  |      |    |   Y   |    Y   |
-----------------------------------------|-----|------|----|-------|--------|
*Debian Wheezy "348"-1.1 bundled-celt [7]|  Y  |      |    |   Y   |    Y   |
*Debian Wheezy "348"-1.1 celt-lib     [7]|  Y  |      |    |   Y   |    Y   |
-----------------------------------------|-----|------|----|-------|--------|
CentOS 6.3         (not in distro)
Slacko Puppy 5.3.3 (not in distro)
*Lucid Puppy 5.2.8 (not in distro)
*PCLinuxOS 2012.02 (not in distro)
FreeBSD 9          (not in distro)
Slackware 13       (not in distro)
Fuduntu 2012.3     (not in distro)


*   Distro is Debian-based
+   Extra CELT codec version available as reported by Mumble
[1] Audio output did not work, so could not test server loopback
[2] Audio did function, but could not get audio output working in Mumble
[3] The bundled libcelt 0.7.1 in Mageia 2 for Mumble has a known bug related
    to library filename mangling which is why it is not interoperable.
    The Mageia QA team are working to fix it.
       https://bugs.mageia.org/show_bug.cgi?id=6581
[4] Server loopback for "349"-2 only works if all connected clients support
    the OPUS codec
[5] Mumble is only in the "testing" repository in Vector Linux
[6] It took 3 full days to get a Gentoo base system and KDE4 installed using
    the standard instructions, after which X wouldn't start; Mumble was tested
    via ssh X forwarding without audio
[7] "348"-1.1 = 1.2.3-348-g317f5a0 with proposed patches



  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 20 Aug 2012 15:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 20 Aug 2012 15:18:05 GMT) Full text and rfc822 format available.

Message #473 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Subject: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Mon, 20 Aug 2012 11:15:54 -0400
Ron --

Can you please let me know the procedure for how to verify the orig tarball 
for the "349" version in Debian Sid?

Up to and including the "348" version of Mumble in Wheezy that Patrick Matthäi 
had been packaging, the tarballs clearly came from the upstream snapshots 
located at [1], so those are simple to verify via 'diff' directly.

But the "349" version in Debian Sid doesn't come from there; instead the 
tarball is somehow created from the upstream Git repo.  'pristine-tar list' 
doesn't come up with any tarballs, so in a local clone of the upstream Git 
repo I did a checkout on commit 315b5f587910983d764955f456fe64e696a786cc that 
the "349" orig tarball seems to be based on, a checkout of commit 
43a04a7e813d3e420409c5465b71af148e779717 in your Git tree that the "349" orig 
tarball seems to be based on -- but when I try to compare the directories I 
see a bunch of files that are only in the upstream directory or vice-versa.

So would you mind giving me a pointer for how to verify the tarball?
Thanks.

[1] http://mumble.info/snapshot/

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Wed, 22 Aug 2012 07:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 22 Aug 2012 07:24:03 GMT) Full text and rfc822 format available.

Message #478 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
Date: Wed, 22 Aug 2012 03:21:33 -0400
[Message part 1 (text/plain, inline)]
On Tuesday, August 14, 2012 11:36:33, Ian Jackson wrote:
[…]
>   13. The mumble maintainers, with appropriate help from other
>      interested parties, should prepare an upload of mumble for wheezy
>      with
>        - embedded celt 0.7.1 enabled
>        - no other version of celt enabled
>        - whatever other release-critical bugfixes they consider
>           relevant (subject to any appropriate discussion with the
>           release team as necessary)
>        - closing #675971.

Option 1:

I've prepared another version of Mumble based on the mumble-1.2.3-412-g6c9694d 
release snapshot on August 3rd.  This pacakge is built as described above, and 
also supports Opus via the Debian opus system library which uses Opus version 
0.9.14.  I've tested:

   - communication via Opus with the "349"-2 version in Sid
   - communication via Opus with another version of the "412" pacakge
     that uses the embedded 0.9.8 version of Opus that ships with the
     Mumble upstream source
   - communication via Celt 0.7.1 with several other clients



Option 2:

Using the mumble-348-fixes-embedded patch I sent on Aug 1st, and upload a new 
version of "348" that's in Wheezy.  [Needs modification to add a Closes: 
#675971 in the changelog.]  I haven't yet gotten any feedback on the patch.

Related question: Can a DD upload a package to Sid with a lower version number 
than what is currently in the archive?



Option 3:

Manipulate the "349"-2 source in Sid, fix it, and upload a "349"-3.  I was 
investigating this in order to minimize the diff necessary, but I'm not sure 
what all of the implications are of the modifications done to the 
"orig.tar.gz" tarball compared to the upstream repo it's based on.  Some of 
the changes simply look like they might be innocuous autoconf stuff added, but 
there are also some scripts and build files removed.  File containing the list 
of differences attached.  This option would inolve reverting one Git commit in 
order to remove debian/patches/10-use-celt-guard.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[mumble-sid-349-differences.txt (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 24 Aug 2012 15:06:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 24 Aug 2012 15:06:07 GMT) Full text and rfc822 format available.

Message #483 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 682010@bugs.debian.org
Subject: Call for votes on CELT in Mumble
Date: Fri, 24 Aug 2012 16:03:31 +0100
I previously proposed this.  I have added a sentence to para 4 about
the results of Chris's interop tests and fixed the paragraph
numbering.

I'm calling for a vote.  The options are:

 A  Recommend to mumble maintainers to support bundled celt 0.7.1
 F  Further discussion

The full resolution text I'm proposing:

  Context:

  1. The questions surrounding the codecs in mumble, especially celt,
     have been referred to the Technical Committee.

  2. The mumble maintainers have stated their willingness to follow
     our advice (Constitution 6.1(5)).  This may or may not amount to
     a delegation to us of the decision (6.1(3)) but in any case we
     merely need to state our reasoning and conclusions and are not
     being asked to overrule the maintainer.

  Release Critical status of celt 0.7.1 in mumble:

  3. mumble is a useful and fairly widely-used voice chat program.

  4. Distributions of mumble (from other distros and upstream)
     currently implement the celt 0.7.1 codec as a baseline.  It does
     not appear to the TC that (in wheezy) the provision of any other
     codec obviates the need for mumble to support celt 0.7.1.
     mumble with celt 0.7.1 has been tested and found to interoperate
     properly with nearly all other mumble versions.

  5. Consequently, we consider the lack of celt 0.7.1 support in
     mumble a release-critical bug.

  Security risks from celt 0.7.1:

  6. While the upstream security support situation for celt 0.7.1 is
     not ideal, the TC does not consider that the security risks
     associated with celt 0.7.1 in mumble are intolerable.

  7. The Debian Security Team have stated that they have no objection
     to including celt 0.7.1 in mumble in wheezy.

  8. Consequently, mumble should remain in wheezy with celt 0.7.1
     (the alternative being to remove mumble as unfit for release).

  Packaging approach:

  9. There are no other packages intended for wheezy which ought to
     want this codec.

  10. Providing separate celt library in wheezy is undesirable because
     it might promote the use of a codec which we are planning to
     retire in the medium to long term.

  11. While embedded code copies are in general to be avoided because
     lead to proliferation of multiple versions, that therefore does
     not apply in this case.

  12. The upstream mumble source already contemplates building with
     various embedded versions of celt.

  13. There is no reason to support any other version of celt in
     mumble.

  14. Consequently, the mumble source package should be configured to
     use an embedded copy of celt 0.7.1.  (If necessary the embedded
     copy of celt in the source package should be updated to the
     actual 0.7.1.)

  We therefore recommend that:

  15. The mumble maintainers, with appropriate help from other
     interested parties, should prepare an upload of mumble for wheezy
     with
       - embedded celt 0.7.1 enabled
       - no other version of celt enabled
       - whatever other release-critical bugfixes they consider
          relevant (subject to any appropriate discussion with the
          release team as necessary)
       - closing #675971.

  16. #675971 should remain at an RC severity, be untagged wontfix,
     and maintained open until it is closed as discussed above.

  17. If the release team are content with the other changes
     in the new mumble package, the new version should be unblocked
     to propagate into wheezy.

  18. After that propagation, the separate celt packages should be
     removed from wheezy.  This should be requested by the celt
     maintainer filing a removal bug in the normal way, after mumble
     with embedded celt 0.7.1 has propagated to wheezy.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 24 Aug 2012 16:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 24 Aug 2012 16:09:05 GMT) Full text and rfc822 format available.

Message #488 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Call for votes on CELT in Mumble
Date: Fri, 24 Aug 2012 12:08:03 -0400
On Friday, August 24, 2012 11:03:31, Ian Jackson wrote:
[…]
>   14. Consequently, the mumble source package should be configured to
>      use an embedded copy of celt 0.7.1.  (If necessary the embedded
>      copy of celt in the source package should be updated to the
>      actual 0.7.1.)

We figured out a month ago that Celt 0.7.1 in the Debian system library and 
the version in the upstream Mumble source for embedding are the same.  [1]  
I'll copy it again here for convenience:

   $ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt
   Only in celt-0.7.1/libcelt: Makefile.in

[1] http://lists.debian.org/debian-ctte/2012/07/msg00333.html

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 24 Aug 2012 16:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 24 Aug 2012 16:18:05 GMT) Full text and rfc822 format available.

Message #493 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Call for votes on CELT in Mumble
Date: Fri, 24 Aug 2012 17:16:01 +0100
Chris Knadle writes ("Bug#682010: Call for votes on CELT in Mumble"):
> On Friday, August 24, 2012 11:03:31, Ian Jackson wrote:
> […]
> >   14. Consequently, the mumble source package should be configured to
> >      use an embedded copy of celt 0.7.1.  (If necessary the embedded
> >      copy of celt in the source package should be updated to the
> >      actual 0.7.1.)
> 
> We figured out a month ago that Celt 0.7.1 in the Debian system library and 
> the version in the upstream Mumble source for embedding are the same.  [1]  
> I'll copy it again here for convenience:

Right.

>    $ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt
>    Only in celt-0.7.1/libcelt: Makefile.in
> 
> [1] http://lists.debian.org/debian-ctte/2012/07/msg00333.html

But you might want to rename it.  I don't think we (the TC) need to
have an opinion about that.  I don't want to tie the mumble
maintainers' hands on these kinds of details.

But if you would be happier I can withdraw the version above and ask
for a vote on a text without the parenthetical comment.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 24 Aug 2012 16:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 24 Aug 2012 16:39:03 GMT) Full text and rfc822 format available.

Message #498 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Call for votes on CELT in Mumble
Date: Fri, 24 Aug 2012 12:37:22 -0400
On Friday, August 24, 2012 12:16:01, Ian Jackson wrote:
> Chris Knadle writes ("Bug#682010: Call for votes on CELT in Mumble"):
> > On Friday, August 24, 2012 11:03:31, Ian Jackson wrote:
> > […]
> > 
> > >   14. Consequently, the mumble source package should be configured to
> > >   
> > >      use an embedded copy of celt 0.7.1.  (If necessary the embedded
> > >      copy of celt in the source package should be updated to the
> > >      actual 0.7.1.)
> > 
> > We figured out a month ago that Celt 0.7.1 in the Debian system library
> > and the version in the upstream Mumble source for embedding are the
> > same.  [1]
> 
> > I'll copy it again here for convenience:
>
> Right.
> 
> >    $ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt
> >    Only in celt-0.7.1/libcelt: Makefile.in
> > 
> > [1] http://lists.debian.org/debian-ctte/2012/07/msg00333.html
> 
> But you might want to rename it.  I don't think we (the TC) need to
> have an opinion about that.  I don't want to tie the mumble
> maintainers' hands on these kinds of details.

It would be nice to do eventually; i.e. renaming celt-0.7.0 to celt-0.7.1 to 
make it clear what version Mumble actually had in it.  There are several of 
these little things I'd like to send upstream patches or Git pull requests 
for, but I don't think it's necessary to deal with it now.

Likewise I found that the mumble upstream source currently builds in Opus 
version 0.9.8, but the library comes out named as "libopus.so.0.0.0" which 
again is non-intuitive as to what version it actually is.  This doesn't really 
matter for the version in Debian because it will use Debian's libopus0 library 
instead (which contains Opus version 0.9.14, which I found to be compatible).

> But if you would be happier I can withdraw the version above and ask
> for a vote on a text without the parenthetical comment.

I thank you for the offer, but I don't think that's necessary.  Fine as-is.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Fri, 24 Aug 2012 17:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 24 Aug 2012 17:39:03 GMT) Full text and rfc822 format available.

Message #503 received at 682010@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Call for votes on CELT in Mumble
Date: Fri, 24 Aug 2012 18:37:42 +0100
Ian Jackson writes ("Bug#682010: Call for votes on CELT in Mumble"):
> I previously proposed this.  I have added a sentence to para 4 about
> the results of Chris's interop tests and fixed the paragraph
> numbering.
> 
> I'm calling for a vote.  The options are:
> 
>  A  Recommend to mumble maintainers to support bundled celt 0.7.1
>  F  Further discussion

I vote A F

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Mon, 27 Aug 2012 18:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 27 Aug 2012 18:45:03 GMT) Full text and rfc822 format available.

Message #508 received at 682010@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 682010@bugs.debian.org
Subject: Re: Bug#682010: Call for votes on CELT in Mumble
Date: Mon, 27 Aug 2012 11:43:51 -0700
On Fri, 24 Aug 2012, Ian Jackson wrote:
> I previously proposed this.  I have added a sentence to para 4 about
> the results of Chris's interop tests and fixed the paragraph
> numbering.
> 
> I'm calling for a vote.  The options are:
> 
>  A  Recommend to mumble maintainers to support bundled celt 0.7.1
>  F  Further discussion

I vote AF.
 

Don Armstrong

-- 
Sentenced to two years hard labor (for sodomy), Oscar Wilde stood
handcuffed in driving rain waiting for transport to prison.  "If this
is the way Queen Victoria treats her prisoners," he remarked, "she
doesn't deserve to have any."

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 30 Aug 2012 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 30 Aug 2012 17:27:03 GMT) Full text and rfc822 format available.

Message #513 received at 682010@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: 682010@bugs.debian.org
Subject: Re: Call for votes on CELT in Mumble
Date: Thu, 30 Aug 2012 19:08:52 +0200
* Ian Jackson (ijackson@chiark.greenend.org.uk) [120824 15:03]:
> I'm calling for a vote.  The options are:
> 
>  A  Recommend to mumble maintainers to support bundled celt 0.7.1
>  F  Further discussion

I vote AF.


Andi



Reply sent to Don Armstrong <don@debian.org>:
You have taken responsibility. (Thu, 30 Aug 2012 18:15:08 GMT) Full text and rfc822 format available.

Notification sent to Chris.Knadle@coredump.us:
Bug acknowledged by developer. (Thu, 30 Aug 2012 18:15:08 GMT) Full text and rfc822 format available.

Message #518 received at 682010-done@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 682010-done@bugs.debian.org
Subject: Re: Bug#682010: Call for votes on CELT in Mumble
Date: Thu, 30 Aug 2012 11:12:24 -0700
With the vote of Andreas, the outcome is no longer in doubt.
Therefore, the Technical Committee resolves:


  Context:

  1. The questions surrounding the codecs in mumble, especially celt,
     have been referred to the Technical Committee.

  2. The mumble maintainers have stated their willingness to follow
     our advice (Constitution 6.1(5)).  This may or may not amount to
     a delegation to us of the decision (6.1(3)) but in any case we
     merely need to state our reasoning and conclusions and are not
     being asked to overrule the maintainer.

  Release Critical status of celt 0.7.1 in mumble:

  3. mumble is a useful and fairly widely-used voice chat program.

  4. Distributions of mumble (from other distros and upstream)
     currently implement the celt 0.7.1 codec as a baseline.  It does
     not appear to the TC that (in wheezy) the provision of any other
     codec obviates the need for mumble to support celt 0.7.1.
     mumble with celt 0.7.1 has been tested and found to interoperate
     properly with nearly all other mumble versions.

  5. Consequently, we consider the lack of celt 0.7.1 support in
     mumble a release-critical bug.

  Security risks from celt 0.7.1:

  6. While the upstream security support situation for celt 0.7.1 is
     not ideal, the TC does not consider that the security risks
     associated with celt 0.7.1 in mumble are intolerable.

  7. The Debian Security Team have stated that they have no objection
     to including celt 0.7.1 in mumble in wheezy.

  8. Consequently, mumble should remain in wheezy with celt 0.7.1
     (the alternative being to remove mumble as unfit for release).

  Packaging approach:

  9. There are no other packages intended for wheezy which ought to
     want this codec.

  10. Providing separate celt library in wheezy is undesirable because
     it might promote the use of a codec which we are planning to
     retire in the medium to long term.

  11. While embedded code copies are in general to be avoided because
     lead to proliferation of multiple versions, that therefore does
     not apply in this case.

  12. The upstream mumble source already contemplates building with
     various embedded versions of celt.

  13. There is no reason to support any other version of celt in
     mumble.

  14. Consequently, the mumble source package should be configured to
     use an embedded copy of celt 0.7.1.  (If necessary the embedded
     copy of celt in the source package should be updated to the
     actual 0.7.1.)

  We therefore recommend that:

  15. The mumble maintainers, with appropriate help from other
     interested parties, should prepare an upload of mumble for wheezy
     with
       - embedded celt 0.7.1 enabled
       - no other version of celt enabled
       - whatever other release-critical bugfixes they consider
          relevant (subject to any appropriate discussion with the
          release team as necessary)
       - closing #675971.

  16. #675971 should remain at an RC severity, be untagged wontfix,
     and maintained open until it is closed as discussed above.

  17. If the release team are content with the other changes
     in the new mumble package, the new version should be unblocked
     to propagate into wheezy.

  18. After that propagation, the separate celt packages should be
     removed from wheezy.  This should be requested by the celt
     maintainer filing a removal bug in the normal way, after mumble
     with embedded celt 0.7.1 has propagated to wheezy.


Don Armstrong

-- 
I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 30 Aug 2012 18:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 30 Aug 2012 18:54:03 GMT) Full text and rfc822 format available.

Message #523 received at 682010@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 682010@bugs.debian.org
Subject: alternatives to mumble
Date: Thu, 30 Aug 2012 20:51:06 +0200

This is not a comment in support of or against Mumble, rather, it is
looking beyond Mumble

A few weeks ago I put up a wiki page about alternatives to mumble:

   http://wiki.debian.org/AlternativesToMumble

and I've put up an ITP (sponsor needed) for SylkServer (supports SIP,
Jabber and IRC conferencing)

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682698

Ultimately, the widespread deployment of standards-based solutions (such
as SylkServer and others mentioned in the wiki) should eliminate any
need for anyone to run Mumble and then celt can be put to rest.

It should be emphasized that many of the open solutions using standard
codecs interact very well.  The only reason Mumble has become prominent
is the convenience of setting it up compared to something like Asterisk
MeetMe.

For example, I run an Asterisk `MeetMe' conference room with about 5
codecs enabled.  I call in from a Polycom SIP phone on my desk, another
person calls in from a Google Talk client on iPhone (using Jabber).
Completely different platforms, standard codecs, all works together.

It would be good to get feedback on the ITP and wiki and maybe even a
sponsor?



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 30 Aug 2012 20:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 30 Aug 2012 20:30:06 GMT) Full text and rfc822 format available.

Message #528 received at 682010@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Daniel Pocock <daniel@pocock.com.au>, 682010@bugs.debian.org
Subject: Re: Bug#682010: alternatives to mumble
Date: Thu, 30 Aug 2012 16:26:45 -0400
On Thursday, August 30, 2012 14:51:06, Daniel Pocock wrote:
> This is not a comment in support of or against Mumble, rather, it is
> looking beyond Mumble
> 
> A few weeks ago I put up a wiki page about alternatives to mumble:
> 
>    http://wiki.debian.org/AlternativesToMumble
> and I've put up an ITP (sponsor needed) for SylkServer (supports SIP,
> Jabber and IRC conferencing)
>
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682698

I'd like to discuss this in the ITP above rather than in this bug report, but 
I'll mention that I caught your DebConf12 talk "Free (as in freedom) 
communications, VoIP and messaging":

   http://penta.debconf.org/dc12_schedule/events/933.en.html

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#682010; Package tech-ctte. (Thu, 30 Aug 2012 20:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 30 Aug 2012 20:39:05 GMT) Full text and rfc822 format available.

Message #533 received at 682010@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: Chris.Knadle@coredump.us
Cc: 682010@bugs.debian.org
Subject: Re: Bug#682010: alternatives to mumble
Date: Thu, 30 Aug 2012 22:34:44 +0200

On 30/08/12 22:26, Chris Knadle wrote:
> On Thursday, August 30, 2012 14:51:06, Daniel Pocock wrote:
>> This is not a comment in support of or against Mumble, rather, it is
>> looking beyond Mumble
>>
>> A few weeks ago I put up a wiki page about alternatives to mumble:
>>
>>    http://wiki.debian.org/AlternativesToMumble
>> and I've put up an ITP (sponsor needed) for SylkServer (supports SIP,
>> Jabber and IRC conferencing)
>>
>>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682698
> 
> I'd like to discuss this in the ITP above rather than in this bug report, but 
> I'll mention that I caught your DebConf12 talk "Free (as in freedom) 
> communications, VoIP and messaging":
> 
>    http://penta.debconf.org/dc12_schedule/events/933.en.html
> 

Thanks for feedback about that, I noticed how long the 682010 discussion
had become and I just couldn't help thinking that with this much
interest in the issue, there would be some momentum for discussing other
solutions (in the appropriate place of course)




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 28 Sep 2012 07:26:03 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 12:13:34 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.