[00:17:02] --- dev-zero@jabber.org has become available [00:17:09] --- dev-zero@jabber.org has left: offline [00:22:12] --- Russ has left: Disconnected [01:10:26] --- dev-zero@jabber.org has become available [01:10:31] --- dev-zero@jabber.org has left: offline [05:30:16] --- Jeffrey Altman has left: Replaced by new connection [06:41:12] --- reuteras has left [07:00:59] --- deason has become available [07:09:54] --- Jeffrey Altman has become available [08:04:38] --- Jeffrey Altman has left [08:15:50] --- Jeffrey Altman has become available [09:28:06] --- cclausen has left [09:33:01] --- dev-zero@jabber.org has become available [09:33:20] --- dev-zero@jabber.org has left: offline [09:49:51] --- Jeffrey Altman has left [09:59:45] --- Russ has become available [10:01:02] --- Jeffrey Altman has become available [10:10:09] --- pod has left [10:22:32] --- bpoliakoff has become available [10:30:53] modpost: GPL-incompatible module openafs.ko uses GPL-only symbol '__rcu_read_unlock' with 2.6.30 -- already fixed in 1.4.11pre1? [10:31:03] nope. [10:31:25] your kernel has debugging on which makes rcu use a symbol unavailable to us. [10:31:32] can't be fixed by us. [10:31:42] Ah, okay. So the answer is to tell them to turn off kernel debugging? [10:32:01] it's CONFIG_LOCK_DEBUG or somesuch [10:32:13] I'm guessing __rcu_read_unlock is something basic and fundamental that we can't realistically do without. [10:32:42] if you don't want to trash kernel data structures, no [10:37:59] Thanks! [10:44:27] --- dev-zero@jabber.org has become available [10:44:35] --- dev-zero@jabber.org has left: offline [11:18:53] --- dev-zero@jabber.org has become available [11:18:56] --- dev-zero@jabber.org has left: offline [11:19:42] --- Jeffrey Altman has left [11:33:29] Derrick is right; turn off... I think it is CONFIG_LOCK_DEBUG, and the problem will go away. [11:35:25] --- Jeffrey Altman has become available [12:01:52] --- stevenjenkins has left [12:24:22] Hm, so, the user says that he doesn't have that debug setting turned on, he's turned off all the debug flags that he can, and it still fails. OpenAFS used to compile with the same settings and now doesn't built with 2.6.28 either. I'm not sure what to make of that. [12:26:18] The only flags that contain debug that are turned on are, according to the user: CONFIG_X86_DEBUGCTLMSR=y CONFIG_ACPI_DEBUG=y CONFIG_IRDA_DEBUG=y CONFIG_MAC80211_DEBUG_MENU=y CONFIG_MAC80211_TKIP_DEBUG=y CONFIG_IEEE80211_DEBUG=y CONFIG_PNP_DEBUG_MESSAGES=y CONFIG_THINKPAD_ACPI_DEBUG=y CONFIG_ATH5K_DEBUG=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_MEMORY_INIT=y [12:26:38] * Russ is suspicious of that last one. [12:29:17] --- haba has become available [12:31:40] Does someone know right away why: cc: /usr/src/openafs-1.4.11pre1/lib/libsys.a: No such file or directory [12:32:48] 1.4.11pre1, udebug wants to link against libsys.a but there is none there [12:34:17] Sounds like a dependency problem, although I don't kow immediately why that might be the case. [12:35:04] Ok, I'll investigate [12:36:55] src/sys/libsys.a does not get built in spite of udebug needs it [12:37:05] --- Jeffrey Altman has left [12:37:38] So how did I configure the build system into that? [12:39:25] Well, first question: are you just doing a make, or are you making a specific target? [12:39:53] I think target ubik needs dependency sys [12:40:33] Ah, indeed. [12:40:51] Graph cycles through sys [12:40:52] OOps [12:41:38] Hmmm [12:41:44] --- deason has left [12:42:18] --- deason has become available [12:42:27] I'm not seeing where that graph would cycle. [12:42:42] You get a graph cycle with: [12:42:44] --- Makefile.in 3 Jun 2009 05:39:47 -0000 1.122 +++ Makefile.in 18 Jun 2009 19:42:33 -0000 @@ -184,7 +184,7 @@ rxkad: cmd comerr sys des rx rxkad_depin auth: cmd comerr comerr des lwp rx rxkad audit sys_depinstall auth_depinstall ${COMPILE_PART1} auth ${COMPILE_PART2} -ubik: cmd comerr auth ubik_depinstall +ubik: cmd comerr auth sys ubik_depinstall ${COMPILE_PART1} ubik ${COMPILE_PART2} tubik: ubik libafsrpc [12:42:48] me neither but my freebsd make does say so [12:42:54] Hurm. [12:43:21] afs des rx rxstat fsint are what sys adds. [12:43:47] afs adds nothing interesting. [12:43:53] Neither does des. [12:44:00] --- stevenjenkins has become available [12:44:01] rx adds lwp. [12:44:14] lwp adds util [12:44:17] util adds procmgmt [12:44:24] But all that looks okay. [12:44:40] rxstat adds nothing. fsint adds nothing ew. [12:44:44] So yeah, not seeing the cycle. [12:44:55] Can FreeBSD make spit out more debugging data? [12:47:12] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533541 has all the details on the __rcu_read_unlock problem now. [12:48:53] Freebsd make is "not up to it" [12:49:56] russ, what was the openafs delta you thought fixed https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/129480 [12:50:01] because it should be the same issue [12:54:08] Yeah, I just got mail back from him saying the sid version worked. [12:54:57] Although it couldn't be that particular patch, since that was in 1.4.7. [12:55:09] It broke for him in 1.4.10 and then was fixed in Debian's -2 1.4.10 package. [12:55:40] Given the limited deltas I pulled up in 1.4.10-2, the only thing I can think of affecting this is STABLE14-linux-mmap-antirecursion-fix-20090512. [12:56:11] Unless there's something really weird going on with STABLE14-dprintf-rename-20090427 or STABLE14-linux26-defer-cred-changing-20090511 or STABLE14-memcache-write-on-laststore-20090512. [12:56:18] Those are all the detals that I pulled up that affected the kernel module. [12:56:41] (Well, also STABLE14-linux-mmap-antirecursion-avoid-spurious-eio-20090526.) [13:01:48] configure would have mattered. none of those. [13:03:12] configure as in re-running configure rather than using the results of a previous build? [13:03:28] that, and the particular configure script which exists [13:05:35] I'm not sure what you mean there -- running configure from the wrong version of openafs? [13:06:31] --- abo has left [13:09:14] they are or are not building unpatched rc1? [13:09:34] --- Jeffrey Altman has become available [13:09:48] They're building 1.4.10 with some additional patches. [13:10:15] do any of them change osconf.m4? [13:10:21] It failed with straight 1.4.10 and succeeded with 1.4.10 plus those deltas, although I don't know if they had a crappy tree. [13:10:25] did they regenerate configure? (regen.sh) [13:10:28] did they rerun it [13:10:38] right, that's the key [13:11:01] When they upgraded to the 1.4.10 from sid, they would have gotten a regenerated configure since I do that as part of the package build. [13:11:20] Do you think maybe they were reusing configure results from a previous kernel when building the module with the 1.4.10 from squeeze? [13:11:36] Or hm, maybe had stray object files sitting around. [13:11:40] I'm going to ask him how he does the build. [13:12:44] ok [13:25:45] --- mdionne has become available [13:28:05] From memory, I think CONFIG_LOCKDEP brings in __rcu_read_unlock [13:29:01] --- stevenjenkins has left [13:32:25] your memory is better than mine; that sounds like it [13:35:39] --- stevenjenkins has become available [13:39:09] to be honest it was part memory, part e-mail archive. It's one reason OpenAFS doesn't usually build on Fedora rawhide - they enable lockdep. [13:45:29] derrick, does OS X keep logs somewhere of kernel panics? Or is there something I can do to figure out why I'm panic'ing? [13:50:15] /Library/Logs/PanicReporter; look in src/packaging/MacOS for a panic decoder [13:51:17] thanks [13:51:46] I mean, the "why" is "I'm bad a kernel coding" but that's unhelpful :) [13:52:10] I'm a little confused -- are contributions now supposed to be off the git repo, or off CVS HEAD? [13:54:07] no git repo was announced. [13:55:26] expressed differently: people keep being confused about git, which i don't understand since we said when the cutover happened we'd announce it. [13:55:55] speaking for myself, I'd probably miss the announcement. [13:58:48] I would guess people are worried about doing all this against CVS, and the switch will happen [13:59:10] but that's conjecture on my part [14:00:46] I don't know if the "The 1.5 branch is now dead." comment in the last newsletter is perhaps confusing [14:01:16] cvs head and cvs 1.5 branch were synchronized. the 1.5 branch is no longer receiving all updates. [14:01:34] all updates are going on the cvs head which will become the basis for the git trunk. [14:01:45] and 1.5.61 will be released off of the git trunk [14:03:56] doing work against CVS or git doesn't matter: a patch is a patch [14:04:33] if it would help, i could commit a patch which is the difference 1.5 to head onto 1.5 making them bitwise identical. [14:04:57] should we re-pull local cvs trees from head? or just wait until git? [14:04:58] $ rxdebug kvikklunsj.stacken.kth.se -v Trying 130.237.234.46 (port 7000): AFS version: OpenAFS 1.4.11pre1 built 2009-06-18 [14:05:20] you can cvs up -rHEAD a tree which is 1.5.x [14:14:01] haba: How did you get the dependency issue fixed? [14:14:11] Russ: gamake [14:14:14] gmake [14:14:45] Did you still need the ubik: sys dependency? [14:15:12] nope, gmake did figure it out somehow, freebsd make not. [14:15:17] Hurm. [14:15:24] 'cause looking at the code, making ubik depend on sys looks right. [14:15:29] udebug is indeed linked with libsys. [14:16:38] I think I blame either the freebsd make or how the Makefiles of OpenAFS are written. Just now I think we should just write "use gmake" in the release notes and move on. And I have 2 small patches which will come to openafs-bugs in a minute. [14:39:26] OpenAFS _does_ compile against 2.6.28. [14:40:23] /afs/cs.cmu.edu/misc/linux26/src/Config/PROTO contains a config I use which works [14:50:33] --- cclausen has become available [14:50:49] can someone here check on the status of www.openafs.org ? [14:52:22] --- matt has become available [14:52:48] gmake: yes. bsd makes aren't the only ones that have issues. [14:55:37] --- matt has left [14:59:55] pings for me. care to make an actual problem report? [15:00:02] Now 2 servers at Stacken with 1.4.11pre1 (on FreeBSD 6.1) [15:00:44] jhutz@jis.mit.edu/owl: can you get to the website? [15:00:47] jhutz: it pings, but actually trying to GET / doesn't respond [15:04:50] RT doesn't respond either [15:05:39] Well, since RT is the web server... [15:06:50] In any case, it looks like AFS is unhappy, possibly because it doesn't know about the MIT server change _and_ I moved the CMU server today. Maybe it'll be happier after a reboot. [15:18:47] If 1.5 is really dead and some updates are now going to head and not 1_5_x, that IMHO deserves a much clearer announcement somewhere [15:28:28] good night [15:28:53] --- haba has left [16:51:31] --- pod has become available [17:24:31] --- edgester has become available [17:27:12] hi everyone, someone is asking is I can provide download statistics in the newsletter. Does that make sense? Can we even track how many openafs downloads are done via AFS? [17:27:31] I assume its in the web server logs [17:27:43] although that would just be web downloads, not downloads from AFS [17:28:10] ya, but I'm concerned about leaving out the AFS downloads [17:29:51] audit logging could be enabled and those could be tracked as well [17:30:19] obviously, this isn't all that useful as some sites re-post AFS downloads locally [17:30:24] or have locally modified installers [17:30:51] I think the actual numbers would turn people away [17:31:22] as in not enough people downloading? [17:31:32] yes [17:31:42] AFS isn't like FireFox [17:31:45] My boss latched onto the fact that turnout for the workshop was low [17:31:48] you can't use it in a vacuum [17:31:58] well, that is due to the cost to attend [17:32:10] --- stevenjenkins has left [17:32:13] I thought it was the economy [17:32:33] the 2008 workshop had rrcord attendance from what I was told [17:34:17] The turnout for the workshop was higher than any previous west coast workshop. [17:34:40] There were various factors that made the 2008 workshop particularly attractive attendance-wise. [17:34:58] I wish I could have included that in the newsletter [17:35:28] --- stevenjenkins has become available [17:38:30] "across the river from lots of big financial afs users". "near major east coast international hub". [17:39:35] downloads via afs, incidentally, can't be sensibly tracked at this time. also, consider what happens if the "downloads" happen via a cached copy in afs remotely. [17:41:23] I kinda figured tracking downloads via AFS wasn't feasible [17:43:24] > If 1.5 is really dead and some updates are now going to head and not > 1_5_x, that IMHO deserves a much clearer announcement somewhere [17:43:35] you realize aside from build system differences they are the same, right? [17:49:22] i thought a few fixes from Jeff were applied to head only [17:55:09] i dunno. he went out to walk his dog, so i can't ask [17:55:11] or maybe I misread an earlier comment - can't check in CVS now [17:55:52] if they've diverged it's probably worth comment. [17:56:42] yes, if developers are working off 1_5_x, they need to know if it's no longer getting all deltas [17:56:45] (i've been committing everything to head and 1.5, because doing so is basically free) [17:57:48] i could give you a cynical take on patches from jeff not being in 1.5.x, but it would be just that: a cynical take [18:03:59] I thought I saw a couple of patches go to head only, but since CVS is down I can't check now. I'd be curious to hear the cynical take :) [18:07:03] apparently "rebooting" grand meant is also didn't come back up. i wish jeff would have left it alone. [18:07:21] ouch, that sucks [18:07:42] any plans to replace grnad? [18:07:52] why would one bother? [18:08:07] it's old [18:08:16] and? [18:08:21] on another subject - given that rxosd is already re-using the vnodemagic field in the on-disk vnode, can I presume there is no available field there, short of expanding the format [18:08:55] no other field was immediately apparent to me as available; i would not go any further than that [18:09:02] presumably, newer tools won't wokr on it [18:09:07] and? [18:09:21] how long does the hardware have to live? [18:09:46] its a vm [18:09:52] ah [18:09:55] sorry. let me ask a different question. what services does grand provide that you are concerned about? [18:10:24] as for download statistics, they are useless. [18:10:41] I'm concerned about the age of the OS version that it's running [18:11:09] because if the services are running today they won't run tomorrow if nothing on the OS changes? [18:11:41] Jeffrey Altman: I told David Boldt something like that re: download stats [18:12:17] yes, it is entirely possible that the system just stops working tomorrow [18:12:19] no, I'm concerned that security patches are no longer available for grand [18:12:20] --- deason has left [18:12:29] --- stevenjenkins has left [18:12:30] most large orgs that use AFS (at least on Windows) distribute transformed packages to their users that are pre-configured. [18:12:58] --- deason has become available [18:13:14] downloads via my web server out of the AFS cache would also not be counted. [18:13:22] --- stevenjenkins has become available [18:13:26] neither would the downloads from CNET [18:14:16] now if you want to have a phone home functionality in the client (which I suspect most people would object to) perhaps as part of an automatic update notification, then that would be a number that is worth viewing [18:14:56] a "phone home" stat would be interesting and objectionable [18:15:18] I can also tell you that based upon the number of reports I get from Microsoft, there are still a huge number of quite old OpenAFS clients out there on Windows. [18:16:11] ok [18:16:28] are those statistics posted? [18:16:40] i badly would like to add a phone home for updates in the mac client, and expect to get crucified if i try. [18:17:05] also, is the most recent OpenAFS for Windows status report really from July 2008? [18:17:06] microsoft crash report statistics are private information that are only available under a non-disclosure agreement. [18:17:20] yes it is. I have not updated it since then. [18:18:14] to be honest, there really hasn't been much new to say until recently (the Hot Fixes) and given the workshop and all of the other stuff that I've been trying to do I have not had time to rewrite it. [18:18:51] I figure that getting the protocol documentation up to date and planning for the RPC refresh is higher on everyone's priority list. [18:19:38] I'm not complaining, just making sure that I'm not missing something [18:20:01] now if someone else wanted to volunteer to review all of the RPCs and update the protocol docs (now editable in doxygen) and put together an enumeration of all of the issues that a 32-bit to 64-bit time conversion (among other things) would result in, please raise your hand. [18:42:13] ugh, I was trying to work on the admin guide, but having CVS down sucks [18:43:28] apparently grand is a windows machine. [18:43:37] LOL [18:43:48] well, it was broken, and the answer was to reboot, so... [18:43:55] wow, that's the best fake Linux machine I've seen [18:44:03] cygwin. [18:44:35] :( [18:50:15] good night [18:50:42] --- edgester has left [18:50:58] sleepy time? [18:51:07] or, oh yes indeed it's fun time? [18:51:14] my understanding is that jason has a long day tomorrow [18:57:16] sorry; i forgot to waych and make sure it came back up. grand is a vm; i will reset [18:57:34] if grand is not www, you can poke that too. [18:59:21] it is [19:17:04] There, all better. All it needed was a swift kick in the (virtual) reset button. [19:28:08] --- mdionne has left [20:48:43] I've pulled up all of my changes from head to 1.5 [20:49:10] however, it should be noted that there are several old commits that were sane that never existed on 1.5 that still exist on the head [21:34:54] --- stevenjenkins has left [21:39:26] --- stevenjenkins has become available [22:06:04] --- deason has left [22:29:30] --- cclausen has left [23:29:32] --- dev-zero@jabber.org has become available [23:29:35] --- dev-zero@jabber.org has left: offline