[00:09:47] --- dev-zero@jabber.org has become available [00:12:34] --- manfred furuholmen has become available [00:15:55] --- Simon Wilkinson has become available [00:39:09] --- dev-zero@jabber.org has left [01:45:44] --- dev-zero@jabber.org has become available [02:18:21] gerrit's now back. 2.0.17 with the Reviewed-On issue fixed [05:02:24] --- cclausen has become available [05:26:07] --- Claudio Bisegni has become available [05:33:57] --- Jeffrey Altman has left: Replaced by new connection [05:35:01] simon: check 207? works for me, but... [05:37:12] I have no 10.4 handy, but I can check on 10.5 if that's of use? [05:37:59] that's fine. [05:38:18] i'm just assuming you dont' have the exact xcode i do installed, so any additional coverage is good [05:39:07] Okay. I'll grab it. [05:54:10] --- Claudio Bisegni has left [05:54:47] --- manfred furuholmen has left [06:36:39] --- manfred furuholmen has become available [07:06:26] --- matt has become available [07:15:44] --- deason has become available [07:16:51] --- Russ has become available [07:41:34] --- mmeffie has become available [07:44:37] --- sxw has become available [07:44:44] --- Jeffrey Altman has become available [07:45:33] Hmm. I guess ktc_curpag didn't make an appearance in all the libraries it should have. [07:45:44] Anyone for 1.4.11.1 ? [07:46:03] What relevant change made it into 1.4? [07:46:17] Well, it it's broken pam_afs.so [07:46:48] yes, and? I mean, how did it break since 1.4.10? [07:46:56] Ah, was that bug in 1.4.10, too? [07:47:07] I though ktc_curpag only appeared post 1.4.10 [07:47:47] No; he claims it worked in 1.4.10, but broke in 1.4.11. So, remind me why pam_afs changed in 1.4.11 in such a way that this broke. As opposed to not changing, because it's 1.4 [07:49:09] I doubt pam_afs changed. ktc_curpag appeared to fix an AIX bug. [07:51:10] ah [07:51:42] I suspect it isn't an an export list somewhere. [07:51:53] And of course, nobody who tests is still using kaserver. [07:52:00] Wouldn't it be nice if people actually ran our release candidates? [07:52:16] I'm not sure that matters. [07:52:32] It would be, yes. [07:53:55] Hmm. Russ says its fixed, but I don't think the commit ID he's posted is right. At least, gitweb can't find it. [07:54:29] The problem with ktc_getpag is that Derrick accidentally added it only in the AFS_KERBEROS_ENV #ifdef. [07:54:37] I fixed that when I merged Debian's PAM patch. [07:54:45] --- abo has left [07:55:06] * Russ has a cherry-pick with conflict and is now trying to figure out how to preserve the magic cherry pick comment. [07:55:27] --- abo has become available [07:55:29] Do you care about the author date? [07:56:09] we can fix the lock implementation for clients that have uuids. we can't fix it for clients that do not. fixing the implementation has been on my list for years. [07:56:12] --- stevenjenkins has left [07:57:18] No, not particularly. [07:57:43] git commit --author [07:58:18] The thing that I did seems to have worked. (git commit -c and then pasted in the cherry-pick comment.) [07:58:36] That'll work too. [07:58:44] I suspect that pasting in the cherry-pick comment is not entirely kosher, but hopefully I didn't mess up the syntax. [07:58:59] Yeah. The point is, the current behavior sucks, and it sucks largely because the client obtaining a lock is not given a cookie that must be used to release or extend it. I don't want to see the same design flaw in rxosd [07:59:30] For our tools. all you ned to do is match /picked from commit [0-9a-f]{40)/ [07:59:32] * Russ is building now to check. [08:00:38] agreed. [08:01:13] let me try to explain it on list to hartmut and felix. they don't understand how the wire protocol lock interface is broken. [08:01:30] They dont? [08:01:53] apparently not given the e-mails that are going back and forth [08:02:11] I think Hartmut agrees--I think the issue is reopening interfaces. [08:02:28] But it's needed. [08:02:38] And the reason why we didn't notice the pam_afs problem was because the src/pam makefile ignores all build failures. Or did, until I fixed that in the cleanup on master. [08:02:40] --- stevenjenkins has become available [08:02:56] --- deason has left [08:02:59] --- abo has left [08:03:43] --- abo has become available [08:04:41] Yup, that fixed it. [08:04:56] Now reviewable in Gerrit as 208. [08:06:12] --- deason has become available [08:08:37] --- reuteras has left [08:09:03] Go ahead, Jeff; I don't seem to be getting anywhere. [08:10:01] i assumed the mapfile just needed ktc_curpag in it, and "we" didn't notice because only linux and solaris use the mapfile? [08:11:30] ktc_curpag *did* only appear in 1.4.11 [08:12:15] --- manfred furuholmen has left [08:12:24] The mapfile is actually irrelevant. [08:12:47] the problem was that you (correctly) added ktc_curpag to pam_afs (not pam_afs.krb) instead of its existing logic. [08:12:54] But the implementation was behind AFS_KERBEROS_ENV. [08:13:06] So it wasn't in the version of the library with which pam_afs.so was linked. [08:13:17] The stable pam modules are all linked static. [08:13:46] Although I suppose the mapfile may be relevant if the RPM build process switches to linking them dynamic. [08:14:12] --- manfred furuholmen has become available [08:26:01] Did we eliminate the various "(MR-AFS)" in help messages for commands and options that have nothing to do with MR-AFS, like "bos salvage -nowrite" ? [08:26:16] oh, we link the pic version now [08:26:19] --- sxw has left [08:33:46] right, that went in post-Gerrit as part of the reconciliation with the Debian packages, now that we have PIC libraries. [08:38:04] --- sxw has become available [08:41:04] 207 is fine, but there's a lot of warnings coming out of the preference panel code. [08:46:17] --- mmeffie has left [08:52:24] --- sxw has left [09:53:22] --- manfred furuholmen has left [10:30:07] --- Russ has left: Disconnected [10:56:09] --- Russ has become available [11:08:15] --- dev-zero@jabber.org has left [11:42:31] --- asedeno has left [11:44:59] --- asedeno has become available [11:45:04] --- asedeno has left [11:47:18] --- asedeno has become available [11:55:56] afs_inet_ntoa_r belongs in libafsrpc, i suspect. [12:02:47] And eventually should be replaced with an inet_ntop replacement. [12:03:03] (inet_ntop handles IPv6 and is thread-safe.) [12:03:42] Sadly, I don't think inet_ntoa_r is our biggest barrier to IPv6 [12:04:16] Yeah, it's just a dead interface that we should migrate away from someday. :) [12:10:32] --- dev-zero@jabber.org has become available [12:47:50] derrick: I don't think I understand what you're proposing in 158 [12:48:17] GetNewVolumeId can only return a range of adjacent ids [12:49:55] --- deason has left [12:50:01] --- deason has become available [13:10:39] Do people think the BosConfig file format is still subject to change? [13:11:07] In what way? It's an internal implementation detail, isn't it? [13:11:08] We currently say: Although the F file is in ASCII format, do not use a text editor to alter it. Its format is subject to change and incorrectly formatted entries can prevent server startup in ways that are difficult to diagnose. [13:11:15] In BosConfig(5). [13:11:19] That strikes me as a bit aggressive. [13:11:46] Well, given we just taught our configuration management system to talk bos in order to modify the file, I think its fair :) [13:12:15] Well, it makes BosConfig.new somewhat pointless if one isn't allowed to manually touch the file. [13:12:32] Although I suppose you could have assembled the file by giving bos commands to some other bosserver. [13:12:36] Well, it's right, but for the wrong reasons. It is a text file, with syntax that hasn't changed in almost 20 years and is not likely to ever change again. But some of that syntax is a little more demanding than it looks. Also, if you change the BosConfig file while the bosserver is running, it will stomp all over your changes when it shuts down. [13:12:50] How about: [13:12:53] Although the F file is in ASCII format, it is normally best to not use a text editor to alter it. Its format may change, and incorrectly formatted entries can prevent server startup in ways that are difficult to diagnose. [13:12:55] Oh, Simon, you didn't need to do that. [13:12:57] Just tones it down a bit. [13:13:11] I could remove the format may change part too. [13:14:03] You could replace the format may change part with a warning about the parser being picky. Also, you could add a warning about the bosserver stepping on it, and a reference to BosConfig.new, if those aren't already there. [13:14:25] Yeah, I'm working on documenting BosConfig.new, which is why I'm in here. [13:50:01] Matt: You just pushed two different things to change 183? [13:55:00] 1. was in eror [13:55:01] error [13:55:18] 2. need to repush anyway, please ignore (sorry) [13:56:02] That's OK. Just wanted to check you'd realised. The refs/changes/ interface makes it horribly easy to mistype and send patches who knows where. [13:56:16] Yup, that's what did it. [13:56:32] I noticed the change had gone whacko, tho. [14:30:36] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537098#25 seems to indicate that the problem with chroot into AFS is our old friend, multiple mount points for the same volume confusing the AFS kernel module. [14:32:08] I could try having him upgrade to 1.4.10 from backports.org to see if that helps. [14:54:58] So if I'm to submit one change to gerrit introducing x, and another changeset adapting x, do I need to wait until x is merged to submit the next part? [14:55:31] Nope. [14:55:59] But if x has to be changed as a result of reviewer comments, then you will have to rebase, and resubmit x' [14:58:34] So what would the method for submitting that second changeset look like? [14:58:39] if we want something in 1.4 that already got merged in master, should we submit a new cherry-picked change against the 1.4 branch? [14:58:52] Yes, please. [14:58:52] matt: you can submit a branch with two commits on it [14:59:26] err, that is, push the head of a branch that has two commits deviating from 'master' [15:00:48] If I've pushed head, then make the next commit, I would push the sha1 of the first commit after master? [15:01:04] No. [15:01:10] Well, yes, that would work, but no. [15:01:45] What gerrit does when you do a push is that it pushes all of the changes that are reachable from the ref you give it, but not reachable from the ref you are pushing to. [15:01:50] s/gerrit/git/ in the above. [15:03:34] So that means, if the changeset x is pushed, adjust and commit again, and then just push that sha1? [15:03:48] Yes. [15:04:00] Ok. [15:04:35] It gets more complicated when you're pushing multiple change sets in a series. See the example in the Gerrit documentation. [15:10:39] --- dev-zero@jabber.org has left [15:10:55] --- cclausen has left [15:15:04] --- deason has left [15:41:58] --- deason has become available [16:18:30] --- cclausen has become available [16:38:19] --- Russ has left: Disconnected [16:59:37] --- Russ has become available [17:03:40] --- matt has left [22:29:15] --- deason has left