[00:15:39] --- jaltman has left: Disconnected [00:35:09] --- kaj@kth.se has become available [00:40:08] --- abo has become available [00:58:17] --- haba has become available [01:03:39] --- dev-zero@jabber.org has become available [01:33:21] --- dev-zero@jabber.org has left [01:36:06] --- dev-zero@jabber.org has become available [02:46:07] --- Jeffrey Altman has left: Replaced by new connection [02:54:56] --- haba has left [04:44:14] --- jaltman has become available [05:25:52] For GSoC, shall we leave the project list in the wiki so that anyone can add projects to it? [05:26:21] As for mentors this year, the only one that has expressed an interest to me is Simon. [05:28:24] I think we should copy it over to the openafs.org site. Dementia's web server has an annoying habit of falling over. [05:29:30] Another option is to store it on the GSoC site [05:29:53] I haven't looked at what melange can do this year [05:30:29] I could create a Google Doc that is accessible to all mentors and link to it from the OpenAFS GSoC Home page [05:31:11] Simple is probably better, in this case. Is there a reason not to just have flat HTML somewhere? [05:31:39] I think jhutz was interested in mentoring the usermode NFS project. [05:44:18] --- haba has become available [06:09:54] > I think we should copy it over to the openafs.org site. Dementia's > web server has an annoying habit of falling over. oddly, this didn't happen with the old (1998) hardware. [06:30:16] --- reuteras has left [07:00:17] --- deason has become available [07:13:32] --- dev-zero@jabber.org has left [08:07:53] --- Kevin Sumner has become available [08:32:33] --- kaduk@mit.edu/barnowl has left [08:33:55] --- Russ has become available [08:34:33] --- kaduk@mit.edu/barnowl has become available [08:50:35] 1.4.12 ready to tag. speak now, or.... [08:57:31] go for it [09:00:01] --- haba has left [09:07:43] --- abo has left [09:08:26] --- abo has become available [09:15:47] ah. no. one problem. requires minor makefile tweak. fc_test can't be built in 1.4 series (circular make dependencies, not broken code/libs) [09:18:43] Is that something we've broken recently? [09:26:30] i think i broke it post 1.4.11 for irix. i have no idea how it escaped notice until now [09:50:13] FYI, Leslie Hawthorn would prefer that Secure Endpoints not register a separate project for Network Identity Manager. She requests that the Network Identity Manager project ideas and any other independent projects (implementing Microsoft StrSafe interfaces on *nix) be proposed under the OpenAFS organization. She would prefer to maximize the number of organizations that can take part in GSoC. Since OpenAFS already is established, she would prefer that we take on the additional projects and act as an umbrella organization. [09:52:08] works for me [09:55:02] shadow: my guess is benp's issue is SRV; do you have that for what you tried, too? [09:57:22] i tried for reed.edu, figure that's the simplest way to reproduce [09:57:28] and lo, ... [09:58:02] it will never *succeed* for me, but get_cellconfig shouldn't fail [09:58:11] i have a debug build running now [09:58:56] I mean, the logic hasn't been written yet for extracting the cell name out of a SRV response, so for SRV's it'll just give you a null cell [09:59:28] that's.... unfortunate, because i did write that logic. it means i failed to correctly amend the commit [09:59:42] and no one commented/noticed (myself included) [10:12:05] looks like realCellName is only assigned a value for the AFSDB case not the T_SRV case [10:15:15] yeah. working on it [10:16:11] (trying to do too many things at once. worst case? beehive got their liquor license friday. irish coffee ftw?) [10:41:20] --- kaj@kth.se has left [11:08:19] fun: (re)make dest in src/auth installs in the destdir but not in TOP_LIBDIR [11:08:31] which explains why obviously-correct code failed to work [11:09:24] 1537. tested. [11:28:08] Nice. Fix for that somewhere? [11:29:07] no. i'll look later. [11:29:15] we probably have a lot of this problem [11:31:07] Yeh. [11:31:38] So, today I've had two people moan about the Fedora 12 IMA issue. One of those is important, sadly. [11:32:44] (where important == pays wages ) [11:33:40] what will make them happy? [11:33:58] Not having things that look like panics in dmesg [11:34:13] er. so. upgrading to something newer [11:34:46] Yeh. 2.6.33, but it's not part of Fedora 12, which is what our next desktop distro is going to be based on. [11:36:22] uh. didn't we have a workaround for this? [11:36:28] --- abo has left [11:36:47] --- abo has become available [11:36:55] Not really, sadly. [11:37:46] well, there's always memcache, but [11:37:59] include a ksplice of the fix with the openafs rc script? ;) [11:38:09] Could do, I guess. [11:38:29] Just ksplice IMA into oblivion would suit me. It's not like we run it. [11:39:09] Basically, the workaround is to junk the ima messages with rsyslogd, but that doesn't catch the dump_stack() calls, and still slows down the machine. [11:39:57] ksplice a null into the printf? [11:40:21] ksplice dump_stack() to just return? [11:40:38] doesn't dump_stack serve other purposes? [11:40:56] Yeh. Panics would be less informative. [11:41:30] I'm probably just going to push for rebuilding the kernel with CONFIG_IMA disabled. But, historically, we've tried to avoid running with locally built kernels. [11:41:38] --- deason has left [11:42:07] --- deason has become available [12:09:13] ben says still one more issue. [12:13:15] So, the reason I don't believe the locking in 6c628445 is because afs_getevent() returns with the event lock (which is a regular mutex) held, and we then msleep() on the glock. But you can only hold a mutex when sleeping if that mutex is the mtx argument to msleep() (so "hold" is perhaps dubious), and we still hold the event lock at that point. Possibly the solution is to explicitly drop giant and msleep on the event lock, but I haven't thought about it very much. [12:14:10] > ben says still one more issue. Who is this not-me that I will confuse myself with? [12:14:13] it could be that i transliterated the code wrong [12:14:20] pen poliakof [12:14:23] er, "Ben" [12:14:27] this is an aklog issue [12:14:43] pen boliakoff ;) [12:14:59] which is odd: aklog -d dtrt [12:15:16] is it possible it has some extra unprintable char or something in there? [12:15:17] er, prints trt [12:55:33] no, it's fixed. i just need to give benp a new afsd also:\ [12:55:48] now, the interesting thing: looking at this, we leak memory [12:56:04] patch in a moment. (the leak is not new) [13:01:28] 1538 [15:20:39] --- deason has left [15:48:53] I'm assuming from the tagging going by that we're very, very close to a 1.4.12 release. Should I expect the tarballs sometime pretty soon? I think I have the Debian packages otherwise prepped. [15:49:13] i have tarballs now. i suppose i can give them to you. [15:49:27] Or put them up on grand? [15:49:31] Well, in AFs. [15:53:04] I think I already checked here last fall, but http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542213 with its error message of "openafs: dcache hv<0>------------[ cut here ]------------" followed by the normal BUG thing likely to be something that we've subsequently fixed? [15:53:34] The oops is in afs_cachetrim. [15:54:41] well, they will go up on grand. [15:55:11] dcache hv: maybe. i mean, i know what code it is. but it doesn't necessarily mean the relevant thing i am thining is "the fix" [16:08:44] Okay, I'll ping him to try again once I've uploaded 1.4.12. [16:08:56] --- mdionne has become available [16:13:59] if it was reproducible it would have been nice to know earlier [16:14:03] oh well [16:14:19] It was occasionally reproducible for him. I never saw it. [16:14:31] occasionally basically means not [16:14:34] I also didn't get another reply from him to my last message. [16:14:42] Yeah, I don't think it was something that was reproducible enough to be easy to debug. [16:14:43] like, if you can't collect info, then it's not really reproducible [16:50:29] --- mdionne has left [16:57:29] --- mdionne has become available [17:01:58] --- jaltman has left: Disconnected [17:52:34] Debian 1.4.12 packages uploaded. [17:55:37] The Git repository for Debian OpenAFS packaging now has a complete history of both the Debian packages and of OpenAFS since it now includes the entire OpenAFS Git repository as well, since I merged all the tags (it's too hard in Git to keep tags separate and not push them). Still only 65MB. [17:55:57] Which is large, but not tremendously horrible. [17:56:07] The old Debian repository was 308MB since it included all the old tarballs. [18:23:03] --- mdionne has left [18:39:58] --- jaltman has become available [18:46:09] At some point I need to figure out why Doxygen is very unhappy with our current protocol document translations. [18:53:57] 1.5.72 immediately explodes on write (Linux 2.6.32 Debian) with an oops in rx_WriteProc. [18:54:09] BUG: unable to handle kernel NULL pointer dereference at (null) [18:54:24] I saved the call trace. [18:54:33] I suspect I'll need to reboot. [18:58:21] --- Russ has left: Disconnected [19:00:36] --- Russ has become available [19:02:16] if you can reproduce it with current origin/master i care [19:02:38] if you can't, i don't care. [19:02:41] Okay. [19:02:57] Is there a 1.5.73 coming out soon, or should I try to pull up all the deltas from Git? [19:03:14] * Russ thinks that the experimental 1.5 packages are kind of doomed, as every version I try to package does something like this. [19:03:47] But I can confirm that your fix for the afsd interface to the kernel module works! [19:04:02] It started and reading files works fine. Writing files just didn't work. [19:04:12] pull up? uh. [19:04:18] git checkout origin/master? [19:04:28] but yes, 1.5.73 soon [19:04:41] oh. writing files? yeah. that's fixed [19:04:43] I mean to the Debian packaging branch. [19:04:53] Oh, okay. [19:04:55] oh. for that, wait for 1.5.73 [19:05:04] for testing yourself, git checkout origin/master [19:05:06] Okay, will do. [19:05:14] Right. [19:05:30] Yeah, that's how I usually test if I'm doing development. [19:05:39] People have been clamoring for 1.5 packages for broader testing. [19:06:05] Plus I should update the Debian build rules in head to something that isn't ancient, and have been waiting until I successfully built packages from head. [19:20:29] Hmm. I tried to build your 1.4.12-1 packages on Lucid, but openafs-modules-dkms ended up with no maintanier scripts. [19:22:32] That implies I have an insufficiently tight dependency on dkms. [19:22:34] It looks like dh_dkms -popenafs-modules-dkms does stuff but dh_dkms does nothing. [19:23:02] I suspect: [19:23:08] dkms (2.1.1.2-1) unstable; urgency=low [ David Paleino ] * [ff95487] dh_dkms: continue the loop if there's nothing to do on the current package. (Closes: #568580) [19:26:45] I was a bit worried about the dh_dkms stuff, since it seems rather cutting-edge, although I think it's the right thing to do for squeeze. [19:26:58] I can probably work around that with the -p flag for right now, or add a tighter build dependency. [19:27:19] I wonder if there's any chance Ubuntu will sync the current version. [19:29:28] I’ll report a dkms bug and see what happens. [19:34:14] Cool, thanks. [19:34:26] I'm happy to add a workaround if it ends up being useful to aid package building on Ubuntu. [19:35:38] Okay. I’ll try ‘dh_dkms -popenafs-modules-dkms’ in a PPA build and see if that works. [19:50:31] Actually, I bet I’m going to be bitten by the revenge of #568591 this time. [19:51:36] If I'm reading that bug correctly, I think it won't matter since it's the only thing in the postinst for that package. [19:52:19] The problem is that Ubuntu has taken the first patch in that bug but not the second, and hence introduced the bug that the postinst always fails. [19:52:39] Oh, I see. [19:52:54] Well, that at least should make it more likely they'll take an update from Debian. [19:54:14] Whoo, that's the first 11 hour work day that I've put in in a while. :) [19:54:20] Kind of nice to feel productive like that again. [20:24:10] https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/534832 dh_dkms silently exits at the first non-dkms package https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/534833 dh_dkms postinst snippet always fails https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/534843 Sync dkms 2.1.1.2-2 (main) from Debian testing (main) [20:24:30] Thank you! [21:00:11] russ: are you still around? [21:01:30] Yup! [21:02:21] if I want to build a .deb package from my own modified git checkout, is there an easy way to do it, knowing nothing about how packages are built? [21:02:47] I'm looking at http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/x88.html#AEN108 right now, not sure how pertinent it is [21:04:14] That's instructions for how to build a package entirely by hand, which while somewhat interesting for what's under the hood isn't how anyone builds Debian packages. [21:04:54] I have no intention of distributing this in any way, I just want to install my stuff, and have it do the right thing [21:05:15] The easiest way would be to run debcheckout openafs (on a Debian system with devscripts installed), apply your additional patches to that tree, and then run debuild. However, note that the current packages will only build on an unstable system. [21:05:43] debcheckout should give you a Git clone of the current Debian packaging repository. [21:05:51] which is 1.4.x [21:05:52] yes? [21:06:04] Yes, but 1.5.x is available in the experimental branch. [21:06:07] In that same repository. [21:06:28] when i want to debuild things, it never works. i start with binaries but can never get the source back [21:06:29] Actually, I should say that the current packages will only build on unstable or testing. [21:06:43] I'm on unstable, I believe [21:06:47] possibly testing [21:06:56] regardless, that part I can figure out [21:07:09] Yeah, then debcheckout should do what you want. Alternately, git clone git://git.debian.org/git/pkg-k5-afs/openafs.git [21:07:15] Warning: 66MB repository. [21:08:13] It's a git repository based on the upstream repository, so you should even be able to merge local branches into it and have the right things happen. [21:08:21] --- abo has left [21:08:41] and I suppose there's no easy way to convert my current upstream git checkout? [21:08:43] --- abo has become available [21:08:57] Actually, there is. You can just add that Git repository as a new remote. [21:09:01] Since they have common ancestry. [21:09:19] git remote add debian git://git.debian.org/git/pkg-k5-afs/openafs.git [21:09:21] git fetch debian [21:09:38] and then you can create a local branch based off of debian/master for 1.4 or debian/experimental for 1.5. [21:10:27] interesting [21:10:31] thanks a ton [21:11:11] If you want to get fancy, install git-buildpackage and look at http://www.eyrie.org/~eagle/notes/debian/git.html for how I do it, although that involves setting up cowdancer to create a build chroot. [21:11:36] For local hacking, it's probably easiest to just use debuild. [21:11:44] I'll stick to "unsophisticated" :) [21:12:03] That will make a native package rather than a proper non-native package unless you check the upstream tarball out of pristine-tar, but you probably don't care. [21:13:04] The big drawback to Debian package building is that there are a ton of really excellent tools that mean that once you have a build environment set up and understand all the tools, building packages is *really* easy and straightforward even for multiple distributions at the same time, but the learning curve on all the tools is... interesting. [21:13:39] mm, I'll try debuild, and see what I can make happen [21:13:50] That's the simplest -- best place to start. [21:13:58] And have to run -- time to go exercise and sleep. [21:14:02] cool, thanks a ton [21:14:15] Sure thing. [21:14:22] --- Russ has left: Disconnected [21:14:43] --- abo has left [21:15:37] --- abo has become available [21:41:46] --- Russ has become available [22:14:08] --- reuteras has become available [23:54:42] --- kaj has become available [00:00:00] --- Russ has left: Disconnected