[05:17:00] --- Jeffrey Altman has left: Disconnected [05:21:03] --- meffie has become available [06:56:28] --- wiesand has become available [06:59:55] --- deason has become available [07:00:12] Hello crowd ;-) [07:00:24] hello [07:02:03] hi [07:02:15] I guess Ben isn't actually here - so it's just the three of us? [07:02:52] --- Marc Dionne has become available [07:03:15] Four :) Hello Marc [07:03:51] hi Stephan - don't see anyone listed in the room, odd [07:04:15] It seems we're with Andrew and Mike. [07:04:35] Ben is listed, but probably just that. [07:04:39] iirc ben said he was in a meeting [07:05:22] I haven't seen any feedback on 1.6.6 yet. Anyone? [07:06:09] If not, let's talk about 1.6.7 then. [07:06:56] What's on the horizon that hasn't been pulled up yet? (besides 10773) [07:07:02] i haven't seen any feedback either [07:07:25] i have one potential item, which is maybe something that helps with the getcwd ENOENT problem [07:07:38] there's giveupallcaballbacls possible [07:07:41] apossibly [07:07:52] Marc: That would be great. [07:08:17] and 6266 and related changes [07:08:30] Andrew: yes, that's still on the table. IIRC, you were opposed to GUACB? [07:08:39] 6266-and-related I'm more comfortable with now, as the relevant site has been running with dafs with it for a little while without problems [07:09:06] and 6266-and-related I can do; I need to submit them again, I think [07:09:28] I was and still am opposed to GUACB without a switch to turn it off (and have it default to off when it's first introduced) [07:10:08] Right. Still no volunteer for implementing that switch I suppose? [07:10:58] I don't mind doing a global switch, since that's really easy, but... [07:11:14] But? [07:11:18] I was hoping sometime to have a per-cell setting for "various things" and this would be one of them [07:11:36] oh, I guess we have the setuid thing, maybe this can use the same infrastructure [07:11:57] The setuid thing? [07:12:16] the option to turn on and off setuid support [07:12:27] the fs setcell ? [07:12:30] 'fs setcell' right now [07:12:47] it seems to imply it's supposed to be for other per-cell options, as well, but we only ever had one [07:13:18] yes, which makes it odd :) [07:13:31] fs setcell -guacb? [07:14:05] yeah, something like that [07:14:23] Makes sense. [07:14:50] I'm not volunteering to do it yet; I'd rather see how the idledead stuff goes and the 6266 stuff; after those are done I'll see how close we are if it's still okay to introduce a new thing [07:15:00] --- shadow@gmail.com/barnowlFF98C472 has become available [07:15:01] (don't want to promise too many things at once) [07:15:13] Makes sense too. [07:15:23] sorry for the delay. i enabled two-factor for google last week and suddenly couldn't get on. "duh" [07:15:57] marc, was there more to say on the getcwd thing? or just, we'll see a patch submitted? [07:17:06] yeah, I'm curious too [07:17:17] What's related to 6266? [07:18:21] there's another commit for adding the fileserver options, maybe others; I'm not sure if there are gerrits yet for them in 1.6 [07:18:37] it's all the same feature; there are just probably a few other commits for it [07:18:51] andrew, yes i will probably post a patch shortly [07:18:55] 10634 would also be nice [07:19:10] as would the parallel-build fix stuff... I think there was something new for that? [07:19:35] there's a bunch of new patches still on master waiting for reviews, yes? [07:19:57] reviews in progress, and some stuff i have to fix [07:19:58] 1.6 is doing very well regarding parallel builds, and I remember Jeffrey objecting to such a build system change in stable. [07:20:04] i pointed out one bug with the parallel build changes, other than that the set builds ok here in testing [07:20:20] er, stuff from the reviews that is. i dont have anything else not in gerrit. [07:20:30] i have no objection to it in stable: if the resulting binaries are the same, don't care. stable is (to me) code, not the build system. [07:21:15] ok, thanks. [07:21:49] I have no real objections either. Reduces skew w.r.t. master. [07:22:14] also want: 10214, and 10322; I think that's all for my list of things I want in [07:22:19] the changes are really, try to get the deps right, even if a bit heavy handed. [07:22:48] libadmin: what a mess [07:23:05] yes, no fun. [07:24:33] after this, i'm wondering, could i try to do something with gcc / clang to autogenerate dependencies? (and some work to figure inter-package deps?) [07:25:00] i merged up to the point of the issues. the stuff below was all relatively mundane stuff, before you started the heavy-handed things [07:25:11] yes, thank you. [07:26:07] It would be good to get review for the mavericks build changes by Ben. [07:26:18] Many of them are rather trivial. [07:26:18] number? [07:26:33] http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-stable-1_6_x+topic:mavericks,n,z [07:26:33] there's a bunch: http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-stable-1_6_x+topic:mavericks,n,z [07:27:03] Is there any disagreement about those in general? [07:27:07] and yeah, I haven't looked at what's in 1_6_x yet, I will soon [07:28:33] It's not much yet. The bulk is Ben's stuff at this point. Which why I'd like to get those merged soon. [07:32:12] Before pulling up, please check briefly whether there's a change close to being merged that touches the same files. [07:33:02] I don't know about that sbrk change, but that's something to talk about in gerrit [07:34:07] Example: 10602. It's trivial, but once it's merged a number of nontrivial ones pulled up lately would have to be rebased. [07:34:13] the sbrk calculation of used memory was already bullshit [07:34:21] It simply should have been merged before pulling up the others. [07:35:23] it's still going to look funny if someone monitors it if it goes to -1 instead of a getrlimit value [07:37:05] if there was a designated set of changes to submit stuff "on to", we could just put them in a single line, while waiting for approval [07:37:46] but if any changes that touch the same file need to be changed and resubmitted, you'll need to rebase the others anyway... [07:38:28] Exactly. We should try maintaining a list. [07:38:43] And pull up what we can reasonably work on in the near future. [07:39:39] Avoiding a huge backlog in the first place. [07:41:14] well, should we rebase them all in single line? I could put everything on top of the tail of, say, ben's changes, if you want [07:42:12] That only helps if it's already clear that *all* of them will go in quickly. [07:42:30] In which case we can just as well merge them before pulling up more changes. [07:43:32] By the way, how would one do that? (Without pushing everything again, making buildbot busy) [07:44:08] This is a technical git question, I admit. [07:44:49] rebase them onto ben's changes? just check out the latest one, and then cherry-pick the others onto it [07:45:21] or checkout the latest change in a series, and then 'git rebase' it onto a branch that has, say, ben's changes on it [07:45:28] you can fetch commits from gerrit, then checkout a local branch [07:46:30] Thanks, I'll try eventually. [07:47:12] even if something changes in the series and needs to be re-pushed, having everything in a line would ensure there are no significant conflicts, and fixing a path conflict should always be a simple repush, with no manual editing required [07:48:07] It does happen though. [07:48:25] Maybe a bit OT: any opinions on 10765? [07:49:50] Maybe it would keep folks from trying 1.7 on Linux... [07:52:07] it seems long for the navbar but maybe [07:52:35] I don't remember, can I view a website change by just pointing a browser at the checked-out web source? [07:53:32] Not easily I believe. [07:53:38] there used to be a way to do something with sb.openafs.org [07:54:34] Looks like an ancient version of the page. [07:56:36] I believe Ken has his own staging site. [07:57:11] I could just alter the source in-browser in opera, but it doesn't seem to like it when there are frames, oh well [07:57:48] ok, it's not just me :) [07:58:44] We can work out the details in gerrit. [07:59:10] Ok, it seems we have enough topics lined up to make 1.6.7 worthwile. Fixes only, no features. [07:59:36] GUACB would be a feature, if it makes it. [08:00:52] 6266 is a feature [08:01:14] Ah, ok. [08:01:51] well, a lot of times the "features" are done to fix some problem. [08:02:24] but, yes, we should try to do just bug fixes for stable. [08:02:54] A feature or two is fine with me. [08:03:30] At least until there *are* feature releases again. [08:04:27] Ok, anything else to discuss today? [08:05:03] Marc, any dark clouds on the Linux sky yet? [08:05:29] no, we're still ok with current mainline, but we're not at rc1 yet [08:06:03] Thanks. Let's see. [08:06:59] Worst case, we'll make 1.6.6.1 ... [08:07:28] I think we're done? Thanks a lot everyone. [08:08:59] I hope I'll get the minutes done later today. Goodbye. [08:09:01] --- wiesand has left [08:10:56] --- deason has left [08:15:31] --- meffie has left [08:53:09] --- deason has become available [09:57:27] --- Marc Dionne has left [15:15:43] --- deason has left [15:15:44] --- deason has become available [15:56:24] --- deason has left