[00:46:40] --- lars.malinowsky has become available [00:52:11] --- Russ has left: Disconnected [05:59:05] --- steven.jenkins has become available [07:09:32] --- deason has become available [07:26:58] --- reuteras has left [07:29:13] --- matt has become available [07:33:44] Request for comment on an aspect of draft-wilkinson-afs3-rpc-refresh-00. [07:33:53] The various replacement file operations RPCs take a new OUT AFSFetchStatusEx and AFSVolSyncEx. [07:35:35] we agreed last week to get rid of AFSVolSyncEx and simply add the lastCreatedVolumeTime to the AFSFetchStatusEx structure [07:36:16] doing so permits InlineBulkStatus operations to be used with FIDs from multiple volumes. [07:36:40] Right. Also, noting Simon's comments on gerrit 4573, on missing ext-union. [07:37:20] My interest is in asking whether we should have in extensible (ext-union) IN structure on all of these--even if it currently is a structure containing NULL. [07:41:35] do you have proposals for what it would be used for? [07:43:39] At this stage it would I think be future proofing, but it would enable an easier path for a variety of incremental extensions. [07:43:55] One might be additional operation context related to semantics, as jhutz and I were discussing at hackathon, and was the problem I was thinking of. [07:57:49] semantics such as callback sync v async? [07:58:05] Yes, that would be one. [07:59:14] I think the fuller solution might involve more structure than just flags, but the extensible union, extended callbacks, etc, give a lot of overall flexibility, in tandem with perhaps truly new RPCs (e.g., transactions). [07:59:39] Again that's hypothetical. [08:08:16] --- lars.malinowsky has left [08:31:34] --- jaltman/FrogsLeap has left: Replaced by new connection [08:31:35] --- jaltman/FrogsLeap has become available [08:39:25] --- jaltman/FrogsLeap has left: Disconnected [08:39:37] --- jaltman/FrogsLeap has become available [09:15:45] --- ksumner has become available [09:33:13] --- rra has become available [09:36:43] --- jaltman/FrogsLeap has left: Disconnected [09:43:10] --- jaltman/FrogsLeap has become available [10:14:27] --- pod has left [10:20:22] --- pod has become available [10:26:57] --- ksumner has left [10:52:37] --- ksumner has become available [11:58:29] (sigh) [12:01:11] do i need to worry much about having more than one outstanding commit? [12:05:04] "outstanding" commit? like, submitting more than one commit at once? [12:05:28] yeah, something like that [12:05:58] i don't like independent changes becoming interwined in a sequence of commits [12:07:07] (and then having to do really mind bending things (for me anyway) to fix past submissions) [12:16:04] so, if you do everything on one branch, the commits you submit will "depend" on each other, but it doesn't prevent a change from getting accepted into the tree before the dependant commits do [12:16:39] but if you make separate branches for different, unrelated, things you want to fix (which is recommended), they won't do that [12:17:12] which you can do via something like git checkout -b myfix1 origin/master git checkout -b myfix2 origin/master [12:17:14] is that the thing that didn't let me have untracked files in the tree? [12:17:32] then 'git checkout myfix1' or 'git checkout myfix2' to switch back and forth between them [12:17:59] or just clone two entirely different git trees and repos if you don't wanna have to deal with git so much ;) [12:18:23] no, the thing that doesn't let you have untracked files in the tree is rebasing [12:18:34] so yeah, if you make one branch per commit, you shouldn't ever need to do that [12:18:47] you can just 'git commit --amend' [12:58:16] --- pod has left [12:58:33] --- pod has become available [13:10:27] --- lars.malinowsky has become available [13:32:33] --- deason has left [13:32:33] --- deason has become available [15:10:07] --- ksumner has left [15:27:31] I need to patch gerrit/git/jabber.openafs.org. Is tonight around 5pm PDT a good time for everyone? Reboot is required, so there will be a short outage. [15:28:59] fine with me [15:49:20] --- shadow@gmail.com/barnowl1CD2CB82 has left [15:49:27] --- shadow@gmail.com/barnowl1CD2CB82 has become available [16:00:22] --- deason has left [16:00:25] --- deason has become available [16:57:09] Okay, will be going ahead with the patching and reboot of git/gerrit/jabber/etc. in about five minutes. This will take the chat room off line for a bit. [17:07:04] --- LOGGING STARTED [17:07:50] --- jaltman/FrogsLeap has become available [17:08:35] --- rra has become available [17:08:45] looks like the patching went fine :) [17:09:37] hope you installed a 2.6.38 kernel and a 1.6.0pre4 afs client :) [17:13:09] * rra hehs. Actually, I didn't. :) [17:13:20] I do need to upgrade that system to squeeze at some point, though; it's still running lenny. [17:13:59] its a shame you can't have a panic trace be dumped to the chat room [17:14:29] I guess we could. serial console to xmpp gateway [17:14:35] The Linux kernel tracing stuff is kind of unfortunately not great. [17:14:42] I was running into that when trying to debug with Simon. [17:15:13] --- matt has become available [17:15:22] With Solaris, we could just configure a dump partition and when the kernel paniced, it would dump system state to that partition before rebooting, and you could then do analysis. Debian's kernel builds with all the dumping stuff turned off, for one, and then there's a bunch of hoops you have to jump through to turn it ohn. [17:40:27] --- jaltman/FrogsLeap has left: Replaced by new connection [17:40:33] --- jaltman/FrogsLeap has become available [18:06:53] --- lars.malinowsky has become available [18:07:06] --- steven.jenkins has become available [18:08:20] --- kula has become available [18:09:42] --- phalenor has become available [18:09:42] --- shadow@gmail.com/barnowl1CD2CB82 has become available [18:10:17] --- jakllsch has become available [18:27:00] --- jaltman has become available [19:16:18] --- jaltman has left: Disconnected [19:32:03] --- pod has become available [19:57:29] --- matt has left [20:49:43] afs/afs.h is an installed header file, but it references afs_ucred_t, which is not defined anywhere in the headers that we install. [20:50:44] Hm, only in #ifdef KERNEL, though. So why is the AFS Perl module defining KERNEL? [20:51:48] uh. good question [20:52:07] Ah, no, it's not. [20:52:11] We have unprotected references. [20:52:27] Lines 1443 on in afs/afs.h define static_inline functions that reference afs_ucred_t. [20:52:50] I suspect that stuff should be #ifdef KERNEL as well. [20:54:06] what's including afs/afs.h? [20:54:14] The AFS Perl module does so directly. [20:54:20] Maybe it doesn't need to? [20:54:27] ick. it shouldn't [20:54:29] It's an installed header file, though. [20:54:41] We offer it up to the world. :) [20:54:52] * rra tries taking it out and seeing what breaks. [20:55:03] sure. we offer libuafs functionality to the world. [20:55:43] (and probably most of the time you don't need it there either) [20:59:26] * rra hacks around various other compile problems. afs/afs.h doesn't appear to be needed, but this is a weird one. [20:59:28] Can't load '/home/eagle/dvl/debian/libafs-perl/src/../blib/arch/auto/AFS/AFS.so' for module AFS: /home/eagle/dvl/debian/libafs-perl/src/../blib/arch/auto/AFS/AFS.so: undefined symbol: lwp_cpptr at /usr/lib/perl/5.10/DynaLoader.pm line 192. [21:00:14] linking what into AFS.so? [21:00:36] afs/util.a, libafsrpc, and libafsauthent. Ah, hm, why are there LWP symbols when we're doing pthreads? [21:00:51] -L/usr/lib -L/usr/lib/afs -lbos -lvolser -lvldb -lafsrpc -lafsauthent -lcmd -lusd -laudit /usr/lib/afs/util.a /usr/lib/libafsrpc.a /usr/lib/libafsauthent.a -lresolv [21:00:53] Is the full list. [21:01:06] uh. what are those other libraries? [21:01:22] you've mixed libraries. all bets are off. [21:01:24] Probably something messed up in Makefile.PL. [21:01:42] Hm, nope, it's intentional. [21:01:49] That's the list used for pthreaded links. [21:01:56] What *should* we be using? [21:02:10] 'cause not all that stuff is in libafsrpc and libafsauthent, I'm pretty sure. [21:02:19] fix the real problem [21:02:21] (This all worked in 1.5, so something's changed.) [21:02:30] What's the real problem? [21:02:36] it may well not be. but you can't just decide you'll use whatever and assume it will work [21:03:27] Okay, well, taking a step back, the AFS Perl library wants to call the various userspace libraries to do all the various things AFS can do (from bos through audit), but using the pthreaded Rx code, since threaded Perl can't cope with LWP. [21:03:37] libraries built for use with lwp will depend on lwp. some functionality wasn't being built for pthreads. linking against random stuff and hoping for the best means when it breaks, you get to be sad. [21:03:38] That link line was what worked with 1.4 and 1.5 as recently as I think 1.5.57 or so. [21:04:02] that it did was luck. [21:04:04] Do we now build a pthreads version of everything? Let me see what may be missing.... [21:04:12] i doubt it. [21:04:22] you're building against 1.6, right? [21:04:25] Ah, libvolser is the culprit. [21:04:26] Yes. [21:04:32] then no, we don't. [21:05:14] Hm, so that probably means that I'm simply screwed and the AFS Perl module isn't supportable with OpenAFS 1.6, unless I'm missing something sneaky. And possibly wasn't *really* working before, although it did previously pass its test suite.... [21:05:27] other users of volser code which are threaded currently build the objects they need. [21:05:48] i bet it worked sometimes before. you were just lucky [21:06:06] we did talk about this mess at the hackathon [21:06:10] Well, the part that I don't get is that we definitely didn't link with liblwp. [21:06:18] So somehow the volser code had no LWP symbols in it. [21:06:21] And now it does. [21:06:29] Which isn't surprising; what I don't understand is why it didn't before. [21:06:53] it probably got a call to IOMGR_Select now that it didn't have before [21:07:01] e.g. your luck ran out [21:07:33] like say in vsprocs.c [21:07:51] IOMGR_Sleep. [21:08:10] Looks like 9af8d46e was the commit that added the symbol I'm actually failing on. [21:08:42] thing is, "fixing" it won't fix it. and just rebreak that issue [21:09:01] Right. It's an error recovery issue, so it's not surprising that people haven't noticed with the AFS Perl library. [21:09:57] the fun bit is Rx has some structures which contain elements related to which thread system you are using. so, mixing objects = recipe for disaster [21:10:05] Yeah, that makes sense. [21:10:16] Okay, hm, so I basically need a pthreaded volser library to support the AFS Perl module. [21:10:30] at minimum. possibly more. but at least that [21:10:34] It sounds like I should have Debian remove libafs-perl from testing for right now so that it doesn't block transitions, because this isn't going to be a fast fix. [21:19:14] What was said about it at the hackathon, btw? [21:22:48] I assume the long-term solution here is to build pthread versions of all of the libraries. Ideally by dropping LWP entirely, but possibly just as an alternate set. [21:25:56] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621999 now has a summary of the situation. [21:31:49] basically that we provide pthreads versions of the finer-grained libraries we have now (or similarly broken down) and kill off lwp. [21:32:05] Okay, cool. I'm definitely in favor. [21:33:10] and uh, promptly blew away that link. i'll go dig it out of the muc logs [21:33:26] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621999 [21:33:30] I had it right there. :) [21:33:37] It's nothing you don't already know. [21:34:41] The AFS Perl module is a fairly good test case for "we should have a real, stable API," since the stuff it wants to do is quite reasonable, and the stuff it has to do in order to get at it is pretty unreasonable (and has been for the entire history of AFS going back to Transarc, to be sure; it's not a new problem). [21:35:33] yeah. pretty much [21:42:00] So, is the only thing preventing just throwing the switch and building everything pthreaded just Ubik? Or are there other issues? [21:42:14] Does every platform we support do pthreads now? [21:42:32] marc might be done fixing ubik. it's not in 1.6.0 and it's late in the game for that [21:42:44] Oh, right, not in 1.6 to be sure. I wasn't expecting it there. [21:43:06] the last non-pthreads platform was probably sunos 4. my sunos 4 box was removed, so uh, i guess i don't care. [21:43:08] If I hack together a fix for 1.6, it would be to build a separate pthreaded version of the libraries. [21:43:39] I'm not sure if I can do that without enabling pthreaded Ubik, though. [21:44:10] i don't remember. i should look. you only "need" pthreaded ubik_Call, basically. not the rest. [21:44:36] yeah, the client only needs the easier part. [21:59:57] --- rra has left: Disconnected [22:16:39] --- Russ has become available [23:11:35] --- reuteras has become available [23:49:19] --- lars.malinowsky has left