Re: roaraudio dispute
On Mon, Jul 23, 2012 at 03:24:12PM +0100, Ian Jackson wrote:
> Having said that I am concerned that there has been impropriety in the
> process. In
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675610
> Ron wrote
> We'd like to have nothing depending on roar for wheezy
> Without the background knowledge the most natural reading of that
> message is that there is some technical problem with roar which cannot
> easily be fixed, and that the roar maintainers agree. The maintainer
> of cmus took it as a request from the roaraudio maintainers to remove
> the dependency. That's how I would have read it too.
[…]
> So while I wanted to put all the above on the record, there may be
> little more to be done about it by the TC. (I have CC'd leader@ in
> case they want to take this up.)
Hi Ian et al., thanks for bringing me in the loop (even though I'm
following this discussion anyhow). If there is a trust problem, that
would be in fact up to DAM, but it's true that the DPL is generally kept
in the loop of those kinds of discussions.
For my part, I'm inclined to see no malice by default, unless the
contrary is proven. I understand what you mean when pointing to the
above bug report, and I agree a bit more clarity would have been
welcome. But there might be plenty of other honest reasons for saying
"we'd like to do $foo for Wheezy", other than impersonating a
maintainer. And given my no-malice-by-default principle, I do not see
malice there, just someone trying to make things work, according to his
own technical judgement (which might be wrong or not, but that's a
different matter).
I also expect the maintainer receiving such a bug report, to do some
technical verification before acting upon it. Failing that, and in case
the maintainers want to trust the bug reporter, I expect them to verify
the authoritativeness of the reporter.
All in all, I don't see any need to take further action on this part of
the dispute, ... but I'm looking forward to the conclusion of its other
parts!
Thanks for your work on this,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#682010: [mumble] Communication failures due to CELT codec library removal
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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207241059.29861.gt...@spearhead.de
Bug#682010: [mumble] Communication failures due to CELT codec library removal
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.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20494.37446.760315.144...@chiark.greenend.org.uk
Re: Bug#681834: network-manager, gnome, Recommends vs Depends
It seems to me that our objectives must include: 1. Users who do not do anything special should get network-manager along with gnome (in this case, along with gnome-core). These users should continue to have network-manager installed, across upgrades. 2. Users should be able to conveniently install and upgrade gnome without network-manager. 3. Users who deliberately removed network-manager in squeeze (which they will generally have done by deliberately violating the Recommends from the gnome metapackage) should not have to do anything special to avoid it coming back in wheezy. Other objectives which may be relevant include: 4. Users who do make a decision that they do not want to use network-manager should not have to read specific documentation, or temporarily have network-manager installed, risk being exposed to bugs in network-manager's configuration arrangements, and so on. 5. The `gnome-core' metapackage should in some sense perfectly or exactly correspond to upstream's notion of what `the gnome core' refers to. 6. Users who choose to globally disable Recommends should still get the desired behaviours as described above. Of these I can dispose of 6 quickly. I don't think anyone on the TC thinks that this is a requirement, or even a `nice to have' which is worth considering in this context. If you disable Recommends entirely you are responsible for the consequences. This has been extensively discussed and I think the conclusion is settled. 6 is irrelevant. And 4 merits a bit more discussion. It essentially implies that those users should not end up installing the n-m package, even transiently. This is because not installing a package is the simplest, clearest and most effective way of ensuring that it has no effect on the system. There have been approximately four approaches proposed: A. Users who want gnome without network-manager should allow it to be installed, and then disable it (with update-rc.d) or the like. As I understand it this is the gnome maintainers' view. B. Such users should forgo the use of the metapackages and install the relevant combinations of packages by hand. C. Some new metapackage(s) should be created which are like the gnome metapackages but contain different package selections and in particular do not have a hard dependency on network-manager. D. The dependency on network-manager from gnome-core in wheezy should be Recommends, not Depends. Now let us see how each of these options fares against our goals: A. B. C. D. refuseniks refuseniks createdemote to install n-m, do not use other Recommends disablemetapackagesmetapackages 1. n-m by Yes Yes Yes Yes default 2. gnomeYes Inconvenient Yes Yes without n-m 3. preserve No No NoYes[2] n-m removal squeeze->wheezy 4. no n-m No Yes Yes Yes means not installed 5. gnome-core Yes Yes Yes Maybe like upstream [1] [1] Whether gnome-core having a `Recommends' rather than a `Depends' on n-m satisfies this objective is rather subjective. Arguably it does. Indeed this reveals that this objective is in itself subjective: it is not a technical objective about the behaviour of actual computers. Rather it is a `marketing', `doctrinal' or `political' objective. Any actual technical content of this objective has been captured already by the other objectives in our list. Now the fact that some objective is in a sense `political' doesn't mean that we should dismiss it. Freedom - the ultimate goal of the whole project - is itself a political objective. But I would argue that the goal of conforming to gnome upstream's declarations about the content of gnome is much less important to Debian than the actual behaviour of the computers running Debian; and it is also much less important than the freedom of our users to make their computers do what they want (and that includes removing n-m even if gnome upstream don't approve). In particular I think that the requirement to honour in wheezy a user's decision to remove n-m in squeeze is important; it is not served by any of the other possibilities and certainly does not outweigh their advantages (if any). So on to: [2] I haven't tested this upgrade myself or peered at the algorithms in apt and aptitude but my understanding from Steve Langasek's message <20120717195515.gb21...@virgil.dodds.net> (Tue, 17 Jul 2012 12:55:15 -0700) is that in this situation n-m will not be reinstalled. Certainly if the dependency is a Depends then preventing the installation of n-m is practically impossible.
TC mailing list and BTS usage
Now that we are dealing with a number of issues simultaneously, and all getting a number of copies of lots of messages, I think we need to think about our workflow a bit better. We would like to - avoid spamming an existing bug with our deliberations (in particular, that makes it difficult to reassign the bug back usefully since the history will be obscured by a giant email thread) - allow people to subscribe to only some of the issues being discussed - organise the discussion in a way that makes it possible to find all of it easily without having to deal with multiple varying subject line keywords - everyone to get as few redundant mails as possible I propose the following scheme: 1. The first time an issue is referred to the TC, a new bug will be created which is filed against `debian-ctte'. This bug will be set to block all the other bug(s) involved. 1a. If an existing bug is reassigned to the TC, or other irregularities occur, before discussion starts the first person to reply in the context of the TC will ensure that this situation is rectified. This might involve creating the new bug and reassigning blocked bugs back to their originating packages. 1b. For avoidance of doubt, only bugs originally filed against the TC will be used for this purpose. 1c. If multiple such bugs are created they will be merged but we will use only the lowest-numbered for discussion. 2. The specially-created bug will be used for all discussion. All discussion will be CC'd to it. 3. Interested parties should subscribe to the bug when they become aware of the situation (for example by being alerted to it by a CC) and may have to read the archives of the TC bug to catch up. 4. Messages about a TC issue should NOT also be CC'd to the debian-ctte list. (Since the BTS will send the messages there.) 5. Ideally messages should not be CC'd to - TC members - People participating in the discussion who have subscribed to the bug BUT the exact set of people included in that scope is not 100% clear and it is better to err on the side of including people: - Participants /should/ CC other people in the discussion unless they are sure that they're TC members or subscribed to the bug 6. When the discussion is completed and a decision made or the issue resolved, the TC bug will be closed but remain available for any further discussion, enforcement, or whatever. The other bugs involved will naturally become unblocked and may need to be assigned or reassigned as appropriate. 6a. The special TC discussion bug will not be reassigned to another package. 6b. If necessary new bugs might be created, if none already exist, to ensure that every package which needs to change or team which needs to do work, has the appropriate communication. We should consider this proposal before implementing it, although of course the current approach is very ad-hoc. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20494.51776.384105.199...@chiark.greenend.org.uk
Bug#682010: [mumble] Communication failures due to CELT codec library removal
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 asses
Bug#682010: [mumble] Communication failures due to CELT codec library removal
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.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20494.55920.837498.721...@chiark.greenend.org.uk
Bug#682010: [mumble] Communication failures due to CELT codec library removal
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
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@list
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
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.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207241709.48267.chris.kna...@coredump.us
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
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.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207242150.24041.chris.kna...@coredump.us
Re: Bug#681834: network-manager, gnome, Recommends vs Depends
]] Ian Jackson Hi, > It seems to me that our objectives must include: [...] > 3. Users who deliberately removed network-manager in squeeze (which >they will generally have done by deliberately violating the >Recommends from the gnome metapackage) should not have to do >anything special to avoid it coming back in wheezy. A somewhat tangential question here – is this a general requirement? Doesn't that prevent maintainers from (worst case) ever upgrading Recommends to Depends? I'm worried about what precedent this would be setting. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txwwcq60@xoog.err.no
