Bug#681687: missing mime entry
On Thu, Jul 19, 2012 at 12:34:19AM +0100, Ian Jackson wrote: Neil McGovern writes (Bug#681687: missing mime entry): As I understand it, there are still a number of issues with this approach (.desktop files do not contain enough information to get argument ordering correct in all cases, and it's far too late to start using a new auto-generation system this late in the cycle). I don't think it likely that the TC will want to overrule the Release Team's decision on this point. So I hereby propose the following TC resolution: 1. The Technical Committee agrees with Neil McGovern's analysis of the situation regarding evince's missing mime type entry. 2. If changes are desirable to our system for dealing with mime type entries and desktop files, including changes to policy or additional automation, these should be made via the usual development and policy amendment processes. It is now too late to do this for wheezy. 3. We do not disagree with the Release Team's assessment that the failure of the evince package to provide a mime type entry is a release critical bug. 4. We therefore decline to overrule the Release Team. I concur with this. update-mime is a Policy requirement; maintainers don't get to unilaterally decide that bits of Policy are obsolete and ignore them on the basis that the applications they care about are using a different interface. Maintainers have a duty to either follow the Policy, or engage the Debian community to get Policy changed. And I think the GNOME Maintainers haven't done the latter because they know it wouldn't fly - this is a change that breaks compatibility with other software and renders the system as a whole buggier, and changing Policy doesn't paper over that. I'm inclined to think that this should be considered RC for a lot more packages than just evince. I'm not going to go hunting those, but I definitely support the release team's position that it be RC for evince in particular, because evince is the default pdf viewer and pdfs are a very common document type to be passed around between applications that don't yet implement the freedesktop standard. Now, I think providing a tool to auto-translate .desktop files into mailcap entries is a perfectly appropriate way to go about solving this bug, if someone chooses to do that. If such a tool emerges, I think that's great for Debian as a whole, and we can consider revising Policy to consider .desktop files the primary interface instead. But until we have such a tool working in the release, it's the responsibility of the evince maintainers to make sure their package complies with policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: mumble and celt, #682010, TC
On Sat, Jul 21, 2012 at 01:33:54AM +0200, Patrick Matthäi wrote: I think this version of mumble is not fit for release, and I think the RMs agree. At the current stage I also would suggest to remove it from Wheezy, as Ian and Chris suggested. And I, as a Release Assistant, am grateful that Ron is still trying to salvage the package for Wheezy, even if the version that's currently in is not suitable. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Fri, 20 Jul 2012, Steve Langasek wrote: On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote: I've updated the summary with the suggested changes (at the end). From the BTS, it doesn't look to me like this summary has taken? I've cleared out the summary in the BTS because it wasn't particularly useful. [I forgot that I had designed summary to work with paragraph text, not org-mode style outlines.] Don Armstrong -- We want 6. 6 is the 1. -- The Prisoner (2009 Miniseries) _Checkmate_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20120721142925.gx9...@teltox.donarmstrong.com
Re: roaraudio dispute
On Friday, July 20, 2012 23:22:33, Steve Langasek wrote: On Sat, Jul 21, 2012 at 07:34:36AM +0930, Ron wrote: I see that Philipp asked you to undo the change and you have declined, as is indeed your prerogative. I assume that that's because you agree with Ron's reasoning, but without seeing Ron's reasoning, it is difficult to understand your decision. It is both that I agree with Ron's reasoning and that the linkage against libroar in the first place was a quite bad experience and I had already considered dropping it again (as can be seen in below conversation, where at first I don't even realize that Ron's reasoning is Celt removal but I assumed it was just libroar being unneeded and having annoyingly strong dependencies). This actually wasn't just about celt. Bastian Blank (among quite a few others over many months) was also, uh, upset shall we say, about roar dragging DECnet in to the debian installer. Both Philipp and Patrick were quite clear, and repeatedly insistent, about voicing their opinion that they would rather have roar removed than fix these things in roar itself. I can vouch for the horribleness of this library stack. https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/883602 So we have: - a package that mangles mac addresses of interfaces as soon as it's installed, - recommended by a library, - that had to be NMUed *more than once* to get rid of this dependency (bug #608807, bug #655740), - and is packaged as a native package with a binary package name that doesn't follow shared library naming conventions, - and this is all a dependency of an *audio* library! So thank you, Ron, for your efforts in trying to stop this madness from being pulled in on our users systems. My thanks likewise, because that sounds like an enormous mess. Trying to conflate this with the mumble issue however is Not Helpful. I agree. I don't see any reason the TC should be revisiting maintainers' decisions to drop celt 0.7.1 as a dependency; the mumble case is a very particular issue related to the exact manner in which the server is repeating the audio to all clients, and I don't see any reason to suspect this would be an issue for the other packages that have dropped celt support. Roaraudio was being looked into because we were discussing reintroducing celt, due to a combination of a naive but well-meant suggestion on my part itself due to to a lack of relevant information about why the dependency on celt was being removed from the mumble package. The way this all started in the first place was that I couldn't figure out why celt was being removed, because the bug report on the mumble package about that [1] was wholely uninformative about all of the numerous issues the celt 0.7.1 library has that we've now discussed at length. [Dead upstream, desire to remove the package from the upstream authors, ancient version, bitstream incompatability with each release, etc.] I tried to search for bug entries in the BTS on the celt library itself, but I wasn't able to find any, possibly because the package had been removed. In the original bug report [2] that resulted in a communication breakdown and a referral the TC, the discussion on the celt library surrounded only a possible crasher bug, which left bug reporters confused as to why that issue couldn't be handled another way such as reporting the matter upstream -- because we didn't know upstream was dead. Because of all this, reintroducing the celt library seemed to look like a reasonable solution. And once reintroduced, it was reasonable to look at the other packages that had depended on it -- this was my suggestion. I tried to find which packages were affected by the removal and found [3], to which it seemed roaraudio had been most impacted. The previous maintainer for roaraudio complained about loss of a major feature due to celt removal [4] and additionally seems to have quit Debian over some kind of conflict related to this very issue. [5] These latter two things seemed to imply that removing use of celt from roaraudio might have been wrong. At least an initial examination into roaraudio seemed reasonable, in my humble opinion. I don't think we went too far down that path. So anyway -- hopefully this clears up how this issue got conflated. It's something along the lines of the road to hell is paved with good intentions. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674650 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674634#5 [5] https://lists.debian.org/debian-devel/2012/06/msg00983.html [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674634#10 -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Saturday, July 21, 2012 02:42:43, Steve Langasek wrote: On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote: I've updated the summary with the suggested changes (at the end). From the BTS, it doesn't look to me like this summary has taken? On Sat, 21 Jul 2012, Ron wrote: I think that's roughly right. If there's anything more people need clarified or answered, just ask. And I'm still not quite clear what his objection was, because the response I got was: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124 The objection is that the issue has been raised before the CTTE, so it needs to be resolved first before action is taken. If the original petitioner is satisfied with the solution and no longer feels the need to involve the TC, I don't see any reason for the TC to remain involved. Certainly historically, we have considered our job done once there's no longer a dispute that someone wants escalated to the committee. It's not at all our charter to fix all the bad bugs, only to adjudicate when consensus can't be reached on its own. If Chris and Ron *are* working together now towards an agreed solution, I'd much prefer that we let them get on with it. The issue I have now is that The Plan that Ron and Thorvald have come up with Will Not Work, depending what the _goal_ is. If the goal is to be able to interoperate with the existing *server* base [which was exactly why this came to the TC in the first place], that won't be possible -- because the Speex codec up to this point is not part of the selection process in the existing servers. [1] [Special thanks goes to Nicos for watching our backs here.] In terms of existing servers, this would in effect be equal to the only use Opus option that currently exists in Sid right now, which is unable to interoperate _at all_ with every available version of the client on at least one platform. I'm pretty sure it's not a viable option. So while I was initially enamored with The Plan, I'm now back to being concerned after looking at the code Nicos pointed me to. [2] I think it's clear now that we need to explicitly check with him on the proposed solutions, because he's consistently given sage technical advice in this matter. So I wish we were done with the TC, but I don't think we are -- this is a really tough problem. Right now I think if we want to be fully interoperable, we're going to require embedded celt -- I don't like this alternative either, but AFAIK it's what the other distros are doing, and the alternative of continuing to use the celt 0.7.1 library is likely to be deemed just too heinous and evil because we really need to stop proliferating it if at all possible. Nicos -- let me know what you think. It may be that it's Ian's intention to take up this issue in Chris's stead because he himself thinks there's a problem that he wants to put before the TC. That's fine too, but I think in that case, Ian, you should state this explicitly (and, logically, recuse yourself from voting on it under 6.1.2, 6.1.3, or 6.1.4 since you're then a party to the disagreement). I think Ian saw that I was too enthralled and that I jumped to conclusions, and put things on hold to give time for a sanity check. I commend him for doing that as I think that's generally wise, especially where the author for the solution was going to be away for a week. Additionally as Ian took the lead on this problem, I really don't want to commit to go off and take action without his input -- that definitely wouldn't seem right to me. From what I understand now, while we could fix up some of the RC issues with the client/server in testing and unstable, we'd need yet another upload of mumble to unstable with propagation to testing in order to actually fix the client inter-operation bug. From what I can tell now, the ideal solution is to wait until Thorvald has a chance to enable speex for all bandwidths. If that is impractical/impossible then we get to choose between a convenience copy of celt, not releasing mumble, or releasing with opus. Is that the understanding of everyone else? From what I've read here, I don't think there are *any* ideal solutions. We cannot retroactively cause all deployed clients on other OSes (or on other versions of our own OS) be willing to negotiate a codec they don't already negotiate; all clients on a given server must use the same codec to talk to each other; and the set of codecs supported by all clients appears to be the empty set, unless we want to all agree to use an obsolete experimental codec which suffers from serious non-theoretical security issues. So I'm really not sure why it's useful for the TC to be debating which of the bad options we consider least bad. There isn't much choice, as lack of interoperability was why the matter was brought to the TC, and the action chosen directly affects interoperability.
Bug#681687: missing mime entry
On 21.07.2012 09:11, Steve Langasek wrote: Now, I think providing a tool to auto-translate .desktop files into mailcap entries is a perfectly appropriate way to go about solving this bug, if someone chooses to do that. If such a tool emerges, I think that's great for Debian as a whole, and we can consider revising Policy to consider .desktop files the primary interface instead. But until we have such a tool working in the release, it's the responsibility of the evince maintainers to make sure their package complies with policy. A patch providing this converter has been available for a few months [1]. The mime-support maintainer just never got around to upload it or even comment on it. The new mime support maintainer team, which took over the package just a few days ago, did ask the release team, if it would be possible to still apply this patch for wheezy [2]. I think this should be the solution we should aim for and I would appreciate if the release team could give the mime-support maintainers a green light for the unstable upload. If the converter solution turns out to be too buggy or requires larger changes, we have a simple contigency plan, i.e. just drop the converter again. I would really appreciate if we could try to fix this *whole* issue for good for *wheezy*. Re-adding the mime file in evince can still be done if the proper mime-support fix has not been done in say a month or two. Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 [2] https://lists.debian.org/debian-release/2012/07/msg01048.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#681687: missing mime entry
On Sat, 2012-07-21 at 23:12 +0200, Michael Biebl wrote: On 21.07.2012 09:11, Steve Langasek wrote: Now, I think providing a tool to auto-translate .desktop files into mailcap entries is a perfectly appropriate way to go about solving this bug, if [...] The new mime support maintainer team, which took over the package just a few days ago, did ask the release team, if it would be possible to still apply this patch for wheezy [2]. [...] [2] https://lists.debian.org/debian-release/2012/07/msg01048.html As far as I can tell, that's very much not what that message says. In fact, it doesn't appear to request anything of the release team at all. Regards, Adam -- 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/1342906842.13223.130.ca...@jacala.jungle.funky-badger.org
