[00:06:33] --- kaj has become available [00:15:57] --- pod has become available [00:17:15] --- dev-zero@jabber.org has become available [00:17:57] --- dev-zero@jabber.org has left [00:27:13] --- dev-zero@jabber.org has become available [00:27:22] --- reuteras has left [00:54:58] --- Simon Wilkinson has become available [01:03:04] jaltman: That's just a pretty front end to functionality that's already in git - you can get the same results from the comfort of your own command line using git log and git diff [01:59:32] > who is the sun packager for releases? doug engert has built most of them recently. [01:59:59] but it's just make dest [02:45:57] --- Jeffrey Altman has left: Replaced by new connection [02:45:58] --- Jeffrey Altman has become available [02:46:16] --- jaltman has left: Replaced by new connection [02:46:17] --- jaltman has become available [02:51:32] --- abo has become available [05:16:35] --- meffie has become available [05:29:47] --- meffie has left: Lost connection [05:40:04] --- abo has left [05:40:23] --- abo has become available [06:12:15] > who is the sun packager for releases? I would like to know if they are built with gcc vs sunpro C [06:13:04] and discuss build setup (a la the wiki page on 'how to build openafs' that lists how to build on Debian) [06:14:40] They're not built with gcc. [06:14:51] tx. [06:14:59] that's what I wanted to know. [06:15:01] You can't build kernel modules for Solaris with gcc, and we hardcode the compiler to the Sun one in the config file. [06:15:13] ? [06:15:18] Did you see my blog post about how to set up Open Solaris so it can build OpenAFS? [06:15:26] nope. [06:15:28] what url? [06:15:43] And I have written a config test to find the correct compiler on Solaris that is still not used. [06:15:47] ah, found it. [06:15:47] http://blob.inf.ed.ac.uk/sxw/2009/12/22/building-openafs-on-opensolaris/ [06:16:11] haba: Is it in gerrit? [06:16:29] The configure test has been in OpenAFS for years. CVS.... [06:16:43] Ah, I think it's been removed. [06:16:45] that's exactly what I was looking for simon; tx. [06:17:08] haba -- I've seen site-specific patches for configure; didn't realize anything was in mainstream [06:17:35] The last set of patches for Solaris CC selection was one from me, where I expanded the range of places we looked. [06:17:49] And I still think we should try to bend some peoples arms to give us Solaris packages. I even suggested some names to start nagging. [06:18:28] As in, to build OpenAFS as Solaris packages? [06:19:32] BTW, same problem with Heimdal. It was obviously not built on any modern Solaris, so building 1.3.2rc2 on Solaris does not work (yet). We are talking with Love about it. [06:19:45] Simon: yes, distribute pkg files. [06:21:32] When starting to distribute .pkg files, these could then follow the Solaris guidelines where to install stuff. Like /opt/ [06:22:32] There will always be people who don't like change, but those can stick with their tar-files and install from them. I do not care. [06:23:08] Sure, find someone who's prepared to do that work for each release, and I can't personally see any reason why not. [06:25:03] I guess the main work will be the first release. [06:25:50] It's being prepared to make the commitment both to do the first release, and then to keep the packaging up to date as things move forwards. [06:54:25] haba: is your config test in RT or gerrit? [06:55:03] (sorry, missed the fact that I was scrolled backwards in the window. ignore that last query) [06:57:43] My suspicion is that haba is referring to the code in src/cf/solaris-cc.m4 [06:58:47] For Heimdal, Love has a buildbot farm. Add Solaris machines to the farm and they can automatically be built. [06:59:30] It's not the physical mechanics of the building that is an issue. [07:00:07] It's keeping the package descriptions up to date as we change things in the release. Ask Russ how often he needs to update the Debian packaging, or look at the number of times things have to get changed for RedHat. [07:20:39] --- deason-gmail has become available [07:24:25] build setup: i can probably find you the actual build log. sadly doug's away this week [07:24:47] > You can't build kernel modules for Solaris with gcc you probably can now, we haven't tried in a while. you couldn't before [07:25:39] and as far as solaris packages, chaskiel did some work on it long ago which he might still have [07:25:49] It's probably actually a good thing that we build with 'native' compilers, rather than gcc. Hopefully shakes out more wrinkles. [07:28:59] probably. and i'm not volunteering to do the gcc work. but if someone does we should provide the option [07:30:07] We've also got the work that was done to separate out the kernel build environment from the userspace one that we could generalise. [07:51:32] hmm. given we're turning off restarts, I guess that rx leak that Jeffrey and I noticed should really get recorded somewhere, then fixed. [07:54:14] there is a leak that hasn't been fixed? [07:54:41] remember, the one that we spotted at inf, and you then confirmed mit had too [07:55:43] and then Derrick and I fixed a few things. I need to go back and see what that was and make sure it is plugged. [07:56:16] we'll hopefully be running 1.4.12 pretty soon after it is released [08:10:18] --- dev-zero@jabber.org has left: Lost connection [08:31:36] --- dev-zero@jabber.org has become available [08:49:58] --- haba has left [09:27:56] --- dev-zero@jabber.org has left [09:41:17] --- kaj has left [10:03:41] --- meffie has become available [10:05:34] --- deason has become available [10:05:45] --- deason-gmail has left [10:33:20] --- kaj has become available [10:46:29] --- phalenor has left [10:46:30] --- steven.jenkins has left [10:46:30] --- dwbotsch has left [10:48:24] --- dwbotsch has become available [10:48:29] --- steven.jenkins has become available [10:49:36] --- Russ has become available [10:58:15] --- phalenor has become available [11:12:02] simon - charles curley had started some 'change from kaserver to kerb' stuff for the openafs docs. you might contact him directly if he doesn't reply to your mail. [11:12:18] Okay. Will do. [11:12:47] I wrote some stuff up a while back that he may still have a copy of (I don't; it's at a former employer -- I could get it if needed) [11:13:37] Was that for the User Guide or the Admin Guide? [11:59:19] github really doesn't like producing its impact report for openafs [12:09:11] --- Kevin Sumner has become available [12:09:40] last time I tried loading that it was huge and made the browser start using a lot of cpu [12:10:29] Yeah. Kills Safari. [12:12:38] test [12:12:58] > Was that for the User Guide or the Admin Guide? Admin guide, iirc. [12:19:31] Jason has done a lot of good work on the Admin Guide. [12:20:26] which doesn't say there isn't more to be done [12:21:44] but the kaserver to Kerberos v5 conversion should be complete [12:24:46] There's still stuff in there that really shouldn't be. [12:25:02] The entire section on "Mutual authentication" for example. [12:25:42] But I think the big bits have been done. [12:36:44] I believe that as long as AFS has only Kerberos based security classes that http://docs.openafs.org/AdminGuide/ch02s11.html#HDRWQ75 is reasonable. Once rxgk is deployed, the entire section on how security works will need to be replaced. [12:38:33] The UserGuide section on logging in is (on the other hand) so out of date as to be useless http://docs.openafs.org/UserGuide/ch02.html#HDRWQ21 [13:09:21] --- kaj has left [13:09:34] --- kaj has become available [13:35:52] --- shadow@gmail.com/owlBD8333E1 has left [13:43:16] --- haba has become available [13:50:19] --- dev-zero@jabber.org has become available [14:03:09] --- dev-zero@jabber.org has left [15:04:38] --- Ben Poliakoff has become available [15:05:11] --- mdionne has become available [15:05:36] --- Ben Poliakoff has left [15:45:49] --- deason has left [15:57:24] --- shadow@gmail.com/owl8B3EC998 has become available [16:25:26] --- kaj has left [16:33:43] --- meffie has left [16:35:57] --- kaj has become available [17:44:44] --- andersk@mit.edu/home-on-the-dome has become available [17:49:28] --- andersk@mit.edu/home-on-the-dome has left [17:49:52] --- andersk@mit.edu/dr-wily has left [17:49:52] --- andersk@mit.edu/dr-wily has become available [17:50:00] --- andersk@mit.edu/dr-wily has left [17:50:00] --- andersk@mit.edu/dr-wily has become available [17:50:04] --- andersk@mit.edu/home-on-the-dome has become available [17:50:33] --- andersk@mit.edu/home-on-the-dome has left [17:52:44] --- andersk@mit.edu/home-on-the-dome has become available [17:54:56] --- summatusmentis has become available [17:55:39] --- Russ has left: Disconnected [17:56:49] --- andersk@mit.edu/home-on-the-dome has left [18:05:07] --- deason has become available [18:15:46] --- Russ has become available [18:16:15] Hm. In FBSD/osi_inode.c, Chaskiel commented out afs_syscall_{icreate,iopen,iincdec} back in 2002, replacing them with stubs that return EOPNOTSUPP. Is there any reason to keep the old code around? [18:17:11] it depends if we think anyone has inode fileserver binaries on freebsd. [18:17:19] probably not. [18:18:14] (I only notice this because someone decided to s/dev_t/struct cdev*/ in ufsmount.h ...) [18:43:51] Those system calls are used only to support inode-style fileservers. Since I doubt we want to do that, you should leave them out. [18:46:57] Er, the question was whether I should remove them old code from the file and leave the stubs without an #ifdef them. [18:55:29] I think that would be fine. [19:19:23] --- mdionne has left [19:20:52] --- asedeno has left [19:20:55] --- asedeno has become available [20:20:05] Ugh. afs_lockctl()'s clid parameter is treated as a (32-bit) int, but for FBSD is passing a caddr_t, which is (char *) (and therefore 64-bit on my laptop). [20:22:00] caddr_t? from where? [20:23:26] ah. a_id. what's in a_id? [20:23:29] int afs_vop_advlock(ap) struct vop_advlock_args /* { * struct vnode *a_vp; * caddr_t a_id; * int a_op; * struct flock *a_fl; * int a_flags; * } */ *ap; [20:23:52] assume i don't have a bsd source tree handy at the moment [20:24:31] Yeah, getting there ... [20:26:12] i should arrange to keep fbsd source around; it's close enough to darwin in many ways that i can probably make it work [20:27:19] "void *" (still looking) [20:44:06] It ... appears to be unused? (I don't have any particular reason to think this needs fixing, I'm just going through the warnings from the build and looking at the suspicious things.) [20:44:39] if lockIdcmp doesn't use it, probably nothing does [20:47:54] Hm, there is: #if defined(AFS_SGI65_ENV) || defined(AFS_DARWIN_ENV) || defined(AFS_XBSD_ENV) /* XXX check this. used to be *only* irix for some reason. */ (!onlymine && (flock1->l_pid == clid)) So it seems to want a PID from somewhere ... [20:48:14] "maybe" [20:55:54] I guess this is the point in the call path where the type mismatch enters: #if defined(AFS_SGI_ENV) || defined(AFS_DARWIN_ENV) || defined(AFS_XBSD_ENV) int afs_lockctl(struct vcache * avc, struct AFS_FLOCK * af, int acmd, afs_ucred_t * acred, pid_t clid) #else u_int clid = 0; int afs_lockctl(struct vcache * avc, struct AFS_FLOCK * af, int acmd, afs_ucred_t * acred) I'm kind of tempted to change the prototype there to be caddr_t for FBSD and declare a local clid=0, and not care any more until something breaks. [21:01:26] that's possiblly not the worst idea. it's kinda icky but i understand [21:02:53] "Alternately, I could go live in a cave for a month and actually understand the VFS layer" [21:03:11] living in a cave sucks. i did it for a while. not literally. [21:57:04] assuming we can determine that we cannot receive callbacks from a file server, should we stop serving data from that file server? [21:58:44] no, I guess not. what we should do is degrade into a mode where callbacks expire almost immediately [22:14:16] --- reuteras has become available [22:23:02] --- Russ has left: Disconnected [22:27:50] --- steven.jenkins has left [22:38:39] --- steven.jenkins has become available [22:59:55] --- deason has left [23:57:58] --- kaj has left