[00:31:03] --- abo has become available
[01:44:48] --- haba has become available
[02:06:13] --- Jeffrey Altman has become available
[04:45:37] --- Jeffrey Altman has left
[05:24:18] --- Simon Wilkinson has left
[05:28:14] --- reuteras has left
[05:28:29] --- reuteras has become available
[05:52:18] --- reuteras has left
[05:58:58] --- Jeffrey Altman has become available
[06:11:30] --- abo has left
[06:18:08] --- abo has become available
[06:36:09] --- deason has become available
[07:01:28] --- mmeffie has become available
[08:02:12] --- Jeffrey Altman has left
[08:33:14] --- jaltman has become available
[10:20:23] --- haba has left
[11:20:16] --- mmeffie has left
[11:38:13] --- jaltman has left: Disconnected
[11:43:57] --- jaltman has become available
[11:55:05] --- sxw mobile has become available
[11:56:39] <sxw mobile> Did Tom get a chance to comment on those dafs patches that just went flying by?
[11:57:27] <shadow@gmail.com/owl8E1009BB> given where they came from i'm not very worried about that
[11:58:28] <shadow@gmail.com/owl8E1009BB> tho i see he asked for tom's comment. bleh
[11:58:51] <shadow@gmail.com/owl8E1009BB> neither is particularly exciting
[11:59:15] --- Russ has become available
[11:59:16] <stevenjenkins> sxw - have you gotten some RFC docs from Tom?
[11:59:26] <stevenjenkins> there were two that you should be receiving...
[12:02:19] <deason> tom mentioned 769 to me just now
[12:02:41] <deason> that one actually is "interesting" in that you can deadlock if you do it wrong
[12:04:32] <deason> (tom seems fine with it, btw)
[12:04:56] <shadow@gmail.com/owl8E1009BB> good.
[12:08:12] <sxw mobile> the only person I gave RPC docs from is Jeffrey.
[12:08:35] <sxw mobile> have, that is.
[12:12:05] <stevenjenkins> sxw - tx; I'll check on the status
[12:16:43] <deason> hmm, is the gerrit 'patch history' thing supposed to show the differences in the patches, or the differences in the files with the patches applied?
[12:17:00] --- dev-zero@jabber.org has become available
[12:17:16] <deason> I thought I remember it just showing the differences of what the patch itself does, but maybe I just never looked at the differences for an updated/rebased change before
[12:18:41] <jaltman> for a rebased change gerrit shows you all of the changes between the two revisions
[12:23:27] <deason> okay, I just remembered it wrong
[12:24:06] <sxw mobile> I think its supposed to just show you the difference between the two patches.
[12:24:44] <sxw mobile> so in a change that is just rebased, you should see no changes.
[12:25:00] <jaltman> that isn't what it does
[12:26:05] <sxw mobile> its definitely what it used to do. can you provide an example of the new behaviour?
[12:26:37] <jaltman> the most recent submission from Andrew
[12:26:57] <jaltman> its been this way for a very long time
[12:27:45] --- haba has become available
[12:31:22] <deason> yeah, change 716, patchset 4 and 5 are the same, except 5 is rebased
[12:31:37] <deason> the 'patch history' changes show the differences of the commits since then
[12:32:05] <sxw mobile> hmm. I'm not seeing this behaviour on my 2.16 gerrit instance. I'll dig deeper when I get a moment.
[12:37:14] --- sxw mobile has left
[12:38:40] --- sxw mobile has become available
[12:52:17] --- haba has left
[12:57:00] --- Simon Wilkinson has become available
[13:28:12] --- sxw mobile has left
[13:30:42] --- meffie has become available
[13:44:50] <andersk@mit.edu/dr-wily> I’d appreciate a Gerrit upgrade to 2.0.24, since I’ve been unable to
sign in since 2.0.19:
http://code.google.com/p/gerrit/issues/detail?id=38
[13:47:29] <Simon Wilkinson> I'm planning on doing 2.0.24 on Friday, providing r.s.a.c doesn't hit any major speed bumps before then.
[13:47:43] <shadow@gmail.com/owl8E1009BB> and you cleanred your cookies, right?
[13:48:24] <Simon Wilkinson> There are some suggestions that there might actually be database problems here, too.
[13:48:54] <shadow@gmail.com/owl8E1009BB> actually, looking at that, probably not it
[13:49:27] <Simon Wilkinson> andersk: What is your delegate identity, and your claimed identity?
[13:50:23] <andersk@mit.edu/dr-wily> I think I was trying to make it http://anders.kaseorg.com/ , but I
don’t actually remember what Gerrit ended up deciding.  In any event,
it’s different now than it was when I signed up.
[13:51:01] <andersk@mit.edu/dr-wily> My delegate identity was probably something at Launchpad at that
point, but I was switching it around pretty frequently to try to make
it work with different sites.
[13:52:15] --- haba has become available
[13:52:40] <Simon Wilkinson> So, which identity would you like to be able to access your account from?
[13:53:54] <andersk@mit.edu/dr-wily> Let’s go with https://login.launchpad.net/+id/TKJNYQ7 for now.  I
think that’s currently associated with one of several duplicate
“Anonymous Coward” accounts I created while trying to get it to work.
[13:57:48] <andersk@mit.edu/dr-wily> (I want http://anders.kaseorg.com/ to work eventually, but that
requires the bugfix in 2.0.24.)
[14:02:00] <Simon Wilkinson> Try that ...
[14:04:00] <andersk@mit.edu/dr-wily> Worked, thanks.
[14:04:25] <Simon Wilkinson> Cool. It'll probably break come 2.0.24.
[14:04:32] <Simon Wilkinson> If it does, let me know, and I'll fix it up again.
[14:52:42] --- dev-zero@jabber.org has left: Replaced by new connection
[14:52:42] --- dev-zero@jabber.org has become available
[15:13:26] --- deason has left
[15:13:46] --- deason has become available
[15:21:17] --- Simon Wilkinson has left
[15:22:36] --- meffie has left
[16:05:49] --- mdionne has become available
[16:16:02] <mdionne> there's a gerrit bug for that patch history weirdness: http://code.google.com/p/gerrit/issues/detail?id=217
[17:34:28] <Russ> What's the status of Gerrit 752 (the AppArmor fix to use the right credentials when accessing the cache)?   The Ubuntu folks seem to be happy with it, and I'm preparing new Debian packages and am wondering if I should include it.
[17:35:29] <shadow@gmail.com/owl8E1009BB> no one's verified it, which is why i didn't push. it looks like it's
correct
[17:36:07] <shadow@gmail.com/owl8E1009BB> if they say it works you probably should include it, and i should push
it
[17:36:11] <shadow@gmail.com/owl8E1009BB> or you should
[17:40:57] <Russ> I'm verifying a build on trunk right now and then will push it and queue the backport to 1.4 for review.
[17:41:14] <shadow@gmail.com/owl8E1009BB> ok
[17:43:30] <Russ> I love being able to do a parallel build.
[17:47:44] <andersk@mit.edu/dr-wily> I’ve tested it on 1.4; it works and fixes the problem.
[17:48:34] <shadow@gmail.com/owl8E1009BB> you have teh gerritz. mark it!
[17:48:48] <andersk@mit.edu/dr-wily> Oh, it’s already been merged I guess.
[17:52:12] <Russ> Yeah, I already got it.
[17:52:20] <Russ> I'm fixing the merge conflicts in the stable pull-up now.
[17:52:57] * Russ waits for 1.4 to build.
[17:54:33] <andersk@mit.edu/dr-wily> While you’re adding patches to Debian, 9b37972 (Linux: 2.6.32 - Adapt
to writeback changes) is needed to avoid oopses on kernel 2.6.32, if
you don’t have that already.
[17:59:00] <Russ> Yeah, got that one already.
[17:59:07] <Russ> Here's what I'm pulling plus the AppArmor one:
[17:59:16] <Russ>     - [7833e472] Make afsd.pod reflect reality
    - [c9974c7a] Avoid prematurely destroying callback_rxcon
    - [9b37972e] Linux: 2.6.32 - Adapt to writeback changes
    - [abdf72bc] Linux: Avoid deadlock in readdir - release GLOCK for
      filldir
    - [bdb4f98a] Protect rx_call iovq from simultaneous attempts to empty
      it
    - [c08609ae] Avoid using released hosts

