[00:11:16] --- kaj has become available [05:15:27] --- Simon Wilkinson has become available [05:36:04] --- jaltman has become available [05:42:57] --- jaltman has left: Disconnected [05:43:06] --- jaltman has become available [05:55:00] --- Simon Wilkinson has left [05:56:43] --- jaltman has left: Replaced by new connection [05:56:44] --- jaltman has become available [06:31:40] --- Jeffrey Altman has become available [06:35:37] Ben, what Jason is looking for is the list of developers that are actively performing the work. [07:03:48] --- mho has left [07:16:30] --- reuteras has left [07:33:33] --- deason has become available [07:35:09] I think ben is talking about a status report submitted to FreeBSD, not OpenAFS (though imo the latter would be good to have, too, but I know less about the process/conventions for the former) [08:15:38] --- jaltman has left: Disconnected [08:15:45] --- jaltman has become available [10:00:44] --- kaj has left [10:02:33] --- jaltman has left: Replaced by new connection [10:02:33] --- jaltman has become available [10:06:01] --- mattjsm has become available [10:30:29] yeh, FreeBSD Status Report is a regular update about the FreeBSD Project. [10:32:22] Yeah, this is a monthly report that FreeBSD puts out. [10:36:57] --- rra has become available [10:44:22] --- Jeffrey Altman has left [10:55:20] --- jaltman has left: Disconnected [10:55:31] --- jaltman has become available [11:00:50] --- Jeffrey Altman has become available [11:09:01] --- Jeffrey Altman has left [11:31:57] --- jaltman has left: Replaced by new connection [11:31:58] --- jaltman has become available [11:39:44] --- kaj has become available [11:55:17] hm, I was under the impression that hudson only had good integration with java-y build systems; I suppose that's not true? [11:55:35] or at least not true to the degree where it's prohibitive for us [11:56:09] hudson actually looked like it'd work pretty well mod the lack of gerrit integration to the extent we needed [12:00:53] is there a list of prereqs for build slaves somewhere? google and clicking around hudson-ci.org is failing me [12:10:29] http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-OtherRequirements [12:10:46] was the closest i saw, and is incomplete [12:11:04] (sorry, inadvertantly sent instead of inserting a newline) [12:21:30] also, I cannot reach hudson-master.rampaginggeek.com:8080, if I'm supposed to be able to [12:22:00] i bet it's not poked through [12:45:04] --- Simon Wilkinson has become available [12:46:18] --- Simon Wilkinson has left [12:46:23] --- Simon Wilkinson has become available [12:47:11] If Jason is looking at Hudson, then we really should be using the Hudson plugin that uses event streams, rather than the one which triggers from git pushes. [12:48:06] he's clearly looking at it, look at recent pushes :) [12:51:21] Yeah. Just spotted all of that. Really need to get him a daemon account to do the Hudson messages from, if only so that folk can filter them to /dev/null [12:53:03] he's clearly experimenting, but, yeah.... [12:54:13] If we end up building every commit for (say) Linux, Mac OS, Windows and Solaris and each build has a started and completed message ... [13:31:39] I would prefer the buildbot integration that now exists as we already have a buildbot client on Windows [13:46:59] an issue that came to my attention today was the introduction of the preprocessor symbols S_IRUSR instead of S_IREAD and S_IWUSR instead of S_IWRITE by the AFS_DEMAND_ATTACH_FS code. S_IRUSR and S_IWUSR are not supported in the C RTL although S_IREAD and S_IWRITE have been deprecated on UNIX. As the DAFS usage is the only usage in the tree, do we want to replace them with the older BSD compatibility symbols? [13:51:10] If other bits of the code use S_IREAD and S_IWRITE, then I think we could be consistent and use them everywhere. [14:23:01] for building both dafs and non-dafs threaded binaries. are we going to create new src/dafs_viced and src/dafs_volser directories? Or are we going to build both sets of executables within the src/tviced and src/tvolser directories? I prefer the src/dafs_viced and src/dafs_volser approach. [14:23:43] the alternate directories approach is fine if they contain only makefiles [14:24:06] they don't for Windows which is why I prefer the alternate directories approach [14:24:21] uh. why not? [14:24:32] I don't like the names, but alternate directories does seem like the option most in keeping with the rest of the tree. [14:24:33] on Windows there are version specific resource files [14:25:07] expand on version. because, i think 1.5.75 better be 1.5.75 in both cases, and i assume you mean something else. [14:25:13] src/tviced already differs from src/viced for DAFS by the inclusion of new source files [14:25:21] also, there are no such files now in tviced? [14:25:38] yeah, the underscores can suck it [14:25:42] the lack of them in tviced is a bug [14:25:53] see tvolser/volserver.rc [14:26:08] we have no underscore or dash directories today. keeping it that way: seems fine [14:26:24] I really would like to see us do away with extraneous directories in which we maintain a separate Makefile and build everything again with slightly different options. But that's not for now. [14:26:29] Looks like we need to conditionally build bits of vol as well [14:26:36] jhutz: not for 1.6 [14:26:41] not for 2.0 [14:26:45] src/vol is already being build in multiple ways [14:27:04] The presence of source files in src/tviced is a bug. [14:27:05] Really, we need to discover how to write code that has _runtime_ options. [14:27:29] well, the source files in tviced are "threaded world only", so it's subjective. could go either way [14:28:05] they are DAFS only too boot so I would move them into the new DAFS directory or back to src/viced [14:28:09] now, that said, some of those are, worse than that, dafs only [14:28:16] yeah. [14:28:23] so we can and should move them [14:28:57] > we need to discover how to write code that has _runtime_ options. Well, yes, and that is the right answer for tviced vs dafs_tviced. But there's not much we can do about viced vs tviced, since "is compiled and linked with -pthread" is not really a runtime option. [14:29:02] --- abo has left [14:29:07] the rc file looks like it could be built by the makefile pretty easily. wait. no. it's volserver.rc. don't care. new thing is not called volserver. [14:29:08] It would a lot easier if there was a single source directory, even if some of those files aren't built for every type of object built from that source directory. [14:29:12] --- abo has become available [14:29:23] rathole. [14:29:42] --- meffie has left [14:29:54] Not "single across the tree", but "git mv tviced/*.c viced/" [14:30:22] serialize_state.h also [14:30:26] ==sxw [14:30:29] and then the makefile needs to be fixed [14:30:33] so.... [14:30:46] Yeah. I wasn't proposing that as a patch, more an indication of what I meant. [14:30:54] if someone wants to submit it before i get to it, go nuts [14:31:07] i will get to it. i am trying to test all the shit we promised [14:31:42] if someone submits for UNIX with new names I will fold in the code necessary to get DAFS to build on Windows. although there will be no guarantee at this point that it will work. [14:32:14] I won't get a chance before the weekend. [14:32:16] --- Kevin Sumner has left [14:32:19] separate dirs: yeah, that was the idea; I was wondering about doing subdirs inside viced et al, but I suppose that's rather big [14:32:40] and S_IREAD/S_IWRITE: nothing used those either? so this is kinda ick [14:32:45] --- Kevin Sumner has become available [14:32:52] subdirs: please no. [14:32:58] not now anyway [14:33:07] --- meffie has become available [14:33:07] Windows could just #define S_IRUSR S_IREAD [14:37:24] names for new dirs... dtviced, dviced, viced.dafs, dafsviced? not sure if that "no dash/underscores" above implied "no separators in general" [14:38:02] dviced would be my vote. [14:38:24] What restrictions does Windows impose in terms of directory names and lengths? [14:38:47] dviced. [14:38:52] ==shadow [14:38:58] dviced, dvolser [14:39:02] for FAT, 8.3. for non-FAT, nothing that we would care about [14:39:11] our longest one in that dir is already shlibafsauthent, I think, so I'd assume we'd be okay for length [14:39:17] dafsviced: kill me. viced.dafs: i kill you [14:39:21] --- mattjsm has left [14:39:50] src/viced_DAFS/ ;) [14:39:59] dtviced: a plague on both your task groups [14:40:03] it needs a dot [14:40:29] or no, I meant tviced_DAFS [14:40:39] it definitely needs a dot [14:40:44] huh? [14:40:58] tviced._-DAFS [14:41:14] Why don't we put a colon and/or slash in it, for good measure? [14:41:25] use both. electrons are cheap [14:41:28] A space. I really think our directory names need spaces in them. [14:41:32] Space is free, right. [14:41:40] rot13 [14:41:46] newlines [14:41:48] tviced._/\-:DAFS [14:42:11] \-: is right [14:42:14] "and what do you call this software project?" "GNU/aristocrats!" [14:42:15] And, lets face it, paths that fit in an 80 column display are for whimps. [14:42:36] --- Kevin Sumner has left [14:42:38] --- meffie has left [14:42:42] --- abo has left [14:42:57] How about The\ shiny\ new\ demand\ attach\ fileserver\'s\ home\ in\ our\ tree [14:43:07] --- Kevin Sumner has become available [14:43:09] src/afs-demand_attach\\file.service [14:43:13] Or dviced, for short. [14:43:19] --- abo has become available [14:45:35] --- Simon Wilkinson has left [14:49:26] --- meffie has become available [15:55:20] If I say we could call the directory John_-_Winston, I bet no one here would have any idea what I was talking about. [16:36:11] --- deason has left [16:39:31] --- jaltman has left: Disconnected [16:57:35] --- dwbotsch has left [16:57:47] --- dwbotsch has become available [17:02:22] --- steven.jenkins has left [17:03:39] --- jaltman has become available [17:05:13] --- steven.jenkins has become available [17:15:34] --- steven.jenkins has left [17:16:24] --- steven.jenkins has become available [18:43:18] I guess that what I was really asking was: "Derrick and Matt, would you like to be listed in the FreeBSD report?" [18:44:03] This, of course, doesn't work as well when Matt isn't here. [18:52:10] what makes you think Derrick is here? [18:53:53] Derrick reads the logs. [18:54:00] fool [19:15:16] "So, is that a 'no'?" [19:24:07] you can list me. you've done more than me of late [19:38:20] --- jaltman has left: Replaced by new connection [19:38:21] --- jaltman has become available [20:44:55] When attempting to push changes to gerrit, I'm receiving: fatal: internal server error fatal: The remote end hung up unexpectedly Would someone with bits take a look? [20:47:05] well, either that worked, or we are now sadder [20:47:17] oh yeah. sadder. [20:48:13] restart-gerrit apparently does so, but only loosely [20:52:31] I wonder if pushing multiple changes at once is interacting poorly with hudson [20:57:50] could be [20:59:42] Should be fixed now. [20:59:47] At least at the basic level. [21:00:32] lets see if we fall over again [21:01:47] not this time [21:03:39] thanks for fixing [21:04:45] I really need to figure out why restart-gerrit doesn't work. [21:04:50] I do the same thing by hand as root and it works fine. [21:07:43] Stopping Gerrit Code Review: OK su: Authentication service cannot retrieve authentication info (Ignored) Starting Gerrit Code Review: OK have anything to do with it? [21:07:53] Shouldn't. [21:08:42] make the script do sh -x to a file? [21:24:22] --- Born Fool has become available [21:29:10] --- rra has left: Disconnected [22:40:51] --- reuteras has become available [23:14:12] --- kaj has left [23:53:53] --- Born Fool has left