[05:41:09] --- Marc Dionne has become available [06:37:18] --- meffie has become available [06:42:47] --- meffie has left [06:47:35] --- meffie has become available [06:59:26] --- Stephan Wiesand has become available [07:01:13] --- Marc Dionne has left [07:03:17] Hello. Who's actually here? [07:04:17] Well, that's a hard thing to define... [07:04:31] good enough :-) [07:04:54] --- Marc Dionne has become available [07:05:04] * meffie waves [07:06:04] I guess there's not an awful lot to discuss. [07:06:12] --- deason has become available [07:06:25] Jeff, Mike: Thanks for the feedback. [07:06:31] Yay [07:06:59] I also received a message from Christof. He's running a File+DB server. No real testing yet though. [07:07:25] But at least someone confirmed that the db server can actually be started ;-) [07:07:44] Any additional feedback? [07:08:19] Probably not. [07:08:44] But what we have I would consider sufficient for announcing pre1. [07:08:52] But then there's 9898. [07:08:58] I think you are fine for pre1 [07:09:23] there's a fileserver and dbserver running here; no problems [07:09:35] Thanks. [07:09:37] yes, I thought the one question was 9898 [07:09:43] I've been running the windows stress test against the pre1 server for several days now and there were no issues [07:09:57] Ah, good. [07:10:27] 9898 seems important. But it's really late. [07:11:26] It would invalidate the client testing we have, and the binaries (both Christof and Stephen have been building). [07:11:46] i think you might want it in the final release, the question is whether it's essential for pre1 [07:12:05] it doesn't have to be included in pre1 [07:12:37] although I'm not sure what else we would add in pre2 other than 9898 and pre1 has not been tagged yet [07:13:13] If pre1 tests fine, who needs pre2? ;) [07:13:19] I thought we didn't issue a preX when we already know we're going to include something else for preX+1... [07:13:53] Chances are someone will find something. Or something else will come up. [07:14:30] Andrew: makes sense, but 9898 would delay pre1 for a week. Not desirable, is it? [07:15:11] It doesn't have a single +1 yet. [07:15:56] Who'd be really unhappy about deferring 9898 to pre2? [07:16:06] I'm not sure how it's better to defer it [07:16:13] I'll give it a +1 [07:16:19] I mean, if you know it must go in for the final release, it must go in some pre [07:16:37] --- shadow has become available [07:16:37] and so if you issue pre1 without it, and then pre2, you've invalidated all (linux) client testing [07:16:46] I feel like we can put it in pre1 and if it causes problems back out/adjust. [07:17:02] so even if you put it in right now, and it causes things to crash immediately, even that seems better [07:17:05] since then you know right away [07:17:07] exactly and since pre1 has not been given to the public yet you might as well include it in pre1. a pre2 round will only increase the time until final is issued [07:17:40] Unless we have a pre2 for other reasons. [07:18:01] which is hypothetical at this point [07:18:14] well, if pre2 doesn't change anything in the client... it still seems a bit better [07:18:18] The change won't affect EL5/6 at all, right? [07:19:01] will it really delay us for a _week_? if someone can just mention the relevant kernel versions, I could smoke test them before tomorrow [07:19:21] the change does a cleanup even for the non-hlist case, so it does touch code for all kernel version [07:19:22] Building the RHEL and Fedora stuff takes days. [07:20:06] Thanks Marc. [07:20:12] ah, okay [07:20:33] well, my vote is still for it, but I'm not going to be unhappy if you defer [07:20:58] Of course we can announce pre1 without binaries. [07:21:01] so maybe you'd prefer a minimal change that just fixes the hlist case without touching the rest? that would only touch kernels that have the issue [07:22:40] Thanks, but let's take it as it is now, ie we take it. [07:23:01] the reasoning for the current stuff may be that that last hunk has 2 hlist cases and 1 'list' case... using different things for them would make that a bit messier [07:23:15] --- shadow has left [07:23:32] yeah it's better to leave it as is if possible [07:25:20] Sigh. Ok, I'll test it on EL5/6 and F18, and if it works for me, I'll merge it we'll call it pre1. [07:26:20] Maybe we should actually call it pre2 right away? [07:26:32] Since there are binaries out there called pre1... [07:27:21] I wouldn't mind that, just be clear in a release announcement that pre1 wasn't public or whatever [07:27:30] Of course. [07:28:10] and okay, if we're including 9898... there's an openbsd change that antoine asked me about; I assume that could maybe go in without much fuss? [07:28:46] omg... [07:28:48] since obsd is kinda 'who cares' [07:29:07] it was just a suggestion :) [07:29:23] where's the change? [07:29:26] it won't delay anything any further [07:29:27] 9908 [07:29:30] --- Derrick Brashear has become available [07:29:49] so apparently all my messages so far have been being silently 405'd :\ [07:30:12] Derrick: I didn't receive anything from you. [07:31:09] Ok, I'll pull 9908... [07:31:24] yes, like i said, all my messages got silently 405'd, so none of you saw anything i said [07:31:35] So, what id you say? [07:31:42] Yeah, 9908 looks fine; I can +1 if you want (but I'd have to sign in) [07:32:10] A few +1s always make me fell better when hitting the submit button. [07:32:40] i think it was all covered. the "just skip to pre2" and "yes, you should just take any obsd changes that touch nothing else" were basically the just [07:32:42] gist [07:33:37] Fine. Let's do it like this. I'm a bit sorry for Stephen and Christof though. [07:34:16] Anything else to discuss? [07:34:36] i have nothing [07:35:04] well, if we wanted, should we release source-only pre2, and say that binaries are coming? [07:35:10] or does that possibly turn away too many testers [07:35:32] I figure most who are likely to test will do so anyway. [07:36:08] honestly it's the rpm people who you get by giving them binaries. the people who build from source will test anyway [07:37:15] --- Derrick Brashear has left: Disconnected [07:37:26] I just wonder how many rpm people are likely to test at all. [07:37:46] not enough. [07:37:53] I think we'll announce without binaries. [07:37:59] ok [07:38:08] scripts.mit.edu probably will, but they have to patch the source and rebuild anyway. [07:38:33] Many sites build their own rpms. [07:39:09] I think they still use the srpm to do so, though. It's been a while since I looked at that build process. [07:39:16] What do they )scripts) patch? [07:40:14] they change the client to do some weird site-specific access checks, so they can serve cgi scripts as different users [07:41:05] iirc, run the webserver under one token, but restrict access for ~user in afs for just that user... it involves some specific way of numbering things? or something like that, from what I remember [07:41:20] Thanks. [07:41:30] Ok, I think we agree on how to go forward. [07:41:31] The main thing is a privilege separation thing, there's a global pag with tokens for a daemon.scripts principal, but those tokens are only allowed to be used if uid -- volume id, and "users" on the site are signed up through a separate process and get assigned the volume id of the particualr site as the uid on scripts. [07:42:56] So' let's call it a day (here). Thanks a lot everyone! [07:44:08] For the curious, http://scripts.mit.edu/trac/browser/trunk/server/common/patches/openafs-scripts.patch is the scripts patch in question [07:44:56] Stephan Wiesand: on another subject, may i ask about the openafs-repository-noarch.rpm ? [07:46:12] is that something that is still manually created? i remember doing one for an older version (1.4.x i think) [07:49:10] Frankly, I have no clue where that came from in the past. [07:49:30] --- ktdreyer has become available [07:53:32] --- Derrick Brashear has become available [07:58:25] ok [07:59:03] simon or i built it by hand. it's just a repo file [07:59:35] ah, ok. [08:03:08] I'll look into it. No big deal. [08:03:49] But again I'm wondering how much use it had. [08:04:52] it means you can yum update and have the right thing happen. [08:05:08] otherwise, you get to manually track new kernel module rpms [08:05:24] It also means that any update that gets dumped there ends up on your systems. [08:06:24] we had someone complaining about it :) but I assumed old webserver access logs or something could give stats on it [08:09:27] any update that gets dumped there is only for the current release of openafs, just a newer module. otherwise you upgrade the kernel and have no afs at all (or have to use dkms) [08:09:32] --- Derrick Brashear has left [08:11:18] I understand. But it requires a lot of trust to use such an external repo. I'm probably not the only one too paranoid to ever consider it. [08:17:17] i'm not sure i'm following. setting up a yum config just makes it helpful to install the rpms that are from openafs.org, no? [08:19:24] Right. And if for some reason a trojaned sshd update ends up there, all my systems are owned the next time they run yum update. [08:20:36] --- Derrick Brashear has become available [08:20:36] that is true for any repo you add to the search list on your system [08:20:45] it's not true anyway: [08:21:04] sshd is signed. the trojaned update if signed, sure, it will take it, but you already lost [08:21:12] otherwise, no [08:21:20] so, i'll stick with my theory [08:30:29] Have to leave now. Bye. [08:30:36] --- Stephan Wiesand has left [08:37:13] --- meffie has left [09:01:48] --- Marc Dionne has left [11:27:51] --- Derrick Brashear has left: Disconnected [12:18:29] --- Derrick Brashear has become available [13:32:10] --- Derrick Brashear has left: Disconnected [14:07:03] --- Derrick Brashear has become available [15:17:09] --- ktdreyer has left