Re: Bug#682010: re celt and mumble referred to the TC
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. -- 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/20489.18157.524359.320...@chiark.greenend.org.uk
Re: Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Bug#682010: re celt and mumble referred to the TC
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 -- 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/20120720123201.gn18...@audi.shelbyville.oz
Re: Bug#682010: re celt and mumble referred to the TC
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.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/201207200849.54631.chris.kna...@coredump.us
Re: Bug#682010: re celt and mumble referred to the TC
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 -- 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/20120720132756.go18...@audi.shelbyville.oz
Re: Bug#682010: re celt and mumble referred to the TC
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. -- 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/20489.26924.400019.43...@chiark.greenend.org.uk
Re: Bug#682010: re celt and mumble referred to the TC
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. -- 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/20489.26973.340520.805...@chiark.greenend.org.uk
Re: Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Bug#682010: re celt and mumble referred to the TC
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 -- 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/20120720145755.gp18...@audi.shelbyville.oz
Re: Bug#682010: re celt and mumble referred to the TC
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. -- 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/20489.29420.892140.930...@chiark.greenend.org.uk
Re: Bug#682010: re celt and mumble referred to the TC
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. -- 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/20489.29879.656700.133...@chiark.greenend.org.uk
Re: Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Bug#682010: re celt and mumble referred to the TC
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. -- 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/20489.30924.284557.249...@chiark.greenend.org.uk
Re: Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