[18:00:05] <shadow@gmail.com/owl8E1009BB> lemme see if there's anything else
[18:00:45] <Russ> I should probably go name deltas so that I can use nice names instead of Git identifiers, but OMG the tedium.
[18:00:52] <shadow@gmail.com/owl8E1009BB> yeah. sigh
[18:01:11] <Russ> I named 30 or so the last time I did a Debian package and just didn't feel up to it this time.
[18:01:45] <shadow@gmail.com/owl8E1009BB> if you're taking c08609ae you probvably want cbe580fe
[18:02:46] <Russ> Ah, yes.  That one looked good but wasn't pulled up yet.  I suspect I should also pull it up to stable.
[18:03:16] <Russ> We're getting crashes every couple of days that we think [c9974c7a] Avoid prematurely destroying callback_rxcon will fix, but if I'm updating, I may as well get the complete fix, I think.
[18:03:32] <Russ> Since IIRC from the discussion, this is all somewhat related.
[18:06:19] <shadow@gmail.com/owl8E1009BB> 6f2ce4cd also. we should avoid potentially hanging a machine with
orphaned locks
[18:08:28] <Russ> Hm, my pull-up to 1.4 doesn't compile.
[18:09:01] <Russ> In file included from /home/eagle/dvl/openafs/include/afs/afs_sysnames.h:25,
                 from /home/eagle/dvl/openafs/include/afs/param.h:58,
                 from /home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP/afs_atomlist.c:11:
