[05:14:15] --- meffie has become available [05:39:47] --- meffie has left [05:40:29] --- m.meffie has become available [05:41:31] --- m.meffie has left [05:41:37] --- m.meffie has become available [05:44:05] --- m.meffie has left [05:59:10] --- meffie has become available [06:36:49] --- squinney has become available [06:47:53] --- stephan.wiesand has become available [06:48:26] test test [06:58:03] Seems to be working [06:58:18] good day [06:59:10] Hello. [07:00:14] My Notebook is running on battery - this may limit the time for the meeting. [07:02:44] Mike, is "bozo: cap retry delay" making progress on master? [07:03:30] well, i think it just needs gatekeeper +2. [07:06:54] i'll rebase and push patchset 4 [07:10:39] Hmm, not many participants today. Anyway, let's look at the agenda. [07:10:58] Open changes for 1.6.x. [07:11:32] Besides "cap retry delay", is there anything left that needs special attention? [07:11:46] (forgetting about everything marked -2) [07:12:05] I just merged 10165. [07:12:33] 10247 [07:13:44] It lacks review, but that's it? [07:14:17] --- deason has become available [07:14:27] it is a silly bug. [07:14:46] Hello Andrew [07:15:12] Mike, sure, this should go in. [07:15:32] hi [07:15:44] Are there any must-haves for 1.6.6 that haven't been pulled up? [07:15:53] yeah, 10247 is silly/small, but imo that means it should be easy to review :) [07:16:32] Poked Ben [07:18:18] I've been wondering that we should log some big warning if you're not running rxkad-k5... there's no indication about it if you're not paying attention to security advisories [07:18:28] there's no change for it, but introducing that would just be a logging call [07:19:36] Sounds like a good idea. This change would be the same on master and 1.6? [07:20:54] also, it occurred to me, maybe we should update the man pages for klog/klog.krb, to say it is deprecated (or historical)? [07:20:58] possibly not, the rxkad-k5 implementation is very different between the two [07:21:12] :-( [07:21:31] you mean the kaserver ones? I thought they should still say that [07:21:52] the krb5 ones I thought were updated for rxkad-k5; if they're not, they should [07:22:01] er, that is, if they are kaserver, they should already say that [07:22:33] i'll double check. [07:23:38] This place reeks like foul eggs... [07:23:46] which? [07:24:15] Reykjanes peninsula [07:25:03] (Iceland) [07:25:27] sulfur in the hot springs [07:25:39] Exactly. [07:25:46] not much to discuss on the those previous points, though; moving on? [07:26:05] Ok. There's the linux changes by Derrick [07:26:37] It seems we want those for both 1.6.5.1 and 1.6.6 ? [07:26:50] those fix a regression namely when we switched to aio_write we broke several things which expect you will always have a write fop [07:27:02] so i would assume 1.6.5.1 wants them [07:27:16] When was this problem introduced? [07:27:43] for 1.6.4 [07:27:50] (in the 1.6.3 cycle) [07:28:14] Btw I'm running the 1.6.5 client on an SL5 system - why haven't I noticed? [07:28:31] wrong kernel? [07:28:53] or, nothing which tries to either use writev() to write to afs, or drop a core there? [07:29:04] basically, those are the 2 things that fail [07:29:12] at least in the past, my understanding of the .1 platform support releases is that it says to users "only use 1.6.5.1 if 1.6.5 doesn't work/build for you" [07:29:20] open a file in afs. use writev() to write to it. get bogus error [07:29:29] It's the default EL5 kernel. So, probably nothing trying to do those. [07:29:39] yeah. probably [07:29:52] well, not that you'd miss a core unless you knew you were looking for it [07:29:55] if it contains an actual bugfix, it kinda changes things [07:30:15] They need review. Poking... [07:32:02] Agreed that both 1.6.5.1 and 1.6.6 should block on 10248 and 10254? [07:33:57] seems prudent [07:34:25] i would. but it's not my circus, not my monkeys. [07:34:27] no, what I was just saying was objecting to that [07:34:44] or, well, maybe [07:34:58] I don't feel too strongly about the current system of .1 platform releases, but it seems inconsistent with them [07:35:26] basically, i never want to be in a position of telling someone "yeah, we just shipped that, here's the patch you need to actually make it work" [07:36:17] Well, real testing happens after the release... [07:36:43] i really tested this patch :) [07:36:50] but that always happens with the .1 releases; we have bugfixes that are going into the next release [07:37:25] if it's a bugfix, it's "supposed" to go in a bugfix release, and 1.6.5.1 is not a bugfix release; you could just call it 1.6.6 [07:37:40] I don't feel strongly about it, I'm just pointing it out [07:37:49] 1.6.5.1 is also okay [07:38:07] like i said, not my circus, not my monkeys. [07:39:05] All three changes in question fix selected linux clients. [07:39:44] But using that argument, we could also include the SLES fix from Christof... [07:40:19] what is that? [07:40:52] 10252 [07:41:00] df thing? [07:42:22] No, the df thing is for folks using the wrong mount point. Not a candidate for 1.6.5.1 IMO. [07:43:36] Andrew, Simon created a 1_6_5_x branch. We shouldn't cut a 1.6.6 from that. Too messy. [07:43:42] right, the keyring thing [07:44:19] imo fine for 1.6.5.1 [07:45:10] Yes, probably. [07:45:17] also, these things are in gerrit for 1.6.x; if you want to do the same branching thing as in 1.6.5, I assumed they would need to be in gerrit for 1.6.5.1, and then later merge 1.6.5.1 into 1.6.x [07:46:19] It's the first time I'm doing this... my plan was to pull up from 1_6_x to 1_6_5_x [07:47:14] And not merge the branch back ever. [07:48:16] Anything wrong with that? [07:49:49] that's probably fine, too; I was trying to look at prior examples, but I guess there aren't any :) [07:50:10] None that I think we should follow ;-) [07:50:18] (1.4.12.1) [07:51:20] I'll bring up the 1.6.5.1 issue on the mailing list. In the end, I'll have to decide and probably make someone unhappy. No problem :-) [07:51:40] But Andrew's points are taken. [07:53:17] are we going to discuss timelines today, then? [07:53:44] We should. Does anyone know whether Linux 3.12rc1 will require further changes? [07:54:10] Because that would probably set constraints... [07:55:27] no, but I can probably try at least building against it today [07:55:54] Setting that aside, my idea would be to get 1.6.5.1 out next week, and 1.6.6pre1 a few days after. [07:56:09] Andrew: that would be great. [07:59:11] Does this sound reasonable? [07:59:55] are you expecting to have the backlog cleared by then? [08:00:03] I guess there's nothing in there that should require significant time [08:00:31] The backlog has shrunk to ~20 changes. Should be doable. [08:01:08] Especially if you keep helping me with the rebases. But those should be few now. [08:03:35] Review is still needed for most of them. This and my availability will define the schedule. [08:04:02] with that schedule, I expect/hope the backlog to largely be merged or at least reviewed by the weekend [08:04:43] and the remaining few we can probably do something about by the end of meeting next week if they ahven't been handled [08:04:46] so, sure [08:05:08] "Unfortunately", the weather has been great here, and will be for much of the time. So I have plenty of things to do rather than playing with gerrit. [08:06:31] Anything else to discuss today? [08:06:56] if it makes things easier for you, I could rebase everything in one line to ensure there are no conflicts and whatever [08:07:11] for things that we think will go in, but are just waiting for enough reviews [08:08:15] That would help. Now that bozo: cap retry delay seems ready, it makes sense. [08:08:31] There seems to be some debate about the pullup of 7554? [08:08:44] i'll pull up the bozo thing now. [08:09:36] Which is 10229 [08:10:10] yes, 10229 as it originally existed I believed could make things worse for some cases where it works now [08:10:53] in order to avoid that, it requires a new change to go on master, and then pulled to 1.6 [08:12:20] or it's possible the "makes it worse case" doesn't exist, but I don't think that's true; and nobody has tried advocating that route [08:12:34] (iirc this has also been broken ~forever, so I don't think it's critical for 1.6.6) [08:12:45] Ok, probably needs more discussion. [08:12:53] New bug in RT: https://rt.central.org/rt/Ticket/Display.html?id=131731 [08:13:32] But it's about 1.6.1-1+ubuntu0.2 [08:16:13] Anything else? [08:16:46] well, it's a bug about a segfault if you give the options incorrectly in 1.6 [08:16:49] and on master apparently it's broken [08:17:17] So, not urgent. Thanks. [08:17:22] not critical to me, but the first one is probably indeed a bug still on 1.6.x [08:19:10] Ok, the sun is creeping towards my display, and the battery is nearly depleted. [08:19:18] ok [08:19:59] Time to move on. Thanks a lot everyone. I'll write up minutes as soon as I've found an accommodation with an AC socket ;-) [08:20:04] Bye. [08:20:33] --- stephan.wiesand has left [08:26:50] --- squinney has left [10:50:50] --- meffie has left [10:51:30] --- m.meffie has become available [12:22:35] --- m.meffie has left [12:25:41] --- m.meffie has become available [14:38:07] --- m.meffie has left [15:47:57] --- deason has left