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 -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.
Bug#682010: re celt and mumble referred to the TC
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 ...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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::HandleT::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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
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.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.
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. 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.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
