[00:38:15] --- jaltman has left: Disconnected [01:39:41] --- Russ has left: Disconnected [02:18:50] --- Born Fool has become available [02:44:30] --- Born Fool has left [05:37:00] --- cudave has left [05:37:50] --- dwbotsch has become available [06:31:11] --- jaltman has become available [07:26:55] --- kaj has left [07:37:05] --- deason has become available [07:50:14] --- Kevin Sumner has become available [09:27:18] --- Russ has become available [09:28:47] hm, can we get rid of the IP_WILDCARDS define in ptserver? I just noticed it; it turns on/off the IP wildcarding in machine entries [09:28:56] (and is always on, currently) [09:39:19] How bothered are we that pthreaded ubik can't be built in an objdir? [09:41:05] (It also can't be built by parallel make, either) [09:41:49] --- kaj has become available [09:43:19] not building in an objdir would break building when the sources are located in readonly media? if so, I think it is an issue that needs to be addressed [09:44:13] yes, I'd prefer it fixed... [09:48:53] and IP_WILDCARDS should just always be on. [09:49:34] I have some patches, but sadly the use $<, so they need rethought. [09:51:08] gah, firefox just crapped its pants. sigh [09:51:13] mix [09:51:59] shadow: as in, you want the symbol to stay around? [09:52:58] er. which symbols? [09:53:09] Simon: you were asking before about alternatives to $<... I think you mentioned listing the .c files on the CCRULE like, which didn't sound horrible [09:53:16] i think we should axe the IP_WILDCARDS off code [09:53:21] shadow: IP_WILDCARDS [09:53:30] and nuke the ifdef [09:54:00] er, remove the _code_? we want wildcards still, don't we? [09:54:13] (or to be simpler/clearer, gerrit 2253, yay/nay?) [09:55:24] That looks right to me. [09:55:34] (I haven't verified that it's sufficient, though) [09:56:00] we want wildcards. we want to remove the non-wildcard case [09:56:24] Which is what 2253 does. [09:56:28] 2253: yes [09:56:42] well, i had no firefox, see. it decided to crash, as i mixed to all of you :\ [09:56:58] :) [09:57:24] of course, all the "addresses" patches are based over 2248, which needs minor attention before it goes. [09:57:41] At some point we should do a global search for every thing we test for definition, and work out if we ever define it. [09:57:56] --- abo has left [09:57:57] --- meffie has left [09:58:13] --- meffie has become available [09:58:30] --- abo has become available [09:58:39] --- Kevin Sumner has left [09:59:18] shadow: well, they don't actually touch the same code; it's just my mistake of being in the same branch [09:59:49] --- Kevin Sumner has become available [09:59:53] fair enough [10:00:07] (they did all pull build and work cleanly) [10:00:18] which is not a huge shock [10:01:18] with 2248... I don't see much gain in adding the new field and breaking parsers, so I'm inclined to take it out... but I get the impression that all others feel the opposite? [10:02:25] I have two concerns with 2248 [10:02:55] The first is that you're changing the meaning of a field without changing it's name. So anyone who is used to the (incorrect) value of the created field will be caught out [10:03:21] The second is that if you don't add the new field, but still make the first change, there's no way of anyone who actually needs the value that used to be reported to get it. [10:03:54] the other option was changing the documented behavior of the 'created' field, but when I brought that up last I thought that was deemed less desirable [10:04:39] In general, I think defining a to mean b is a poor solution. [10:05:06] and the second point I will admit, but I find it very unlikely; I really think everyone just thought it was actually the created time [10:05:44] But I'm sure Derrick will have view's here. Ill attract his attention by misusing some apostrophe's [10:06:09] derrick is busy proving a rebase is alas needed anyway [10:06:12] and the definition of the 'new' field is a bit fuzzy from a high-level view, since when RPCs are issued isn't clear from a user level [10:07:09] i think we're sort of boned no matter what we choose here. [10:07:15] there's also a ticket for 2248 that I forgot about, so I'd like to add the FIXES for it... but it'd be nice to fix whatever else on the same push [10:07:32] Sure. [10:07:59] basically, it's a major release. i could live with changing the output and breaking parsers, as long as we note it [10:08:09] I forget who originally noticed it was wrong... was it haba? [10:08:13] My, personal view, is that I don't care about command output because I insisted that all of the tools that we wrote here were written using the AFS libraries, rather than screen scraping. [10:08:32] So, my reaction is slightly coloured by that. [10:09:13] likewise, i think parsing is evil. but people who use it expecting to get something sensible is not horribly unreasonable of them [10:09:52] (yes, it was haba; I usefully put a link to the thread in the ticket, hooray) [10:11:15] Yay! [10:11:29] I guess I should finish off the scripts so that FIXES speaks to RT. [10:11:51] I think at some point we have to be permitted to change the output. I too am frustrated by the need to provide extra options on the command line to get access data that we believe should be provided by default. [10:12:22] I think major releases is an acceptable point. [10:12:24] I'm not sure a 1.x release is the time to make that change. When we switch to 2.x is when I think we should do it [10:12:44] --- meffie has left [10:12:46] we're already changing what parsers need to deal with now, due to dafs. [10:12:58] people *will* have to examine scripts. [10:13:02] life's hard [10:13:10] I think you have to allow yourself to do it now. Otherwise, you have to wait years before you can make the change - Anything that doesn't make 2.0 has to wait till 3.0 - no thank you. [10:13:26] --- meffie has become available [10:14:15] To improve this, I think the critical thing is making it easier for people to write reliable script interfaces to AFS. Which means we have to work on our shared library support. [10:14:35] i'll feign shock [10:14:39] Norbert's perl-AFS is great, but actually building the thing against OpenAFS is a bit of a nightmare. [10:14:49] yes, hopefully at some point we get usable libraries... or at least machine-readable output options [10:14:57] someone will try to shove libtool down my throat now. let me just pre-emptively barf at them [10:15:06] I don't care about the technology. [10:15:20] Although Russ will probably pop up to promote libtool) [10:15:35] i care to the extent that it needs to be supportable, or it needs to wait until it's supportable [10:15:38] the usual issue [10:15:54] What we really need to do is define what our API is. [10:15:57] I'm not suggesting that things that don't make 2.0 have to wait for 3.0. I'm suggesting that things that break with IBM compatibility and set a new policy such as (don't expect screen scraping to be stable between releases) should have a real "major" number change. [10:16:24] we never claimed screenscraping would be stable, so it's not a policy change [10:16:27] --- phalenor has left [10:16:31] Until we've done that, there's no point in working on the technology to provide it. We need to take a scythe to our header files. [10:16:33] we have tried. that's all. [10:17:26] (If 2.0 is Kerberos, maybe 3.0 should be a usable shared library interface, and retiring all of the old headers and libraries) [10:17:50] and make all the tools and such actually use those libraries [10:17:54] yes [10:18:29] Indeed. [10:18:32] --- Russ has left: Disconnected [10:18:34] No more static linking. [10:18:54] Simon: re pthreaded ubik: isn't this the same as tviced/tvolser ? they don't appear to be doing anything special that I immediately see [10:19:05] uh. suck it. there are cases where i want static linking even in the brave new world [10:19:50] deason: They're a mess. For objdir builds you need to handle the situation that your dynamically generated build products are in a different place from static headers [10:20:02] --- abo has left [10:20:04] And for parallel makes, you can't produce two targets with the same build rule. [10:20:20] --- abo has become available [10:20:30] They also depend on the non-pthreaded version having been built first, but don't express that dependency anywhere. [10:20:58] I get that, but... so does tviced/ not work in that case, too, or what? [10:21:08] tviced seems to work. [10:22:16] I mean, I just thought this was already solved, since we do the pthreaded/non-pthreaded thing already, and I hadn't heard about it being broken or anything [10:22:44] I fixed tviced already [10:24:45] yes... is there anything about tubik/'s situation that makes it different? or it just hadn't been done yet? [10:25:30] It hasn't been done yet. It also uses rxgen and compile_et differently (well, tviced doesn't use them at all) [10:26:31] --- phalenor has become available [10:26:32] tviced also has broken dependencies - there are no dependencies for any of the .c files. [10:41:59] Is there a sensible way to debug "pts: no quorum elected"? I am using some tricks to get things bound to a single network interface which might cause the issues. [10:42:42] you are trying to run multiple PT servers on the same interface? [10:43:54] what's in the PtLog? [10:45:35] also 'udebug 7002' [10:45:49] just that it is using the correct ip address as the primary address and that it is running unauthenticated [10:46:24] one server or two? [10:46:42] udebug tells that "I am sync site forever (1 server)" [10:47:01] ok. what's listed in CellServDB? [10:49:23] hmm, now it works, mysteriously. demo-effect ._. [10:52:35] We had problems when we moved our dbservers onto machines with multiple addresses. You want both NetRestrict and rxbind. [10:53:34] NetInfo is not enough? [10:54:04] ideally, NetInfo to add fake addresses, netrestrict to mask unused addresses, rxbind to bind to an interface [10:54:14] where "fake" in this case means nat [10:54:17] No. You end up with packets coming in on one interface, but going out on the other. In our configuration, that broke because the machines firewall blocked those packets. [10:55:06] --- Kevin Sumner has left [10:55:26] --- Kevin Sumner has become available [11:04:18] ah, found the issue. [11:04:55] if running "pts createuser" immediately after bos create ptserver... it fails with the quorum message. [11:14:46] Folk might be interested in http://homepages.inf.eda.c.uk/sxw/openafs-clang/ [11:15:03] Or rather http://homepages.inf.ed.ac.uk/sxw/openafs-clang/ [12:21:02] --- tkeiser has become available [12:22:16] --- kaj has left [12:45:49] --- andersk has become available [12:48:07] hmm, wasn't this made to work a few months ago? did it break again, or did this not ever work? $ ./translate_et -1765328370 -1765328370 (krb5).14 = [12:48:27] that code is supposed to be KRB5KDC_ERR_ETYPE_NOSUPP, I think [12:50:33] oh, hm, was that just for aklog, not translate_et? [12:54:05] it only works on windows. [12:54:22] the krb5 dependencies were never addressed on unix in a portable manner [13:13:56] aklog as well, aklog: unknown RPC error (-1765328370) while getting AFS tickets [13:15:07] this is 1.4.12.1 with mit 1.8, we set allow_weak_crypto and it is ok know. [13:15:27] (now) [13:21:11] --- meffie has left [14:32:49] any suggestions on the name for the to-exist runtime option for the fast-restart equivalent for DAFS? [14:32:56] --- phalenor has left [14:33:06] I've written something with -unsafe-attach, but I don't know if that's sufficiently scary for some people [14:33:16] works for me [14:33:35] although I might suggest -UNSUPPORTED-unsafe-attach to make it more scary [14:33:36] --- dwbotsch has left [14:33:45] --- dwbotsch has become available [14:42:57] --- phalenor has become available [15:54:32] --- deason has left [16:00:31] My change was just for aklog, not for translate_et. It certainly does work for aklog (in fact, I think the Windows change was based on the Unix) [17:21:25] --- tkeiser has left [18:13:35] --- pod has left [18:33:37] --- Russ has become available [20:22:14] --- jaltman has left: Disconnected [21:38:09] --- tkeiser has become available [21:38:45] --- tkeiser has left [21:53:19] --- Born Fool has become available [22:39:39] --- Born Fool has left [23:37:49] --- Russ has left: Disconnected