[06:13:08] --- meffie has become available [06:41:13] --- stephan.wiesand has become available [06:57:51] test... [06:58:24] pass [06:58:41] Thanks. Hello Mike. [06:59:22] Today, I found an AC socket to park the car next to :) [07:00:43] anonymous coward socket? [07:01:04] --- deason has become available [07:01:17] you don't have AC in your car? [07:01:26] no... [07:01:31] must get hot during the summer [07:02:09] see http://www-zeuthen.desy.de/~wiesand/sdf.jpg for my current setup [07:02:41] nice view [07:02:52] can you send a photo without the laptop in the way? [07:03:22] The laptop is actually covering the not-so-nice part of the view... [07:03:30] :) [07:03:42] It's a harbour - I'm waiting for boarding the ship. [07:04:16] But I can send about 600 really good photos with such views I've taken in the past two weeks. [07:04:56] Let's start? [07:05:37] There wasn't much feedback on how to handle the 1.6.5.x branch. [07:05:54] So I guess pulling up from 1.6.x is ok. [07:05:55] pullups from 1.6 so nothing is forgotten on 1.6 [07:06:07] Ok. [07:07:10] Regarding what to include, I'm inclined to add the two linux changes from derrick, the suse linux change from Christof, and the AIX change from Andrew. [07:08:10] Any objections? [07:08:11] that is fine with me [07:08:23] do it [07:08:41] okay, I guess [07:09:03] ok [07:09:19] Ok. So once we got everything merged on 1.6.x, I'll pull those up. [07:09:31] Which brings us to the open changes for 1.6.x. [07:10:54] 10167: Andrew feels this should get a +1 from Derrick. Any chance we'll get that? [07:11:10] Is it just too complex to review anytime soon? [07:12:13] conceptually/architecturally it's not complex [07:12:18] done. ithought i had. [07:12:26] Thanks. [07:12:56] 10174 carries a similar remark, but does have a +1 from Derrick. Who should I beg to review this one? [07:14:25] well... ah, mike probably can :) [07:14:44] 10253 is something I thought may make sense. Or is it borderline feature or something that shouldn't change in stable? [07:15:01] 10253 seems fine [07:15:16] sufficiently trivial [07:15:38] arg, mike, did you _actually_ review that? [07:16:06] It' a behaviour change though. (10253) [07:16:24] yeah, i have. [07:16:37] yes, it changes the behavior from broken to not broken [07:17:19] Grin. Ok, let's take it. [07:18:01] Any news on 10229 or the related RT entry? [07:18:38] I think Stephan's point is that it can result in afsd failing on systems after the update where it would have continued in a partially broken state before hand. [07:19:48] can afsd fix the mount point so that it is the equivalent absolute path instead of failing? [07:20:37] that's added complexity. [07:20:39] I'd consider that worse to include in the stable series than 10253 though. [07:20:45] not being familiar with how the unix cache manager is setup, what creates the mount entry? [07:20:59] the admin or the packaging [07:21:01] that can still 'break' by mounting in a different location, can't it? [07:21:26] the thing is, this can only happen in rare situations where an admin has been dumb. [07:21:32] you mean the actual dir, or the thing that specifies where to mount? [07:22:02] I would expect very close to 100% of the time, it's either handled by packaging, or someone copy/pasting an existing cacheinfo file [07:22:18] (where it's mounted is either the cacheinfo file, or an arg to afsd) [07:23:29] based upon Derrick's comment the specification of the path (absolute or relative) is a human choice. all of OpenAFS's packaging will always use an absolute path and only someone configuring by hand and doing it wrong will shoot themselves in the foot. Is that a correct assessment? [07:24:39] Let's take it as it is. If someone comes up with an even better solution on master later, fine. [07:25:08] 10225 is another one I thought makes sense for 1.6.6 [07:25:28] I believe so; the mount point is not a question you are asked during install if that's the question [07:25:43] so for packaged installs, you can only change it by deliberately going out of your way [07:26:01] 10225 is fine [07:26:19] which raises the question of how did Christof end up with an installation that used a relative path. [07:26:26] if you don't want to get hurt, don't hurt yourself. [07:27:13] he probably wasn't using packaging and added the file manually [07:27:32] or eidted it manually [07:27:41] 10229 isn't the solution for that chaskiel rt ticket; the change for that is 10244 [07:28:48] Understood. And the questionmark behind 10229 remains, right? Should it be abandoned or marked -2 for the time being? [07:29:27] it just needs another fix to make it so it doesn't make any existing situations worse [07:30:03] o we just wait for that. Fine. [07:30:38] 10272 was just agreed to go into 1.6.5.1, but needs review. Anyone? [07:30:44] (which I don't think we should block for) [07:31:17] for 10272, I was hoping someone would double-check me that it's impossible that that impacts any other platform [07:31:18] Ok, won't block on add-on to 10229. [07:31:34] 10272 reviewed. [07:31:42] I have builds running with it on EL5/6. [07:31:58] Simon is the best person to review 10272. [07:32:03] i checked the commit 10272 was pulled up from. the only place it could have possibly had an impact was otherwise covered. we're good [07:32:08] However I believe it is safe [07:32:24] Thanks. [07:32:29] since there are only 4 platforms that even define rxk_init under any circumstances, and the 3 besides aix should always have rxk_listener defined [07:33:01] I believe the last two are the vldb_check changes from Mike. [07:33:19] 10268/9 [07:34:01] it's vldb_check. they're fine, but, sufficiently noncritical that any time you wanna take anything there my opinion is "go crazy" [07:34:32] Thanks. [07:35:44] I believe we're good to merge everything open for 1.6.x which isn't marked -2, except for 10229. [07:37:06] I should get this and the 1.6.5.x pullups done on the ship. (And the outstanding minutes). [07:37:52] The satellite link there has a terrible latency though. Andrew, I may ask for your help again.. may I? [07:39:24] Problems with 10174? [07:40:14] sure, should I just go ahead and put them all in a line, or am I waiting to be asked for something specific? [07:40:32] Please let me try first ;-) [07:41:45] there are also still a couple of things not on the 1.6.x branch [07:41:59] the change I mentioned earlier for chaskiel's nbsd com_err.h bug [07:42:11] and 10273, if we want to include that (which I just saw was merged) [07:42:39] I think the com_err.h we agreed not to block on. [07:43:08] okay, but it may show up there soon [07:43:18] If it does, fine. [07:43:32] The same for 10273. [07:45:21] It starts raining. I'll soon have to remove the power cable. [07:46:02] Anything else to discuss today? [07:46:18] nothing from me [07:46:43] I'm good [07:47:18] Thanks a lot everyone. [07:48:02] thank you [07:48:29] I'll go offline and move into the waiting line. Chances are I'll be available for an hour or two afterwards. [08:38:32] Since you're still here, what's going on with 10174? [08:40:02] mike was going to re-review, apparently [08:40:35] Apparently. Just wondering why. [08:42:31] just double checking, again. [08:43:00] Fine, thanks. I just merged it, after your nod. [08:43:12] thanks. [08:44:37] The last question mark is behind 10269 now. The rest just waits for buildbot. [08:47:27] 10269 is not too important, just a "nice to have". [08:57:24] --- stephan.wiesand has left [08:57:32] i'd rather see a version of 10237, since that fixes build problems [08:59:21] --- meffie has left [09:26:09] --- stephan.wiesand has become available [09:44:23] --- stephan.wiesand has left [10:06:42] 10244 is verified and approvied (it just needed to be rebased); if someone can merge it, I can submit to 1.6 [10:26:05] 10244 merged [11:16:46] thanks [11:20:12] --- deason has left [11:20:13] --- deason has become available [11:35:13] --- stephan.wiesand has become available [12:22:01] --- stephan.wiesand has left [15:39:01] --- deason has left [18:50:48] --- Jeffrey Altman has left: Disconnected [18:56:28] --- Jeffrey Altman has become available [18:57:12] --- Jeffrey Altman has left: Disconnected [19:00:11] --- Jeffrey Altman has become available [19:35:12] --- Jeffrey Altman has left: Disconnected [19:43:34] --- Jeffrey Altman has become available