[00:03:06] --- lars.malinowsky has left [00:24:06] --- reuteras has become available [00:51:28] --- lars.malinowsky has become available [02:01:34] --- reuteras has left [02:12:26] --- lars.malinowsky has left [02:12:40] --- reuteras has become available [02:31:49] --- reuteras has left [02:39:43] --- sxw has become available [03:25:12] --- reuteras has become available [03:27:34] --- reuteras has left [05:38:07] --- lars.malinowsky has become available [06:26:13] kaduk_mitedu: huh, would it be tricky to get that going on a userland-only platform? [06:30:18] or to do it as a for-my-information-only sort of thing? [06:34:26] or maybe i just want to do this as post-merge testing instead of pre-merge [06:52:26] ah, sunos does it userland only [06:57:03] --- lars.malinowsky has left [07:21:54] hmm, afsio.c [07:22:11] what about it? [07:22:49] seems it doesn't have a propper path in the makefile [07:23:43] src/venus/Makefile.in that is, it's just "afsio.c" instead of ${srcdir}/../venus/afsio.c [07:25:39] Well ${srcdir} == {$srcdir}/../venus [07:25:54] uh, no, those other files are ${srcdir}/../.... because they aren't this directory. it should be... ${srcdir}/afsio.c [07:25:55] oh, then why couldn't it find afsio.c? [07:26:07] You're doing on objdir build, right? [07:26:10] So == shadow [07:26:26] sxw: yeah [07:27:03] We don't currently have any buildbot coverage for objdir builds, so things like this unfortunately slip through [07:27:10] get past that ... make: don't know how to make ../../../openafs/src/venus/../vlserver/vldbint.cs.c. Stop [07:27:32] well, that implies a missing dependency on vlserver [07:27:54] since i promise you if src/venus/afsio.c exists, that's the right place for the vldbint.cs.c file [07:28:36] huh. shouldn't be. venus->libafscp->vlserver [07:28:48] Wrong path. [07:29:01] vldbint.cs.c will be in objdir, not srcdir. [07:29:19] oh right. generated. [07:30:17] --- Jeffrey Altman has left [07:31:17] gerrit 4508 [07:32:21] I think you're missing some changes there. [07:32:47] (vldbint.cs.c is still in srcdir ... ) [07:33:56] er, wtf. i guess i didn't git add. [07:35:27] now [07:35:42] afsio.o: afsio.c ${AFSIO_INCLS} AFS_component_version_number.c [07:35:57] should the afsio.c in that like be adjusted too? [07:36:00] nope [07:38:05] Make is clever enough to handle checking for dependencies in both the src and object directories [07:38:43] ah, that "feature" :-) [07:42:27] --- mho has become available [07:44:26] --- deason has become available [07:48:25] tell me if you now build and i'll merge. i pushed that at the end of some things which have issues, i forgot to rebase to head [07:48:29] er to master [07:51:26] the review of patch set 2 was done after a build [07:51:37] *my review [07:52:24] ok. [07:52:27] well, i pushed. [07:55:24] feh, i cherry picked that before i did a commit of my changes [07:56:29] judging from past experience, i don't dare try to fix this myself :-) [08:09:11] --- lars.malinowsky has become available [08:36:23] jakllsch: did you answer your question about buildbot, or do you want more information still? [08:37:00] i'm not sure i care anymore. i keep gitting into a bad mood. [08:38:09] dude, after being a cvs user for years, writing cvs tooling, and surmising how you could do third party branching in cvs (and figuring out how to build the tools), git, while flawed, is fing paradise to me [08:38:56] cvs is also harder to fit into puns :) [08:39:32] shadow_gmailcom: you must not have the predisposition to inflexibility i do [08:40:11] i have a mac in front of me. on that screen are 8 tiled 80x24 xterms, and i have been using tiled 80x24 xterms since 1992. i'm very flexible. [08:40:25] heh :-) [08:41:04] i adapt to the current screen size of whatever is in front of me. so, somewhere between 4 and 9 xterms (9th xterm's space is consumed by an alternate IM client at the moment) [08:41:12] so, yeah. very flexible. [08:43:06] okay, so how long did it take you to get used to git? [08:43:45] i am still not a git expert. but for most things i need to do, it works. probably 2-3 weeks. [08:44:34] seems like anything i do i end up screwing up and needing about 4 times the original amount of time to fix [08:45:51] In my experience, the fundamental problems that folk have with git are conceptual ones. In particular, the fact that commits are atomic, and tree-wide, and the fact that history is immutable. [08:46:21] --- lars.malinowsky has left [08:51:01] Oh, course, having the ability to rewrite history does make the "history is immutable" part a little harder to wrap your head around. :-) [08:51:25] It also took me 2-3 weeks to become comfortable with the git mindset. [08:51:37] Yeah. The critical thing is to realise that you aren't rewriting history, you're making a new copy of everything that inherits from the object you change. [08:51:52] Parallel universes, if you like. [08:52:40] --- lars.malinowsky has become available [08:52:49] I would call it "commits are immutable" myself; sha1 fd7eda9 always always refers to the same thing [08:53:52] Yeah, but that also always refers to the same history. [08:54:23] Where lots of people become unstuck is when they rebase, and wonder why all of the places that pointed to commits within the rebase range haven't magically moved to point to their new commit. [08:56:15] It's best not to rebase things that have references to them. [08:57:24] That way, you're less likely to become unstuck in time. [08:58:24] well to me, "history" means like, the history of a branch, or what I see in "git log" etc, which can change all the time [08:58:52] What the name of the branch points to can change; this is at the core of what is probably confusing you. [08:58:55] the history of a certain commit is immutable, sure, but it's just part of the commit [08:59:53] What you see from git log will never change. What you get with git log will change if you've changed where that branch name references. [08:59:57] --- Russ has become available [09:00:01] In the real world, "History" changes all the time, but is append-only. Modulo alternate universes and parallel timelines, of course. :-) [09:10:27] I wonder when anyone last looked at our refrigerator stuff. I can't see where we're calling set_freezable, so I doubt any of our threads are ever frozen. [09:16:23] Oh, that's probably true. I'm not sure that's fatal, though. [09:19:10] If we're not freezable, I'm not sure why we ever needed to call the refridgerator. [09:23:44] For one, I don't think kernel threads used to be nonfreezable by default. Further, we need to call the refridgerator because we run in the context of user threads that might be freezable. [09:24:05] Yeah. I had wondered about the latter. [09:24:30] I'm just trying to rationalise our current event structure so that we just use wait_event_freezable() [09:43:52] --- lars.malinowsky has left [10:13:10] --- lars.malinowsky has become available [10:20:25] --- jaltman/FrogsLeap has left: Disconnected [10:21:13] --- jaltman/FrogsLeap has become available [10:23:05] --- jaltman/FrogsLeap has left: Disconnected [10:28:36] --- jaltman/FrogsLeap has become available [10:31:16] --- lars.malinowsky has left [11:48:39] i just wish i could get my head around it :[ [12:38:02] the last change to AFSLore/GitDevelopers added link spam, what's the best way to undo that? [12:39:36] I think Russ has usually just done it via git and git revert. [12:39:50] I thought there was a way to do it over the web, but I can't see anything plausible. [12:40:17] git! your favorite! [12:41:08] Looks like the newest version of ikiwiki will support web based reversion, but I suspect we're not running it yet. [12:41:55] --- asedeno has become available [12:43:50] Come to that, I don't even know where to push to to manipulate ikiwiki from git. And I think Russ is on vacation ... [12:53:33] --- ksumner has left [12:53:49] shadow_gmailcom: you around? problem has showed up again. gcore to grab the core again? [12:56:52] phalenor: He is around, I believe. [12:57:05] yeah, he got me in private msg [12:57:53] using just the core, see if you get a hostList with gdb this time [13:00:38] gdb is dying again with, dwarf2read.c:2736: internal-error: process_die: Assertion `die->child == NULL' failed. [13:02:39] Of course, you'll be building with Solaris Studio. [13:02:48] dbx seems a little better, I can at least print hostList [13:03:25] Yeah, at least your debugger and compiler are matched, then. [13:04:29] and at least my binary and core are matched. that was the issue yesterday, the binary wasn't built with debugging symbols, but it is now. [13:04:57] and the gcore didn't pause things, so my tokens still aren't working [13:05:19] Cool, which means that the problem should be in that core,. [13:07:28] I'm just glad it's showed up 2 days in a row... [13:09:05] well, next thing, is rxdebug the server and find your client's connection to get the epoch and cid [13:09:22] --- andersk has left [13:10:36] eh... rxdebug -long ? [13:10:52] oh, allconnections [13:11:46] it's something/something ? [13:12:55] Cuid %x/%x where those are epoch and cid in hex, respectively [13:14:34] --- andersk has become available [13:15:25] ok, so it's one of these 3 [13:16:37] ideally you want to walk the host list and find the stuct host which is your host and port [13:16:45] your ip, port 7001 since no nat in play [13:17:14] like, you'll be using the ->net to get to the next one [13:17:28] but i can't tell you off the top of my head what dbx wants [13:17:30] I see [13:17:48] something like this, print *(struct host*)&hostList [13:18:46] the host field, what format is that? [13:19:13] net order [13:19:30] ip as an int32 [13:19:46] yeah, so for you, byteswapped. [13:20:14] you could also break in SRXAFS_FetchStatus or something if you just want the host/client it's getting for you [13:20:33] what would 128.118.200.11 be then? [13:20:42] my fear is if you attach for real with dbx you'll cause "server down" long enough that your client will make a new connection and the problem will go away, so i figure the correct answer is to do whatever with the core first [13:21:28] c80b8076, i tink [13:24:35] 0BC87680 [13:25:01] hmm, must be looking at the wrong thing then [13:25:18] I'm seeing things like, host = 197686912U [13:25:35] thats in decimal. [13:25:53] er, that's "it" in decimal [13:25:59] right, ok [13:26:37] ah, that is it [13:27:01] what flags on that struct host (and is port 7001)? [13:28:14] http://pastebin.com/ZeLBvWhh [13:29:05] so, not HOSTDELETED. good. [13:29:28] I see 3 connections from this host, though. guess I should keep walking [13:29:51] however, CLIENTDELETED is set. [13:31:20] well, the way you'd find the right one is walk host->FirstClient and look for the sid and VenusEpoch in the client that matches your rx conn. and hopefully you find exactly one. and i suspect you find 2 [13:31:34] maybe in 2 different struct hosts, if there's a bug that causes that [13:31:53] well, there's going to be cleanup to be done, and some portability [13:32:01] ahh [13:33:25] --- jakllsch has left [13:33:49] --- jakllsch has become available [13:36:45] the real fun is how to get the pthread rock (e.g. getspecific) for the rx connection from the core [13:37:09] you want to see the client structs for this host? [13:37:21] yeah. [13:38:06] --- shadow@gmail.com/barnowlA9683AD7 has left [13:39:15] /afs/bx.psu.edu/user/phalenor/public/clients [13:39:39] er, firewall, one sec [13:40:18] --- Derrick Brashear has become available [13:40:22] er, hmm. [13:40:36] nice. "[Error] We failed to connect." from my jabber client. sigh. [13:43:07] --- shadow@gmail.com/barnowl1CD2CB82 has become available [13:43:12] --- Derrick Brashear has left [13:43:54] ah, that IP used to belong to a vmware hypervisor management console. [13:45:55] now this will work, in case you missed it. /afs/bx.psu.edu/user/phalenor/public/clients [13:52:59] well, what cid/epoch is your conn? [13:54:50] it's one of the ones from 128.118.200.11, /afs/bx.psu.edu/user/phalenor/public/fs7.rxdebug [13:55:30] er, it's not bdb0631b/369d2cc8 [13:55:57] er, maybe it is. you'd know more than me. [15:06:27] --- andersk has left [15:35:00] --- andersk has become available [16:11:32] --- deason has left [20:17:53] --- jhutz@jis.mit.edu/owl has left [22:53:12] --- Russ has left: Disconnected