- Thursday, January 6, 2022

release-team@conference.openafs.org

Thursday, January 6, 2022< ^ >

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

Room Configuration

Room Occupants

GMT+0
[14:36:28] Cheyenne joins the room
[16:38:52] mbarbosa joins the room
[16:56:54] meffie joins the room
[16:58:09] <meffie> happy new year!
[17:01:21] kaduk@jabber.openafs.org/barnowl joins the room
[17:01:48] <kaduk@jabber.openafs.org/barnowl> happy new year!
[17:02:54] wiesand joins the room
[17:03:11] <Cheyenne> Happy new year!
[17:03:11] <wiesand> happy new year!
[17:04:43] <wiesand> I made some progress lately, though it's hardly visible yet.
[17:05:06] <wiesand> Rebased a few changes, and pulled up a few too.
[17:05:56] <wiesand> The most interesting one right now is probably 14879
[17:06:28] <wiesand> Haven't looked at the UBUNTU test failures yet
[17:07:08] <meffie> excellent news, thank you
[17:07:50] <kaduk@jabber.openafs.org/barnowl> I pulled up the ubuntu1804 log just now, and it's ... weird.
[17:08:27] <meffie> oh the ubuntu builders run the ctap tests.
[17:09:13] <wiesand> Once that's sorted out, I think the plan was to add a 1.8-specific version of 14295 (which would resolve that issue, presumably?)
[17:09:21] <meffie> isnt there a change we need after 14879
[17:10:22] <kaduk@jabber.openafs.org/barnowl> Ah, okay.  That would make sense.
[17:10:35] <meffie> ah, yes 14295 is the master version of the "accomodate c-tap 4.7"
[17:11:27] <wiesand> and needs a serious backport to apply to 1.8.x
[17:11:51] <wiesand> Mike, I was hoping you'd take care of that?
[17:13:56] <wiesand> Otherwise, I'm plowing through the 1.8.9 candidate list. I'm close to finished, but not quite yet.
[17:15:12] <meffie> yes, i can do
[17:15:44] <meffie> i should be able to do that tomorrow.
[17:16:11] <wiesand> One open question is whether we consider 14623 (Remove kdump) and 14624 (deorbit afsinstall) suitable for the stable series
[17:16:19] <wiesand> Thanks
[17:17:26] <meffie> i think so. removing kdump will make it easier to for patched to apply
[17:18:06] <kaduk@jabber.openafs.org/barnowl> kdump we think doesn't actually work, IIRC.
[17:18:22] <wiesand> Leaving afsinstall in place would do no harm. But "remove kdump" touches quite a few files and I'd like to avoid the skew.
[17:18:45] <Cheyenne> Yeah.. kdump is pretty much broken
[17:18:55] <kaduk@jabber.openafs.org/barnowl> afsinstall also probably doesn't do anything useful, but I don't have
as clear a picture on that.
[17:19:03] <wiesand> Ok, I'll give those a try.
[17:21:13] <wiesand> I think afsinstall isn't even installed by default. And it's confined to a single subdirectory. Adding it back if it actually is missed would be easy. But I bet it won't...
[17:21:38] <kaduk@jabber.openafs.org/barnowl> indeed
[17:22:52] <wiesand> One item on the wish list was https://gerrit.openafs.org/#/q/project:openafs+branch:master+topic:apple-silicon
[17:23:12] <wiesand> There seems to be a problem with just one change in that stack
[17:23:40] <kaduk@jabber.openafs.org/barnowl> And I was pretty unproductive over the holidays (i.e., didn't look at
that stack at all)
[17:24:46] <wiesand> That was just a reminder ;-)
[17:25:34] <meffie> i think marcio said we was going to do some updates on that topic this week based on andrew's comments
[17:26:36] <wiesand> Another stack I looked at is https://gerrit.openafs.org/#/q/project:openafs+branch:master+topic:aix
- I don't expect serious problems there
[17:27:19] <kaduk@jabber.openafs.org/barnowl> The AIX stack was, I think, pretty straightforward.
[17:27:58] <kaduk@jabber.openafs.org/barnowl> The only hairy bits were about waiting on terminated children, with
some perl minutiae that I had to look up and whatnot.  But that should
be the same between branches.
[17:27:59] <wiesand> A bit scary, but I really think we want it in 1.8.x soon: https://gerrit.openafs.org/#/q/project:openafs+branch:master+topic:cleanup-LINUX_ENV
[17:29:02] <wiesand> The rest of the list is still a bit messy…
[17:29:10] <wiesand> working on that
[17:29:41] <kaduk@jabber.openafs.org/barnowl> It ought to be possible to mechanically validate the LINUX_ENV
cleanup.
[17:29:54] <kaduk@jabber.openafs.org/barnowl> I am not sure that I have a prepackaged solution to point you at for
actually doing that, though.
[17:31:02] <Cheyenne> I can help with the LINUX_ENV cleanup stuff if needed..
[17:32:13] <wiesand> Thanks. I'll ask for help if I need it.
[17:34:49] <wiesand> That's about what I have for today. Anything else on stable?
[17:35:18] <Cheyenne> clean build with Linux 5.16-final on both openafs-stable-1_8_x and master
[17:35:59] <kaduk@jabber.openafs.org/barnowl> nothing on stable from me
[17:37:08] <meffie> i have nothing new
[17:38:15] <wiesand> Thanks Cheyenne. Looks like we don't have to scramble on 1.8.9 then. Good…
[17:38:24] <kaduk@jabber.openafs.org/barnowl> On master, I'm currently making my way through 14041 (ubik testing
harness).  I find myself writing up some notes about what the
different structures do, in order to actually make sense of the code;
that may merit getting put into the commit itself.
[17:38:27] <wiesand> On to master/1.9 then?
[17:39:18] <Cheyenne> One potential upcoming Linux issue is a huge reorg in the linux header files
[17:39:42] <wiesand> great :-/
[17:40:33] <wiesand> expected to happen for 5.17?
[17:41:35] <Cheyenne> Not sure.. it's still going through upstream review/comments
[17:44:53] <Cheyenne> Ben, I pushed an update to the afs.h fix that moved the jhash include into the kernel block
[17:45:10] <kaduk@jabber.openafs.org/barnowl> oh, cool.
[17:45:52] <wiesand> that's on my watch list too of course…
[17:46:43] <wiesand> Anything else to discuss today?
[17:46:44] <Cheyenne> I was thinking / wondering if it might make sense at some point to split the kernel related stuff out of afs.h (e.g. into afskernel.h) so it's not "exported"
[17:47:13] <kaduk@jabber.openafs.org/barnowl> Probably.
[17:47:33] <kaduk@jabber.openafs.org/barnowl> I suspect that afs.h was originally intended as kernel-only, but
inadvertently leaked out into being something else
[17:49:53] <meffie> yeah. afskernel.h seems redundant, since i thought afs.h was kernel only
[17:51:58] <meffie> i wonder why it was exported?
[17:53:03] <meffie> maybe for consts like MAXVOLS?
[17:53:52] <kaduk@jabber.openafs.org/barnowl> That's my guess, yeah.
[17:54:13] <kaduk@jabber.openafs.org/barnowl> Even in openafs-ibm-1_0 `make install` would put afs.h in
destdir/include/afs, though
[17:54:34] <meffie> yeah, it was like that when we found it.
[17:54:41] <kaduk@jabber.openafs.org/barnowl> And I think I don't have a local copy of earlier stuff on this machine
[17:57:14] <meffie> i
[17:57:23] <meffie> i am sure it was always like that.
[17:58:01] <kaduk@jabber.openafs.org/barnowl> So, afskernel.h is still something to think about, it seems.
[17:58:05] <kaduk@jabber.openafs.org/barnowl> Other topics for today?
[17:59:32] <wiesand> None here
[17:59:40] <meffie> cheyenne is looking into a buildbot upgrade (testing locally first)
[18:00:09] <meffie> since we are running an old version, we need to update from time to time :)
[18:00:58] <kaduk@jabber.openafs.org/barnowl> sounds good
[18:01:12] <Cheyenne> It's looking like a fairly simple/clean upgrade at the moment
[18:01:23] <meffie> thanks
[18:02:01] <meffie> that's all i have.
[18:02:33] <kaduk@jabber.openafs.org/barnowl> okay.
[18:02:38] <kaduk@jabber.openafs.org/barnowl> let's adjourn, then
[18:02:50] <wiesand> Thanks a lot everyone!
[18:03:05] <Cheyenne> see you all next week.
[18:03:44] <meffie> thanks all.
[18:04:00] <kaduk@jabber.openafs.org/barnowl> thanks, and have a good week!
[18:04:37] wiesand leaves the room
[18:26:58] mbarbosa leaves the room
[18:27:20] mbarbosa joins the room
[19:31:46] kaduk@jabber.openafs.org/barnowl leaves the room
[21:06:36] mbarbosa leaves the room