[00:36:36] --- haba has left [00:54:38] --- Russ has left: Disconnected [01:31:27] --- jaltman has left: Disconnected [01:32:58] --- jaltman has become available [01:57:40] --- haba has become available [04:11:09] --- haba has left: Lost connection [04:11:09] --- abo has left: Lost connection [04:11:09] --- mho has left: Lost connection [04:11:09] --- reuteras has left: Lost connection [04:42:16] --- reuteras has become available [04:48:06] --- abo has become available [04:50:01] --- haba has become available [06:52:36] --- meffie has become available [06:59:48] --- mho has become available [07:16:55] --- reuteras has left [07:21:29] --- deason has become available [07:50:11] Interesting. The next release of gerrit will support hooks. [07:50:25] Which suddenly makes things like RT notification a lot, lot, easier. [07:51:00] yes. yes it did. [07:51:01] (It makes trivial buildbot integration easy too, but sadly the hooks don't get told enough to do the more complex access control stuff that we'd like) [07:51:21] mix? [07:51:45] er, /did/will/ [07:52:20] Do you have the neccesary powers to create an email address that can comment on any bug in the openafs-bugs queue? [07:52:32] i have all the powers, apparently [07:53:10] Excellent. [07:53:23] while i shouldn't use them, i realistically have all the powers: i can become root on the machine it's running on [07:53:46] :) [08:04:20] I certainly do. [08:04:56] i created gerrit an account already [08:05:10] it is a worker. its password is not set to anything people are expeted to use [08:06:22] My rough plan, which I will post to openafs-devel too before putting into action is to send an email into RT whenever [08:06:38] a) a patchset is created in gerrit that has a 'FIXES' reference in it [08:06:49] b) a change is merged into git that has a 'FIXES' reference in it [08:06:53] So, in the current setup, you can only have "comment", which is not public, or "correspond", which actually gets sent in email to the requestor et al. [08:07:21] ... and I think those probably want to be 'correspond' - I'd like the requestor to be pointed at the change in gerrit, for example. [08:08:37] Yeah, that makes sense. I wasn't sure if you wanted something in between, where it's publicly visible but doesn't result in RT sending email. [08:09:41] I think for now, I'm happy with burying people under email. I'd really like to push requestors at gerrit, too. [08:17:08] --- jaltman has left: Disconnected [08:19:41] truthfully, i don't see why providing to RT what we should nominally provide already is particularly controversial. if there is a mean to do it, we should. [08:19:58] it does mean we need to push people to include FIXES [08:20:56] I generally do that when I'm reviewing. [08:21:18] better to ask in advance [08:22:25] I think it is in the gerrit document [08:27:04] --- RedBear has become available [08:55:30] --- haba has left [09:36:52] --- meffie has left [09:38:23] --- jaltman has become available [10:01:44] --- Kevin Sumner has become available [10:06:52] --- Simon Wilkinson has left [10:11:10] --- Simon Wilkinson has become available [10:43:10] --- kaj has become available [10:57:59] Is OpenAFS going to apply for Summer of Code again this year? [11:03:37] we will again apply for GSoC [11:11:31] Applications are due in early March [11:14:21] 8-12th I think LH said, [11:17:19] Is there any place to find out how the AFS binaries posted to openafs.org are compiled at the moment (configure flags and the like)? [11:18:11] Yes. [11:18:28] Here is probably as good a place as any :) [11:18:33] Which platform do you care about? [11:19:07] Particularly Linux and Solaris clients, AIX servers. Right now, are jumbograms enabled by default? [11:19:26] that's not really a configure flag or compile option [11:19:33] they aren't. it's a run time switch, tho [11:19:39] they are disabled by default as of.... 1.4.11, I think? [11:19:44] Excellent. [11:20:12] --- Russ has become available [11:20:40] In general, the OpenAFS builds are built with the 'standard' configure options - that is, what you get if you just do ./configure [11:21:13] --enable-transarc-paths for aix and solaris [11:21:18] but otherwise yes [11:21:18] linux clients depends on the distribution, though, of course [11:21:38] Debian enables a bunch of stuff. [11:21:41] but that's not openafs.org, so whatever [11:21:52] well, _some_ of it isn't [11:22:03] Ok, that's good to know. My organization is trying to decide it it is worth compiling and providing our own AFS binaries (particularly for Linux) or just using the ones on openafs.org, and this has come up before. [11:22:13] --- abo has left [11:22:27] --- abo has become available [11:22:35] We're using RHEL5, btw. [11:22:43] By the looks of things, jumbograms were disabled from 1.4.8 onwards. [11:22:59] yeah, my sense of time on that is ompletely off [11:23:17] Thanks Simon. Any opinions of using AFS binaries vs. in-house compilations? [11:23:39] Well, I build the Fedora/RHEL binaries, so I'm biased :) [11:23:46] :) [11:24:01] I like your binaries, and I'm advocating for using them. [11:24:23] Using our binaries makes a lot of sense, unless you need things we don't enable. [11:24:49] But, if you end up having problems, and you can say "I'm using the binaries from OpenAFS.org", it makes it a lot easier for us to troubleshoot. [11:25:02] Simon - binaries that fix the compile_et conflict coming soon? [11:25:29] 1.4.12 will fix it. [11:25:52] he wants a prerelease, which i suppose i could give him [11:26:17] 1.4.12rc1 isn't a good release to run, IIRC. [11:26:39] i agree, but give the people what they want [11:26:44] well... depending on the timeline for 1.4.12... maybe a 1.4.11-2... since this issue has existed for a good 6 mos [11:26:57] then another week isn't going to matter, is it. [11:26:57] if 1.4.12rc1 is known bad, then, I'm not gonna try it out :) [11:27:17] like, everyone would like to volunteer someone else to do lots of work. good luck with that. [11:28:02] 1.4.12rc1 should probably not be used without additional patches. I need to prepare Debian packages that include those additional packages, since I need to get a fixed aklog into MIT. [11:28:34] You pretty much want everything that's in 1.4 git after the 1.4.12rc1 tag, I think. [11:28:44] Yup. [11:29:09] 26ffbd3f1c07420796c772e821786cfa4bcc0bc5 is the important one. [11:30:46] I have now redone the Debian packaging using a technique of Sam Hartman's that adds real merge commits to the upstream branch, so in theory I can just merge all changes from the 1.4.12rc1 tag. [11:31:17] --- haba has become available [11:31:46] That sounds very nifty... [11:32:29] My problem is that I have tools that easily build RPMs from an upstream release. Anything else requires manual intervention, and therefore keeps being pushed to the back of the stack. [11:32:37] yeah, it imports the tarball release and commits it as a merge commit referencing the upstream tag. [11:37:04] IIRC, Red Hat doesn't have as strong of tools for having your package source in a VCS and automatically generating a diff to apply during build based on the changes in your VCS relative to the upstream tarball. [11:43:01] They don't have any tools, sadly. [11:58:13] Did the issues with the AFS cache on ext3 get resolved? [11:58:56] Or, rather, is housing the AFS cache on an ext3 partition ok? [12:03:18] --- jaltman has left: Disconnected [12:05:30] I use ext2 for the AFS cache because it is faster on the metadata updates. [12:05:51] And if the partition is hosed I can newfs it. [12:07:34] The ext3 issues should be resolved. [12:07:49] But ext3 is significantly slower than ext2 [12:08:03] That's what I thought was the case. [12:37:41] er, what ext3 issues? [12:40:56] IIRC, there were issues a while ago when using ext3. Possibly stability or data-loss. I keep getting the details of the much more recent cache-on-ZFS discussion with the details of cache-on-ext3. I was pretty sure these had been fixed, at least as long as 1.4 has been around, but I wanted to make sure. [12:47:23] --- Kevin Sumner has left [12:47:42] --- Kevin Sumner has become available [12:50:44] We didn't truncate files in the cache properly. [12:52:05] The fix was b02e22b5f0590929ef9120da4799ca9a47fa3aeb (RT 124942) [13:37:19] --- haba has left [13:53:22] --- jaltman has become available [13:56:46] --- mdionne has become available [14:04:50] --- kaduk@mit.edu/barnowl has become available [14:52:52] --- Kevin Sumner has left [15:45:45] --- kaj has left [16:00:16] --- deason has left [17:10:28] --- deason has become available [17:54:15] --- jaltman has left: Disconnected [18:33:08] --- mdionne has left [18:50:27] --- asedeno has left [18:51:44] --- jaltman has become available [19:50:26] --- asedeno has become available [21:05:04] --- jaltman has left: Disconnected [21:11:56] --- jaltman has become available [21:47:59] --- deason has left [22:23:28] --- reuteras has become available