16:59:51 <dondelelcaro> #startmeeting
16:59:51 <MeetBot> Meeting started Thu Jul 26 16:59:51 2012 UTC.  The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:51 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:08 * dondelelcaro will chair bdale when he arrives
17:01:15 * vorlon waves
17:01:19 <dondelelcaro> ah, cool
17:01:50 <vorlon> cjwatson sends his regrets; BT has eaten his Internet
17:02:02 <dondelelcaro> ah, bummer
17:02:30 <dondelelcaro> #topic Who is here?
17:02:37 <vorlon> o/
17:02:42 <Diziet> ~50%
17:02:43 <dondelelcaro> me
17:02:47 * rra waves.
17:03:08 <dondelelcaro> should we just get started?
17:03:13 <dondelelcaro> or do we want to wait?
17:03:31 <rra> I suspect we should probably just get started, particularly given that we have 50% of Ian at the moment.
17:03:38 <dondelelcaro> ok
17:03:38 <rra> But could lose that at any time.
17:03:53 <dondelelcaro> ok
17:04:11 <dondelelcaro> #topic Git repository git://git.debian.org/git/collab-maint/debian-ctte.git
17:04:36 <dondelelcaro> just a note that the git repository is there; I've been shoving the agenda into it, and hopefully y'all can change it too
17:05:03 <dondelelcaro> it should also announce changes here
17:05:27 <dondelelcaro> #topic Next Meeting Time?
17:06:09 <dondelelcaro> does thursday august 30th at 17:00 UTC work for everyone?
17:06:14 <rra> That's good here.
17:06:39 <Diziet> Yes.
17:06:46 <vorlon> AFAIK yes
17:06:50 <rra> Note that that's Wednesday and not Thursday.
17:07:05 <dondelelcaro> isn't wednesday the 29th?
17:07:10 <rra> Oh, wait, you're right.
17:07:12 <rra> Sorry.
17:07:14 <dondelelcaro> no worries
17:07:15 <rra> Note that rra can't read a calendar.
17:07:33 <dondelelcaro> ok. We can change that if we need to via e-mail
17:07:59 <dondelelcaro> #topic #573745: python maintainer [vorlon to write up resolution]
17:08:03 <dondelelcaro> #chair vorlon
17:08:03 <MeetBot> Current chairs: dondelelcaro vorlon
17:08:07 <vorlon> heh
17:08:08 <dondelelcaro> #chair rra
17:08:08 <MeetBot> Current chairs: dondelelcaro rra vorlon
17:08:15 <dondelelcaro> #chair Diziet
17:08:15 <MeetBot> Current chairs: Diziet dondelelcaro rra vorlon
17:08:50 <vorlon> yeah, getting that written up is still nominally at the top of my TC todo list
17:09:03 <dondelelcaro> ok; do we have anyting more to discuss about it?
17:09:13 <vorlon> but there have been some mail threads of late on the list that I've been finding distracting :/
17:09:19 * dondelelcaro just stuck all the open items on the agenda, so no specific call outs about it
17:09:21 <vorlon> I don't think so
17:09:22 <rra> I don't here -- I think the writeup is the next step.
17:09:25 <dondelelcaro> cool
17:09:34 <dondelelcaro> #topic #636783: super-majority conflict;
17:09:58 <dondelelcaro> I believe Diziet asked for this to be postponed until we resolved some of the open questions, right?
17:10:13 <Diziet> Yes.
17:10:14 <rra> Ian proposed that we postpone this while we deal with the current pile of stuff.  I'm not sure, personally, but that does have some appeal mostly because we're in the middle of freeze.
17:10:21 <dondelelcaro> right
17:10:25 <rra> Everyone is touchy and twitchy and busy and stressed right now, which may make it not the best time to do this.
17:10:26 <dondelelcaro> I'm ok with that too
17:10:31 <rra> We always explode whenever we're in freeze.
17:10:36 <dondelelcaro> yeah
17:11:08 <rra> Most of the constitutional fixes are uncontroversial, but the discussion over whether we should override maintainers more should probably happen when people are calmer.
17:11:48 <dondelelcaro> #agreed postpone #636783 until open issues are resolved
17:12:04 <dondelelcaro> #topic #681419 Depends: foo | foo-nonfree
17:12:37 <rra> Based on the research done and the discussion so far, I think we're converging on a position that those sorts of dependencies should be handled with virtual packages, but I'm not positive.
17:12:59 <rra> In other words, foo-nonfree would Provide: foo, and packages would just depend only on foo.
17:13:12 <vorlon> I'm not in agreement
17:13:42 <vorlon> that appears from the discussion to be Diziet's and rra's position; I think trying to avoid naming non-free packages in the Depends field is counterproductive
17:13:51 <rra> It's not actually my position -- I personally don't care.
17:13:54 <vorlon> ok :)
17:14:03 <rra> It was more that Diziet felt that way and no one seemed to be objecting, so this is good.
17:14:18 * rra doesn't feel like he has a dog in this hunt; I'm happy to go with whatever people decide.
17:14:46 <dondelelcaro> I personally don't care much either way; just so long as non-free isn't pulled in accidentally
17:15:11 <rra> Okay, I think the other proposed position was that packages may list non-free packages as an alternative iff the non-free package will never be pulled in by default.  Which, among other things, implies that it can't be listed first due to how our dependency resolution works.
17:15:20 <dondelelcaro> perhaps the right way is to suggest virtual packages as the easy way to make sure that is done, but to allow Depends: foo | non-free so long as non-free isn't pulled in
17:15:50 <rra> Yeah, we could offer both solutions in Policy as informative text with the normative requirement being that non-free packages not be installed by default by dependency resolution.
17:15:59 <Diziet> A relevant question here is the FSF's objection to "recommending" non-free software.  Which perhaps we don't all agree with but I think it has some significant force.
17:16:14 <rra> I suspect that the FSF would want us to go all the way to the virtual package solution.
17:16:25 <Diziet> They would probably prefer it.
17:16:27 <Diziet> TBH I would too.
17:16:32 * rra personally finds the FSF requirement to be so ill-defined and vague as to make it difficult to write policy on that basis.
17:16:51 <rra> Even apart from the question of whether it's a policy that we want to conform to.
17:16:56 <Diziet> I don't want to do it _because_ it's some (vaugue, as you say) FSF requirement.
17:17:08 <rra> Oh, I know -- but matching is politically useful where we can.
17:17:11 <rra> I do get that part.
17:17:27 <Diziet> I think it's a relevant consideration to _us_.  Should we be recommending non-free software when the whole point (in at least some views) is to promote freedom.
17:18:00 <Diziet> I think asking people to invent a virtual package name that describes the functionality or interface is not too onerous and we only have ~80 examples in the whole archive.
17:18:05 <vorlon> I don't consider denoting that there's a non-free package that can be used as a substitute to be recommending
17:18:13 <rra> I think the argument in favor of allowing foo | foo-nonfree without a virtual package is simplicity and therefore robustness; the virtual package is a more complex packaging technique and requires some more thought and effort and people are more likely to get it wrong.
17:18:42 <Diziet> get it wrong> The consequences of that would be simply that the non-free dependency wouldn't satisfy, rather than anything worse, most likely.
17:18:43 <vorlon> and virtual packages don't allow for versioned dependencies
17:18:46 <rra> Also, there's always the consideration that we wouldn't make a bunch of people whose packages are working fine now from the perspective of the maintainer change things.
17:18:52 <Diziet> vorlon: We don't need those.
17:19:03 <dondelelcaro> Diziet: well, currently we don't
17:19:20 <vorlon> I don't think that's actually known
17:19:30 <Diziet> rra: I don't think that's a relevant way to look at it.  If we want not to refer to non-free stuff this way then those packages /are/ doing so in a way we don't want.
17:19:31 <rra> vorlon: We're not using them right now.
17:19:53 <rra> Well, that's the question, right?  Do we not want to refer to non-free stuff this way?
17:19:57 <Diziet> It's difficult to imagine a case that couldn't be handled by a suitable (perhaps version-number-containing) virtual package name.
17:20:10 <rra> Personally, my feeling was always more like vorlon's; I don't see the alternative as a recommendation.
17:20:11 <Diziet> rra: In general I would prefer that, yes.
17:20:18 <rra> The package we list first is our recommendation; we then allow alternatives if you really want.
17:20:30 <Diziet> rra: Very difficult to argue that "Recommends" doesn't recommend things.
17:20:43 <rra> And yet, that's exactly what I'm doing.  :)
17:20:52 <rra> I don't think that Recommends: foo | foo-nonfree recommends foo-nonfree.
17:20:52 <Diziet> Well I think it's frankly implausible.
17:21:01 <rra> It recommends foo, and mentions that foo-nonfree is an alternative to foo.
17:21:08 <Diziet> These things are read by humans as well as computers.
17:21:30 <dondelelcaro> rra: actually, I don't know why you'd have Recommends: foo | foo-nonfree
17:21:37 <Diziet> I would prefer not (for example) to have to make packages.debian.org properly qualify and explain all this.
17:21:46 <rra> Well, yeah, but Recommends: foo [!i386] doesn't recommend that you avoid i386 systems.  :)
17:21:57 <rra> dondelelcaro: Oh, good point.
17:21:59 <Mithrandir> dondelelcaro: various archives that does recommends: rar | rar-nonfree
17:22:08 <rra> There's really no reason for the alternative except for Depends.
17:22:11 <Mithrandir> (sorry to interrupt)
17:22:12 <dondelelcaro> Mithrandir: right, but it doesn't make any sense to do that
17:22:17 <Diziet> Mithrandir: Strange to see why you wouldn't just have rar-nonfree provide rar.
17:22:18 <rra> The point is to allow the local administrator to override the defaults.
17:22:26 <rra> You can do that with Recommends without needing the alternative.
17:22:27 <vorlon> rra, dondelelcaro: yes it does
17:22:39 <vorlon> recommends are installed by default; user already has installed foo-nonfree; foo should not be pulled in
17:22:54 <Diziet> Can I suggest we take this to email ?
17:23:02 <Mithrandir> Diziet: cli interface has changed, perhaps?
17:23:10 <rra> vorlon: Ah, hm, yes, point.
17:23:13 <Mithrandir> anyway, I'll stop interrupting. :-)
17:23:22 <vorlon> I'm fine to follow up by email
17:23:32 <dondelelcaro> ok. I guess we need to flesh out these options
17:23:40 <dondelelcaro> via e-mail
17:23:49 <dondelelcaro> anyone object?
17:24:12 <dondelelcaro> #agreed flesh out #681419 Depends: foo | foo-nonfree options via e-mail
17:24:21 <dondelelcaro> #topic #681687 missing mime entry
17:24:45 <rra> Ian's latest proposal seemed reasonable to me.
17:25:23 <rra> I would really rather not tell everyone that they have to put back their update-mime configuration for all MIME types in all packages unless we really have users complaining, in large part because that's going to be a disruptive change at this point in the release cycle and it's really not clear to me how much people use metamail programs any more.
17:25:39 <vorlon> I don't actually agree that it's too late to deploy such automation in wheezy
17:25:40 <rra> I know it's important for PDF.
17:25:43 <rra> The other stuff not so much.
17:25:48 <vorlon> but I'm happy to defer to them
17:25:52 <dondelelcaro> ok
17:26:03 <rra> The automation is indeed not horribly complex.
17:26:16 <Diziet> Is it really a disruptive change ?
17:26:41 <Diziet> rra: The problem with it is that we don't understand its implications.  That is, we don't know exactly what the resulting behaviour will be and it will probably introduce new RC bugs.
17:26:46 <rra> It's a simple per-package change, but it's a lot of packages, and against the explicit objections of the maintainers, so yeah, I think it is.
17:26:49 <dondelelcaro> I think that's something that we can leave to the RMs to decide, though
17:27:10 <Diziet> Whereas putting the mime files back (which should never have been removed in the first place) is definitely not going to introduce any RC bugs.
17:27:19 <rra> Diziet: The thing is, those entries haven't been well-maintained for a while.
17:27:31 <rra> I don't think the update-mime database was any paragon of usability in squeeze.
17:27:31 <Diziet> At least they're not regressing.  I think regressions are worse.
17:28:01 <Diziet> I'm happy to leave the RMs to decide which other packages, if any, are in scope.
17:28:02 <rra> And it may or may not be the case that you can simply re-add them; other stuff may have changed since.  You have to at least look at them and make sure they still make sense, and ideally test them.
17:28:16 <rra> But yeah, I'm not sure we need to debate this; I'm happy to let the RMs decide.
17:28:54 <dondelelcaro> ok; any objections to the current resolution (or just following up via e-mail)?
17:28:57 <Diziet> If you disagree about evince I think you should put forward the other alternative so we can vote it down.
17:29:27 <rra> Diziet: I definitely think we should re-add the entry for evince.
17:29:32 <Diziet> Right.
17:29:33 <vorlon> I've just followed up by email with my objection from above
17:30:11 <dondelelcaro> ok
17:30:19 <Diziet> vorlon: Well if you disagree then you need to write an alternative text which says something like "we overrule the RMs decision that it is too late for this automation"
17:30:24 <rra> My preference would be to let the release team make the call on the automation, and on what missing MIME entries are RC, so just declining to override them makes sense here.
17:30:32 <vorlon> Diziet: er, no?
17:30:36 <vorlon> I'm not aiming to override them
17:30:45 <rra> I think vorlon's just aiming to convince them. :)
17:30:48 <Diziet> Ah :-)
17:30:52 <vorlon> I'm just not going to vote for a statement that I agree with a decision that I don't ;)
17:31:12 <dondelelcaro> vorlon: so just remove point 3, I'm imagining?
17:31:29 <vorlon> or replace it with "we defer to the release team"
17:31:30 <Diziet> I think we do need to state whether we agree with it to avoid that just being bounced back to us.
17:31:59 <Diziet> An explicit statement that we defer to the release team would do.  I'd prefer to vote on my verson too but that's easy enough.
17:32:08 <vorlon> ok
17:32:09 * rra would prefer to explicitly defer rather than saying whether or not we agree.  If we say we agree, I think it makes it harder for them to change their mind if they want, and I don't see a point in doing that.
17:32:10 <Diziet> vorlon: Would you like to draft an alternative point 3 ?
17:32:20 <vorlon> already did in my email follow-up! :)
17:32:30 <Diziet> I did say I'm only 50% here :-)
17:32:35 <dondelelcaro> heh
17:32:36 <Maulkin> (For info, if someone can show lots of test data which indicates the automation works absolutely fine, I'd be happy to look at including it for wheezy.)
17:32:37 <Diziet> OK, I guess we're done with this then ?
17:32:48 <Diziet> Maulkin: Heh :-)
17:32:49 <dondelelcaro> any objections to moving on?
17:32:55 <rra> None here.
17:33:04 <dondelelcaro> #topic #681783 Recommends
17:33:16 <Diziet> (I don't think saying we agree makes it harder for the RMs to change their mind.)
17:33:22 <Diziet> (But whatever.)
17:33:26 <rra> I agree with the initial reaction to this one that it's all too vague.
17:33:28 <vorlon> I don't think I'm sufficiently up to speed on the recent thread on that bug
17:33:31 <rra> Diziet: I may be oversensitive to that.
17:33:53 <dondelelcaro> #topic #681783 Recommends in meta packages
17:34:01 <dondelelcaro> that's a little bit less vague
17:34:14 <rra> Oh, sorry, I didn't mean your summary, I meant the bug.
17:34:24 <dondelelcaro> heh; I think both are pretty vague. ;-)
17:34:37 <Diziet> I think it's vague.  What does "supported" mean?  Perhaps the question is what kind of undesired behaviours are permissible when Recommends is violated.
17:34:53 <dondelelcaro> yeah, I don't really think there's any specific technical thing to be decided here
17:35:02 <dondelelcaro> it sounds like something which should be handled by policy, if even there
17:35:29 <rra> Yeah.  And I'd want to have someone write up some specific wording to Policy to talk about it -- I think Policy is already pretty clear about what Recommends means.
17:35:47 <Diziet> I would be happy to try to write a clear statement.
17:35:54 <Diziet> But people might not agree with it.
17:36:05 <rra> It might be worthwhile to be more explicit in Policy that the expected normal behavior is to install Recommends.
17:36:14 <rra> I mean, I think it already says that, but it may not be sufficiently clear.
17:36:32 <Diziet> I think it would be helpful to give some cover to maintainers against useless bug reports.
17:36:38 <rra> I don't think we actually clearly say "if you don't install Recommends, some stuff may not work; this is not a bug."
17:36:42 <Diziet> Right.
17:37:04 <Diziet> Can we action me to write something ?
17:37:19 <dondelelcaro> do we want to handle that? or do we want to punt over to the normal policy process?
17:37:23 <dondelelcaro> I'm ok with either way
17:37:40 <rra> Maybe have Diziet write something and then reassign the bug to Poilcy?
17:37:49 <dondelelcaro> sounds fine to me
17:37:50 <rra> Where it can sit for six months while I don't do anything on Policy?  *sheepish look*
17:37:55 <dondelelcaro> heh
17:38:20 <Diziet> I think whether I write something or not we will have to make a decision.
17:38:21 * rra clearly needs to sit down with vorlon and make him write about Python while he makes me resolve Policy bugs.
17:38:34 <Diziet> To at least dispose of the bug to say "no change to policy"
17:38:49 <rra> Diziet: Is that what the bug is really asking for -- chagne Policy?
17:39:01 <rra> The bug seemed like an open-ended request for clarification.
17:39:14 <Diziet> rra: Maybe.  I think we should vote on it somehow.
17:39:23 <Diziet> I don't mind if we don't mandate a specific policy change.
17:39:24 <rra> It's the sort of thing that I was inclined to punt as ill-formed.
17:39:42 <rra> I guess some of this is from having worked on Policy for years.
17:39:54 <Diziet> punt as ill-formed> "The TC feels that policy in this area is correct, but might benefit from clarification"
17:40:01 <rra> I usually just punt anything that gets filed against debian-policy that's too open-ended and vague, since my experience is that this stuff never goes anywhere.
17:40:06 <rra> That works.
17:40:09 <Diziet> ^ if we vote on that then we can dispose of the bug and clarify.
17:40:10 <Diziet> OK
17:40:32 <dondelelcaro> Diziet: that sounds good to me
17:40:41 <dondelelcaro> any objections to doing that and moving on?
17:40:49 * rra hates unactionable bugs.  :)  "The world should be better" is not a well-formed bug.
17:41:06 <Diziet> rra: "script is insecure and general tty insecurity"
17:41:09 <Diziet> :-)
17:41:17 <rra> Yeah.  :)
17:41:27 <Diziet> Fixed after half a decade IIRC by a complete rewrite of the pty allocation arrangements.
17:41:49 <dondelelcaro> #action Diziet to write up statement to dispose of #681783 with possible reassignment to policy
17:41:52 <rra> Anwayy, no objections to doing that and moving on.
17:42:04 <vorlon> rra: heh; let me know when you'll be up here and I'll block the time
17:42:15 <dondelelcaro> #topic #682010 mumble/celt client/server compatibility
17:42:17 <rra> vorlon: October!  Well, not quite all the way up to where you are.
17:43:00 <vorlon> :)
17:43:25 <rra> So, I have to admit that I didn't follow all of the back and forth on this, but my general impression is that the problem here is that the current version of the software uses an audio codec that the maintainer of that codec doesn't believe is release-worthy for wheezy.
17:43:42 <rra> Is that the basic gist?
17:44:04 <vorlon> and furthermore there's concern that not supporting that particular codec impacts interoperability
17:44:19 <Diziet> Roughly, although Ron's comments about celt haven't been quite so categorical.
17:44:20 <rra> Because the other existing versions of that software use that codec, as I understand it.
17:44:28 <dondelelcaro> right
17:44:41 <dondelelcaro> and the server aparently isn't capable of transcoding or whatever
17:44:45 <vorlon> however, I don't feel we really have a clear picture of the technical facts, from the thread
17:44:50 <rra> He disliked it enough to go to the work of getting it removed from the archive, it sounded like, but possibly doesn't categorically object to reintroducing it, yes?
17:44:52 <vorlon> because both parties are saying that the other is wrong
17:44:59 <dondelelcaro> yeah
17:45:01 <Diziet> As you may have read I looked at the code and I wasn't very convinced by some of the maintainer's characterisations of the difference between the old codec and the new officially supported one.
17:45:09 <rra> Yeah, I saw that.
17:45:29 <vorlon> I missed that one - are you suggesting that the new one is also full of security bugs?
17:45:32 <Diziet> dondelelcaro: AFAICT the server doesn't ever transcode so every client needs to send a codec everyone understands.
17:45:39 <dondelelcaro> Diziet: right
17:45:48 <rra> Certainly, from a release perspective, the easiest thing to do would be to just reintroduce the specific version of celt everyone else is using and go with the status quo for one more release.  The potential drawback, as I understand it, is security bugs.
17:45:53 <Diziet> vorlon: I haven't done that kind of review.  But looking at the diff there's a lot of noise in it and the code structure, style and so forth are similar.
17:45:54 * dondelelcaro honestly hasn't used any of this stuff, so can't say for certain
17:46:22 <vorlon> ok
17:46:25 <rra> I guess I'm moderately unimpressed by the argument that the audio codec used in a chat client potentially has a bunch of security bugs.
17:46:42 <rra> I mean, yes, it's a security issue, but the exposure there is not on the level of a public-facing Internet service, yes?
17:46:52 <Diziet> You may think I'm biased against Ron but I would point out that when this whole spat with Philipp first came to my attention I wasn't sympathetic to Phillip.
17:47:03 <Diziet> rra: Yes.
17:47:06 <rra> Don't you have to be in a chat with an attacker in order to exploit the vulnerability?
17:47:09 <Diziet> You are exposed if you run the client.
17:47:19 <rra> Oh, anyone can connect to it when you're running it?
17:47:20 <Diziet> The attacker can normally join your chat.
17:47:23 <rra> Oh, okay.
17:47:24 <rra> bleh.
17:47:26 <vorlon> Debian runs a public mumble server, easy enough to attack
17:47:41 <vorlon> well, debian.net I think - let's not get into /that/ argument ;)
17:47:43 <Diziet> That might depend but most of these chat channels operate on a "kick people who aren't welcome" basis.
17:47:48 <rra> But the security vulnerabilities are theoretical at this point?
17:47:53 <Diziet> AFAIK
17:48:00 <Diziet> I haven't seen anyone point any out specifically.
17:48:03 <rra> In other words, we don't *know* of any security problems; we (for some value of we) just think the code is horrible.
17:48:16 <Diziet> No.
17:48:27 <Diziet> "We" think the code is dead upstream, is the main point.
17:48:28 <vorlon> my understanding was that someone concocted a proof of concept against later versions of the code, and that the opus code has been proofed against it
17:48:47 <rra> Oh, okay.  So there may be a known vulnerability.
17:48:50 <Diziet> Not that it's horrible.  I haven't seen anyone claim the opus code is much better than the celt code from a security pov.
17:48:50 <vorlon> and celt has not and probably suffers from the same issue, and has no upstream to support fixing that issue or others in the future
17:49:13 <Diziet> What's weird is why don't we have references to this vuln ?
17:49:26 <rra> And Ian asked the security team, IIRC, and they basically said "we're not jumping up and down with joy, but we wouldn't block the package"?
17:49:28 <Diziet> If so we could see "can we apply the patch to celt" which might be interesting info.
17:49:32 <Diziet> rra: Yes.
17:49:55 <vorlon> can I check if someone understands what the outstanding problems are with getting speex reenabled in the mumble client and relying on that codec instead?
17:50:07 <vorlon> that was the gist of ron's proposal
17:50:36 <Diziet> I don't understand fully.
17:50:36 <rra> Backing up a little bit: Assume that we all decide that it's okay to reintroduce celt.  Do we actually have someone who is willing to do the work of reintroducing celt into the archive?  I mean, is Ron willing to do that, or is someone else willing and capable to do it if Ron doesn't want to be stuck supporting it because he doesn't agree with it?
17:51:13 <Diziet> But AIUI that would involve downgrading all the clients in a channel to speex which might well be unacceptable to the userbase effectively making our version of the mumble client unuseable in those contexts.
17:51:26 <rra> vorlon: My understanding was that we were unsure whether the existing clients out there in the world that speak celt would actually negotiate speex.
17:51:27 <Diziet> Ron seems to have said he's willing to do it.
17:51:50 <Diziet> Most recently he's said he just wants us to take the responsibility (I think, read "blame") for any resulting security doom.
17:52:03 <Diziet> rra: There was that too.
17:52:28 <rra> Well, I'm okay with us taking the blame.
17:52:41 <rra> It's a pretty clear tradeoff -- possible but not proven insecurity against backwards compatibility.
17:52:41 <dondelelcaro> so I think what's sort of missing here currently is actual packages coupled with tested interaction of clients
17:52:45 <rra> That sort of question doesn't really have a wrong answer.
17:52:53 <vorlon> rra: right - I would like to know the answer to that question.  Chris seemed to be insisting that they wouldn't, but I spotted several flaws in his methodology (like, the fact that he didn't actually have a version of the new client with speex reenabled)
17:53:04 <rra> We may release and then have a security vulnerability and have to pull it from the archive because we can't fix it.  That would be a shame, but meh.  It doesn't seem like the end of the world.
17:53:13 <Diziet> dondelelcaro: I think we know that if we reenable the embedded celt it will work as intended with existing clients.
17:54:06 <dondelelcaro> Diziet: I think that's likely, but I'd like to see real packages which have been tested to do that
17:54:09 <rra> If speex works, are people generally comfortable with speex from a security standpoint?
17:54:21 <rra> We're not just changing one problem for another?
17:54:24 <Diziet> rra: I don't think anyone has looked at the speex code from that pov.
17:54:25 <dondelelcaro> rra: it's used everywhere, so if speex has a problem, someone will have to fix it
17:54:33 <rra> Ah, okay.  And it's still supported, which is the key.
17:54:34 <vorlon> speex is an unrelated codec, and widely used elsewhere in the distro
17:54:39 <Diziet> rra: We're adding a problem because the client has to cope with speex already.
17:54:47 <rra> Okay, cool.
17:54:59 <rra> Well, if speex works with the existing clients, that makes the question much easier, so yeah, we should go figure that out.
17:55:09 <dondelelcaro> right
17:55:19 <rra> If it doesn't, then I think we should probably just vote on whether to reintroduce celt or remove mumble, which feel like the alternatives otherwise.
17:55:20 <vorlon> and that was waiting for upstream to be back from vacation?
17:55:28 <dondelelcaro> vorlon: that's my understanding, yeah
17:55:34 <Diziet> rra: I don't think it does make it that easy because of the downgrade question.
17:55:51 <rra> Well, I guess we could release a mumble that's incompatible with everyone else, but I'm not sure we'd be doing anyone any favors.
17:55:53 <vorlon> so can we ask Ron to follow up on that, and manage to quiesce the thread until then? :)
17:56:22 <rra> Diziet: Right, for "work" read "works and doesn't make the chat too slow to be usable or introduce other major problems."
17:56:25 <vorlon> fwiw I use mumble fairly extensively on Ubuntu, and actually care about compatibility with servers running older releases :)
17:56:28 <Diziet> I don't know quite how to put this but I'm wary of asking Ron to follow up on something.  The questions Ron asks seem often to be a bit leading.
17:56:31 <rra> In other words, either it doesn't force downgrade or the downgrade doesn't introduce problems.
17:57:04 <vorlon> Diziet: hmm, I understand
17:57:07 <rra> vorlon: Does Ubuntu consider this security vulnerability a problem, do you know?  I assume you've got your own security team that may potentially be looking at this stuff.
17:57:36 <vorlon> Diziet: though if we ask him to work with upstream to prepare a client with speex enabled to demonstrate that it works, I'm not sure how a leading question can sabotage that :)
17:57:46 <ChrisKnadle> The speex codec is not part of the codec selection mechanism in mumble-server.
17:58:17 <vorlon> rra: I highly doubt that it's on the Ubuntu security team's radar, it's in Ubuntu universe
17:58:24 <rra> Ah, okay.
17:58:34 <rra> Damn, can't get someone else to do the work for us.  :)
17:58:37 <vorlon> ChrisKnadle: yes; Ron asserted that it's not part of the codec selection because it's there's a built-in assumption that it's available as a baseline?
17:59:00 <vorlon> I want to see what actually happens when two clients connect to a server having only speex in common
17:59:08 <vorlon> right now we don't have such a test
17:59:12 <dondelelcaro> so, I believe right now we're at the "show us the code and interoperability" stage?
17:59:21 <rra> Yeah, seems like it to me.
17:59:22 <vorlon> because the 349 build that drops celt support *also* drops speex support
17:59:24 <ChrisKnadle> vorlon: Speex is used only in low bandwidth situations, and I don't understand when it's used in terms of mumble-server
17:59:44 <vorlon> ChrisKnadle: I don't understand either, which is why I want an empirical demonstration :)
17:59:51 <Diziet> show us the code> How will we determine whether downgrading a channel to speex is acceptable ?
17:59:56 <ChrisKnadle> vorlon: and I agree that such a test would be very worthwhile
18:00:21 <dondelelcaro> Diziet: I guess first we'd want to see whether it interoperated with what
18:00:25 <vorlon> Diziet: I would consider it acceptable provided that it works at all
18:00:57 <dondelelcaro> Diziet: the quality we could argue later once it actually works
18:01:25 <Diziet> vorlon: I'm not sure that that's the proper tradeoff if the alternative is security problems which seem largely to be FUD.
18:01:55 <rra> It would give us something that we could do if anyone finds a vulnerability, though.
18:02:05 <vorlon> I think that particular tradeoff is not one I'm interested in overruling the maintainer on
18:02:10 <ChrisKnadle> The catch in re-enabling speex is that it requires messing with the repo from git upstream
18:02:17 <rra> If we established that speex would work, then if we find a security vulnerability during the wheezy release cycle, we could just upload a new version that disables celt.
18:02:32 <rra> It gives us another option.
18:02:33 <ChrisKnadle> (because speex was removed upstream)
18:02:35 <Diziet> vorlon: AIUI we are not at this point being asked to overrule the maintainer.
18:03:07 <Diziet> Bear in mind also that we shipped this same codec in squeeze.
18:03:40 <Diziet> As I understand Ron's current position he will be content with a decison that shipping the embedded celt is fine.
18:03:48 <rra> Diziet: Yeah, but also it's worth considering that the mere fact that we're having this giant discussion probably means that a few people are now off trying to find security vulnerabilities in celt.
18:03:51 <Diziet> rra: That's certainly helpful.
18:03:54 <vorlon> Diziet: my point is that if we have a solution for the basic interop problem, and the choice is now between whether we're interoperating using speex or celt, I'd rather not take the TC down that rathole and refer it back to the maintainer
18:05:01 <Diziet> My view at the moment is that (unless something surprising turns up) I would like to recommend to the maintainer to ship celt.
18:05:51 <vorlon> I would like to know what the prospects of speex-based interop are before making any decision
18:06:08 <rra> I'm leaning towards that myself, honestly.  I'm a big fan of backwards compatibility, and, well, there's a lot of ugly code with a lot of potential points of vulnerability and it's hard for me to weigh that too highly against backward compatibility.  But knowing the speex interop results would be very helpful.
18:06:19 <dondelelcaro> right
18:06:45 <dondelelcaro> so we basically are looking for whether speex interoperates, and whether celt 0.7.1 interoperates?
18:06:50 <rra> If we knew that speex interoperated, I'm with vorlon; punting the whole thing to the maintainer would make sense.
18:07:03 <rra> dondelelcaro: I think we're fairly sure that celt 0.7.1 interoperates, no?
18:07:23 <ChrisKnadle> yes -- celt 0.7.1 is supposed to interoperate by mumble "contract" upstream
18:07:26 <vorlon> so I think we should follow up with Ron about getting speex re-enabled upstream, and then timebox getting that
18:07:31 <ChrisKnadle> i.e. it *is* the base codec.
18:07:49 <vorlon> what's an appropriate time frame for getting that input?  1 week? 2
18:07:50 <vorlon> ?
18:07:55 <Diziet> rra: The maintainer's most recent position seemed to be to be almost asking us for cover to ship celt (while producing FUD to explain why we shouldn't).  I would like to call that bluff.
18:08:04 <dondelelcaro> rra: I think so, but it should be a good control, but if it doesn't work, then we should know that
18:08:28 <dondelelcaro> vorlon: probably 2 weeks, I'd think?
18:08:29 <Diziet> Sorry, I should try to be less tendentious.
18:08:33 <rra> Diziet: Eh, I'm not sure I'd put it quite that way.  Or, I guess, the way I'd put it is that I'm okay with providing cover, and I can understand why he wants cover.
18:09:05 <Diziet> rra: Helpfully we can agree about the action that should follow :-0.
18:09:09 <Diziet> s/0/\)
18:09:26 <rra> I'm happy to be the person about whom people say "he decided to ship something with potential security vulnerabilities; that was so stupid."  That doesn't bother me.  :)
18:09:51 <rra> Tradeoffs are like that.
18:10:15 <vorlon> :)
18:10:24 <rra> Okay, so I agree on two weeks.
18:10:27 <dondelelcaro> anything else on this? we're ok to wait for two weeks?
18:10:34 <vorlon> +1
18:10:35 <Diziet> Me too
18:10:39 <rra> So action is to request Ron follow up with upstream about speex interop?
18:10:45 <vorlon> yes
18:10:48 <dondelelcaro> right
18:11:00 * dondelelcaro will agitate for celt interop too, just as a control
18:11:11 <rra> And then we reconsider with, hopefully, that data in two weeks.
18:11:16 <dondelelcaro> sounds good
18:11:19 <Diziet> I still want to say that _even if the speex interop says "yes"_ I disagree with the implied conclusion "ship speex not celt".
18:11:27 <Diziet> So I don't agree with this decision but I'll go along with it.
18:11:32 <vorlon> Diziet: understood
18:11:42 <rra> Diziet: Yeah, and I'm somewhat with you on that, which is why I say reconsider, not anything else.  We can talk about it in two weeks with more data.
18:11:56 <dondelelcaro> Diziet: cool; I think this is just an interim step, not the final solution
18:12:17 <Diziet> OK.  I just want to forestall "we collected data X => conclusion Y" when Y doesn't follow IMO from X.
18:12:34 <rra> Knowing that speex works actually makes me more comfortable with shipping celt.
18:12:36 <dondelelcaro> who wants to be responsible for contacting ron?
18:12:48 <rra> Since then we know that we can just turn off celt if we get a security vulnerability we can't fix without making the package unusable.
18:12:49 <Diziet> Not me.
18:13:03 <dondelelcaro> I guess I can deal with it
18:13:04 <dondelelcaro> ok
18:13:16 <Diziet> rra: Point.
18:13:31 <dondelelcaro> #action dondelelcaro request Ron follow up with upstream about speex interop within two weeks
18:13:41 <dondelelcaro> anything more on this?
18:13:55 <dondelelcaro> ok; moving on
18:13:56 <dondelelcaro> #topic TC mailing list / BTS usage [http://lists.debian.org/msgid-search/20494.51776.384105.199244@chiark.greenend.org.uk]
18:14:24 <dondelelcaro> I think what Diziet proposed seems reasonable; worth trying, and then we can adjust if necessary
18:14:28 <Diziet> I'm just fed up of getting 3 copies of everything and _still_ not being able to find it.
18:14:33 <dondelelcaro> heh
18:14:41 <rra> My initial reaction there was that I wasn't sure that the problem we were worried about (huge bug logs) was all that severe, but I have no objections to the proposal.  Although it struck me as kind of complicated.
18:14:42 <vorlon> I haven't read the proposal yet
18:15:00 <Diziet> It only looks complicated because I wrote down the edge cases.
18:15:07 <vorlon> I do get frustrated that trying to do a group-reply to TC bug mails consistently breaks in mutt
18:15:09 <Diziet> Basically it's "we'll use (only) a dedicated bug"
18:15:28 <Diziet> vorlon: I'm not sure if my proposal will help.
18:15:42 <vorlon> I should maybe read the proposal and let you know :)
18:15:54 <dondelelcaro> yeah, I really need to fix bug subscription
18:15:56 <rra> I would also note that there's something about the debian-ctte list configuration that's very weird.  Is there something custom on that list that forces a Mail-Followups-To header or something?  My client absolutely refuses to follow up to a bug address instead of mailing debian-ctte directly.
18:16:05 <rra> I think that's contributing partially to the problem.
18:16:15 <vorlon> right, that's exactly what I mean
18:16:16 <Diziet> rra: I will look into that.
18:16:32 <Diziet> #action Diziet to look into list mail-follow-up-to etc. configuration
18:16:45 <dondelelcaro> ok; anything more on this?
18:17:02 <dondelelcaro> #topic additional business
18:17:15 <dondelelcaro> anything else we need to discuss?
18:17:24 <dondelelcaro> or want to discuss?
18:17:25 <rra> I did have one question: would people like me to throw us more stalled policy bugs like the free/non-free thing?
18:17:34 <rra> Since I, uh, have a list.
18:17:36 <Diziet> Sure.
18:17:37 <rra> A loooooong list.  :)
18:17:42 <rra> I'll avoid doing them all at once.  :)
18:17:43 <Diziet> Maybe drip-feed them.
18:17:46 <dondelelcaro> yeah
18:17:56 <dondelelcaro> maybe one at a time would be good
18:18:01 <rra> Yeah, that's what I was thinking.
18:18:07 <rra> Each time we resolve one, I can toss in another.
18:18:15 <Diziet> That's an, uh, incentive.
18:18:16 <rra> Maybe I should send along BROWSER.  :)
18:18:19 * rra grins.
18:18:20 <dondelelcaro> heh
18:18:38 <rra> Diziet: I clearly heard you say at DebConf that you wanted more work.  :P
18:18:52 <Diziet> :-P to you too... :-)
18:18:56 <vorlon> yeah, I think I would find it helpful if we would take issues more one at a time
18:19:09 <Diziet> vorlon: One per month is too few.
18:19:19 <vorlon> well
18:19:22 <Diziet> Maybe set a limit of 2 or 3 ?
18:19:33 <Diziet> Chairman to pick and defer as applicable.
18:19:33 <vorlon> if we can finish off one issue every 2 weeks, that's fine with me too :)
18:19:43 <rra> I'll try to make sure that the Policy bug is well and truly stalled before I send them along, too.  A lot of them just need someone to pay attention to them (including BROWSER); the ones where there's really an entrenched disagreement are less frequent.
18:19:43 <vorlon> I just find the discussions not well parallelizable on my end
18:19:52 <Diziet> vorlon: It seems we don't actually manage to do easy things we mostly all agree with until we have a meeting.
18:20:09 <Diziet> Eg the evince mime thing.
18:20:10 <rra> We could consider having these meetings every two weeks instead of every month.
18:20:13 <Diziet> No.
18:20:17 <Diziet> It's already too long.
18:20:34 <rra> They do seem to be highly productive.
18:21:04 <Diziet> I could live with it if they're strictly time limited and start on time, I guess.
18:21:17 <rra> Yeah, we're kind of failing on that at the moment.
18:21:22 <rra> Well, I would prefer to do more in email.
18:21:32 <Diziet> Yes.
18:21:36 <dondelelcaro> yeah, I agree
18:21:37 <Diziet> Me too.
18:21:47 <rra> I'm just noticing that we're going through stuff like crazy on IRC and weren't in email, so contrary to my personal preferences, this does seem to be highly productive.
18:22:02 <Diziet> This is because for some reason people don't just say "I second your resolution"
18:22:10 <dondelelcaro> I think our real problem is just that it's hard to gauge via email whether we all agree
18:22:14 <rra> On the other hand, with some of the stuff, like mumble, that's because we gathered a bunch of information in email and I was able to come into the meeting with a pretty good grasp of the problem.
18:22:47 <Diziet> dondelelcaro: That would be fixed if people replied tentatively.
18:22:48 <rra> I can try to be more aggressive about speaking up in email.
18:23:03 <Diziet> Eg "I dunno about all this but my vague feeling is X"
18:23:18 <dondelelcaro> Diziet: yeah, sounds reasonable
18:23:29 <rra> Currently I'm reluctant to say that I agree with something when I'm not sure, and what happens on IRC is that I say I agree with something and then someone else raises a point that I didn't think of and I change my mind.  For some reason, that process seems harder in email.
18:23:45 <Diziet> Must go now.
18:23:53 * Diziet departs
18:23:59 <rra> Yeah, we should close down -- I have to head out as well.
18:24:02 <dondelelcaro> right
18:24:09 <rra> We're 30 over, after all.
18:24:16 <dondelelcaro> anything last second?
18:24:28 <dondelelcaro> ok, lets stop here
18:24:32 <dondelelcaro> #stopmeeting
18:24:55 <dondelelcaro> #endmeeting