[00:00:53] --- Russ has left: Disconnected [00:12:21] --- dev-zero@jabber.org has left [00:43:59] --- haba has become available [00:55:44] --- dev-zero@jabber.org has become available [03:22:55] --- matt has become available [03:34:28] --- Simon Wilkinson has become available [03:48:03] Andrew: gerrit continues to show the correct data but you are correct that what is being put onto git master is wrong. [03:49:10] That's going to be a gerrit bug. I suspect that the problem coincides with a gerrit upgrade. [03:49:29] > Some time between Fri Aug 21 00:04:10 2009 -0700 and Fri Aug 21 14:16:26 2009 -0700, [03:49:37] because simon applied an update. [03:49:40] In general, gerrit bugs belong on the repo-discuss list. However, we're very behind in gerrit versions at the moment. [03:50:13] So, let me upgrade, let's see if the bug goes away. If it doesn't, someone (not me!) should find it and fix it, or we should report it upstream. [03:52:08] we're boned as far as committers tho, yes? [03:52:33] Well, you still know who it was. [03:52:50] You seem to be getting the gerrit account information, rather than the information from the original patchset. [03:52:59] right [03:53:06] the point is, it will always be wrong [03:53:17] The question is whether you're getting the committer information as the person who submitted the patch to gerrit, or the person who hit submit and applied the patch to the tree. [03:53:20] we are boned to the extent that we can't change history in a public repo [03:53:27] that's what i mean [03:53:30] Yeh. No going back. [03:54:56] it is showing the committer that pushed the submit button. not the committer that submitted the code to gerrit for review [03:55:32] Which is actually correct. It might not be what we want, but it's the correct behaviour for a cherry picked commit. [03:56:25] what I think we want is an additional set of fields with Submitter: and SubmitDate: [03:57:30] when shawn or someone writes it, we'll have it :) [03:57:34] Indeed. [03:57:47] There's no point in discussing things we'd like in gerrit unless someone is committing to implement them. [03:58:11] agreed [04:06:32] shawn has been really busy since 2.0.18 was released [04:09:10] Yeh. He's rewritten the whole thing. [04:48:50] --- Derrick Brashear has left [06:03:14] --- mmeffie has become available [06:48:41] --- matt has left [07:13:12] --- deason has become available [07:26:25] --- Simon Wilkinson has left [07:37:03] --- mmeffie has left [08:03:47] --- jaltman has left: Disconnected [08:42:37] --- haba has left [09:03:05] --- jaltman has become available [09:13:16] --- jaltman has left: Replaced by new connection [09:13:18] --- jaltman has become available [09:33:04] > receives an XCB for metadata on an untrusted connection. What means do we have for trusting callback connections? [09:35:12] none at the moment but we will have trusted callbacks with future security classes [09:35:40] such is mentioned in the XCB draft, section 3.6 [09:40:46] --- jaltman has left: Replaced by new connection [09:40:48] --- jaltman has become available [09:42:15] some guy comes up to your machine and says "trust this or i'm gonna kneecap you" [09:50:41] --- jaltman has left: Disconnected [09:59:44] --- haba has become available [10:17:59] --- deason has left [10:18:06] --- deason has become available [10:18:15] --- cg2v has left [10:24:14] --- dev-zero@jabber.org has left [10:28:17] --- haba has left [10:59:08] --- haba has become available [11:28:59] --- Russ has become available [12:00:27] --- jaltman has become available [12:29:04] --- jaltman has left: Disconnected [13:38:46] --- Simon Wilkinson has become available [13:39:29] There's also the option that an administrator may decide "this machine is on a trusted network, therefore I trust all connections" [13:56:09] --- Simon Wilkinson has left [14:19:10] --- Simon Wilkinson has become available [14:58:15] --- deason has left [15:06:16] db949b7fade69d7eb1e38ad85d5b822c443306cb is just wrong on non-Linux platforms. [15:06:38] It adds shed loads of warnings into the tree on Leopard, for example. [15:09:26] (This is the fix for printing size_t on Linux ... ) [15:14:19] If it's Just Wrong on non-Linux, changes are fairly good it's at least wrong-ish on Linux, too. [15:14:50] Well, on linux it's right because the #defines are right on Linux. [15:15:44] But on Leopard, at least, a size_t is unsigned long, and AFS_64BITPOINTER_ENV isn't set, so we get compile warnings galore. [15:16:48] I'm fairly surprised that C99 doesn't specify macros to be defined by inttypes.h for size_t and ssize_t. [15:16:52] I'm pretty sure when we discussed what to do about size_t printing, the conclusion was just to use %lu, and explicitly cast to (unsigned long) [15:17:10] If we could assume C99, we could just use %Zu and be done with it. [15:17:54] No, Z is libc5 [15:18:10] lowercase 'z', maybe [15:18:22] --- deason has become available [15:18:30] Yeh, sorry %zu. [15:18:53] But, anyway, we can't. And I now can't verify any patches against master. Mutter. [15:21:33] sorry; I couldn't very anything before I put that in :) [15:21:54] Yeh, well. [15:21:57] we could also just have a configure test specifically testing for what we need for size_t [15:22:35] We could, yes. [15:23:25] Part of me wonders if just casting might not be easier. [15:23:29] Oh, but what we can do is #if __STDC_VERSION__ > 199901L #define AFS_SIZE_CAST #define AFS_SIZE_FMT "zu" #else #define AFS_SIZE_CAST (unsigned long) #define AFS_SIZE_FMT "lu" #endif printf(" blah blah %10"AFS_SIZE_FMT"\n", AFS_SIZE_CAST l); [15:23:53] Ugly, but fairly safe [15:24:00] The problem is that you can't use 64 bit pointer env. There are platforms where size_t is long, but pointers aren't 64 bit. [15:24:12] Yeh. Yuck. [15:24:48] It'd look a little less ugly if you renamed AFS_SIZE_FMT to ZU [15:25:07] And then hope you never use ZU anywhere else :) [15:25:13] true. [15:25:26] even AFS_ZU would be shorter [15:25:56] We don't use our own printf everywhere this affects, do we/ [15:26:03] I was just about to look. [15:26:12] The only place we use our own printf is viced. [15:26:17] Because, well, we could just support zu always. [15:26:33] We could always switch to using our own printf everywhere. [15:26:40] But that's a bigger change. [15:26:47] I wonder what the gatekeepers would think of that. Portability sucks [15:26:47] --- abo has left [15:27:00] Oh yes. [15:27:15] I'd like to see a quick fix for this particular problem, though. [15:27:26] --- abo has become available [15:28:27] 'quick' sounds like a configure test, but that's just me (since we have AFS_SIZET_FMT everywhere now, but if we cast, you'd have to add the casts) [15:29:21] or actually quickest is just using %zu when available, fall back to %u have leave it as broken as it used to be before we even tried fixing this [15:29:47] s/have/and/, not sure how I did that [15:29:59] I think the configure test would be the most elegant way of resolving it quickly. [15:30:11] Wait, what does the configure test do? [15:30:26] Oh, you figure out the size of size_t? [15:30:29] Yeh. [15:31:11] Simplest test would be to turn on warnings-as-errors, and size_t blah = 0; printf("%u",blah); [15:31:13] ... and set AFS_SIZET_FMT appropriately. OK, so we should set it to zu when we think that's available. And otherwise try 64 and 32 [15:31:44] simon: that assumes we know how with the compiler we're using, though [15:31:51] Note that it will be available on glibc 2.1 and later [15:32:07] deason: True [15:32:14] is that even possible to do with all of the compilers we use? [15:32:20] Probably not, no. [15:32:38] Gah. This is nasty. [15:32:40] fortunately, autoconf comes with a test for determining the size of a type [15:32:57] just have a configure test to get the size for size_t, use %zu with preprocessor logic in the header [15:33:04] I'm not sure if that's our issue, though. [15:33:05] and fallback to the configure-test %u or %lu size [15:33:28] --- abo has left [15:33:56] Because I suspect on the platform I'm using sizeof(int) == sizeof(long) [15:33:59] --- abo has become available [15:34:13] and yet you still need to be correct about using %lu against %u [15:34:30] yeah, I know, annoying as hell [15:34:38] hm [15:35:33] --- haba has left [15:35:53] Just checked. sizeof(int) == sizeof(long) == 4 [15:35:56] well, does it matter for then, though? if we're building on a platform that doesn't support %zu, do we need to squish the warning? [15:36:08] as long as we get the size right, it shouldn't be an actual problem [15:36:11] Actually, it's close enough... - If zu is available, use it, period - Otherwise, if int and long are different, use AC_CHECK_SIZEOF - Otherwise, use the compiler-warning check, because it doesn't _really_ matter, and if the compiler doesn't produce warnings, we don't care if the type matches. [15:36:11] Yes. [15:36:44] I suspect the first 2 are sufficient. [15:37:05] Only doing the first two doesn't make the warning(error) go away [15:37:28] Yes. But I think we'll have %zu on all of the platforms where we're able to do warnings-as-errors. [15:37:29] since --enable-checking isn't even going to work on non-gcc anyway (at least for now), using a gcc-specific check should be good enough, I would think [15:37:38] Indeed. [15:38:24] Do you fancy putting this together? [15:39:06] --- haba has become available [15:39:16] I don't mind, but not now, I'm not available tonight [15:39:31] Okay. [15:39:36] I can get to it over the weekend, unless someone else gets to it first [15:39:58] assuming I can do it right; I already screwed up the first try, apparently, heh [15:40:00] --- abo has left [15:40:32] Well, it improved things on Linux which is greatly appreciated. [15:40:37] --- abo has become available [15:40:51] We just didn't catch the breakage, and that's not your fault. [15:43:09] right; the failure was due to lack of sufficient verification before approving the patch. Where by "sufficient", I mean "enough to catch this problem", which I think is more than the minimum I would normally want. [15:44:04] Yeh. I think we've actually got a problem with many of these "fix things on Linux" patches. [15:45:05] Unfortunately, what warnings you can and can't suppress on a per file basis is very compiler version specific. Lots of the changes from whole file supression to pragma based supression break things for gcc 4.2. [15:47:53] really? That sucks a lot [15:50:21] Yeh. Given quite a few platforms ship with that as their standard compiler. [15:50:26] Patch will be forthcoming. [15:51:50] --- jaltman has become available [15:56:13] I have not been terribly impressed with GCC4's record regarding not screwing over existing, working code with its "enforcement" stance. Of course, compilers can do anything they want with code that doesn't fall within the spec, but in most cases, "the same thing as every previous GCC" is a much better choice for GCC4 than "throw up all over the place". [15:56:37] Well, we are requesting 'throw up all over the place' in this situation. [16:01:36] Yes, it's different when you ask for it. [16:02:42] The scary thing is some of the ways it breaks with dodgy code (in particular when you're aliasing inappropriately) at high optimisation levels. That's hurt us at work in the past. [16:06:01] --- Russ has left: Replaced by new connection [16:06:01] --- Russ has become available [16:13:07] Anyone who runs gcc with optimization other than -O2 is asking for trouble [16:13:30] Yeh, generally postgrads. They like life on the edge. [16:21:31] --- dev-zero@jabber.org has become available [16:21:45] --- dev-zero@jabber.org has left [16:22:00] --- dev-zero@jabber.org has become available [16:27:43] --- dev-zero@jabber.org has left: Replaced by new connection [16:27:44] --- dev-zero@jabber.org has become available [16:37:54] Okay. So the Linux kernel module on master also doesn't compile on RHEL5.3 [16:47:31] http://gerrit.openafs.org/640 reverts the commit that broke it. [16:51:07] --- dev-zero@jabber.org has left [20:08:25] --- Simon Wilkinson has left: Lost connection [20:44:39] --- Russ has left: Replaced by new connection [20:44:39] --- Russ has become available [23:55:17] --- dev-zero@jabber.org has become available [23:59:40] --- dev-zero@jabber.org has left [23:59:52] --- dev-zero@jabber.org has become available