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.kna...@coredump.us, Ron <r...@debian.org>, 682...@bugs.debian.org, 675...@bugs.debian.org, Nicos Gollan <gt...@spearhead.de>, Thorvald Natvig <thorv...@natvig.com> Don Armstrong -- Who is thinking this? I am. -- Greg Egan _Diaspora_ p38 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org