/home/eagle/dvl/openafs/include/afs/stds.h:14:23: error: sys/types.h: No such file or directory

[18:09:06] <Russ> That doesn't seem to be related to the AppArmor change.
[18:09:13] <Russ> Now I wonder if 1.4 compiles at all at the moment.
[18:09:35] <Russ> Or maybe I didn't do enough make cleans.
[18:09:39] <Russ> We'll see in just a second.
[18:09:44] <shadow@gmail.com/owl8E1009BB> i doubt it's your fault
[18:12:10] <Russ> Yeah, 1.4 doesn't build.
[18:12:22] <Russ> Looks like one of the pullups introduced a sys/types.h include.
[18:12:27] <shadow@gmail.com/owl8E1009BB> no
[18:12:36] <shadow@gmail.com/owl8E1009BB> something got rid of IGNORE_STDS
[18:12:47] <shadow@gmail.com/owl8E1009BB> sys/types.h is from ibm
[18:12:52] <Russ> Ah, okay.
[18:13:10] <shadow@gmail.com/owl8E1009BB> IGNORE_STDS_H in afs_sysnames.h is supposed to protect you
[18:16:39] <Russ> Hm, I'm not seeing any obvious candidates for having broken that.
[18:17:06] <shadow@gmail.com/owl8E1009BB> nor i. so the current stable-1_4_x fails?
[18:17:23] <shadow@gmail.com/owl8E1009BB> i wonder what's *actually* on my machine
[18:19:01] <Russ> Well, what I tried to build does.
[18:19:12] <Russ> I should do a complete clean of the tree and start again -- I thought I did, but maybe I didn't.
[18:19:41] <mdionne> no problem compiling 1.4 here
[18:20:09] <Russ> Okay, it's something wrong with my working directory, I think.
[18:20:14] <Russ> Starting over after a git clean -x -f
[18:23:56] <Russ> Nope.  Still fails for me.
[18:24:30] <Russ> Building in directory: MODLOAD-2.6.30-2-686-bigmem-MP
make[4]: Entering directory `/home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP'
Makefile.common:50: warning: overriding commands for target `.c.o'
/home/eagle/dvl/openafs/src/config/Makefile.config:137: warning: ignoring old commands for target `.c.o'
env EXTRA_CFLAGS="" /home/eagle/dvl/openafs/src/libafs/make_kbuild_makefile.pl MODLOAD-2.6.30-2-686-bigmem-MP libafs.ko /home/eagle/dvl/openafs/src/config/Makefile.config Makefile.afs Makefile.common
env EXTRA_CFLAGS="" make -C /usr/src/linux-headers-2.6.30-2-686-bigmem M=/home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP modules
make[5]: Entering directory `/usr/src/linux-headers-2.6.30-2-686-bigmem'
  CC [M]  /home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP/afs_atomlist.o
