[00:12:34] There. That's the last major Debian patch done properly. [00:17:07] I'm done with marcus' list [00:17:26] You've just done his "Interesting things" bit, right? [00:19:01] yes [00:19:02] Russ: Does change 92 change the installation location for the message catalog? [00:19:58] No. With make dest, it's still in the same place as always. [00:20:09] I was tempted to get rid of the C subdirectory, but decided to keep things in the same spot. [00:20:39] Yeh. Just checking it wasn't going to break the RPMs. [00:20:50] i reall yshould sleep, but i just want to finish one more thing. sigh. [00:21:04] Nope, should be fine. [00:21:07] I was thinking you lot were burning the midnight oil! [00:21:17] --- agoode has left [00:21:24] --- agoode has become available [00:21:25] Yeah, I really should have been asleep a long time back myself, since I was trying to be on east coast time. [00:21:29] I suspect this isn't going to work. [00:23:18] reply to marcus sent [00:23:30] why are you trying to be on East Coast time? [00:23:52] i am trying to get the 10.6 build building again, but the changes to the MakefileProto are sort of ugly, ignoring the broken linker issue entirely for the moment [00:25:49] Going to Michigan Sunday. [00:25:59] funny, me too [00:26:24] I haven't decided yet [00:26:45] What's in Michigan? [00:26:50] Cartel [00:26:54] Ah. [00:26:59] sadly not the band [00:27:48] I'm not sure yet what to do about RT #125101. [00:28:04] but its too big an issue to deal with tonight [00:32:38] Okay, all the fixes from Marcus's patch set are submitted. [00:35:34] thanks [00:35:47] I'm calling it a night. [00:37:35] Yeah, me too. [00:42:01] yeah, ok, maybe i have my answer [01:10:02] --- dev-zero@jabber.org has left [01:12:23] --- Russ has left: Disconnected [01:38:00] --- dev-zero@jabber.org has become available [02:49:17] --- haba has left [04:50:19] --- sxw has become available [04:57:32] --- haba has become available [05:33:07] --- Jeffrey Altman has left: Replaced by new connection [05:35:47] --- sxw has left [06:22:45] --- sxw has become available [07:00:50] --- Jeffrey Altman has become available [07:05:16] --- sxw has left [07:08:17] --- deason has become available [07:20:01] the 10.6 vm turns this damn thing into a torch. [07:51:02] --- reuteras has left [08:03:15] --- sxw has become available [08:08:56] Just building OpenAFS is enough to make this thing burn its way through my leg. [08:10:41] --- sxw has left [08:17:14] --- asedeno has left [08:17:24] --- asedeno has become available [08:25:58] --- haba has left [08:37:45] either gmake or lipo changed between 10.5 and "later than 10.5". sigh. guess i need to find a new trick for building the kernel module [08:52:12] > I was tempted to get rid of the C subdirectory Isn't that directory level a locale name? [09:24:57] well, this will either work, or explode [09:25:13] --- Russ has become available [09:27:24] jhutz: Yes, it's a locale name, but because of how we're using catopen, that turns out to not matter. [09:27:48] It might matter eventually if someone actually internationalized fstrace, but if someone wanted to internationalize AFS command messages, that's not where I'd start and there are lots of other problems. [09:29:12] i started out unsure why the multiple apple binary object types were not built like linux MPS for kernel modules, then lipo'd together. i understand now [09:35:27] http://bugs.debian.org/537098 is someone who's chrooting into AFS and getting completely bizarre behavior. I'm not quite sure how to make head or tails of it, and would appreciate other perspectives. [09:35:59] He says something broke for him between 1.4.2 and 1.4.7. [09:37:57] same kernel, only thing changed was openafs? [09:52:59] No, it would be a different kernel too. [09:53:03] Upgrade from etch to lenny. [09:54:36] so that's not a useful bug report other than "it's broken". yes. yes it is. [09:54:49] Yeah, broken in really odd ways. [09:55:02] I particularly don't understand the latest message, which implies some sort of multi-client corruption. [09:59:21] --- mmeffie has become available [09:59:50] would a separate manpage explaining -auditlog and (soon-to-be) -audit-interface make sense? [10:00:00] keeping track of the same options in like 8 manpages seems... suboptimal [10:04:46] Unfortunately, from the reader perspective, having to go to a separate man page to see another option for the command one is immediately concerned about is also suboptimal. [10:04:56] I think this is a place where we should take the hit for the end user. [10:06:14] * Russ wastes time claiming project contributions in Ohloh. [10:08:34] yes, but there's potentially quite a bit of text to put there that will change... I'd like to be able to just say 'see fileserver(8) for an explanation of each interface' or something, if possible [10:19:30] Hm, yeah, that makes sense. "Supports the same options as the File Server, see fileserver(8) for the details." [10:30:45] what I did is in change 82, if you wanted to look at the pod changes [10:31:53] you mean, perspectives other than "don't do that" ? [10:33:50] Should we just tell people not to chroot into AFS? [10:34:03] This did used to work. We did it at Stanford back when the world was young and the dinosaurs ate the sheep. [10:40:29] The latest message sounds like his root.cell is corrupted somehow. As for the getcwd thing, I'm not sure what causes that -- normally, we shouldn't be involved. Unless the FTP server is doing getcwd other than by calling the kernel's syscall by that name, in which case it might indicate we're doing something with .. that confuses chroot [10:41:43] --- agoode has left [10:43:16] If it calls the kernel syscall, that should be fine? [10:44:56] shadow: Did you want to check anything further with the SIGSYS change or should I go ahead and submit it? [10:45:22] --- agoode has become available [10:45:50] well, we should verify that it doesn't break 10.3, but you might as well fire it. [10:46:22] yeah, if you don't have the ability to do that, I'm not sure we should wait for it. And it seems hard to see how it could. [10:49:09] If it calls the kernel syscall, I don't see how we can break it [10:49:26] Yeah, just adding a SIGSYS handler should be fine. [10:49:46] fire it [10:51:25] --- agoode has left [10:51:36] --- agoode has become available [10:57:38] --- agoode has left [10:57:50] --- agoode has become available [12:17:24] I wonder how feasible it would be to show up in Ann Arbor on Tuesday [12:17:48] i plan to show up there sunday night [12:18:03] I can't do that [12:18:14] I might be able to fly out first thing Tuesday morning [12:18:30] or perhaps last flight Monday and return Tuesday night [12:18:33] * Russ will also be showing up Sunday night, FWIW. [12:42:09] Wow. [12:42:28] * Russ decides to not reply to Tom's message right now since if I do I'm going to rip his head off. [12:43:19] i did. [12:44:42] That's a much better response than I would have managed. [12:44:53] I suspect he didn't realize how aggressive and personally insulting that message came across as. [12:45:11] i notice people (no one in particular) continue to not address the point of "stable needs to be stable. except for my change." [12:45:19] like, no one has commented on that at all [12:45:56] the "pleasure" of being a gatekeeper: getting to hear about it from both sides. [12:55:00] ok. mod the bug in xcode i just pushed to apple, change 96 is now useful on 10.5 and "later than 10.5". [13:00:22] * Jeffrey Altman is still in ripping heads off modd [13:00:25] mood [13:04:59] amtrak 30 hit something at a crossing in indiana, and is apparently 12 hours late, with replacement (NS) power. guess i should find my way downtown. [13:05:01] er, mix. [13:05:35] * Russ is trying not to react unless there's something productive that I think I can get out of it. But it's hard. [13:07:16] what I would like to get out of it is knocking home the point that sitting in a closet for two years working on code outside of the community is not a good mechanism for seeing that work be integrated upstream [13:07:24] --- summatusmentis has left [13:10:40] google does something very smart. if you send e-mail to a mail alias that is configured to use gmail, they deliver it directly to the gmail account and do not send it to through the MX server for the aliased account's domain. [13:10:59] yeah, well, that's entirely sensible [13:17:28] > stable needs to be stable, except for my change." -- that's a hard problem. Would it benefit from focused attention on the various users -- ie, discussions of 'what needs to happen for you to start testing and adopting 'master'? [13:17:54] it might. part of the problem is it's developers who take that position [13:18:32] The best way of solving this problem that I've seen in other projects is to do what I've been arguing for: stop making huge changes. It really is mostly avoidable. I know that doesn't help with the existing stuff, but if the design doesn't allow for gradual evolution of the current design into the new design, I would argue that this is frequently a design problem. [13:19:05] The giant #ifdef switch is inherently hard to test. [13:19:05] i understand why you do your change for the version you feel comfortable running. i wish you (both yous are the general you) understood why i'm not going to force it on everyone else who also wants the stability, and why i'm not going to do all the work again myself, especially for something large, to push it to the head. [13:19:51] AFS needs to have about 90% fewer #ifdefs than it has now, on a lot of fronts, too. [13:20:32] In fact, I want stable to remain stable precisely so I _can_ maintain my change without getting it integrated. But then, I don't expect people to review and integrate changes that I'm keeping to myself [13:20:38] gerrit's need for unsafe reloads (xss) bothers me [13:21:18] the issue is the people who want stable to remain stable, except, hey, commit my large change so i can stop maintaining it! [13:21:20] jhutz - don't you think that viewpoint, though, is a significant contributor to the problem? [13:22:00] well, it is. because it means any changes which filter to stable result in criticism, due or not. [13:22:09] No, the significant contributor to the problem is ==shadow. [13:22:10] but perhaps i am cynical [13:22:42] At least our problem here is everyone's problem. I've been following the GCC list for years, and it's not uncommon for someone to show up saying "here's this great new optimizer pass that I've been building in a cave for the past two years, please integrate it!" and see all the developers say "that's nice, now take it all apart and give us reviewable patches." [13:22:58] stable means stable except some people think stable means "stable, except my feature is really cool and I think it's important that everyone have it whether they like it or not, so please commit it" [13:23:08] yeah, it's definitely a 'large OSS' problem. [13:23:40] --- agoode has left [13:23:40] yes, but some features are really cool, and stable. you have the knee-jerk "omg you can't possibily have verified this at all can we please stick with 1999" problem sometimes. [13:23:54] --- agoode has become available [13:23:58] Point. [13:25:05] blunt question: russ & jhutz, what would need to happen for you to seriously consider running 1.5 at your sites? (or at least driving that..) [13:25:20] We do have the problem now that people have to choose between something that is truly stable and something that is perceived as very bleedy, without any middle ground. [13:25:28] We plan on deploying 1.5.61 on test servers once released and there are no known show-stoppers. [13:25:31] IMO, the two of you saying 'hey; we're running 1.5' would go a long, long way to helping others consider moving to it. [13:25:34] We've been planning on that for a long time. [13:25:44] There kept being show-stoppers that other people ran into. [13:26:06] Now I'm just waiting for 1.5.61, since packaging for 1.5.60 is from all accounts kind of a waste of time, and master now has nearly all the fixes I needed for Debian. [13:26:17] that's helpful; tx. [13:26:17] Stanford cares a great deal about demand-attach. [13:26:19] We want it to work. [13:26:22] We want to run it. [13:26:38] I'd love to have the kind of time I'd need to consider that. Right now, I just don't. [13:26:40] We're a little short of $$$ to help with, but I can spare some of my time at least. [13:26:59] deason's been fixing DAFS bugs and taking names lately...it's looking pretty good, fwict. [13:27:39] Stanford's development priorities, for whatever it's worth, are (1) demand-attach, (2) AES-based authentication and wire encryption, (3) speed, (4) OSD. [13:28:29] This is as distinct from what I'm working on as a gatekeeper partly, since I'm wearing multiple hats. [13:28:40] * stevenjenkins nods. [13:29:01] Basically, Stanford can afford to spare me for 2-4 hours a week, and the AFS work I do on top of that is mostly coming out of my own time. [13:29:32] * Russ is bad at the whole work/life boundary thing. :) [13:29:55] * stevenjenkins nods. my AFS time via work has been severely limited the past several mo's. [13:30:20] It's been a bad year for that for a lot of people. [13:30:32] * stevenjenkins nods. [13:30:49] * Russ got seriously derailed by a virtualization project, which is important to Stanford but doesn't involve doing anything with any of the open source projects I contribute to. [13:30:54] --- agoode has left [13:31:06] --- agoode has become available [13:31:54] hm. speaking of that, i wonder how portable virtualbox is. [13:32:31] You mean how easy it is to port? [13:32:50] well, let's say, to a platform where i have no lkm support [13:32:56] There have been a few patchsets floating around to get it working on fbsd, but I didn't look to see how invasive they were... [13:35:45] Looks like http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz is the latest patch (includes a kernel module, it seems) [13:36:05] --- Simon Wilkinson has left [13:36:08] --- Simon Wilkinson has become available [13:37:25] actually, i should do something crazier, but tht will involve one of qemu or bochs i suspect [13:38:11] oh well. need to retrieve car. back later. [13:38:23] --- Simon Wilkinson has left [13:38:35] --- Simon Wilkinson has become available [13:41:45] I think jhutz owes me a new keyboard. [13:42:22] Slight T|N>K incident when I read his email on openafs-devel. [13:46:14] hm? [13:47:07] I found your shipping container metaphor amusing. I was drinking tea at the time. Said tea was liberally sprayed onto keyboard. [13:48:18] After what happened to me at the workshop, I suspect you are using a fairly limited concept of "liberally". :-) [13:48:25] --- dlc has become available [13:48:29] Like, I bet your keyboard still works [13:49:11] You have a valid point there. [13:51:46] I spilled my beer [13:55:30] Would anyone mind if I upgraded Gerrit on Friday morning (UK time)? [13:59:50] i have no beer to spill. i wonder what dinner will come with [14:06:02] --- dev-zero@jabber.org has left [14:23:12] I suspect an outage at that time is fine. Please send an outage message to openafs-devel [14:30:02] --- dlc has left [14:35:11] argh, one thing about gerrit is that it makes it difficult to respond to largish comments coherently [14:35:21] an email interface would be nice.... [14:35:36] I think it's on the list. [14:36:21] oh! cool [14:36:27] You can go through and add your response below the comments you're responding to. [14:37:55] http://jira.source.android.com/jira/browse/GERRIT-229 is the bug for an email gateway, BTW. [14:38:45] Could someone delete my message from the openafs-devel moderation queue, and I'll resend it from the correct address? [14:41:36] --- mmeffie has left [14:47:35] --- dev-zero@jabber.org has become available [14:57:48] Russ: are my responses not showing up with separate paragraphs to you, too? [14:58:50] They seem fine to me. [14:58:54] I should probably pitch in with change 100 as well, but personally I'd really like to have a way of enabling -Werror on a file by file basis, so that files that are clean stay so. [14:59:19] hmm, my responses show up as one single paragraph on the web interface to me [14:59:22] but yours are fine [14:59:35] afaict from the emails, we're both just using two newlines... hm [14:59:48] And it's my intention that the auto-verify buildbot stuff will report 'change in warnings' to gerrit. [15:04:41] I wish the error/warning distinction was more universally configurable [15:05:35] at least with gcc, you can just make all warnings errors, or none, or specifically implicit function decls... I don't see what would've been so hard about just having each possible warning settable as a warning or error [15:05:43] I think you can do [15:05:52] -Werror= [15:06:23] that form is not in my gcc manpage; not to say it doesn't work [15:06:46] Simon: #pragma GCC diagnostic error "-Wall" [15:06:51] Applies per file. [15:07:06] You can be more granular than -Wall of course, too. [15:07:15] I think you need a relatively new version of GCC. [15:08:38] Cool. I might just start sprinkling those round the tree like pixie dust. Providing it doesn't break old gcc's, that is. I guess there's probably a suitable #if that it could be wrapped in. [15:09:11] deason: It looks like -Werror= is in 4.3.x [15:09:17] --- Russ has left: Disconnected [15:09:28] --- Russ has become available [15:09:39] Yeah, it doesn't break old versions. [15:09:45] #pragma is ignored if not recognized. [15:10:11] --- dev-zero@jabber.org has left [15:10:17] The GCC folks added that because they build with -Werror by default and require #pragma GCC diagnostic ignored "-Wfoo" when they have intentional warnings. [15:10:54] We should probably make the #pragma conditional on --enable-warnings, since we will break the build when we run into warnings on other platforms that the core devs aren't using. [15:10:55] We actually aren't that far from being able to do that ... [15:11:11] Well, I have this cunning plan to make --enable-warnings the default. [15:11:49] You should probably make the pragma conditional on knowing you're actually using gcc, since another compiler would be within its rights to delete your filesystem and then launch the nuclear missiles. [15:11:54] * Russ would be good with that. Basically, though, I'm advising against -Werror or an equivalent in #pragma for the code we ship to regular users, at least enabled by default. GCC has to be built with --enable-checking to turn that all on. [15:12:15] jhutz: If another compiler explodes on #pragma GCC, I think they get what they deserve -- that would really surprise me. [15:12:24] --- deason has left [15:12:39] --- deason has become available [15:12:42] --- dev-zero@jabber.org has become available [15:12:47] Users have all sorts of weird environments that will generate warnings no one has ever thought about. [15:13:18] Particularly if we ever try for const correctness, since some OSes aren't const-correct in their own standard C library headers. [15:13:23] So, we could have --enable-checking which sets -Werror [15:13:48] And then unprotected pragmas at the top of each file to modify that where necessary? [15:13:56] More realistically, it is acceptable for a compiler to simply abort when it encounters an unrecognized pragma. I really do not want to fall into the trap of assuming everything is gcc. [15:14:00] --- abo has left [15:14:25] Okay, so pragmas protected with whatever the "we're using gcc" #ifdef is? [15:14:29] --- abo has become available [15:14:37] --- stevenjenkins has left [15:14:38] jhutz: That would be a serious quality of implementation defect, IMO. do you know of a compiler that does that? [15:14:47] But yes, ==Simon. [15:15:01] That's probably safer anyway. [15:15:12] --- Simon Wilkinson has left [15:15:19] --- Simon Wilkinson has become available [15:15:35] Simon: I think the basic question we have is do we want to enable -Werror per file, or do we want to enable -Werror globally and disable it for specific warnings per file? [15:15:50] 'cause the build machinery changes to do this are quite different depending on which direction we want to go. [15:16:02] Not offhand, but I haven't played with many compilers lately. I don't know why you'd consider that a defect; the standard specifically leaves the effects of #pragma undefined, and the expectation is that it gets used only when you know what compiler you're using. [15:16:29] Also, I think enabling the warnings if we're building with gcc by default is good, but -Werror should require some sort of --enable-life-sucking flag for those people trying to build on weird platforms. :) [15:16:47] I think it would make sense to set the default per-directory, turning it on for each directory as it becomes clean [15:16:47] jhutz: C99 added pragmas. [15:17:09] Which are supposed to be implemented by all compilers. And as I understand it, as #pragmas precisely because they're ignored by non-supporting compilers. [15:17:42] The direction in which pragma usage is going, from what I've seen, is definitely towards assuming that compilers that don't know what they are will ignore them. [15:17:58] That sounds like retroactively changing the spec to me, but I guess they probably surveyed more existing implementations than I have [15:18:26] --- stevenjenkins has become available [15:18:57] In fact, C99 explicitly says that all unrecognized pragmata must be ignored. [15:19:08] Section 6.10.6. [15:19:19] anyway... - enable -Werror per directory, eventually in all directories - disable it per file when needed, but... - prefer to suppress specific warnings where reasonable [15:19:42] I think I would like to: [15:19:47] I think I have a convenient copy of C90 but not C99 around here. [15:20:09] Add a patch which adds a --enable-checking option, and commit it now, knowing that the tree will not build with it enabled. [15:20:24] Work through the tree either adding the appropriate pragmas, or fixing the remaining warnings. [15:20:27] ... [15:20:29] Profit [15:20:31] --- abo has left [15:20:52] --- abo has become available [15:20:57] Yeah, that sounds good. [15:23:03] --- deason has left [15:23:09] --- deason has become available [15:24:02] You think we are that close to the point where the only warnings left are unavoidable? [15:24:38] Not a million miles away. [15:24:53] There are 938 warnings left in the current tree, once all of the patches in gerrit have been applied. [15:26:23] have you counted 64-bit builds yet? [15:26:50] No. I'm enjoying the warm glow of being nearly there, and don't want the crushing disappointment. [15:27:28] There's also the issue of platforms like Mac OS X which have deprecated loads of functions we use, and moan like crazy about it. [15:28:11] there are 3441 warnings in the 64-bit build on Windows [15:28:14] What really concerns me at the moment, though, is finding a mechanism which stops warnings I've fixed from being introduced. [15:28:45] In the last round, I already had to revisit a load of files I fixed a year or so ago, and fix regressions. I want to make it harder for that to happen. [15:29:10] --- deason has left [15:29:14] one directory at a time clean up all of the warnings on one platform. on that platform require warnings to be treated as errors [15:29:16] --- deason has become available [15:29:17] --- agoode has left [15:29:37] require that such a platform be used as one of the verifications for any patch to be committed [15:29:41] We could probably get 32-bit Linux warning-clean on a lot of directories fairly fast. [15:29:50] It already is, I think. [15:30:22] Linux was going to be first candidate for auto-verification builds, too. [15:30:47] of the warnings on 64-bit windows, 161 are time_t related [15:30:58] 597 are size_t [15:31:19] 458 are signed vs unsigned [15:31:20] How many are same call site? [15:31:22] I bet a lot of them are printf of time_t. [15:31:38] Darwin certainly has a load of printf of time_t issues. [15:32:50] For printf of size_t, do we want to go the unsigned long cast and %lu route, or do we want to try to be more correct and use %zu with string concatenation to use something else on platforms that don't support it? [15:33:37] How about - AFS_FMT_SIZET and afs_printable_sizet() [15:34:02] Where if %zu is supported, AFS_FMT_SIZET is %zu and afs_printable_sizet() is a no-op? [15:34:03] and then we can decide centrally. We can start off using %lu and (unsigned long), and migrate to %zu at a later date? [15:34:07] Yes. [15:34:07] Yeah, that works. [15:34:17] I think we can probably safely cast to unsigned long and use %lu. [15:34:42] It lets us also do the right thing on Windows, whatever that may be. [15:35:07] I really wish there were a better answer to choosing format specifiers [15:35:15] Yeh. [15:37:08] I'd really like us to get rid of most of our type casts, and replace them with inline functions. IMO, its much more maintainable. [15:37:18] Yeah, I think that's a general feeling, on format specifiers. [15:37:46] IIRC, Windows has a problem with one of those assumptions about where unsigned long casts are okay. [15:37:50] I don't remember which one. [15:38:05] How big is an unsigned long on 64bit Windows? [15:38:18] /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/win64-error-counts.txt [15:38:24] --- abo has left [15:38:47] --- deason has left [15:38:49] --- abo has become available [15:38:57] --- deason has become available [15:39:01] Because if, as I suspect it's only 32 bits, and Windows has a 64 bit size_t, we lose. [15:39:10] Yeah, that may be the one that's sticking in my head. [15:39:30] I suspect Windows supports %zu. [15:39:55] Google is unwilling to search for %zu. [15:40:35] unsigned long is 32-bit; size_t is 64-bit [15:41:02] http://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx suggessts we should be using %Iu on Windows [15:41:05] time_t is 64-bit [15:41:12] (for size_t, where I is for Igloo) [15:42:11] Ah, okay. [15:42:20] Similar to how Linux used to use %Zu. [15:44:05] BTW: We've now had more than 100 patches through gerrit. I think that's pretty good going ... [15:46:50] --- dev-zero@jabber.org has left [16:05:45] what does the / mean at the beginning of a line in a .gitignore file? [16:06:18] It anchors the pattern to the top of the tree. [16:06:25] Otherwise, all patterns apply everywhere recursively in the tree. [16:07:37] The only recursive rules in our gitignore files should be at the top level. Everything else should be anchored. [16:07:47] anchors to the directory the .gitignore file is located within? or to the top of the repo tree regardless of where the .gitignore is located? [16:08:03] To the directory the file is located in. [16:09:42] One of the really good thing about doing this kind of code review is the other problems you notice whilst reviewing changes. [16:11:52] Yeah, that's one of the reasons why I'm doing a lot of it. [16:11:58] I feel like I'm finally slowly starting to learn the code. [16:17:11] --- mdionne has become available [16:18:25] please verify and submit http://gerrit.openafs.org/103 when you have time. [16:19:38] Did you run git ls-files ? [16:19:43] yes [16:20:12] still I prefer that someone else verify as well. [16:20:16] I will do. [16:20:33] Do vc*.pdb and rs_state.ini occur in multiple directories? [16:20:42] I'm not entirely comfortable with verification being done by the submitter. [16:20:47] yes [16:20:55] How many different dirs? [16:21:02] they can appear anywhere [16:21:08] Okay. [16:22:44] 1929 warnings left here - 64-bit linux. The runaway champion is kdump: 642 warnings and over 200 errors, all by itself. [16:23:00] That's quite, quite special. [16:23:06] Do you fancy fixing them? :) [16:23:12] looks scary [16:23:34] It turns out that the way that we obtain kernel dumps is disgust the kernel so much that it vomits its state on us. If we fixed the code, it would stop working. [16:23:53] we're mixing kernel and userland includes, so we get tons of conflicts [16:24:15] Maybe we should just disable kdump and see if anyone notices ... [16:24:34] or at least disable it where we know it to be unbuildable [16:25:01] Yeh. I'm pretty sure that the Makefile in that directory is deliberately set up so that it won't stop the build if kdump doesn't build. [16:25:09] Oh, yeah. [16:25:32] We've never shipped it in the Debian package. [16:25:34] Yes the errors are ignored - but it still pollutes the log [16:25:49] I've thought about it, but it really has to be built with the kernel build, not the userspace build. [16:26:08] ...and ~1000 messages is a lot of pollution ! [16:26:13] Indeed. [16:26:50] It might be worth looking at Marcus's Monster, and seeing if he did anything with kdump. [16:28:35] do we know on which kernel versions it is known to compile/work? [16:30:12] I don't. I don't think I've ever seen it build successfully. [16:31:29] * Russ has built it before when we were debugging www problems. [16:31:34] I'm not sure we got anything useful out of it. [16:34:32] Seems like we should disable building it, say for linux kernel > 2.x.x, until someone can fix it. If it's worth fixing it and keeping up with ever-changing kernels [16:34:34] Marcus's patch does have a load of fixes for kdump in it. It's too late for me too start digging now, but someone with splitdiff to hand might want to examine those. [16:35:15] Last time I built it, it was for 2.4, I think. It might have been early 2.6. [16:36:07] which of his patches is this in? [16:37:09] /afs/umich.edu/group/itd/build/mdw/openafs/patches/openafs-h20090621-wfix5.patch.bz2 [16:37:45] does anyone know if marcus got it actually working? [16:38:03] Don't know. [16:39:44] And there's some bits of the kdump.c patch that are just wrong... [16:40:10] But there's good stuff in there, too. [16:40:49] marcus is really funny. he changed the MIT header files for KFW that are in the tree [16:41:29] no really. those are the function declarations. you can't change them [16:43:00] If anyone is thinking about pulling in his kdump.c stuff - I'd rather not mix register removal with prototyping, casting size_t to (int) so you can print it is bad, %p should be %"AFS_FMT_PTR", and I don't think %# is sufficiently widespread that we can use it. [16:48:32] patching just kdump.c from his patch gets rid of 610 warnings, but still leaves quite a few warnings and errors [16:49:05] Getting rid of 610 of the things can't be a bad thing, though :) [16:49:56] But yeh, if we know it won't build we should probably just not build it. I would imagine Derrick probably has the best idea of when it last built. [16:50:40] BTW, while I suspect many people here have already seen it, those who haven't might be interested in Henry Spencer's paper "#ifdef Considered Harmful," which is a really good introduction to how to write maintainable portable code. [16:50:42] http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful [16:52:20] My favorite line: "Portability is generally the result of advance planning rather than trench warfare involving #ifdef." [16:53:01] May I highly recommend afs_xioctl() to you :) [17:07:04] --- summatusmentis has become available [17:07:53] Simon, the regex in the "lang" directory is meant to be recursive as it applies to all of the locale specific directories below "lang" [17:29:43] --- edgester has become available [18:27:39] --- mdionne has left [18:44:22] Jeffrey, when you get a chance, could you check that I did the Windows bits correctly in http://gerrit.openafs.org/Gerrit#change,91 (and also review the approach)? [19:23:05] --- edgester has left [19:36:07] Russ, what other types of files might you consider for AFSDIR_DATA_DIRPATH and AFSDIR_CLIENT_DATA_DIRPATH ? [19:38:27] I'm really not sure -- at the moment, AFS doesn't have a lot of data of that type. The Debian package also includes the upstream CellServDB there for reference for the maintainer scripts. [19:39:26] Examples from other packages are supporting shell scripts that are run by the user binaries for some reason, XML schemas, private Perl modules or Python modules, and that sort of thing. At the moment, the only thing like that we have is the NLS catalog for fstrace. [19:39:29] The reason why I ask is that at least for the client side we do not use the unix style paths at all and I given that I have no files being used at the location it is unclear to me what I would even use it for. [19:40:06] Yeah, I'm not sure what you'd use it for too. That's one of the big reasons why I didn't give it a new directory in the dirpath_nt.h file and just mapped it to etc, similar to how the Transarc paths do. [19:40:42] But it seemed weird to introduce a path just for UNIX without adding it for Windows as well. [19:40:55] And nowhere else makes a lot of sense for the NLS catalog file. [19:41:18] It's not a configuration file, for instance, so putting it in the same directory with CellServDB and whatnot isn't really right for the FHS on UNIX. [19:41:30] Or Linux, I guess I should say, although most UNIXes use something akin. [19:41:37] Since I do not know what I would configure the path to return I think it might be best to not define it for Windows at the moment. [19:42:09] Okay. Do I just pull it from dirpath_nt.h and leave everything else the same? [19:42:15] Its closer to a resource dll which we load by finding the directory the current module is loaded from and searching there [19:43:02] Yeah, it's similar there. Something that would be shared between 32-bit and 64-bit builds. [19:44:44] I guess the easiest way for me to explain is to add comments in gerrit so let me do that [19:44:54] Okay. [19:45:03] * Russ is amused that I have more commits to Perl than I do to MIT Kerberos. [19:47:16] --- andersk@mit.edu/vinegar-pot has become available [19:48:37] done [19:48:48] * Russ registers remctl with Ohloh just to see how the process works. Seems like a neat system. [19:49:47] Am I just failing to look, or is 1.4.11 not in Git or CVS? [19:55:27] there are several tags...openafs-stable-1_4_11pre{1,2,3} [19:55:55] openafs-stable-1_4_11 is the tag in cvs [20:40:42] > there are several tags...openafs-stable-1_4_11pre{1,2,3} each of those corresponds to exactly what you'd think [20:57:24] is there a git tag or branch for the final release of 1.4.11, though? [20:57:40] git? not yet. it needs to be hand-merged yet [20:59:27] Damn, we have a lot of different versions of the AFS syscall layer in the tree. [20:59:33] yes. yes we do [21:00:53] kdump compiling on linux: when 2.6 was new, maybe, but basically not since [21:01:35] * Russ ponders ways of merging them. [21:05:20] afsd, afsweb, auth/ktc.c, bozo/bosserver.c, rx/rx_user.c, rx/test/testserver.c, rx/test/testclient.c, sys/*, venus/fstrace.c, viced/viced.c, and volser/volmain.c all have calls to syscall(). I suspect they all need SIGSYS handling and selection of an appropriate interface. [21:05:54] * Russ isn't entirely sure why libsys doesn't export an afs_syscall() function that everything can just use. [21:06:40] And I bet vsys doesn't work at all on modern Linux. [21:07:09] at some point i knew why no afs_syscall, but it was dumb and probably not applicable now [21:08:10] * Jeffrey Altman ponders how to export a repository from one windows system to another so I can build on multple systems but maintain a single set of commits [21:08:51] Clone from one repository and use push/pull? Or is that what you want to avoid? [21:09:15] that is what I want to avoid [21:09:28] You could do the git clone --reference thing that we were talking with jhutz about earlier. [21:09:52] You'd still have to remember not to commit in the child repositories, though. [21:10:11] And I suspect that commits in the master won't get picked up completely automatically. [21:10:50] I think I need to figure out how to setup a git server on my primary dev box and then git clone from that box onto the slaves [21:11:41] Cool, we have four different CellServDB files in the tree, of three different vintages. [21:12:11] I believe we stopped updating the non-Windows ones [21:12:57] because we stopped using the [21:12:58] them [21:13:05] Yeah, that sounds right. [21:13:19] Well, one of them is in the Debian packaging directory. [21:13:27] Which will get a mass update sometime after 1.5.61. [21:13:40] > You'd still have to remember not to commit in the child repositories [21:13:45] "use afs" [21:13:58] --- stevenjenkins has left [21:13:58] --- deason has left [21:14:00] I'm still tempted to make that update git rm -r. [21:14:14] when I have disconnected mode on Windows I will be able to [21:14:49] --- deason has become available [21:15:22] The kopenafs layer already does its own SIGSYS handling around calls to lpioctl and lsetpag. [21:16:03] * Russ ponders the merits or lack thereof of making libkopenafs the standard system call interface for everything else in the tree. [21:16:16] It has the immediate problem that it only does two system calls. [21:16:22] And we have others. [21:16:24] if libkopenafs is assured to build everywhere... [21:17:05] Well, we're currently unconditionally building it everywhere and no one is complaining. [21:17:12] Of course, that's relatively new. [21:17:22] --- stevenjenkins has become available [21:17:28] More problematic is that it's by default a shared library. [21:17:37] Although one can link to the static version of it if one doesn't want that. [21:18:20] Revamping the system call layer to have something simple and understandable would be really simple if it weren't for the rmtsys code, which is what makes the whole thing kind of insane. [21:18:49] And is why libsys has a dependency on rx, for instance, which is probably why rx has its own syscall. [21:21:32] It's remarkably hard to revamp a portion of AFS. [21:21:36] Everything is entangled. [21:22:00] Thinking it all through is tricky. [21:45:13] --- deason has left [21:47:58] You know what we really need? A detailed protocol specification for every AFS system call, ioctl, or pioctl. [21:48:09] Specifying what the arguments in and out are and mean. [21:48:14] And who implements it when we know. [21:48:25] And a pony. [21:49:29] know what we need? exactly one call, ioctl and pioctl. and one API routine. we can call them dwiw_{call,ioctl,pioctl,API} [21:50:00] (They would be varargs, right?) [21:50:05] VIOC_BITEME. ISAGN. [21:52:01] sure. and, you know, i suppose they can be typed. [21:52:16] --- kula has left [21:58:59] * Russ wonders if there's some meaning conveyed by the difference between the VIOC* and the VIOC_* constants, but suspects there isn't. [21:59:09] nope [22:02:43] --- kula has become available [22:14:24] Jake wrote some documentation for the pioctl interface last Summer. Its in the wiki [22:16:36] Oh, sweet, yes. [22:17:32] * Russ heads to bed. [22:17:36] More tomorrow. [22:17:48] you might want to speak with David Howell though since he is being forced to develop an entirely new interface [22:17:55] Yeah. [22:18:01] --- Russ has left: Disconnected [22:18:25] xattrs are used to return the system.afs.cell and system.afs.fid for the file and then a new /proc interface is used for all queries [23:10:46] --- reuteras has become available [23:16:08] --- dev-zero@jabber.org has become available [23:26:03] --- Jeffrey Altman has left [23:36:48] --- Jeffrey Altman has become available