Home
release-team@conference.openafs.org
Friday, January 11, 2019< ^ >
Room Configuration
Room Occupants

GMT+0
[13:52:04] <kaduk@jabber.openafs.org/barnowl> [checking connectivity]
[13:59:51] wiesand joins the room
[14:00:10] <wiesand> [works for me]
[14:00:30] meffie joins the room
[14:00:39] <meffie> ping
[14:00:47] <wiesand> pong
[14:01:01] <meffie> good afternoon!
[14:01:08] <wiesand> good morning
[14:02:00] <wiesand> I've been busy with private stuff, and will be so for the next five days.
[14:02:08] <wiesand> SO, not much progress.
[14:02:17] <meffie> ah, ok.
[14:02:45] <wiesand> I hope to be "back to normal" next Thursday.
[14:02:47] <meffie> do we have an idea when the ubik changes in 1.6 will be released?
[14:02:59] <meffie> that is 1.6.24?
[14:03:32] <meffie> i get asked a lot :)
[14:03:33] <wiesand> 1.6.24pre1 "soon"
[14:04:16] <meffie> that's what i tell people when they ask :)
[14:04:32] <kaduk@jabber.openafs.org/barnowl> I had a crazy "first week back" last week and was thus pretty busy.
Starting to look at stuff again, though (currently bogged down in one
of the pthread conversion commits; lots of fiddly makefile bits)
[14:04:42] <wiesand> really sorry, it's the best answer I have a.t.m.
[14:05:11] <meffie> yeah it's been busy start of the year here too.
[14:05:44] <meffie> and my december project continues :(
[14:06:10] <meffie> (sorry about the makefile fiddly bits.)
[14:06:14] <wiesand> yes, my private project should have been finished in december too :-(
[14:06:35] <meffie> and I think mark is still not feeling well yet
[14:07:42] <wiesand> re 1.6.24: I guess on top of the changes discussed for inclusion so far, we want those two pulled up by Jeffrey shortly after last week's meeting?
[14:08:23] <wiesand> 13423 13424
[14:08:30] <meffie> i think so
[14:08:30] <kaduk@jabber.openafs.org/barnowl> (I have a vaguely 1.6 topic when we have a break)
[14:08:48] <wiesand> go ahead
[14:09:40] <kaduk@jabber.openafs.org/barnowl> I got ap rivate mail asking about srpms for 1.6.23
[14:09:40] <wiesand> (I think otherwise 1.6.24pre1 is straightforward - it just needs doing)
[14:10:36] <kaduk@jabber.openafs.org/barnowl> And it was pointed out that openafs.mit.edu, the machine running
gerrit/builtbot/etc., is running RHEL6, and I have root access to it.
So I was wondering if people thought it would be weird for me to
make+publish srpms on that machine, even if I can't necessarily test
them very well.
[14:11:19] <kaduk@jabber.openafs.org/barnowl> I think we could also hook Stephan up with shell (non-root) access if
that would be useful, though I mostly assumed that you had plenty of
RHEL floating around that you could use.
[14:11:32] <meffie> i've put rpms + sprms here; https://download.sinenomine.net/openafs/bins/1.6.23/rhel7/x86_64/
[14:11:56] <meffie> those were built with fedora mock.
[14:12:15] <kaduk@jabber.openafs.org/barnowl> What I posted at
https://lists.openafs.org/pipermail/openafs-info/2018-October/042567.html
was enough to get him set for now, so there's nothing urgent here.
[14:12:31] <wiesand> yes, plenty of EL around here, no shell access to openafs.mit.edu needed for that purpose
[14:12:46] <kaduk@jabber.openafs.org/barnowl> Thanks for confirming :)
[14:13:15] <wiesand> one more thing that "just needs doing"
[14:14:04] <kaduk@jabber.openafs.org/barnowl> The main point here being, I think, that the only missing bits when I
cut a release vs. Stephan doing so are the srpm bits, and this seems
like an okay way to close that gap, at least to me.
[14:14:18] <kaduk@jabber.openafs.org/barnowl> But I don't want to sping it on people unawares :)
[14:14:50] <meffie> would we make an srpm for rhel 6 and one for rhel 7? and later one for rhel 8?
[14:15:17] <meffie> if i recall we could not use the same sprm for 6 and 7?
[14:15:42] <kaduk@jabber.openafs.org/barnowl> That seems like too much work :)
I had also heard that the 6 one worked everywhere
[14:15:45] <wiesand> I think we should have one for al EL versions supported
[14:16:00] <meffie> yeah, agreed.
[14:16:16] <wiesand> er, only one
[14:17:03] <kaduk@jabber.openafs.org/barnowl> Sounds like a plan, then -- thanks
[14:17:03] <meffie> that would be best.
[14:17:22] <meffie> thanks ben
[14:18:09] <wiesand> creating and uploading an srpm is really no big deal
[14:18:12] <meffie> ah... reading your mail. the filedigest algo was the thing that bit me in the past!
[14:18:25] <wiesand> it's more work to update the web page to show it
[14:20:49] <wiesand> I think one thing that kept me from uploading an srpm for 1.6.23 was that Steven crafted his own one at ed.ac.uk
[14:20:51] <meffie> i'll talk to cheyenne about the wiki updates for rpms ben mentions in that mail.
[14:20:55] <kaduk@jabber.openafs.org/barnowl> Er, and backing up to the previous topic I also think we want the two
changes that Jeffrey pulled up
[14:21:28] <wiesand> ok, thanks
[14:23:11] <wiesand> review should be sufficient given that these are the 3rd generation of those changes
[14:24:32] <meffie> we could do some crazy things with those "user" bits in the rx header :)
[14:25:04] <kaduk@jabber.openafs.org/barnowl> Rx is ... not the very model of a modern protocol design
[14:25:24] <meffie> heh
[14:26:06] <wiesand> I think there's not much to talk about regarding 1.8.3 either (in addition to what was said last week)
[14:27:09] <meffie> i think andrew is looking at 13390 (removing rxatomic bitops)
[14:27:53] <kaduk@jabber.openafs.org/barnowl> It seems like it ought to be such an easy thing to do, and yet...
[14:28:15] <meffie> seem it was a bad merge/cherry-pick commit at some point. the ifdef mazes killed me.
[14:28:27] <kaduk@jabber.openafs.org/barnowl> Yeah, seems likely :-/
[14:32:19] <kaduk@jabber.openafs.org/barnowl> I removed the -2 on 12381 per request; anyone other than mike want to
look at it or should I just merge it with the current level of review?
[14:33:46] <wiesand> a bit more review would be good imho
[14:34:26] <meffie> thank you ben. that is the commit that we are currently using. but it just dumps the "raw" dirobject. i wonder if we should change the command line options to say so. in the future we man way afsio to parse the dirobject?
[14:34:59] <kaduk@jabber.openafs.org/barnowl> I could go either way on that one (viz. unix "do one thing and do it
well")
[14:35:25] <meffie> ok, thanks.
[14:36:25] <meffie> we use this to look for directories that are nearly full or badly fragmented.
[14:38:23] <wiesand> Anything else to discuss today?
[14:38:43] <meffie> ben, do you have any other gerrits blocking on my update?
[14:38:57] <kaduk@jabber.openafs.org/barnowl> I don't remember any offhand
[14:39:03] <meffie> thanks.
[14:40:11] <meffie> thats all i have, thanks.
[14:40:29] <wiesand> Looks like we're finished then. Adjourn?
[14:40:38] <kaduk@jabber.openafs.org/barnowl> Do you have any timely/critical gerrits blocking on my review?
[14:40:58] <meffie> none come to mind.
[14:41:26] <meffie> let me know if i need to make more changes to kill lwp more :)
[14:42:13] <kaduk@jabber.openafs.org/barnowl> You'll be the first to know :)
[14:42:26] <meffie> excellent. have a good weekend.
[14:42:29] <kaduk@jabber.openafs.org/barnowl> Okay, thanks, and let's let Stephan finish his call to adjourn
[14:42:52] <wiesand> Thanks a lot Mike & Ben! Hope Mark gets well soon.
[14:43:14] wiesand leaves the room
[14:43:17] meffie leaves the room
[15:29:25] meffie joins the room
[16:27:08] meffie leaves the room