- Wednesday, August 27, 2014

release-team@conference.openafs.org

Wednesday, August 27, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[02:34:19] Jeffrey Altman leaves the room
[02:39:31] Jeffrey Altman joins the room
[08:40:12] Jeffrey Altman leaves the room
[08:40:12] Jeffrey Altman joins the room
[08:45:35] Jeffrey Altman leaves the room
[08:45:36] Jeffrey Altman joins the room
[08:49:46] Jeffrey Altman leaves the room
[08:49:47] Jeffrey Altman joins the room
[08:56:33] wiesand joins the room
[09:00:02] Jeffrey Altman leaves the room
[09:00:49] Jeffrey Altman joins the room
[09:05:59] wiesand leaves the room
[09:20:47] Jeffrey Altman leaves the room
[09:20:48] Jeffrey Altman joins the room
[09:25:28] Jeffrey Altman leaves the room
[09:25:29] Jeffrey Altman joins the room
[09:47:56] Jeffrey Altman leaves the room
[11:14:28] Jeffrey Altman joins the room
[13:34:42] meffie joins the room
[13:45:15] stephan.wiesand joins the room
[14:01:16] deason joins the room
[14:01:18] <stephan.wiesand> HELLO ECHO Echo echo cho o o o
[14:01:25] <deason> hi
[14:01:36] <meffie> hello
[14:01:38] hey look i only get 10 copies of each message
[14:01:52] oh, and i'm still the room. yay!
[14:01:53] <stephan.wiesand> I get three, as last week
[14:02:13] <stephan.wiesand> And you're still the room, Hi Daria.
[14:03:04] hang on
[14:03:07] <stephan.wiesand> And Mike is shown as idle. Well, as long as it works...
[14:03:24] did that fix anything?
[14:03:26] meffie joins the room
[14:03:27] stephan.wiesand joins the room
[14:03:38] <stephan.wiesand> apparently, not you being the room ;-)
[14:03:48] <stephan.wiesand> but I get messages only once now
[14:03:48] <meffie> daria is invisible
[14:03:49] shadow@gmail.com/barnowlE5B64A04 joins the room
[14:04:06] <stephan.wiesand> and you're still idle
[14:04:20] <shadow@gmail.com/barnowlE5B64A04> do i become "real"?
[14:04:24] <shadow@gmail.com/barnowlE5B64A04> yes.
[14:04:27] <stephan.wiesand> yes :)
[14:04:31] <shadow@gmail.com/barnowlE5B64A04> i restarted the server
[14:04:32] <stephan.wiesand> Welcome back ;-)
[14:04:40] <shadow@gmail.com/barnowlE5B64A04> also, one of each message.
[14:04:45] <meffie> yes, and i'm idle which is probably accurate.
[14:04:51] <shadow@gmail.com/barnowlE5B64A04> hah
[14:04:52] <stephan.wiesand> I guessed that when it kicked me out withe message "shutting down" ;-)
[14:05:11] <stephan.wiesand> So, better :-)
[14:05:44] <stephan.wiesand> Did Andrew make it back in here?
[14:06:15] <stephan.wiesand> Anyway, let's look at the agenda...
[14:06:24] <stephan.wiesand> No Marc, so probably no Linux news?
[14:07:09] shadow joins the room
[14:07:29] kaduk joins the room
[14:07:48] <stephan.wiesand> (I'm slightly worried - coping with Linux w/o Marc would be "fun"...)
[14:07:53] <kaduk> Hmm, I'll have to try that "send as the server" trick sometime.  If we can figure out what caused it.
[14:08:11] <stephan.wiesand> Daria should know ;-)
[14:08:21] <shadow@gmail.com/barnowlE5B64A04> marc exists regardless of whether he is here
[14:08:34] <shadow@gmail.com/barnowlE5B64A04> and as to me as server, i am just running barnowl. i did nothing
special
[14:09:14] <kaduk> Yeah, I also need to work on getting barnowl talking to talk to MIT's jabberd, so I am not beholden to the vagaries of pidgin.
[14:09:28] <kaduk> Anyway, I'm pretty sure neither of those things were on the agenda.  Sorry, Stephan.
[14:09:35] <stephan.wiesand> np
[14:09:56] <stephan.wiesand> But speaking of the agenda ... 11392 ;-)
[14:10:10] deason joins the room
[14:10:13] <stephan.wiesand> I'm not sure what to make of the comments in there.
[14:11:13] <stephan.wiesand> Is this ok as is? (works fine for me) Or does it need to be reworked?
[14:11:46] <deason> I haven't heard any reason to not include it so far
[14:12:35] <kaduk> The dependency on auth.h still feels a little odd to me, but on the whole I'd say having it as-is is better than not having it.
[14:12:57] <stephan.wiesand> +1s being scarce is a reason...
[14:13:33] <kaduk> I mean, I didn't +1 it because I wanted someone (TM) to answer my question about auth.h :)
[14:14:11] <stephan.wiesand> Which is exactly why I'm prodding
[14:15:14] Simon Wilkinson joins the room
[14:15:19] <deason> I didn't really see a question....
[14:15:45] <deason> the deps and headers we're using I think is "wrong", and I said it would be fixed more properly not in that commit
[14:15:48] <deason> since it's a larger change
[14:16:31] <deason> but it doesn't matter for fixing the objdir builds there, so I thought we didn't care
[14:16:43] <kaduk> You've got ktc_krb5.o depending on ${TOP_INCDIR}/afs/auth.h, but that C file uses ""-includes to get auth.h from ../afs, so I would have expected the dependency to be on ../auth/auth.h (which I didn't say properly in gerrit due to a typo, whoops).
[14:16:50] <kaduk> Am I wrong to expect that form of the dependency?
[14:19:17] <stephan.wiesand> It works, solves a real problem, and now has the blessing of a gatekeeper. I'll merge it unless there's negative feedback here today or in response to the minutes.
[14:19:41] <kaduk> I'll +1 that
[14:20:12] <stephan.wiesand> I guess there are no objections to 11402..4 ?
[14:20:38] <deason> it makes conceptual sense, ben, but the header deps I don't really see doing anything
[14:21:11] <stephan.wiesand> And 11380 seems to take a bit longer. It can wait for 1.6.11 if it has to IMHO.
[14:21:12] <deason> and that commit didn't change which header path we were using; a previous commit changed which one we're using, and this just makes it work
[14:22:10] <kaduk> Okay.  Thanks for the explanation, Andrew.
[14:22:33] <deason> are we certain that %p is available everywhere?
[14:22:51] <kaduk> Mumble POSIX, IIRC.
[14:23:10] <kaduk> I probably checked that we use it elsewhere.
[14:23:32] <stephan.wiesand> What's not covered by buildbot that possibly wouldn't have it?
[14:23:49] <kaduk> Stephan: HP-UX?
[14:23:58] <kaduk> Anyway, there are %ps all over viced/callback.c
[14:24:16] <deason> okay, yes, we use it elsewhere
[14:24:38] <deason> but callback.c is using our formatter, I thought
[14:25:01] <deason> I thought I remember an issue with %p not being processed for something, but that may have been an internal formatter and is no longer an issue
[14:25:57] <shadow@gmail.com/barnowlE5B64A04> the whole thing is a mess and should be redone, but this is a "good
enough for now"
[14:26:44] <deason> okay, yes, in 1.4 %p was not supported by afs_snprintf &co, but it is in 1.6; I think that's what I'm thinking of
[14:26:53] <deason> but it doesn't effect the native printf regardless
[14:27:30] <stephan.wiesand> It's really unlikely that a pre2 would get tested on HP-UX (IRIX?) or any other platforms with those debug options...
[14:28:44] <stephan.wiesand> So, same statement as for 11392: If you can think of a reason not to include them, please speak up within the next days.
[14:29:13] <stephan.wiesand> About the ones Jeffrey brought up: 11433..4
[14:29:42] <stephan.wiesand> They may be low risk, but it seems there's still some discussion. I think they should wait for 1.6.11.
[14:30:04] <stephan.wiesand> Thoughts?
[14:30:39] <deason> 11433 I think needs some thought, but I haven't looked closely
[14:30:55] <deason> I don't think it's as "low risk" as mentioned, because we have no idea what may be using those fields and how its interpreting them
[14:31:12] <deason> (and I agree with jhutz at first glance; I have no idea why a backup system would be using that field and not the updateTime)
[14:31:15] <kaduk> 11434 is pretty no-brainer, I think.
[14:31:46] <kaduk> (I haven't really looked at 11433 in depth, having seen jhutz's comment.)
[14:31:53] <deason> 11434 seems more likely to be includeable, but I'll check
[14:32:12] <deason> from the description it just sounds like we're not paying attention to an argument at all, so...
[14:32:20] <kaduk> yes, that.
[14:33:12] <stephan.wiesand> It's still a change in behaviour then. I feel it would warrant a pre2, as would 11433.
[14:33:55] <stephan.wiesand> And a problem that old hardly warrants that at this point in time.
[14:35:16] <stephan.wiesand> Does anyone think one or both can't wait for 1.6.11?
[14:36:07] <stephan.wiesand> If not, next item: testing. Any new results?
[14:36:15] <deason> they're old, so they can probably wait
[14:36:27] <deason> but for the latter, it's one more release where the documentation is wrong about what a command line option does
[14:37:02] <stephan.wiesand> I'm fine with fixing the documentation w/o issuing a pre2 ;-)
[14:37:54] <stephan.wiesand> But really not with changing runtime behaviour this way, even if it now matches the docs.
[14:38:12] <deason> well and just say "this option is broken due to a bug"?
[14:38:40] <deason> I suppose it's better than doing nothing, but it seems a little silly
[14:39:01] <deason> but okay okay, testing?
[14:40:11] <deason> I have responses from.... 6, and promises from 2 more that they'll be running it soon
[14:40:45] <stephan.wiesand> We could add a "known issues with fixes deferred to the next release" to NEWS = RELNOTES.
[14:41:06] <stephan.wiesand> But testing: Thanks. Responses have been non-negative so far?
[14:42:10] <deason> yes yes
[14:42:14] shadow leaves the room
[14:42:24] <deason> and all linux I think, but a few different distros
[14:44:09] <stephan.wiesand> Which also brings us to "problem reports". Any thoughts on the one Jan Iven reported in rt (NTP time reset causing oopses) or the recent one on -info (bos removeuser making an assertion fail on some distros at least)?
[14:44:30] <stephan.wiesand> Addressing bot is 1.6.11 material IMO.
[14:44:35] <stephan.wiesand> both
[14:44:45] <kaduk> It may not actually be "too hard" to backport the bos thing.  I'm playing with the patch a little, at the moment.
[14:45:57] <stephan.wiesand> Russ proposed one or two simple solutions in RT. Maybe those are more appropriate to add to 1.6?
[14:46:54] <kaduk> Maybe, but it's kind of a hack
[14:47:21] <deason> chas' suggestion to only go into this code path if the file actually is a symlink would cut down on how often this is an issue
[14:47:22] <stephan.wiesand> If I got it right, there is no real solution at hand anyway?
[14:47:47] <kaduk> Well, passing NULL in is a real solution where it works, but is not fully portable, IIRC.
[14:48:26] <deason> iirc the 'solution' that covers all of the bases means you have to do different things on different platforms, and so also detect which one you have
[14:49:11] <stephan.wiesand> And not even master is doing that right now?
[14:49:34] <deason> master has a solution that works most of the time; more often than now certainly
[14:49:52] <kaduk> Master is doing a slightly less hacky version of Russ's suggestion, I think.
[14:51:05] <stephan.wiesand> I'm just saying that I'd be fine with a hack here if t solves the practical problem and doesn't make things worse.
[14:52:13] <kaduk> Well, I think a hack is all you're going to get.
[14:52:30] <kaduk> You just get to pick which hack :)
[14:52:31] <stephan.wiesand> The code in that file has diverged significantly, so keeping things "close" or beautifying the code isn't that much of an objective.
[14:53:01] <stephan.wiesand> I want the most simple and failsafe hack available.
[14:54:01] <stephan.wiesand> If there's a one-line hack, that's my favourite.
[14:54:59] <stephan.wiesand> But you're the experts. Convince me that a more complex one is much better (or just claim it firmly ;-) and we'll go with that.
[14:55:24] <kaduk> Well, I have a patch.  Let's see if it builds...
[14:55:32] <stephan.wiesand> Ok, thanks.
[14:55:49] <stephan.wiesand> Meanwhile next item: 1.8 branch
[14:56:45] <kaduk> Jeff pointed out some todo items via email; they seem reasonable
[14:56:48] <stephan.wiesand> Jeffrey said September might be a window of opportunity. And it seems we have Simon here today :)
[14:57:44] <stephan.wiesand> todo items: yes, they certainly have to be done beofre 1.6.8pre1
[14:57:48] <kaduk> The code that I'm running in my "production" test cell is derived from a somewhat old master, but there were a couple of bugs that I had to fix to get it working well.  But, we're probably in reasonable shape; just need more testing.
[14:58:17] <stephan.wiesand> I'm not convinced they have to done before we branch, nor that they would be easier to achieve before we branch.
[14:59:05] <kaduk> Do we actually have Simon, or just a client that reconnects?
[14:59:19] <Simon Wilkinson> a not entirely present Simon
[14:59:40] <stephan.wiesand> Hi, not enitrely present Simon.
[14:59:57] <Simon Wilkinson> sort-of-hi :)
[15:00:21] <stephan.wiesand> In fact, many (most?) fixes on master today originate from 1.6.x.
[15:01:12] <stephan.wiesand> Problem is found with 1.6, fixed for 1.6, then the fix is forward-ported to master and later pulled up to 1.6.x again.
[15:01:28] <stephan.wiesand> Sounds a bit weird, but it's my perception of reality.
[15:01:52] <kaduk> Well, people only find bugs in what they're running.
[15:02:04] <Simon Wilkinson> We didn't find the ubik bugs in 1.6 :)
[15:02:26] <stephan.wiesand> Or: change is pulled up to 1.6.x, reviewed there again, something is brought up which triggers an update on master.
[15:02:27] <Simon Wilkinson> (but then, they also don't need backported to 1.6, because there's no working pthreaded ubik there)
[15:03:01] <stephan.wiesand> I think the lock that was leaked isn't present in 1.6. Ubik?
[15:04:37] <Simon Wilkinson> Yeah - I can't remember if there's no pthreaded ubik at all in 1.6, or if what's there blows up as soon as you try to use it. Either way, the changes aren't need on 1.6.
[15:05:05] <Simon Wilkinson> But there are issues that are found first on master. I think it depends on whether they're found by people who are developing the code, or by people responding to a support issue.
[15:05:12] <kaduk> (I think the "it's there but blows up when you try to use it".)
[15:05:45] <stephan.wiesand> I'm not claiming the "do it on master first" paradigm is wrong.
[15:06:37] <stephan.wiesand> But I'm asserting that doing cleanups on master before branching will not make anything easier or faster.
[15:07:24] <Simon Wilkinson> It does make cherry-picks somewhat easier, as it means that the number of whitespace issues you encounter are less.
[15:07:33] <stephan.wiesand> Obviously, that's not for me to decide. I'm just voicing my opinion.
[15:08:17] <Simon Wilkinson> I think it's the least-worst time to do it. But I think any cleanup operation has to be carefully balanced between the benefits it brings, against the pain it causes to developers with out of tree patch series (hi Ben!)
[15:08:57] <kaduk> (hi not-entirely-present Simon!)
[15:09:20] <kaduk> (Should I send you an email poke about the rx_opaque size_t 64-bit thing?)
[15:09:41] <stephan.wiesand> otototot
[15:10:50] <stephan.wiesand> How much extra effort would it cost Ben to merge a grand whitespace cleanup now before what he's queued in gerrit?
[15:11:06] <Simon Wilkinson> (kaduk: Yeah. It's not completely dropped off my radar, just that YFS have rewritten big chunks of rxgen, XDR and RX, so extracting it is tricky)
[15:11:22] <kaduk> Whitespace is probably not a big deal, as git knows a fair amount of how to handle it, I think.
[15:11:35] <kaduk> (Sure, and I completely understand that extracting is challenging.)
[15:12:12] <Simon Wilkinson> Providing you do the rebase with the right magic switches, you can generally deal with simple whitespace. Any more complex reformatting (including line breaking and so on) is a bit of a nightmare, though.
[15:12:26] <stephan.wiesand> Yes, git does. Gerrit is anal about those path conflicts though.
[15:13:00] <Simon Wilkinson> Gerrit is anal about path conflicts because it used to have a bug with doing it's own conflict resolution, and so I turned that bit of magic off.
[15:13:32] <kaduk> A big block of commits is entirely new files, so there can't be conflicts there :)
And a lot of the rest is in places that Simon has already gone through and done a bunch of work on, so I think are in decent shape.  (Thanks, Simon!)
[15:13:47] <Simon Wilkinson> That's why git can do unconflicted merges/cherry-picks, when gerrit can't.
[15:13:50] <stephan.wiesand> I said it before: I'm perfectly fine with that setting, It will just cause a need for a huge rebase action if we merge a whitespace cleanup now.
[15:14:37] <stephan.wiesand> But if it's not an issue, all the better.
[15:14:53] <kaduk> I get to do a big rebase anyway, as I've been keeping the bits in gerrit based off the same (old) snapshot of master, to let reviewers compare different versions of the patchsets more easily.
[15:15:36] <meffie> that's probably a good idea.
[15:15:59] <stephan.wiesand> It seems we agree on the whitespace cleanup then.
[15:16:27] <stephan.wiesand> What about libtool issues and kernel module deps?
[15:16:52] <meffie> the makefile cleanup? that patch can be much smaller, if i do what ben suggested and ignore the whitespace errors in the comment header.
[15:17:08] <stephan.wiesand> Is there a real benefit in having them done on master before we branch?
[15:17:49] <kaduk> Last time Jeff asked about libtool, I didn't have anything that came to mind; that hasn't changed.
[15:17:52] <meffie> it was just submitted in frustration, while trying to fix the compile_et stuff.
[15:19:07] <kaduk> Someone (TM) should check that the kernel module is loadable on some various linuxen, in case anything broke since I made my rxgk branch.
[15:19:46] <Simon Wilkinson> There are a few things that will need attention with libtool - I don't think we do the right thing with roken or hcrypto, and there's absolutely no packaging for any of it.
[15:20:06] <Simon Wilkinson> That's a bigger issue for Debian than RHEL, because my understanding is that Debian will need a separate package for each library.
[15:21:06] <stephan.wiesand> My assertion is still that these fixes are more likely to happen soon or even at all if we branch a.s.a.p.
[15:21:09] <kaduk> Debian will end up with a separate package for each library, yes.  Russ has made that my problem now, and maybe Andrew's, too.
[15:21:51] <Simon Wilkinson> I'm not really fussed about when the branch happens, as long as everyone is happy with the added workload of maintaining multiple branches in parallel.
[15:22:21] <stephan.wiesand> We'll have that for a while. I think it's an accepted fact.
[15:23:59] <stephan.wiesand> Every day we wait makes that period only longer and the additional work more IMO.
[15:26:39] <stephan.wiesand> (and I really didn't mean to cut off the discussion... just offering my thoughts)
[15:27:36] <kaduk> I think it makes sense to have some quick sanity checks that master builds and runs vaguely plausibly on the main arches before we branch.  It's less clear that there's a need to make sure that all details are in place.
[15:28:45] <Simon Wilkinson> It's also worth making sure that there are commitments of the necessary effort to move it into a releasable form - there's no point cutting a 1.8 branch that languishes for years because nobody has the time to package, fix or test it.
[15:29:34] <stephan.wiesand> The last time I tried to build and run master it failed early in the build stage.
[15:30:39] <stephan.wiesand> I'm willing to care for the 1.8 branch and help getting it into a usable state.
[15:31:24] <stephan.wiesand> I don't have the time to keep trying that with master until it eventually is branched.
[15:31:41] <Simon Wilkinson> master built and ran at one point. But we're now so far from master, I don't think I can provide any useful information beyond that.
[15:32:05] <deason> so, what it seems like would be helpful is if we have a target date for the branching, and a list of requirements to achieve
[15:32:16] <deason> the only 'requirement' I hear is to make sure we build and run on some platforms
[15:32:39] <deason> and various "cleanup" things (whitespace) can happen as best-effort
[15:32:42] <kaduk> Probably.
[15:32:52] <kaduk> I don't think that having packaging ready is a prerequisite for branching.
[15:33:23] <Simon Wilkinson> Probably not. But I think there needs to be a commitment (however vague) that someone is prepared to do that packaging.
[15:33:43] <kaduk> Sure.
[15:34:27] <deason> do we have a desired target date?
[15:34:35] <stephan.wiesand> today
[15:34:46] <deason> ha
[15:35:00] <meffie> what time/
[15:35:01] <meffie> ?
[15:35:17] <stephan.wiesand> I'm serious. This time last year we talked about "around christmas". See where that got us.
[15:35:27] <kaduk> Hmm, trying to test-build my realpath cleanup, I'm still having trouble with an objdir build, even after picking 11392
[15:35:28] <deason> so set a deadline
[15:35:43] <deason> I want a little time in the future so people have a window for submitting large-scale cleanup things
[15:35:50] <stephan.wiesand> Not my turf...
[15:35:57] <Simon Wilkinson> I would have thought that late September would make sense.
[15:36:25] <Simon Wilkinson> Lets people get their feet back under their desks after summer vacation, get 1.6.10 out of the way, etc, etc.
[15:36:28] <deason> when I was asking that, I meant like, is there a period of time that you (stephan, or anything) would be particularly more busy or less busy, etc
[15:37:18] <stephan.wiesand> I'm having time off until the end of september.
[15:37:41] <stephan.wiesand> I may or may not go traveling for two or three weeks during that period.
[15:38:42] <stephan.wiesand> Afterwards, I'll have to catch up on many other things.
[15:39:34] <deason> so, just for your own schedule, you'd prefer a little after september? am I reading that right?
[15:39:45] <stephan.wiesand> But I'm not that important. You others are doing the actual work.
[15:39:58] <stephan.wiesand> No, I'd prefer today :)
[15:40:34] <deason> I would like you to be around to make decisions on things, but that's just me
[15:40:36] <stephan.wiesand> In that case, I might spend some time on 1.8 tomorrow. I'm unlikely to spemd time on master tomorrow.
[15:41:21] <deason> is there a time when you'll start not being around? in like a week or so?
[15:41:45] <stephan.wiesand> I'll do my very best to stay around. It worked pretty well last year when I was traveling for three weeks I believe. Can't promise though.
[15:42:02] <Simon Wilkinson> You can cut a branch retrospectively :)
[15:42:25] <deason> I know I know, but I mean, maybe spotty availability will start... in a week? 2 weeks?
[15:42:38] <deason> or that's the "tomorrow" you're talking about
[15:42:53] <stephan.wiesand> Andrew: No :) I can take a spontaneous decision to go on travel, and that's the one thing I'm not going to give up.
[15:43:29] <stephan.wiesand> And that's what I did last year too.
[15:43:38] <stephan.wiesand> It was great!
[15:43:49] <deason> okay
[15:44:22] <deason> you are serious about wanting to branch very soon, though? the line drawn in the sand could be september 3, then
[15:45:08] <stephan.wiesand> I'll still try to be online daily, call the meetings, etc. Worked fine last year, but it turned out doing that on iceland was fairly simple. Can't promise for this year, but will try.
[15:45:55] <stephan.wiesand> Drwaing a line in the sand is the right thing to do IMO. Whether it's Sept 3 or Sept 27 I don't really care.
[15:46:22] <deason> when it doesn't matter which thing we pick, I say it falls to you to pick one :)
[15:47:11] <deason> (by "line in the sand" I mean, we try to branch on that day; if we find a problem where we don't build/run at all, then it could move, obviously)
[15:47:32] <stephan.wiesand> It shouldn't. Again, IMHO.
[15:50:03] <deason> so... 24 sep? (it's still an arbitrary date, but probably less likely to make people angry than "next week")
[15:50:20] <deason> stephan.wiesand: agree/disagree? or anyone else, agree/disagree?
[15:50:39] <kaduk> No objection here
[15:50:49] <meffie> late sept sounds reasonable
[15:50:53] <stephan.wiesand> Nor here.
[15:51:29] <meffie> stupid question: does the rxkad-k5 stuff need to be forward ported as part of this?
[15:51:50] <kaduk> We did rxkad-k5 for master as part of the security advisory
[15:51:51] <stephan.wiesand> Of course, those who decide are the gatekeepers. But voicing an opinion as the release-team seem more than reasonable.
[15:52:51] <meffie> ah, thanks kaduk.
[15:52:53] <kaduk> (It uses keys of type afsconf_rxkad_krb5 in the KeyFileExt, and asetkey, so there's still some migration headache, but the functionality is there.)
[15:52:55] <deason> the keys are just in KeyFile.ext instead of rxkad.keytab
[15:53:01] <deason> er, KeyFileExt, right
[15:53:54] <deason> (er, that was responding to mike, not ben)
[15:55:24] <deason> anything else today?
[15:56:05] <stephan.wiesand> Yeah, it's been a long on again. Thanks a lot! Expect minutes tomorrow.
[15:56:45] <meffie> thank you
[15:57:33] meffie leaves the room
[16:23:35] stephan.wiesand leaves the room
[16:33:57] kaduk leaves the room
[20:57:05] deason leaves the room
[20:57:06] deason joins the room
[21:00:01] deason leaves the room