[05:12:12] --- Marc Dionne has become available [06:34:25] --- meffie has become available [06:55:07] --- Stephan Wiesand has become available [07:00:39] Hello [07:01:03] hi Stephan [07:02:17] Is anyone else actually here? [07:02:25] I'm here [07:02:30] Jeff is unlikely to be [07:02:44] though I didn't get scrollback, and my user list is not showing people [07:03:49] My userlist shows Jeff, Marc, Mike, Derrick and you. [07:04:24] Without a gatekeeper present, we can skip the 1.6.5.1 item. [07:04:35] So on to 1.6.6pre1. [07:04:46] Marc, any Linux news? [07:04:59] tested current git this morning, we're still ok [07:05:06] Great, thanks. [07:05:07] hello [07:05:13] Hello Mike. [07:05:21] Addition to the agenda: https://rt.central.org/rt/Ticket/Display.html?id=131749 [07:05:25] Linus made a comment in an interview this morning that 3.12 would be out in "about a week" [07:06:13] 1.6.5.1 will still work with that unless some last minute change comes up again, right? [07:07:11] right [07:09:52] So no time pressure for 1.6.6. FIne. [07:10:54] Is that new bug in RT something that ought to be fixed in 1.6.6? (If it's real?) [07:11:38] what he says looks correct, but I'm not sure what the actual user-visible problem is [07:12:34] It seems this was introduced in 2010? [07:13:46] looks like a cut and paste coding error, normally not hit because of the conditional compile. [07:14:08] no, since 2008 [07:14:28] Not a regression ;-) [07:15:12] that code path is also only hit for pthreaded vos, which we never ship right now [07:15:37] This could wait for 1.6.7. [07:15:56] >what he says looks correct, but I'm not sure what the actual user-visible problem is or no, it's in there, I just can't read [07:16:36] Writing to stdout blocks forever. Is this a real problem? [07:16:59] Or is it just a nuisance when you add debug printfs? [07:17:02] yes, but it's only the pthreaded vos, which is why we've never heard about it before [07:17:37] it would (I assume) break 'vos dump | stuff' [07:18:16] Ah, ok. [07:18:49] I guess this will be fixed swiftly, but I see no need to block 1.6.6 on it. [07:19:17] On to the parallel build issues. [07:19:38] Mike, I'd really like to revert 10310 for the time being. [07:21:06] 10349 should do that. [07:21:40] ok [07:21:55] 10337 seems correct though, and doesn't make any problems in my tests, except when combined with 10310. [07:22:39] So with a couple of votes in favour of 10349, I could merge both. [07:23:23] I also started working on release notes. Gerrit 10359 . [07:24:12] Pretty long list. I'll need help to get this polished and completed. [07:25:25] The first comment has a number of changes listed for which I couldn't find the right words but that should probably be mentioned. [07:26:00] (I intend to remove the change numbers in parentheses in the final commit) [07:26:54] I feel like those could be useful to have in there, but we haven't been doing in this release series, so... [07:27:48] I'm not quite getting you... "those"? [07:27:58] the change numbers in parens [07:28:24] regardless, I'll be looking at that, but there's too much to go through for you to hear much about it right now :) so, moving on? [07:28:41] yes, those are helpful. [07:28:49] Ah, sorry. I just put them in for bookeeping and to make it easier for others to help improve the descriptions. [07:29:32] Ok, going on. Andrew, I figure you have something to discuss? [07:30:47] https://rt.central.org/rt/Ticket/Display.html?id=131747 seems to be the same "issue" as reported by Stephen? [07:30:50] 10354 &co? [07:31:00] yes [07:31:22] And 10354 & co are about this, right? [07:31:33] yeah [07:31:53] the stack with 10354 is more heavily exercised than I though (by a site running with those patches), so I feel better about including it [07:32:11] it fixes the panic on list and in that ticket [07:32:41] some of those are complex, so I was planning on going back through and re-reviewing them [07:32:47] and of course omeone else should, as well [07:33:07] but if someone strongly feels we shouldn't hold up the release for them, I can see that, too [07:33:51] Panics are bad. Not as bad as silent data corruption, but pretty bad. I'm inclined to let pre1 slip for another couple of days for this. [07:35:11] sorry. just arrived. [07:35:18] Hi [07:35:51] Let's give Derrick a minute to read up and comment. [07:37:13] yeah, i think waiting for that sounds like a good plan [07:38:10] and reverting sounds good also, (and i +1'd) [07:38:27] Thanks. [07:38:57] Any idea why we got two reports of client panics within days now, and never before? [07:39:12] Hans-Werner's is against 1.6.2... [07:39:14] i was wondering that. what changed. [07:39:28] like, is it that new kernels make something happen that didn't before? [07:39:34] more sites moving to 1.6.x? [07:40:44] the other site running these patches appears to hit this way more with rhel6, so I'm assuming some relevant kernel code paths changed [07:40:59] ah [07:42:40] is this know to occur besides the 2 reports (Hans, Stephen) [07:43:22] the panic? yes [07:44:05] We're pre-pre1. Let's review and include the 10354 stack. [07:44:53] What are possible reasons for those cache read errors? [07:45:20] Flaky hardware, or other client bugs? [07:45:35] no, I thought I mentioned in on the list [07:45:55] it's probably that we have a pending signal (possibly fatal signals only), and some code path checks for signals and returns EINTR [07:46:29] Sorry. Yes you mentioned it. [07:47:08] So, agreed, I guess.. [07:47:15] either it happens every time (I thought I tried reproducing that a while ago and could not, but maybe I did something wrong...) or only in certain code paths, like, when we need to allocate memory or there's lock contention or something when fulfilling the read/write request [07:47:27] but those are guesses; we'll get some info soon enough [07:47:54] Good. Anything else regarding 1.6.6? [07:48:53] If not: Derrick, should we update the 1.6.5.1 release web page, now that we provide binaries for 5 platforms rather than hust 1? [07:49:05] probably. [07:49:23] if you have an updated page, push it and i will get the web site refreshed [07:49:40] Ken already +1'ed 10348 [07:49:59] oh right. i have to do it [07:50:10] Thanks. [07:50:23] Should this be announced? [07:52:10] I guess I can just send mail to -info. [07:52:44] an announcement would be consistent with what we have done before [07:53:07] Ok, so openafs-announce? [07:53:12] sure [07:53:39] Ok, will do. Thanks for updating the web pages! [07:55:07] Anything else to discuss today? [07:55:29] none here. [07:55:41] one thing [07:55:43] I believe Derrick and Jeffrey are unlikely to be available next week. [07:55:50] one more thing? [07:56:12] I was just wondering, would anyone want these meetings to be via the phone or a webex or anything? [07:56:20] just say "no" if that sounds terrible :) [07:56:31] I was just wondering if more realtime communication could make them go faster [07:57:08] on one hand it probably would but on the other i wonder if in some cases it would make availability worse [07:57:31] it also doesn't give us an automatic log of what was said [07:57:41] (unless we actually recorded the audio or something) [07:57:42] I'm not sure they would be much faster. The availability problem is real. And I really like having the transcript. [07:58:26] So, from my point of view, jabber is fine. [07:58:38] okay, just wanted to mention it [07:58:43] nothing further, then :) [07:58:46] --- kaduk has become available [07:59:16] Jabber is fine for me, too; I just need to get a better client. [07:59:40] Hello Ben. What's wrong with yours? [07:59:45] (backing up a bit, I'll just note that we did need 10337 to get things to build on freebsd) [08:00:17] My build of barnowl doesn't really want to talk to MIT's jabber server, and I haven't had any luck trying to auto-register an account @openafs.org [08:00:24] 10337 will be merged right after reverting 10310. [08:00:53] oh wait, sorry, I had another thing [08:01:00] ;-) [08:01:27] Yup, that's what the log made it look like, I just wanted to confirm that it did fix a real problem [08:01:33] jason, mike, and I have been working to get the buildbot master upgraded, which is almost there [08:01:47] I was waiting on doing any actual changes until after 1.6.6pre1 so we don't break anything when we really need it [08:02:05] should we wait until 1.6.6 final is out? or is between "pre"s acceptable? [08:02:16] (this could be on list, I guess, bah) [08:02:56] IMO, it doesn't matter much. After pre1, changes should be few and far between. [08:03:32] I would like to get 10340 and 10339 into 1.6.6, but neither is strictly freebsd-specific changes. I don't know that it's enough to hold up pre1 for, though. [08:03:56] In particular, it seems unlikely that we must merge anything for at least a week after pre1. [08:07:00] They look innocuous to me. [08:07:27] Right. I don't expect problems from them, but it was worth noting. [08:09:13] If they make it in time, why not. I wouldn't want to wait another week for them though. But I guess it will take a few days to get the 10354 stack reviewed. [08:09:52] I'm not sure what I'm going to do about the misaligned stack for LWP things with clang ... worst-case I'll just make the freebsd packaging set -mstackrealign [08:10:24] No blocker then :) [08:12:10] Ok, any other "one more thing"s? [08:13:11] my one more thing is: I don't have any more "one more thing"s [08:14:25] Good. Thanks a lot everyone! Please help reviewing if you can, so we can get pre1 out eventually... [08:14:44] Bye. [08:14:48] --- Stephan Wiesand has left [08:16:37] --- kaduk has left [08:36:58] --- deason has left [09:08:38] --- deason has become available [09:38:10] --- kaduk@jabber.openafs.org/barnowl has become available [10:35:39] --- Jeffrey Altman has left: Disconnected [10:42:10] --- Jeffrey Altman has become available [10:43:52] --- meffie has left [10:43:53] --- meffie has become available [14:37:29] --- Marc Dionne has left [15:59:28] --- deason has left [16:10:03] --- meffie has left