In file included from /home/eagle/dvl/openafs/include/afs/afs_sysnames.h:25,
                 from /home/eagle/dvl/openafs/include/afs/param.h:58,
                 from /home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP/afs_atomlist.c:11:
/home/eagle/dvl/openafs/include/afs/stds.h:14:23: error: sys/types.h: No such file or directory

[18:25:05] <shadow@gmail.com/owl8E1009BB> and that's 1_4_x without patches?
[18:25:14] <Russ> Yup, just updated from Git.
[18:25:47] <Russ> This is Debian, so it has the split kernel header structure and creates the separate redirection headers in the build tree, although I don't see a sign of that being the problem.
[18:26:36] <andersk@mit.edu/dr-wily> Works for me with Ubuntu’s 2.6.31-14-generic on amd64.
[18:26:53] <Russ> What's supposed to define IGNORE_STD_H?
[18:27:22] <shadow@gmail.com/owl8E1009BB> wait, does 2.6.31-whatever have sys/types.h?
[18:27:30] <andersk@mit.edu/dr-wily> No.
[18:28:19] <Russ> It looks like param.h is supposed to, but mine doesn't.
[18:28:35] <shadow@gmail.com/owl8E1009BB> diffing against 1.4.11
[18:28:41] <Russ> Ah, no, I'm misreading.
[18:29:51] <Russ> src/lwp/Makefile.in is the only thing that's defining IGNORE_STDS_H so far as I can see, other than a few individual source files.
[18:30:06] <shadow@gmail.com/owl8E1009BB> some param files also do. not linux
[18:30:49] <Russ> The param files seem to be testing, not defining.
[18:31:52] <Russ> Ah, hm.  The Linux code to deal with Debian's header structure is not working.
[18:32:00] <Russ> h and whatnot are symlinks rather than directories.
[18:32:30] <shadow@gmail.com/owl8E1009BB> you break it you bought it
[18:33:09] <Russ> Er, because I have an outdated make_kbuild_makefile.pl.
[18:33:12] <Russ> Hm.  What happened there?
[18:33:31] <Russ> Did I never pull up that patch?
[18:33:43] <shadow@gmail.com/owl8E1009BB> uh. it didn't change since 1.4.11
[18:34:04] <Russ> Gah, well, that's the problem.
[18:34:07] <Russ> I never pulled up that patch.
[18:34:15] * Russ will do that after dinner.
[18:35:29] <mdionne> Russ: I had the 1.4 version of the AppArmor fix ready to push - should I just let you test and push it?
[18:37:33] <shadow@gmail.com/owl8E1009BB> i guess he went to get dinner
[18:38:18] <mdionne> yup - I guess I'll hold off for now
[19:01:47] <Russ> mdionne: Sure, feel free to submit it.  I have to get this Debian fix in so that I can test.
[19:06:53] <mdionne> Ok, pushed to 1_4_x
[19:09:02] <deason> > if you're taking c08609ae you probvably want cbe580fe
if cbe580fe is the HOSTDELETED thing, it needs some changes to work with 1.4
[19:09:19] <deason> I'll push shortly; I was verifying and went to go do something else
[19:10:24] <Russ> deason: Oh, cool, thanks.
[19:10:28] <shadow@gmail.com/owl8E1009BB> good point
[19:11:50] <deason> also, I appear to have removed an IGNORE_STDS_H in db949b7fade69d7eb1e38ad85d5b822c443306cb, but that's in gtx...
[19:15:33] <Russ> Well, now I have a new build failure.
[19:15:36] <Russ> /home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP/osi_module.c: In function ‘afsproc_init’:
/home/eagle/dvl/openafs/src/libafs/MODLOAD-2.6.30-2-686-bigmem-MP/osi_module.c:268: error: implicit declaration of function ‘create_proc_info_entry’

