[00:33:22] --- abo has become available [00:33:22] --- reuteras has become available [00:59:40] --- Simon Wilkinson has left [03:06:11] --- jaltman/FrogsLeap has left: Disconnected [03:06:19] --- jaltman/FrogsLeap has become available [04:03:54] --- jaltman/FrogsLeap has left: Replaced by new connection [04:03:55] --- jaltman/FrogsLeap has become available [05:35:00] --- Chris Garrison has become available [06:42:07] --- Simon Wilkinson has become available [06:45:45] --- deason/gmail has become available [06:46:08] --- rra has become available [06:47:17] The intent of NEWS was to be that sort of changelog so that you don't have to include something like the complete VCS history. [07:16:00] --- mfelliott has left [07:16:08] --- mfelliott has become available [07:54:49] --- jaltman/FrogsLeap has left: Disconnected [07:54:57] --- jaltman/FrogsLeap has become available [09:08:36] --- reuteras has left [09:10:00] --- kaduk@mit.edu/barnowl has left [09:12:03] --- kaduk@mit.edu/barnowl has become available [09:12:42] --- steven.jenkins has left [09:16:23] --- steven.jenkins has become available [10:03:52] --- mdionne has become available [10:33:43] windlord:~> afsversion windlord Trying 171.67.225.134 (port 7001): AFS version: OpenAFS 1.6.0~pre6-1-debian built 2011-06-16 [10:33:46] Uploading nowish. [10:33:55] yay [10:34:10] Woo [10:39:33] We'll see whether someone has finally fixed GCC on arm. [10:47:51] --- Simon Wilkinson has left [10:59:22] Could someone approve the openafs-announce message I have pending, btw? I don't think it's been approved yet, at least. [11:04:39] --- summatusmentis has left [11:59:27] --- jaltman/FrogsLeap has left: Disconnected [12:06:11] GCC is still broken on arm. Yay. [12:07:19] ../vol/volume.c: In function 'VShutdown_r': ../vol/volume.c:1320:1: error: insn does not satisfy its constraints: (insn 1117 1116 669 56 (set (reg:SI 8 r8 [561]) (minus:SI (const_int 12 [0xc]) (const_int 5784 [0x1698]))) ../vol/volume.c:1409 29 {*arm_subsi3_insn} (nil)) ../vol/volume.c:1320:1: internal compiler error: in copyprop_hardreg_forward_1, at regcprop.c:767 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. [12:10:25] rra: when you get a chance, could you just say what's around volume.c lines 1320 and 1409? maybe there's nothing obvious, but maybe there's something weird there [12:15:44] There's no source diff at this point between the Debian packages and 1.6.0pre6, so what's tagged in the repo as 1.6.0pre6 is what it's trying to build. [12:21:07] ah, okay [12:24:57] Note that it only ICEs on arm; it's fine on everything else. [12:43:17] okay, yeah, I see nothing even remotely strange; those lines are the end of a function and a memcpy in a different function, so I have no idea :) [12:43:47] I'm building on an armel porter box right now so that I can run gcc with all the flags to generate preprocessed source. It takes a long time since, hey, armel. [12:44:03] I'm also going to try backing down the optimization and see if it then builds. [12:44:41] GCC 4.6 was way buggy on arm, which was rather annoying. It broke a bunch of my packages. [12:48:56] any chance the llvm compiler is any better? [12:49:09] No idea, don't use it. [12:49:27] Last time I checked, it wasn't really supported in Debian to use it to build real packages. [12:49:40] Although if anything I'd expect it to be even worse. [12:49:47] The problem isn't the underlying compiler architecture, it's that it's armel. [12:49:54] It's undertested compared to x86. [12:50:18] LLVM is likely to have that problem even worse, since GCC is the de facto standard for everything open source, and LLVM has a much smaller user base, hence even less penetration into the corner cases. [12:50:37] Like Derrick's cell phone. [12:51:16] Or car radio. Or whatever else he's porting OpenAFS to. :) [13:45:05] --- mdionne has left [13:59:57] --- Chris Garrison has left [14:14:37] --- summatusmentis has become available [15:09:44] --- deason/gmail has left [15:15:51] --- deason/gmail has become available [16:38:00] --- rra has left: Disconnected [17:04:18] --- Russ has become available [17:11:47] --- jblaine has become available [17:12:14] guys, I'm so sorry about my git "issues" [17:14:45] my recent push of what I thought was just my new TAP additions apparently pushed a patch set #3 for http://gerrit.openafs.org/#change,4827 [17:15:12] which should have been left alone at derrick's patch #2 [17:15:47] (it pushed #3 in addition to the new "change" for the TAP stuff, so, successful, but a little too successful) [17:20:58] oh, I can abandon #3 [17:24:45] I'd welcome anyone's input on what I probably did wrong there. [17:26:12] Was working directly on master, not a local branch. Made the changes for 4872 last week or so, committed, pushed to master. Made these new changes for TAP today, committed, pushed to master. So I obviously should have done something between those changes that I did not do. [17:26:59] Oh, I also did do git pull --rebase between the changes. [17:44:20] well, you don't have derrick's version of 4827 in your tree, but you have your updated version in your tree; so when you pushed, you submitted your new version of 4827 [17:45:14] if you don't want to touch it, either you need to make a new branch that just has the TAP tests stuff and not the 4827 changes, or you'd need to pull in derrick's ps#2 in 4827, and make your changes based on that [17:51:05] hm [17:52:11] as for what other developers do (or what I do and I think the others do), to avoid problems like that we make a separate branch for every conceptual "thing" that we want to do [17:52:29] so things that are actually unrelated don't show up as dependencies in gerrit, and we don't need to resubmit unrelated things when something changes [17:52:55] yes, that seems to be my failing [17:53:13] okay, so now I've pulled derrick's #2 [17:53:38] which isn't so bad, you do git checkout -b foobar origin/master for any new "thing" to work on, and you 'git checkout foobar' to switch between them [17:53:54] and the TAP stuff is already committed (only the correct stuff got put into that gerrit change, so it's all set) [17:54:21] well, if you just pull derrick's #2 and resubmit it, I don't think it'll accept it, but I could be wrong [17:55:10] I don't think there's a way to abandon a specific PS in a gerrit change; but after you pull in derrick's #2 you can 'git commit --amend' to make it look different [17:55:25] (even if you don't change anything, the commit time will be different, so the sha1 changes and it looks like a different commit) [17:58:17] ! [remote rejected] de1b2b1187c8e75100cf8d03cef157ce4e3cfb90 -> refs/changes/4827 (squash commits first) [17:59:13] that was from: git commit --amend; git push ssh://gerrit.openafs.org/openafs.git de1b2b1187c8e75100cf8d03cef157ce4e3cfb90:refs/changes/4827 [17:59:32] after restoring 4872 from abandoned state [18:01:32] where de1b2b1187c8e... was what git show showed me (comment: Merge commit 'refs/changes/27/4827/2' of ssh://gerrit.openafs.org:29418/open...) [18:02:51] So basically abandon 4872 and push current state to HEAD:refs/for/master, which will make a new Gerrit change encompassing derrick's stuff, eh? [18:03:48] if you have a commit that says "Merge commit" in the commit message, you did something wrong [18:04:16] I assumed that was from my pull of his p2 [18:04:35] don't literally "pull"; I didn't mean like a "git pull" [18:04:48] heh [18:04:56] you'd want to use the commands in the 'checkout' tab in gerrit [18:05:11] k, I used the ones in pull [18:05:14] cause you said pull :) [18:05:22] well, I'd modify it to git fetch http://gerrit.openafs.org/p/openafs refs/changes/27/4827/2 && git checkout -b something FETCH_HEAD [18:05:38] where 'something' is just a name you give the branch [18:05:55] after you do that you should be able to 'git commit --amend' and 'git push' [18:07:17] is there something that would be causing an inability to create a link table when doing a salvage? [18:07:45] full disclosure, I've modified salvager code, but it's not hitting that code path yet, from what I can tell [18:09:48] deason: WHEW [18:09:52] deason: thank you! [18:12:23] so, now then, I'll make new branches for any new changes, commit and push from those, and just wait out my local master's TAP changes which are not merged into remote master yet [18:12:57] it's making a little more sense now, but I'm feeling pretty stupid about it all [18:14:55] summatusmentis: like, it logs some error when trying to create one? or it never does but doesn't say why? [18:14:56] git made me feel stupid when I started with it to, for what it's worth [18:15:05] jblaine: yeah, we've all been there [18:15:16] that's comforting to hear [18:15:46] deason: logs errors. Gives warnings about VG ######## not having a link table, and then errors out on attempting to create them [18:16:26] gdb indicates it's specifically failing in namei_icreate [18:17:57] jblaine: something that might be helpful keeping track of what things are dpendent on what, and what your git tree looks like is gitk [18:19:00] I don't use it that frequently, but when I completely lose track of what my stuff is doing (or I'm mucking around trying to fix it), gitk can be useful [18:42:36] deason: any thoughts? or is it likely my codepath reading skills are poor? [18:44:55] "errors out"; what's the error? [18:45:16] Unable to allocate link table inode for volume 536870942 (error = 17) [18:45:53] which is EEXIST; so it's not correctly determining that there's no link table for some reason [18:46:11] does the link table actually exist? (volinfo) [18:48:03] what am I looking for in that output? [18:49:57] there's nothing I see that indicates anything about a link table, but I could be missing something [18:51:42] CreateLinkTable() calls IH_CREATE, which fails an if check for ENOTDIR or ENOENT, which is what causes the error printing to occur [18:52:19] my code should get called after that check, but we never get there, so I'm pretty sure it's not my stuff [18:55:34] --- summatusmentis has left [18:59:58] --- summatusmentis has become available [19:01:09] sorry, the fourth special inode is the link table, so the fourth thing when it says Inode 2309968394490740735: Good magic 99877712 and version 1 is the link table [19:01:22] so if it shows up like that ("good magic" and version 1), then it's there [19:02:42] yep, it's there [19:02:42] so that should indicate that FindLinkHandle didn't find the link table for some reason, which probably means the inode scan didn't include the link table inode [19:03:07] did I miss some of your responses when I disconnectd? [19:03:25] the volinfo output says what the inode number is, so you could look at the array of inodes, see why it's missing, and maybe see why listing all of the inodes in that VG didn't include it [19:03:42] no, I didn't say anything between the disconnect and reconnect [19:03:47] mk [19:04:19] or maybe it is in the array of inodes, but the type is not accurate? or something, I don't know [19:06:03] wait, I didn't quite follow that. the volinfo output lists 3 sets of 4 Inodes with good magic. is that what I'm comparing the the big-ish list of VG #s from the Salvager log? [19:07:29] wait wait wait, what are the first few lines of the volinfo output? [19:07:53] I'll pastebin all of it [19:08:22] http://pastebin.com/CMrZByEx [19:10:38] no sorry, you want the volinfo output specifically for the volume you're looking at [19:10:46] which is output via 'volinfo /vicepX ' [19:11:26] er, but, well, if that's all of the volumes on that server, then it's in there, too [19:11:52] hold on, I"m not sure what that is. This server has a single volume on it, and is the only server in the cell [19:12:33] so yeah, the 4th "Inode" line is the inode number for the link table for that volume [19:12:44] wait what, you have two root.cell volumes on there [19:12:54] I'm just recognizing that [19:13:39] that shouldn't confuse the salvager or anything, though; it doesn't really look at the name [19:15:46] alright, let me delete one of these, and go from there [19:23:01] ok, inadvertantly deleted both, recreated one [19:24:39] ok, so on root.cell, the 4th Inode entry is the link table. Where am I comparing that? [19:27:53] wait, vos listvol is showing 3 root.cell now [19:30:04] oh, zap, not remove [19:32:11] so, it seems that the volume that is failing has an id that doesn't match anything vos listvol is showing [19:33:21] however, http://pastebin.com/SX8Trhf8 [19:33:26] that's the new root.cell [20:14:48] well, it's doing the actual salvage.... [20:14:54] (sorry, I had to deal with something else for awhile) [20:15:11] the FSSYNC error message says that you sent an fssync message to the fileserver that the fileserver didn't understand [20:15:34] I believe the fileserver will log everything about all fssync requests it receives at debug level -d 125 if you want to see what it is [20:15:59] --- Russ has left: Disconnected [20:17:23] > you sent an fssync message to the fileserver er, where "you" are the salvager :) [20:20:17] right :) [20:21:03] I'll see what I can figure out about the FSSYNC stuff, that's less related to my code path [20:34:29] --- Russ has become available [21:39:05] --- Russ has left: Disconnected [22:34:21] --- deason/gmail has left [22:52:58] I thought we had added tools.git to gerrit? [22:53:48] Or did we only talk about doing so? [22:54:11] (Bjoern has been pestering me that 'Free BSD' has a space in it on the release distribution pages.)