[03:17:00] --- manfred furuholmen has become available [03:40:56] --- SecureEndpoints has left: Replaced by new connection [03:42:54] --- dev-zero@jabber.org has left: Replaced by new connection [03:42:54] --- dev-zero@jabber.org has become available [05:23:22] --- manfred furuholmen has left [08:21:30] --- SecureEndpoints has become available [09:04:08] --- manfred furuholmen has become available [09:30:08] --- edgester has become available [09:31:16] --- edgester has left [09:40:40] --- SecureEndpoints has left [10:02:33] --- manfred furuholmen has left [10:36:57] --- SecureEndpoints has become available [11:07:22] --- edgester has become available [11:49:31] Simon Wilkinson: I tried the openafs 1.5.55 rpms that were supposed to have disconnected support, but disconnected support wasn't enabled. [11:49:46] --- SecureEndpoints has left [11:50:15] how do I build fedora 1 rpms with disconnected support? [11:50:25] ugh, fedora 10, I mean [11:54:19] --enable-disconnected probably needs to be added to the configure arguments in the spec file [11:55:21] urgh, touchpad in Ubuntu is tweaky [11:57:05] ah, but the spec file in 1.5.56 doesn't appear current. It doesn't include fedora 10 [11:57:19] summatusmentis: sorry [11:58:00] nah, not your fault, just anoying [11:58:29] summatusmentis: ok [11:58:57] and I like to whine :) [11:59:04] :P [11:59:55] the one in cvs may not be up to date. rpm -i the srpm, and get the spec file from it [12:00:28] where are the 1.5.56 rpms? [12:00:36] or srpm, rather [12:00:39] 1.5.55 [12:00:50] the spec file will not thave changed [12:01:52] ah, I tried Simon's rpms, but it would let me build because I didn't have kernel-devel-x86_64-x.xx (should be kernel-devel-X.XX.x86_64 [12:01:56] sugh [12:01:59] sigh [12:39:21] That's a know bug. Specify your kernel version on the command line and all will be well. [12:39:39] I still need to give Derrick the 1.5.x SRPM patches. That packaging isn't entirely done yet. [12:39:51] ah, k [12:40:17] It's known not to build for RHEL5, for example. [12:40:35] I'm running "yum upgrade kernel" on my f10 guest [12:40:49] so , the srpm ill not build at all for rhel5? [12:45:44] There's a bug in the script that works out the on-disk-path from the kernel version, architecture and variant information that's been tickled by some of the recent changes in RHEL. [12:46:01] So, no problem with OpenAFS itself, but the packaging doesn't work properly. [12:46:18] goodie [13:16:19] Simon Wilkinson: I'm dumb, would you please give me an example of how to run rpmbuild on openafs.spec and specify the kernel version? [13:16:50] --define kernvers [13:17:08] The specfile description has the exact syntax [13:20:06] ah, must drop the .x86_64 [13:22:41] RedHat keep changing the way that kernel versions get specified. There's now a ridiculous amount of 'which Fedora is this' special casing going on. [13:48:48] Is that working for you? It's occurred to me that there was something on the mailing list about 1.5.56 not building on Fedora 10 due to a missing library dependency. [13:59:12] I got 1.5.55 to build [13:59:34] Yes. I know 1.5.55 builds, as there's RPMs built for it :) [13:59:51] I was wondering if you'd tried 1.5.56 [14:00:01] not yet, but I will [14:00:46] what changes need to be made to build 1.5.56 [14:00:46] ? [14:01:20] To the specfile? [14:01:27] Just change the AFS version. [14:01:42] ok, change the afs version and drop in new tar.bz2 files? [14:01:56] I'll get around to it at some point. It was going to be this weekend, but my build machine has fallen off the interent. [14:02:10] bummer [14:05:40] building now...I dropped in new tar.bz2 files and renamed the RELNOTES file to 15.56 [14:06:23] Ah yes RELNOTES is release specific too. [14:06:34] I've got a script that builds the new SRPM with each new release. [14:07:16] I just wanted to get a build [14:08:07] any idea what happened to your build machine>? [14:08:44] Yeh. Routing's gone screwy in the University's network, so our different server rooms can't talk to each other. [14:08:53] ouch! [14:08:59] Unfortunately, we don't do 24x7 support, so it'll be Monday morning before it gets fixed. [14:09:20] sounds a little like our campus [14:09:43] I think we do or are trying to do 24x7 for networking [14:09:48] We're just coming out of a 2 week shutdown - everything's been running unattended since the 23rd. [14:10:04] yeah, that'll do it [14:10:10] us too [14:10:45] hmm, got a build error [14:10:58] Something about -lresolv ? [14:11:48] /home/testuser/rpmbuild/BUILD/openafs-1.5.56/src/rx/rx.c: In function 'rx_InitHost': /home/testuser/rpmbuild/BUILD/openafs-1.5.56/src/rx/rx.c:529: warning: cast from pointer to integer of different size /home/testuser/rpmbuild/BUILD/openafs-1.5.56/src/rx/rx.c: In function 'rxi_NewCall': /home/testuser/rpmbuild/BUILD/openafs-1.5.56/src/rx/rx.c:2203: error: expected expression before 'do' [14:12:09] Hmmm. That's ... different [14:12:43] What's at line 2203 of rx.c? It's going to be a macro expansion of some kind. [14:12:57] (I hope this isn't my broken ViceLog patch made it into a release) [14:13:10] rx_MutexIncrement(rx_stats.nCallStructs, rx_stats_mutex); [14:13:35] I tihnk i see it: [14:13:38] call->call_id = #endif /* DEBUG */ rx_MutexIncrement(rx_stats.nCallStructs, rx_stats_mutex); [14:13:51] --- stevenjenkins has left [14:13:54] the endif should be one line lower [14:14:21] Let me look. That doesn't sound entirely right either. [14:15:59] the endif splits a line that shouldn't be split [14:17:08] --- stevenjenkins has become available [14:17:35] Indeed. [14:18:11] What I was wondering about is whether the new mutex stuff had made it in, and that was also causing problems. It would appear that that's only in head at the moment, though. [14:19:37] That's SecureEndpoints DEVEL15-rx-packet-count-debugging-20081229 that's causing the problem. [14:20:13] Actually. No it's not. [14:20:14] You'd think "obviously doesn't compile" would block a release. [14:20:24] That code is correct. [14:20:49] Well, would be correct if the Unix mutex implementation is the same as windows. [14:21:17] I enabled disconnected mode, could that be the cause? [14:21:21] Nope. [14:21:33] The problem is that that code has only been tested on Windows, I'd imagine. [14:22:05] You're saying the code is correct which, depending on the state of a preprocessor macro, either does an assignment or just evaluates the RHS of the assignment and throws away the result? [14:22:17] Yes. [14:22:20] /tested/compiled/ [14:22:56] If we're in DEBUG mode, then we're storing the results as we go. If we're not, we don't care about the value at that point, and so can just Increment the variable and move on. [14:23:21] wow [14:23:28] The problem is that the Unix mutex is implement as a do { } while(0); macro, and the Windows mutex is a function with a return value. [14:25:08] having an else case might be clearer [14:25:45] Well, it wouldn't help the code compile :( [14:26:21] :( [14:26:55] Certainly in userspace, that code won't work anywhere AFS_NT40_ENV isn't defined. [14:29:32] edgester: However, you should only see the problem if DEBUG is defined. [14:36:16] ... but, if we're building for the kernel, it looks like afs_osi.h ensures that DEBUG is set. [14:36:25] edgester: Fancy opening an RT ticket? [14:39:10] --- SecureEndpoints has become available [14:43:10] the 1.5.56 code was compiled on irix and the binaries were tested. [14:44:19] Ah. IRIX is the one platform which doesn't set DEBUG in the kernel. [14:44:44] See afs_osi.h for the gory details. [14:45:42] -DDEBUG is a poor choice for this code if it is compiled on every platform [14:45:52] we don't want it compiled by default [14:46:15] Yes. [14:46:43] And, at present, it won't work at all on platforms whose Mutex operations don't return values. [14:47:55] it can't work [14:48:35] the logic is dependent upon the atomic operations returning a value. otherwise, you can't use the incremented value without a lock [14:48:51] and we don't want to impose a lock acquisition on this ocde [14:51:00] new symbol will be RXDEBUG_PACKET [14:51:34] Cool. That should solve the problem. I think at the moment, that will only work on Windows. I don't think any other platform has the correct semantics for MutexIncrement() [14:51:42] Simon Wilkinson: FYI -afsdb is not ON by default in the rpm [14:52:10] edgester: The RPM's defaults are what they've always been. [14:52:31] I want to revisit that for 1.6.0, but I think doing so before that is just going to cause users pain. [14:53:02] ok, but openafs.org doesn't appear unless -afsdb is on [14:53:22] There is no openafs.org cell [14:53:50] huh? [14:53:55] The AFSDB records for openafs.org point to the grand.central.org cell. [14:53:57] The CellServDB file lists openafs.org and points it at grand.central.org [14:54:07] ah [14:54:16] The CellServDB file does _not_ list openafs.org [14:54:16] from the perspective of an anonymous user, grand.central.org is openafs.org [14:54:54] I suppose we could publish that name in the CellServDB. [14:55:24] it used to. when did you remove it [14:55:28] I thought there were issues with the Windows CM, and having the same cell with two different names? [14:55:39] there are. [14:56:02] it only matters if you access the cell by both names [14:56:16] It was there in October 2005. It was not there in March 2007. [14:56:30] would a CellAlias be a good solution? [14:56:39] --- stevenjenkins has left [14:56:39] > set type=AFSDB > openafs.org Server: dc.windows.secure-endpoints.com Address: 192.168.1.8 Non-authoritative answer: openafs.org AFSDB subtype = 1, AFS db server = penn.central.org openafs.org AFSDB subtype = 1, AFS db server = andrew.e.kth.se openafs.org AFSDB subtype = 1, AFS db server = grand-opening.mit.edu [14:56:47] The only release between was October 2006; I don't have a copy of that one [14:57:31] There is no centrally-managed repository of aliases. [14:57:38] Jeff, what's your point? [14:58:43] Mailing list archives say it was removed in the Oct 2006 release. [15:00:01] --- stevenjenkins has become available [15:00:02] jhutz. a default cellname is specified by the install scripts because a root.afs volume must be able to be loaded and -dynroot is not the default. "openafs.org" is that default cell name. Therefore, we must have something that points to it. Apparently it was removed from the CellServDB but the AFSDB records were left in place. If the default cell name should no longer be "openafs.org", then it needs to point to something else. However, I believe creating an openafs.org would be preferred even if it is only a root.afs and root.cell volume with mountpoints to other cells [15:01:11] And this is the rather exciting thing. I'm pretty sure that the RPMs set the default cellname to openafs.org, turn on dynroot, but don't enable afsdb. [15:01:13] Ooops. [15:01:20] It's been the way it is for a couple of years now. I don't remember why it happened. We can certainly change it back. [15:01:36] Well, if you turn on dynroot, then the default cell doesn't matter much. [15:02:06] Actually, yes. Too much red wine, methinks. [15:02:25] Alternately, we could provide a distinct set of openafs.org servers, possibly more widespread, which provide a root.afs containing all of the cells in the CellServDB. [15:02:54] I think an openafs.org cell should exist [15:03:05] (such things could run tafsd instead of openafs and be very lightweight) [15:03:27] +1 for openafs.org existing [15:03:36] what is tafsd? [15:04:11] Simon Wilkinson: would you please give me a brief explanation of how to use "fs discon"? [15:04:48] Is "fs precache" related to fs discon? [15:06:54] tafssrv, rather. A "trivial" AFS server I wrote, where the complete structure of every volume is described in a config file; though actual contents of files come from files on the server. It provides limited volserver functionality and can be its own vlserver. I originally wrote it to provide a way to include PRDB dumps in backups done by a backup system that only knows how to dump AFS volumes. [15:07:56] interesting [15:13:39] edgester: please try /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/rx-debug-packet-cpp-1.patch [15:30:23] SecureEndpoints: I'll try that. [15:34:26] Seems to be working for me [15:34:46] That patch won't patch for me [15:35:17] patch -p0/1/2 fail [15:38:07] patch -p0, in src/rx [15:39:24] ah [15:50:51] looks like it compiled successfully [15:51:02] it wrote rpms and everything [15:52:12] time for dinner. I'll be back in a little while [15:55:39] thank you for testing [16:36:35] you're welcome [17:17:02] edgester: precache isn't related to the discon code. I'm not sure what that does, I hadn't run into it before now... [17:17:37] See my slides from the European AFS Workshop for the full gory details, but essentially ... [17:18:18] Fill your cache (find . -type f | xargs cat > /dev/null), or similar [17:18:25] fs discon offline [17:18:34] ... do stuff, on or off the network ... [17:18:38] fs discon online [17:18:42] ... file bug reports :) [17:19:56] will do [17:24:03] Simon Wilkinson: do you want the fedora 10 rpms that I built? [17:25:03] rpms are at /afs/dementia.org/home/edgester/rpms [19:10:20] --- edgester has left [21:36:15] --- dev-zero@jabber.org has left [22:48:36] --- dev-zero@jabber.org has become available [22:59:20] --- dev-zero@jabber.org has left [22:59:53] --- dev-zero@jabber.org has become available