[19:21:07] <Russ> Ah, right, because I need this other change too.  Yes, yes.
[19:21:14] <Russ> This is all coming back to me now.
[19:22:35] <Russ> I really should have pulled that stuff up a long time ago.
[19:31:09] <Russ> Wow, there are a lot of warnings in stable now compared to unstable.
[19:31:19] <Russ> Okay, there, I have a working 1.4 build.
[19:33:39] <deason> HOSTDELETED thing for 1.4 in gerrit 776; differs nontrivially from the 1.5 one, though
[19:33:53] <deason> (i.e. I wouldn't use that until someone's looked at it)
[19:34:15] <deason> I don't really get h_GetHost_r under the old hold mechanism; it doesn't tell you if the host was already held
[19:35:06] <deason> previously that wasn't a problem since it just always went into the client struct unconditionally... but how do you know whether to release the host in the client?
[19:35:16] --- mdionne has left
[19:35:33] <deason> there's some assumptions there, like you can always release it in the postamble, since there's no way that thread still has a hold on it
[19:35:52] <Russ> Oh, that's why I didn't pull up those changes -- I submitted them before we had a stable branch managed in Gerrit.
[19:36:01] <deason> if that's the case, it doesn't seem to be stated, which is annoying
[19:36:12] <deason> (talking to myself there, not Russ, heh)
[19:36:56] <Russ> I wonder if I should drop c08609ae for right now since I need to build new packages tomorrow for an emergency update, and just take c9974c7a for the time being.
[19:37:15] <shadow@gmail.com/owl8E1009BB> yeah
[19:38:26] <Russ> I think everything else is safe.  I'll add the other one Derrick mentioned.
[19:38:44] <deason> c08609ae should be unrelated t othe hostdeleted thing, and I thought was pretty straightforward....
[19:39:18] <deason> I thought it was quite possibly what you're hitting; it fixes two possible instances of using freed memory
[19:39:30] <Russ> Oh, hm, do I have those two reversed?
[19:39:41] --- abo has left
[19:39:47] <deason> speaking in SHA1s can get confusing
[19:39:53] <Russ> Yeah.
[19:40:01] <deason> c9974c7a is just a NULL dereference; you're not going to get a malloc segfault from that
[19:40:18] --- abo has become available
[19:40:49] <Russ> Ah, this notice is different than the bug report we filed.  That's what confused me.
[19:41:00] <deason> if you mean dropping cbe580f, yeah, I can see that
[19:41:54] <Russ> Hm, no, http://openafs.sinenomine.net/patch/viced-null-callback-rxcon is c9974c7a is, supposedly, the bug that we're trying to fix.
[19:43:08] <deason> well, that's one of them
[19:43:26] <deason> I thought you also had a segfault in malloc, or something suggesting similar heap corruption
[19:44:00] <Russ> Oh, yeah, we did, but I think that was before the update to the previous package, which had some other fixes.  But that may not have really fixed it.
[19:44:14] <Russ> Derrick, when you said " if you're taking c08609ae you probvably want cbe580fe ", is that because of some dependency or just because they're related?
[19:44:26] <Russ> Since the stable backport of cbe580fe isn't fully baked.
[20:52:53] <Russ> 6f2ce4cd hasn't been backported to stable and doesn't backport cleanly.
[20:52:57] * Russ bails on it as well.
[20:53:03] <Russ> That's the writepage fix.
[21:38:26] --- deason has left
[22:01:45] --- jaltman has left: Disconnected
[22:08:10] --- reuteras has become available
[22:14:49] --- Jeffrey Altman has become available
[22:37:08] --- reuteras has left
[23:40:45] --- Simon Wilkinson has become available
[23:48:33] --- reuteras has become available
[23:58:21] <Simon Wilkinson> When submitting stuff to 1.4.x that has a corresponding commit on master, can people please reference the master SHA1 in the branch patch.
[23:58:37] <Simon Wilkinson> Otherwise all of our automated tools will fail to relate the two commits.