[01:31:20] --- Simon Wilkinson has become available [05:46:21] --- dev-zero@jabber.org has left [05:46:21] --- jakllsch/trantor has left [05:52:49] --- jakllsch/trantor has become available [05:54:26] --- dev-zero@jabber.org has become available [07:30:00] --- deason has become available [09:06:21] --- rra has become available [09:33:33] --- jakllsch/tarsus has become available [09:37:07] rra? I think I have a system where heimdal com_err.h is installed in /usr/include/krb5/com_err.h [09:37:22] what's the appropriate way to handle that? [09:51:49] Add more configure goo to OpenAFS's probes for com_err, I suppose. [09:52:54] You don't actually need (and should not use) com_err directly to report Kerberos errors with any modern Kerberos implementation, so OpenAFS's continued use of it is a little idiosyncratic, which means that it's not really the job of the krb5 macros. I think OpenAFS has some separate probes for it. [09:53:43] Ideally, all AFS usages of error_message and friends directly should be replaced with krb5_get_error_message, at least for Kerberos errors, but as I recall there's some complex com_err initialization issue that makes that harder than one would think. [09:55:07] there are two issues here. we use afs_com_err for all afs error processing but if the string that is returned is "not found" or something like that, then we call "com_err" to process any krb5 or system errors. [09:55:57] Right, because aklog has lost track at that point of the Kerberos context and whether it was a Kerberos error. [09:56:34] its not just aklog but translate_et and some of the processing in src/libadmin/... [09:56:36] yeah, i'm dealing with aklog :_) [09:56:39] --- sxw has become available [09:56:43] At least, that was the situation with aklog; I don't know if we have the same problem elsewhere. I looked at aklog a while back to try to fix it, and gave up due to lack of time. [09:56:56] what's RIOS in the context of the lwp code? [09:57:13] RiscOS? [09:57:17] AFS's translate_et should probably just be called afs_translate_et and only do AFS and system errors through afs_error_message. [09:57:30] libadmin is likely a harder problem. [09:58:43] Basically (jaltman knows this, but for the general record), com_err has become an internal implementation detail in both MIT Kerberos and Heimdal that one no longer should really call directly, although a lot of old code still does for various reasons. [09:59:04] translate_et needs to handle all the error codes that aklog or user tools can present to the end user. as long as krb5 errors are returned by afs tools, I believe it needs to work [09:59:22] Oh, so it's sort of blocked on fixing aklog to do the right thing. [10:00:12] aklog should never be returning internal Kerberos error messages to the user because by that point you've lost all the supplemental error state and explanation that's stored in the Kerberos context that actually explains what failed. Well, it's better than returning nothing, of course, but it means that you've already lost in some fundamental ways if all you have is the error code. [10:00:32] s/internal Kerberos error messages/internal Kerberos error numbers/ I should say. [10:00:35] aklog needs to call a library and not implement stuff itself. [10:00:40] Yeah, that too. [10:01:11] okay, this is all a little more than i was hoping i'd need to care about :_) [10:01:21] YFS published a design proposal to openafs-devel many months ago seeking assistance / volunteers to implement. Got no response on the design or the request for volunteers. [10:01:41] Simon has a partial implementation at this point because we need it for rxgk [10:02:13] jakllsch: All you need to do for your immediate need is to find where in OpenAFS's configure we probe for com_err.h vs. et/com_err.h, and add a probe for krb5/com_err.h as well, and then add another case to the #ifdef tree where we include com_err.h. [10:02:19] The rest of this is just discussion of how to fix it properly. [10:02:25] okay. [10:02:54] I assume this is more *BSD stuff? [10:03:05] yeah [10:03:14] I really wish they wouldn't move headers around. They don't have a krb5.h, only a krb5/krb5.h, as well, which is really obnoxious. [10:03:44] i have a here, fwiw [10:04:06] This was NetBSD, IIRC. They all seem to do something slightly differently weird. :) [10:04:45] OpenBSD has Heimdal without libroken, for example. Which I understand, and can even applaud, except it's One More Case in the mess that is finding the Kerberos libraries. [10:05:09] jakllsch: RIOS is defined by AIX stuff, at least currently [10:05:51] rra: ah, yes, i'm on netbsd-current [10:06:57] (which has had its heimdal updated since the stable branch) [10:07:15] (at least krb5/com_err.h hasn't moved too, or something) [10:08:37] deason: ah. so i don't have to worry about that then [10:08:45] i'm trying to figure out this PRE_Block thing [10:09:05] For arm_nbsd60 [10:10:05] (NetBSD/arm is still pre-EABI) [10:10:13] I'm not exactly sure on the details of what you're doing, but... you know lwp is going away someday, right? [10:10:32] deason: i do, but it seems to still be needed for the userland [10:10:47] it depends on what you're trying to make work [10:11:10] first thing i tried was bos [10:11:14] the default is to make everything with lwp, but... iirc, at least vos, pts etc don't really need to be [10:11:51] it might be more useful to get that stuff to build with pthreads instead... but it also may be more work, I dunno [10:11:55] (which aborted due to one of the PRE_Block checks thats' already ifdefed out on arm_linux and arm_darwin [10:12:07] how do i select the pthread build? [10:12:17] I wouldn't want to be implementing lwp stuff for a new platform, but maybe you find it more fun than I would :) [10:12:48] that's what I mean; it's not in the build system (I don't think), but they should be able to use pthreaded libraries instead without too much effort [10:13:12] and it's going to happen "eventually" anyway [10:13:24] In theory you should be able to build the userspace with pthreads (when pthreaded ubik is enabled, at least), but so far as I know, no one has yet done the work to do that. [10:13:24] well, it seemed adding arm_nbsd to the ifdef worked, for the trivial testing i did [10:13:43] and if e.g. vos were pthreaded instead of lwp, it would make looking at it in a debugger much less irritating... [10:13:44] If LWP is already ported in general to NetBSD, you may get lucky and be able to just use it. [10:14:27] yeah, lwp does arm and it does netbsd, just not both at once :-) [10:14:48] okay, yeah, I didn't mean to suggest it if you've already got something close to working or anything [10:15:35] oh fsm, i could be porting this to hppa_netbsd [10:15:52] You're likely to have more trouble there, since IIRC we dropped hppa support a while back. [10:16:09] hppa_linux never worked properly with 2.6 kernels. [10:16:16] eh, it's not like i care about using that machine for storage [10:16:34] it's mostly a make-sure-netbsd-still-works-on-it sort of machine [10:16:43] Ah, no, we still support hppa for actual hp_ux. [10:16:50] It was just hppa Linux that we dropped. [10:17:09] --- mdionne has become available [10:17:24] And that was for kernel issues, actually, so if you only care about the userspace, it might work. [10:17:31] Although I don't recall if LWP worked properly on it. [10:17:44] well, ARM still has a future :-) [10:17:57] Yeah, that's my attitude. :) [10:18:08] Let's not spend lots of time trying to support stuff that's dead. :) [10:19:02] The biggest problem with LWP is that you need setcontext, which is a mess. [10:20:37] LWP will be pulled from master within six months. I really wouldn't spend significant time building new things on top of it [10:21:33] I'm fairly sure that Simon has a patchset sitting somewhere that removes it [12:30:23] (starking back a couple hours) What's really fun is when I end up with a /usr/include/krb5.h, /usr/local/include/krb5.h which is just #include krb5/krb5.h, and /usr/local/include/krb5/krb5.h Having pieces of both heimdal and MIT installed always makes me sad... [12:36:06] --- mfelliott has left [12:48:47] --- kula has become available [12:50:54] i was thinking about the library that aklog would call today, but haven't worked up sufficient gumptions yet [12:53:52] i was trying to figure this out today, thought i'd ask here before posting to afs3-standards: i'm reading draft-wilkinson-afs3-rxgk-02, and struct RXGK_ClientInfo has a flags field, but nothing in the document explains what it is. [12:55:16] is this something that would make sense if i understood the other stuff in the document more, or is it an omission that should be pointed out? [12:57:10] --- Derrick Brashear has become available [12:58:57] since barnowl quietly didn't resubscribe me (sigh): jakllsch, the lwp on arm, you'll have the same issue linux and darwin do, and you can use either of those, and it will work. the assembler file will be the same [13:07:49] i really like how every time i come back to working on master i find src != obj problems in the build system [13:08:01] kula: That is a valid question, and almost certainly an oversight. [13:08:12] Please raise it on afs3-stds, so it doesn't get lost. [13:08:25] jakllsch: Yeah, we need a buildbot that covers objdir builds. [13:08:26] jakllsch: yeah, probably one of the buildslaves should start doing object builds so we notice. [13:08:31] heh [13:09:52] sxw: will do [13:17:29] should src/libafsauthent/Makefile.in and src/tvolser/Makefile.in be fixed separately? [13:17:40] no [13:18:35] --- Roman Mitz has become available [13:31:38] --- Roman Mitz has left [13:31:48] --- Roman Mitz has become available [13:33:07] --- sxw has left [13:40:11] --- Derrick Brashear has left [14:13:18] --- Derrick Brashear has become available [14:34:04] --- Derrick Brashear has left [15:53:11] --- deason has left [17:07:29] i have no idea how to handle aklog with the new heimdal version in netbsd-current :( [17:08:03] src/aklog/aklog.c:774: warning: 'krb524_convert_creds_kdc' is deprecated [17:08:21] though, that's not the actual fatal error [17:19:09] --- Derrick Brashear has become available [17:35:18] What's the fatal error? [17:35:36] I'm unsurprised that you're getting deprecation warnings for all the krb524 machinery. [17:41:03] well, i added a (crude) autoconf check for krb5_524_convert_principle(3), which my heimdal doesn't have [17:41:24] but the existing ifdefs weren't quite right so i didn't have some local variables i needed to replace it [17:42:35] What is its conversion principle anyway? [17:42:59] no idea, but aklog has code to replace it [17:43:37] all my libkrb5 has for 524 is: krb524_convert_creds_kdc, krb524_convert_creds_kdc_ccache, initialize_k524_error_table, initialize_k524_error_table_r [17:44:44] "Luckily", freebsd still has an old heimdal. [17:46:37] The workings of the 524 translation stuff are all opaque to me since we never used any of that when doing our realm conversion. [18:37:48] --- mdionne has left [18:39:47] --- meffie has left [19:03:17] --- rra has left: Disconnected [19:13:41] --- Derrick Brashear has left [19:13:48] --- Derrick Brashear has become available [19:20:45] --- Russ has become available [19:53:40] --- Derrick Brashear has left [19:53:52] --- Derrick Brashear has become available [20:50:58] --- Roman Mitz has left [21:19:40] --- Russ has left: Disconnected [22:26:16] --- Derrick Brashear has left [22:26:23] --- Derrick Brashear has become available