- Friday, April 16, 2021

release-team@conference.openafs.org

Friday, April 16, 2021< ^ >

kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team

Room Configuration

Room Occupants

GMT+0
[03:01:22] mvita2 leaves the room
[03:43:25] mvita2 joins the room
[12:05:58] mbarbosa joins the room
[12:10:41] meffie joins the room
[12:58:15] mbarbosa leaves the room
[12:58:39] mbarbosa joins the room
[13:29:41] Cheyenne leaves the room
[13:29:57] Cheyenne joins the room
[15:54:20] yadayada joins the room
[15:58:24] wiesand joins the room
[16:00:21] <Cheyenne> Hello all
[16:00:35] <yadayada> hi all
[16:00:58] <mvita2> hello
[16:01:13] <kaduk@jabber.openafs.org/barnowl> greetings
[16:01:35] <meffie> hello
[16:02:44] <wiesand> Hi
[16:06:54] <meffie> thanks for the gerrit wiesand !
[16:07:05] <meffie> 14594
[16:07:47] <mvita2> yay
[16:08:39] <wiesand> Yes, should be fine for 1.8.8. It will need a rebase though due to a path conflict with 14589. np.
[16:09:12] <meffie> I am working on adding a new blurb to INSTALL to mention akeyconvert and shared libraries.
[16:09:44] <meffie> which seem to be easy to miss when upgrading to 1.8.x
[16:10:16] <wiesand> Sounds like a good idea.
[16:11:15] <meffie> so far, all i have is ipum lorem
[16:11:17] <kaduk@jabber.openafs.org/barnowl> I put a call to akeyconvert in the debian package "maintainer script"
that runs on upgrade ... but I apparently didn't think through the way
the packages are divided, so now I have a bug where I try to call a
binary that isn't present.
[16:11:38] <meffie> oh.
[16:11:38] <mvita2> I am interested in 14444 as well
[16:11:49] <mvita2> also a new install issue, but not as urgent or prevalent
[16:12:05] <mvita2> it's merged to 1.8.x but not scheduled for 1.8.8 at the present
[16:12:22] <kaduk@jabber.openafs.org/barnowl> How can it be merged to 1.8.x but not scheduled for 1.8.8?
[16:12:38] <mvita2> well, it's not in the NEWS, so ....
[16:12:55] <mvita2> perhaps I assumed too much
[16:13:07] <kaduk@jabber.openafs.org/barnowl> I think that is more likely to be an omission in NEWS than an intent
to remove prior to release
[16:13:49] <mvita2> or me misunderstanding how releases are built
[16:14:11] <meffie> the tip of the branch is tagged.
[16:14:33] <meffie> so unless something is reverted before then, it will be in 1.8.8
[16:14:35] <wiesand> I either missed it, or misjudged it as not being eligible for the "user visible changes" list
[16:14:40] <mvita2> ah okay
[16:15:20] <wiesand> Yes, if it's merged it's headed for the next release. Unless we have a security release...
[16:15:21] <meffie> (assuming a security version does not steal 1.8.8, then it would be in the next number)
[16:16:46] <meffie> jinx i owe you a coke
[16:17:24] <wiesand> 14594 actually helps with 10831 :)
[16:17:52] <mvita2> I was under the misconception that each 1.8.x commit had to be cherrypicked somehow to get includediin the next point release
[16:19:20] <wiesand> No. What we call "merge on 1.8.x" is actually the cherry-pick from master to 1_8_x.
[16:20:30] <wiesand> gerrit's terminology is a bit confusing, at least to me
[16:21:35] <kaduk@jabber.openafs.org/barnowl> For bonus fun, gerrit lets you pick from a few different "merge
style"s, IIRC, which affect what the resulting git graph looks like.
[16:22:11] <mvita2> yes, git log —graph is my new friend
[16:22:26] <kaduk@jabber.openafs.org/barnowl> I really like git log --graph --oneline --decorate, yes
[16:22:29] <wiesand> Yes, it does allow merges. But not in the "strcit cherry-pick" mode we use it in. (Which is right IMO)
[16:22:58] <mvita2> already using —oneline and —decorate, agreed
[16:24:53] <wiesand> Anyway, if you see it in https://gerrit.openafs.org/#/q/status:merged , it's for the next stable release.
[16:25:32] <wiesand> Even though it wasn't merged ;-)
[16:26:55] <meffie> i guess i think of cherry-pick as a special kind of merge :)
[16:28:56] <wiesand> yes, especially because when Ben or me hit the "Submit" button, gerrit says the change is "committed" and "merged" ;-)
[16:29:14] <kaduk@jabber.openafs.org/barnowl> So what should we be doing to help with 1.8.8pre1?
[16:29:49] <wiesand> It would be nice to get some review on 14589, 14590 and 14594.
[16:29:59] <meffie> ok
[16:30:04] <wiesand> And kick me…
[16:30:26] <meffie> can we help with NEWS changes?
[16:30:46] <meffie> 14540 ?
[16:30:58] <wiesand> There'll be some more pullups later (Big Sur, obviously, probably more FBSD)
[16:32:15] <wiesand> Review of 14540  is most welcome even though it's not quite complet. Like a proposal what to write about 14444.
[16:33:37] <wiesand> But unless Cheyenne has bad Linux news, we're really really close to releasing 1.8.8 now. And again, the delays are mostly my fault.
[16:33:51] <mvita2> I think 14444 may not be an issue if the packaging creates /usr/afs/logs rather than letting bosserver do it
[16:34:09] <mvita2> but I don't know for sure which packages (f any) would do that
[16:34:34] <Cheyenne> morning builds against latest linux kernel (5.12-rc7 +) are good (both master and 1.8.x
[16:34:47] <mvita2> anyway:   "Allow bosserver audit log to open correctly for a new OpenAFS install"
[16:34:52] <mvita2> or something like that
[16:35:11] <wiesand> I'll mention it.
[16:35:23] <wiesand> Thanks Cheyenne.
[16:35:55] <meffie> thanks cheyenne!
[16:38:32] <wiesand> Any other late additions to 1.8.8 wanted? (how important are the ih changes merged recently?)
[16:39:37] <kaduk@jabber.openafs.org/barnowl> The ih changes merged on master fix a salvager crash in a rare type of
corruption
[16:41:00] <mvita2> very rare
[16:41:23] <mvita2> so it's up to you
[16:41:50] <mvita2> I of course would like to see it in 1.8.x some day
[16:42:06] <mvita2> but I wouldn't hold 1.8.8 for it
[16:42:34] <kaduk@jabber.openafs.org/barnowl> +1 "eventually but not critical for 1.8.8"
[16:43:13] <wiesand> I'll look into them. At least I'll earmark them for 1.8.9.
[16:43:31] <mvita2> IIRC I found it under lab conditions - it was not a field report
[16:44:14] <mvita2> oh, I'm wrong - the commit msg says it was seen in the field
[16:44:39] <wiesand> Hmm, one comment says it was forward-ported from a 1.6 site patch…
[16:45:07] <mvita2> but it doesn't change my opinion about "eventually but not critical for 1.8.8"
[16:45:30] <wiesand> Anyway, I'll look at the changes and the discussions in the comments, and then it's either 1.8.8 or 1.8.9, if feasible at all.
[16:45:58] <meffie> thanks wiesand
[16:47:09] <wiesand> on to other master/1.9 topics?
[16:47:37] <kaduk@jabber.openafs.org/barnowl> I did finally get to merge bigsur after last week's meeting, as was
implicitly noted earlier.
[16:47:55] <wiesand> Seen it, thanks!
[16:48:19] <kaduk@jabber.openafs.org/barnowl> I was maybe a bit under the weather most of this week and only perked
up yesterday or so, so not a huge amount to report.  I do have a thing
or two to raise visibility on, though.
[16:49:10] <wiesand> Maybe we should announce 1.9.1?
[16:49:10] <kaduk@jabber.openafs.org/barnowl> I am pretty inclined to merge 14465, that changes the interpretation
of the rx ack payload to be as a bitfield rather than an array of
bytes whose only defined value is 0 or 1
[16:49:31] <kaduk@jabber.openafs.org/barnowl> Yeah, we should probably send a note about 1.9.1; I think it's okay to
only send an email to -devel, though
[16:50:16] <wiesand> No mention on the homepage?
[16:50:43] <kaduk@jabber.openafs.org/barnowl> I forget what we've done for the devel releases in the past.  It would
be okay to put something on the homepage, I think, though.
[16:51:34] <wiesand> 1.9.0 is mentioned there. How about you send mail to -devel, and I copy that to the web site wogether with the usual boiler palte?
[16:51:34] <Cheyenne> I would also mention that 1.9.x is development and not "production" ready
[16:52:02] <wiesand> Of course.
[16:52:06] <kaduk@jabber.openafs.org/barnowl> I will try to send mail, okay.
And yes, will mention it is development and not expected to be
production
[16:54:22] <wiesand> Sorry I'll have to run in a few minutes. Will have quite a bit of time to spend on openafs later though.
[16:54:24] <kaduk@jabber.openafs.org/barnowl> I also have some pthread-bos changes loaded up, and am recalling that
there are in some sense two "versions" of that stack -- the
fine-grained one that Chas and I had worked on and a coarser-grained
one that Andrew put together.  I suspect that one of Andrew's comments
indicates the motivation for doing it that way, but I haven't
(recently) found that one yet.
[16:55:48] <kaduk@jabber.openafs.org/barnowl> And not really relevant for this meeting, but I have 14542 pulled up
and am pondering what the actual difference between the
VpioctlSw/CpioctlSw/OpioctlSw entries are for "original" or
"common/coordinated" pioctl values
[16:55:56] <meffie> progress on deorbiting lwp sounds like time well spent :)
[16:56:36] <mvita2> oh, man I hate that pioctl plumbing
[16:57:37] <kaduk@jabber.openafs.org/barnowl> I think that's about all I have for today, though.
[16:57:57] <kaduk@jabber.openafs.org/barnowl> The "rxgk-phase2" topic on the front page is itching for (my0 attention,
too :)
[16:58:10] <mvita2> +1
[16:58:28] <wiesand> Once we're at fs - any chance to make it tolerate a trailing slash?
[16:58:32] <meffie> rxgk sounds fun too.
[16:58:49] <meffie> trailing slash?
[16:59:27] <wiesand> fs lsm /afs/some/mp/
[17:00:23] <wiesand> "fs: File '/afs/some/mp/' doesn't exist"
[17:00:56] <mvita2> ^this
[17:01:09] <wiesand> ?
[17:01:32] <mvita2> I agree with you Stephan, it's an annoying quirk of fs lsm
[17:01:33] <kaduk@jabber.openafs.org/barnowl> There is some philosophical sense in which it is wrong to silently
strip the trailing slash.  I suspect I can stifle that objection,
though, if a patch appeared.
[17:01:33] <meffie> fs: you may not use '.' or '..' as the last component
fs: of a name in this fs command.
[17:01:58] <meffie> what does fs lsm /afs/some/mp/. show?
[17:02:16] <mvita2> left as an exercise for the reader
[17:02:38] <meffie> i get fs: you may not use '.' or '..' as the last component
[17:02:56] <mvita2> +1
[17:03:07] <wiesand> It's not a big deal. I just run into it every time I create new volumes on g.c.o ;-)
[17:03:50] <meffie> i'm trying to understand what you want it to do?
[17:04:07] <wiesand> yadayada did you solve the problem you mentioned a fortnight a go?
[17:04:25] <meffie> it doest make sense to list the mount of /afs/path/. ?
[17:04:49] <wiesand> mike: I want it to silently ignore a trailiing slash if the argument is a directory.
[17:05:00] <meffie> but 'doesnt exist' is good either.
[17:05:27] <meffie> ok, just treat '/afs/path/' as /afs/path' and not /afs/path/. ?
[17:05:52] <kaduk@jabber.openafs.org/barnowl> (I assume this comes up due to tab-completion?)
[17:06:02] <wiesand> right ;-)
[17:07:33] <meffie> readlink -f /afs/sinenomine.net/user/mmeffie; readlink -f /afs/sinenomine.net/user/mmeffie/
/afs/sinenomine.net/user/mmeffie
/afs/sinenomine.net/user/mmeffie
[17:07:49] <meffie> readlink seems to think that would be ok :)
[17:08:12] <wiesand> I'm just so used to so many GNU/BSD commands ignoring the trailing slash…
[17:08:52] <meffie> yeah, maybe we need better path canonicalization
[17:09:05] <meffie> making a note...
[17:09:21] <wiesand> But as I said, that's rather "wellness"
[17:10:04] <wiesand> Looks like we're finished for today?
[17:10:16] <kaduk@jabber.openafs.org/barnowl> seems like it, yes
[17:10:24] <kaduk@jabber.openafs.org/barnowl> yes
[17:10:36] <meffie> thanks all! be safe.
[17:10:37] <kaduk@jabber.openafs.org/barnowl> (wrong window on the latter 'yes')
[17:10:55] <wiesand> Let's adjourn. Thanks a lot fols!
[17:11:00] <wiesand> folks
[17:11:07] wiesand leaves the room
[17:11:21] <Cheyenne> thanks .. everyone have a safe week
[17:11:31] <kaduk@jabber.openafs.org/barnowl> thanks everyone
[17:11:49] meffie leaves the room
[17:56:44] yadayada leaves the room
[20:11:09] mbarbosa leaves the room
[20:11:39] mbarbosa joins the room
[21:29:10] mbarbosa leaves the room
[23:46:12] mvita2 leaves the room