[06:22:12] --- paul.smeddle has become available [06:58:12] --- Stephan Wiesand has become available [07:02:15] --- Derrick Brashear has become available [07:04:08] Good afternoon [07:04:21] (or morning, as appropriate) [07:04:27] Hi [07:04:46] hello [07:05:12] Howdy. [07:07:19] got an agenda for today? [07:07:36] There was one in the email... [07:08:41] sparse. if that's all, fine. just wondered if there was more [07:09:09] you have something in mind? [07:09:26] hello [07:09:33] missing from that? well, simon's thing wrt perl-AFS, and the solaris 11 fixes [07:10:03] "Other changes that must be included in 1.6.2?" [07:10:36] right. that list. which i suppose we will work out now :) [07:10:57] Andrew said he'd heard back on the issues with the change to the arguments of that kernel function, I was hoping he'd be here to elaborate ... [07:10:58] (i wondered if you have a list already proposed, that we'd be discussing. seemingly not, which is fine) [07:11:26] since jeff just arrived, why not start with the windows status? [07:11:57] https://lists.openafs.org/pipermail/port-solaris/2013-January/000051.html covers pretty much what you need to know about solaris [07:12:03] but sure, windows sounds good [07:12:16] no change on windows. [07:12:40] no kfw4 changes anytime soon? [07:12:46] no one has worked on krb524 which is not specific to windows [07:13:14] --- squinney has become available [07:13:16] thanks Derrick. [07:13:41] Jeff, I think last time you had mentioned libkrb524 from krb5 1.2.x. It looks like there was some commit activity in that directory up until it was removed; is there any reason to not take the last snapshot from before it was removed? [07:14:28] (Most of the changes were on the krb524d, with some security bugs, but there were some other things too.) [07:14:30] i assume the issue is that build machinery would need to be written to do so, rather than lack of code [07:14:48] Derrick: yes. [07:15:28] But if I'm going to do it, I'd rather do it once than twice. [07:15:55] I read through the history. The code in the standalone was *beta*. It was significantly refactored by raeburn when it was integrated into libkrb5. That being said, the only portion that is required here is the client side which packs the request to send to the KDC and parses the response. If you are going to work on it we can discuss it after this meeting. [07:16:53] Okay. [07:17:27] What's next on the agenda? [07:18:06] how to proceed - wait? pre3? announce pre2? [07:18:43] well, we need a pre3 for the Perl-AFS stuff ... [07:18:54] i think it depends how much you plan to add to pre3 [07:19:05] Russ Allbery pushed changes necessary for building Debian. http://gerrit.openafs.org/#change,8872 [07:19:31] if it's a few patches you already have in gerrit which are obvious or easily verifiable, just skip to pre3 [07:19:43] There is a typo in text strings http://gerrit.openafs.org/#change,8869 [07:20:46] The data corrupting bug described in https://rt.central.org/rt/Ticket/Display.html?id=131530 and fixed on master should in my opinion get a fix applied to 1.6. http://gerrit.openafs.org/#change,8838 http://gerrit.openafs.org/#change,8839 [07:21:03] 8869 is certainly harmless. it's not too important either. [07:21:11] imo neither the min/max nor solaris changes are things which need a lot of pre-testing before being in an announced pre. [07:21:38] jeff, we took an alternate fix for the data corrupting bug in 1.6 already [07:21:55] can you update RT to indicate that? [07:21:57] namely aeb42c44bc005b8935650351470020f2e715bcb8 [07:22:52] updated rt [07:23:00] thanks [07:23:42] 8872 is required for ppc64 only? [07:24:23] we don't know. he says "at least" powerpc [07:26:12] i'd have to look at 8872 more to understand the consequences [07:26:38] It shows up at compile time. [07:28:05] including sys/param in userspace is pretty harmless. it's about the least invasive fix you could have [07:28:23] like. it's something which if it happened incidentally you wouldn't even know [07:28:48] yeah, you either get those (pretty standard) macros, or you don't and the build fails [07:28:59] I agree that it seems safe [07:31:02] then i'm just too dumb today to understand why - ok, let's pull it [07:31:55] are there any objections to the three changes for perl-afs? [07:32:03] none here. [07:32:34] paul, ok with them? [07:32:38] not from me [07:32:39] Yup! [07:33:05] (I am now, after the kerfuffle we had about them for pre2) [07:34:06] ok, how about the solaris 11.1 ones? [07:35:11] just looking .. [07:36:05] 8889, 8890 are pretty mundane. 8896, 8897 impact only solaris 11. the earlier url i sent to the port-solaris list explains why both are correct. [07:37:44] Ok. I've read that mail. Seems pretty straightforward, but has it seen any testing at all? [07:38:02] I notice buildbot hasn't even verified the patches yet ;) [07:38:27] 8896/7 were uploaded during the meeting... [07:39:04] they're cherry-picks [07:39:13] I agree that the issue should be addressed in pre3. Hopefully those patches address it. [07:39:29] the platform code is identical between master and 1.6 (on solaris) [07:40:25] so, pull those 4? [07:40:39] (once verififed) [07:40:54] that would be my take [07:41:26] I guess -- I feel unhappy that no one can say that they are running a client on solaris 11.1 with those patches -- be nice if Andrew was here. [07:45:29] we can discuss it with andrew by email later, then decide.. [07:45:53] Ok. [07:45:58] Any other changes? [07:46:19] 8866/67? [07:47:04] you want 8867 for sure. 8866 is harmless if you have it. [07:47:52] 8867 fixes a regression which is since 1.6.1 [07:48:34] Very annoying regression when stumbled upon, too. [07:48:39] Okay. [07:48:47] ok. [07:49:06] 8868? [07:49:24] you should take 8840 since it just uses a macro in place of a constant, and the macro evaulates to the same [07:50:02] 8868, well... it's not a recent regression. i think it merits inclusion but it's not the easy case everything else we talked about today is [07:50:46] andrew didn't make it urgent either - lets postpone 8868? [07:50:52] the only other one worth mention is 8801. [07:51:10] which is correct, and pretty non-invasive. [07:52:28] you really mean 8840? [07:53:08] no, i mean 8801 [07:53:27] oh. for AFS_LS_ALL? yes 8840 [07:53:37] I think we should take 8801. Paul? [07:54:15] Yeah [07:54:20] just looked at it [07:54:37] 8840 depends on "give up callbacks at shutdown" - is that for pre3? really? [07:55:13] ah right. AFS_LS_ALL isn't already in this code. so never mind 8840 [07:55:15] ah, good catch [07:55:21] or rather, "lack of" AFS_LS_ALL [07:55:23] --- deason has become available [07:55:27] well, it wouldn't have applied :) [07:55:59] hello Andrew [07:56:19] Andrew, do you have a client running on Solaris 11 update 1 with the patches you submitted? [08:00:01] stephen, were you able to do any tests with pre2? [08:00:55] I've not had a chance to test beyond compiling it all on fedora 15,16,17 and centos 5,6 [08:01:04] That all succeeded this time around [08:01:28] that's something, thanks [08:01:29] sorry reading reading history; yes 8840 wasn't intended for a 1.6.2; it's just whenever guacb is applied [08:01:30] Just about to start with centos/sl 6. We no longer have any sl5 infrastructure to try it on though. [08:01:57] I brought up a solaris 11.1 with the sol 11.1 patches, and it works, but I'm not stressing it [08:02:35] we still have plenty (sl5) ... have been running a few clients and a dafs server on sl5 since christmas [08:02:52] there is another site probably using it more; I assume I'll hear something if it breaks, and I can get some conformation they're running it if you want [08:05:24] well, "works" is better than nothing [08:06:13] gerrit 8818? [08:06:30] oh wiat, that wasn't intended to be merged [08:06:59] we need something for that issue, though, if we want irix to build [08:07:34] I don't know how urgent that is ... [08:07:44] which is 8816 [08:07:49] offsetof() [08:08:29] are there known sites running servers on irix? [08:09:06] at this point i don't know who is still using irix for anything. the last site i knew of has been quiet [08:09:07] 8813 has a more conservative change of reverting the relevant code, if that makes it easier [08:10:45] I do have an O2 under my desk. It might even boot, but I don't have an account on it. [08:11:14] i actually have one also, but the last time i tried it the disk didn't spin up. something might be loose [08:11:33] "I have lots of spare parts, too." [08:12:14] Last Irix box I used was just managing an archaic tape library. What a sad end. [08:12:35] ok, maybe 8813/18 could wait? [08:15:20] I'm okay with that [08:17:03] so, quite a few changes for pre3 [08:17:38] back to "how to proceed?" [08:18:13] None of them are massively invasive, or require new changes to be submitted [08:18:37] I say we integrate those agreed on today, and tag a pre3 (i.e. skip the pre2 announcement) [08:18:49] that sounds good [08:19:13] ok. [08:19:19] yes [08:19:45] Great. [08:19:59] Any other business? [08:20:08] tell me when you are ready for a tag. [08:20:16] will do [08:20:45] should we wait for ben & jeff to come up with a statement regarding the krb524 timeline? [08:21:06] to... release final? pre3? something else? [08:21:18] pre3 [08:21:22] no [08:21:46] Okay, cool. [08:22:18] ok, fine. paul and me will just go ahead with pre3 then. [08:23:04] Good stuff. I can write up some minutes by trawling the history. [08:23:30] I think we should be able to have pre3 ready tomorrow. [08:24:05] Paul: yes, thanks for writing minutes. [08:25:45] Anything else? Got some firefighting to do here... [08:26:28] Not from me. [08:27:00] --- squinney has left [08:27:06] Ok, thanks everyone! [08:27:26] --- Stephan Wiesand has left [08:45:31] --- meffie has become available [08:49:54] You missed the meeting Mike [08:52:41] nothing exciting happens. [08:53:17] happened. [08:53:34] I'll send that out as the minutes? [08:53:37] ;-) [08:55:16] paul.smeddle: yeah, sorry. read the scroll back. [08:55:56] mike: np, it was informational, rather than an accusation [09:01:08] --- paul.smeddle has left [09:27:02] --- Derrick Brashear has left [10:02:47] --- meffie has left [11:23:51] --- Derrick Brashear has become available [12:38:26] --- deason has left [12:38:27] --- deason has become available [13:47:27] --- Derrick Brashear has left [13:59:55] --- Derrick Brashear has become available [16:02:14] --- deason has left