[00:36:16] --- abo has left [00:54:51] --- abo has become available [01:00:46] --- haba has become available [01:44:47] The xkcd today is related to Windows file copy :) [02:42:45] --- pod has become available [04:28:01] Anyone know how widespread the availability of $VAR:=$(VAR) extra is with 'make' ? [05:01:40] --- Russ has become available [05:02:30] I seem to recall that often doesn't work. [05:02:52] $VAR += extra Automake ensures works, but that doesn't help if one is not using Automake. [05:03:26] ... and in this case, we're definitely not using Automake :( [05:04:53] The way Automake fakes it, btw, is $VAR = ... $(automake_extra1) and then later automake_extra1 = extra [05:05:36] Hmmm. So I could just do that. How does that avoid the recursion error for $(VAR) ? [05:12:43] You don't reference VAR in the setting for VAR. [05:13:00] VAR = foo bar $(automake_extra1) [05:13:05] automake_extra1 = extra [05:13:07] That sort of thing. [05:13:41] You have to anticipate the number of things you want to add to VAR later, which Automake does by global analysis of the makefile. [05:13:51] Okay. I might be able to make that work ... [05:14:15] Sadly the #pragma to disable errors stuff is gcc 4.2 or later only. [05:31:17] --- Russ has left: Disconnected [05:31:58] --- Russ has become available [05:33:16] --- Jeffrey Altman has left: Replaced by new connection [05:33:18] --- Jeffrey Altman has become available [05:38:35] How would people feel about a "quiet CC" patch, which would hide the CC arguments unless you specifically asked to see them. Similar to the way in which the Linux kernel is built ... [05:42:31] It's really hard to get that right portably according to the Automake discussion list. [05:42:47] Automake 1.11 does it for you. I'm planning on switching all my packages over to it once Automake 1.11 is in Debia. [05:42:49] Debian. [05:43:14] It would be really nice to have, because our cc lines are so long that the warnings disappear amongst them. [05:43:31] (Automake would be nice to have too, but I suspect that's not going to happen any time soon) [05:44:07] * Russ has thought about it and would really like to switch, since having a bunch of experience with it, I can affirm that it makes life way easier and you stop thinking about build system issues that we worry about now. [05:44:11] But it's a pretty huge project. [05:45:47] automake makes me sporky [05:45:57] sporky? [05:46:34] desirous of sticking a spork violently into something [05:46:38] or someone [05:46:56] So, providing we kept the sporks away from you, it would be fine? [05:47:12] things i realized i want this morning: a way to with a bitmask configuring only certain audit log messages on [05:47:25] That would be nice. [05:47:38] You could do it with an external program, and the message queues patch, I guess. [05:47:40] making the bitmasks not be inscrutable would be hard [05:47:52] --- abo has left [05:48:00] the problem is you generate the messages anyway, so you get the overhead only to throw it away [05:48:12] I think you'd probably want a command line option that takes 'real words', and turns it into a bit mask internally. [05:48:22] --- abo has become available [05:48:25] probably, but even then it's messy [05:48:46] Yes. OpenLDAP exposes the bitmask to the user, and it's, uh, less than ideal. [05:48:52] what, words to bitmask? [05:48:59] Yes. [05:49:02] oh, never mind, i am reading out of order [05:49:06] Ah. Okay. [05:49:28] I think recent OpenLDAPs also let you specify the log level as a list of words, too. [05:49:30] i appeared 7 minutes ago and started reading. i am reading forward and backward at the same time. "oof" [05:52:00] I wonder if it might be better to just let Adam push a Unix version of change 58, and Jeffrey write his own Windows version, rather than Jeff puppetteering Adam to write the Windows code. [05:52:40] loading.... [05:52:45] it would certainly be faster for me to just push the entire change [05:53:07] however, we agreed that teaching people how we wanted code written was important. [05:53:27] in this case, I want the error messages to have meaning [05:53:52] well, the messages (as opposed to how they are generated on each platform) do. [05:54:11] I think the question is, when we have a change that needs to be made for both Unix and Windows, whether we want both in the same changeset. [05:54:23] I would argue that we don't, because it confuses attribution. [05:55:28] we don't know who to kill when it breaks? [05:55:37] oh wait. attribution, not retribution [05:55:39] I don't care either way. if you push his original changeset I will fix them [05:56:01] Well, if the person who writes it is willing to add the Windows code, I like keeping things cross-platform from the start. But I'm not sure what to do with random external contributors. [05:56:05] I do agree too much time is being spent [05:56:18] I'm wondering the same thing about the regex change -- I could just write the full change that we want, but I don't know if we should. [05:56:43] You need to be careful about discouraging external contributors. [05:56:55] Otherwise they'll just write bug reports, and never submit code. [05:57:03] same here. someone pointed out an issue. but I want the change to be more comprehensive [05:57:04] Usually with my own stuff, I end up rewriting most patches I get. I don't know if that's good or not. [05:57:09] yeah, there's a balance between making it too hard, and doing too much as the acceptor [05:57:16] --- reuteras has left [05:57:24] --- abo has left [05:57:27] for heimdal every patch gets re-written [05:57:48] the result is that heimdal is really easy to read [05:57:55] I think if a changeset has stalled, then it's fair to prod the contributor, and ask if they'll get around to revisiting it, and if they don't reply, doing the work yourself if you want to see it included. [05:57:57] --- reuteras has become available [05:57:59] --- abo has become available [05:58:03] Yeah, that's why I do it for my own software. I'm completely anal about coding style and consistency. [05:58:32] I don't think we have the effort to rewrite everything we receive. I also think it's pretty demoralising if you've contributed code and then you don't see it in a release. [05:58:47] A better idea is to educate contributors about what you expect in terms of style and consistency. [05:58:54] i agree [05:59:04] i keep meaning to write a wiki page on that [05:59:10] But in order to do that, you need to have a consistent code base :) [05:59:11] Well, AFS already isn't that horribly consistent, so we don't have as much of a foundation to enforce anyway, too. [05:59:17] Yeah. [05:59:56] But speaking of patch review, could someone else look over Felix's latest push of 107? I'd like to get that in so that we can move forward with his patches, since they all depend on each other. [06:00:20] after i verify 58 i will look at 107 [06:00:27] Danke. [06:01:30] It's got code #ifdef notdef in it. Where do we stand on that? [06:01:40] It just moves it. [06:01:43] It was there already. [06:01:43] i prefer "if 0" [06:01:49] me too [06:02:01] but i am not going to quibble it [06:02:10] He has a lot of later beautification patches queued, so I've been not commenting on anything that he's just moving around. [06:02:14] Ah yes - it's just moved code. [06:07:14] Does anyone have any thoughts on the best way to resolve the compile_et manpage collision? [06:07:38] afs_compile_et? compile_et_afs? [06:07:48] (and install as such) [06:08:09] Should we be installing compile_et at all? [06:09:08] possibly not. the problem is if we don't it's hard to set up something using only afs style et (afs_error_msg et al) [06:09:09] I suspect not, given that we're not providing a general purpose comerr any more. [06:09:54] Maybe we should install it as afs_compile_et, as you suggest ... [06:10:11] it fits with the API rename [06:10:12] Yeah, that would work. [06:10:26] I'll put a patch together. [06:10:34] I'm going to need to respin the 1.4.11 RPMs with it, too. [06:10:53] ok [06:12:14] I should sort out 1.4.x so we can do pullups. I'll do that now. [06:12:19] s/we/you/ :) [06:14:02] Yay, thanks! [06:15:26] we will have macos 10.3 and openbsd for 1.4.11 up shortly, also [06:16:27] --- cclausen has become available [06:42:01] someone want to review 156? it will make my testing of other changes much easier :) [06:43:18] Done [06:47:14] > we need to define an EULA for inclusion in OpenAFS installers we've had that problem on macos ~forever, sadly. [07:00:03] --- deason has become available [07:20:12] we have the same problem on Windows. [07:22:01] I wonder if the fact that Secure Endpoints Inc. signs the installers that the EULA that ships in those installers should be written by SEI. Basically, you are free to use and distribute as you see fit but do not sue me if you are unhappy with it and its use is at your own risk. [07:22:55] we should have a generic one for any packager. i suspect none wish to be sued [07:23:13] i was looking at other software and then i kernel panic'd myself [07:23:45] Ooops. [07:24:23] I think any EULA would have to be written to satisfy the terms of the IPL, too, which places requirements on any license agreement that you might distribute OpenAFS under. [07:25:27] Personally, unless you're proposing applying additional restrictions, I can't see what difference there would be between the user agreeing to an EULA, and agreeing to the terms of the IPL. [07:25:48] Because the IPL clearly does also apply to end users. [07:25:55] the IPL is not really stated in those terms. [07:28:18] "Program" in the terms of the IPL1.0 means source code not binaries. [07:28:59] section 3. places restrictions on the EULA that may be used with the binaries. [07:29:45] The license disagrees with you... [07:29:53] where? [07:30:06] The definition of "Program" and "Original Program:" [07:30:23] "... including source code, object code and documentation" [07:33:31] which applies only to the "Original Program" definition. The "... and Contributions" does not indicate object code that is the result of building the Program. [07:34:18] using the IPL1.0 itself as an EULA is a violation of Section 3 because it doesn't state how to obtain the source code. [07:35:04] But then you're not distributing under your own license agreement, and so the whole of section 3 doesn't apply. [07:38:53] The definition of Contributor is strange. In order to be a Contributor you must also be a distributor. [07:40:05] The whole license is really badly written. [07:42:05] converting the IPL1.0 into an EULA would not be hard. It would require that we copy out sections of the IPL1.0 text and then add the distribution link to the source release for that version of the binary distribution. [07:43:43] --- reuteras has left [07:44:44] now that we are using git it might include the SHA-1 hash of the release. [07:45:38] Really, you should stop over-thinking this, and just distribute under the IPL. [07:49:31] So what about http://people.kth.se/~abo/tmp/firefoxfedoraeula.png but s/MPL/IPL/ etc.? [07:50:19] what about the IBM Public License version 1.0 and be done with it. [07:50:26] Did they change their EULA? It used to be ... http://www.mozilla.com/en-US/legal/eula/firefox-en.html [07:50:30] And == jhutz [07:51:23] Really, Jeff can distribute under whatever license he wants, as long as it complies with the terms of Section 3. But the OpenAFS project should distribute OpenAFS under the license of OpenAFS, period. [07:52:08] if the openafs project has the resources to do all its own builds... [07:52:38] And we should try and reach an agreement that suits all of our packagers. [07:53:03] Does anyone actually feel exposed under the terms of the IPL, though? The no warranty section there is pretty explicit. [07:55:30] Simon Wilkinson: That's the Fedora firefox EULA - Fedora didn't accept that Firefox needed that whole big eula [07:56:12] i,i https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269656 “AN IRRELEVANT LICENSE IS PRESENTED TO YOU FREE-OF-CHARGE ON STARTUP” [Fix Released, High] [07:59:48] Yeah, there was a huge stink about that. [08:41:45] --- deason has left [08:42:20] --- deason has become available [08:57:13] --- dragos.tatulea has become available [09:23:17] ok, something broke. i need to roll back through changes until i figure out where. [09:23:31] git bisect is your friend. [09:23:58] Tell it the last good revision, and it will drive a binary search to find the thing that broke. [09:24:32] i need to see if revision one worked, first. i just noticed i wasn't testing what i thought [09:43:00] For some reason, the pthreaded rx code introduces a dependency from rx -> rxkad [09:43:44] what is the dependency? [09:43:59] rxkad_global_stats_init() gets called from within the rx initialisation [10:00:29] --- cclausen has left [10:08:44] --- dev-zero@jabber.org has left [10:11:35] --- mmeffie has become available [10:19:24] --- stevenjenkins has become available [10:28:34] --- dragos.tatulea has left [10:29:29] should an application that calls rx_InitHost() have to initialize the rx security classes separately? [10:30:17] yes. [10:41:09] then we should make that happen. [10:41:33] (btw, I agree that they should.) [10:42:39] well, right now that only means undoing rxkad_global_stats_init, yes? [10:45:21] rxkad_client_uid_mutex and rxkad_random_mutex are initialized within rx.c. the initialization along with calling rxkad_global_stats_init() should be moved to a new initialization function exported from src/kxkad [10:55:42] ok. well, day 1 of git, plus the macos 10.6 patch, and nothing else, does work. so it's not that. i guess i will start bisecting. [11:07:41] --- dev-zero@jabber.org has become available [12:19:23] anyone else using the AFS perl modules and getting random "Fatal Rx error: rx packet not free", typically in rxi_AllocPacketTSFPQ (although i've gotten it in another rxi...TSFPQ function)? [12:20:00] istr simon saying one of his coworkers did, but maybe not [12:20:14] i tend to get these when making a new AFS::PTS handle. i had previously thought it was from various bits of the AFS modules calling rx_Init, but I've carefully isolated stuff so that shouldn't be a problem. [12:20:47] okay, i'll see if i can dig up something. i thought i had fixed the problem and was running extended testing, and then i come back and it fell over. [12:21:26] do you have the same problem with the git "master" tree and if so can you rebuild with RXDEBUG_PACKET? [12:21:31] what afs are you linking? [12:23:42] 1.4.7 currently, in previous bits of testing i linked against a 1.4.10 that a co-worker had built. i can try and see if i have enough git-fu to get the git "master" try and rebuild with RXDEBUG_PACKET. [12:24:07] if i do that, what interesting things will i get? will interesting things appear in the core file, will it log, something else? [12:24:23] the GitDeveloper wiki page tells you how to [12:24:47] it will panic aggressively on finding an allocation error as opposed to later [12:24:54] at which point, backtrace [12:24:57] excellent. i'll check that out. i've been looking for something to try my teeth out on with git. [12:25:01] okay, sounds good. [12:26:28] 1.4.7 is before the rx packet leak / race bug fixes from last August. [12:28:48] ah. i'll try the git master thing, since i've at least been able to get this to happen in 1.4.10. [12:30:52] there are two race conditions fixed in 1.4.11 as compared to 1.4.10 [12:31:24] spiffy. [12:31:56] i presume i want `git checkout origin/master'? [12:32:02] yes [12:32:07] thanks [12:32:12] though the clone should give you one [12:54:15] --- Simon Wilkinson has left [13:17:21] --- deason has left [13:24:14] --- stevenjenkins has left: Lost connection [13:24:14] --- mmeffie has left: Lost connection [13:35:07] --- mdionne has become available [13:35:28] --- deason has become available [14:15:48] --- Russ has left: Disconnected [14:35:41] --- mdionne has left [14:53:33] --- deason has left [14:53:37] --- deason has become available [14:56:26] --- dev-zero@jabber.org has left [15:01:08] --- Russ has become available [15:04:36] --- mmeffie has become available [15:05:07] --- mmeffie has left [15:16:34] --- Simon Wilkinson has become available [15:24:37] --- Russ has left: Disconnected [15:55:41] --- stevenjenkins has become available [17:57:37] --- deason has left [18:02:19] --- andersk@mit.edu/vinegar-pot has left [18:02:20] --- andersk@mit.edu/vinegar-pot has become available [18:02:30] --- andersk@mit.edu/vinegar-pot has left [18:02:54] --- andersk@mit.edu/vinegar-pot has become available [18:13:41] --- deason has become available [19:58:03] --- deason has left [19:59:52] --- deason has become available [20:10:52] --- Russ has become available [20:11:36] --- summatusmentis has left [20:38:51] --- dev-zero@jabber.org has become available [20:41:04] --- summatusmentis has become available [20:41:18] --- summatusmentis has left [20:41:26] --- summatusmentis has become available [21:46:49] --- Russ has left: Disconnected [21:59:42] What do I need to frob to get aklog built? [22:18:42] In particular, with a manual 'make', I am hitting aklog_main.c:181:2: error: #error "Must have either krb5_princ_size or krb5_principal_get_comp_string" even though I have krb5_principal_get_comp_string in /usr/lib/libkrb5.so [22:19:22] --- deason has left [23:00:39] --- dev-zero@jabber.org has left: Replaced by new connection [23:00:40] --- dev-zero@jabber.org has become available [23:10:15] --- reuteras has become available [23:23:21] --- Simon Wilkinson has left [23:23:21] --- Simon Wilkinson has become available