- Friday, May 22, 2020

release-team@conference.openafs.org

Friday, May 22, 2020< ^ >

meffie has set the subject to: openafs release team

Room Configuration

Room Occupants

GMT+0
[12:18:33] mbarbosa joins the room
[13:50:25] meffie joins the room
[13:54:33] meffie leaves the room
[13:54:34] meffie joins the room
[15:24:51] kaduk@jabber.openafs.org/barnowl leaves the room
[15:26:13] kaduk@jabber.openafs.org/barnowl joins the room
[15:49:06] yadayada joins the room
[15:56:24] cwills joins the room
[16:00:02] <kaduk@jabber.openafs.org/barnowl> greetings
[16:00:09] <cwills> Good morning
[16:00:21] <yadayada> Hello All
[16:00:35] <meffie> hello
[16:01:10] <kaduk@jabber.openafs.org/barnowl> Thanks for your notes on running through the rxgk test setup,
Cheyenne!
[16:01:31] <kaduk@jabber.openafs.org/barnowl> I am a little embarassed that I failed to include "configure with
--enable-rxgk" in the first place :)
[16:01:50] <cwills> Not a problem.  I did find an unrelated bug if BosConfig was mis configured
[16:02:17] <kaduk@jabber.openafs.org/barnowl> misconfigured as in syntactically malformed?
[16:02:37] <cwills> If you don't have all the parm statements for a dafs bnode you get a segfault
[16:02:51] <cwills> I submitted a simple patch already
[16:02:52] <kaduk@jabber.openafs.org/barnowl> Oh, yeah, that doesn't seem surprising.
[16:03:06] <kaduk@jabber.openafs.org/barnowl> OTOH, manually editing BosConfig is not exactly a supported operation
[16:04:43] <kaduk@jabber.openafs.org/barnowl> That's 14223?
[16:05:04] <cwills> Yes
[16:06:04] <kaduk@jabber.openafs.org/barnowl> thanks
[16:06:09] wiesand joins the room
[16:06:23] <wiesand> sorry for being late
[16:07:20] <kaduk@jabber.openafs.org/barnowl> I think it's within acceptable parameters
[16:07:55] <kaduk@jabber.openafs.org/barnowl> I see some finalize-1.8.6pre3 bits in gerrit; do you need things from
us in order to make that happen?  (E.g., review on the linux-5.7
stuff?)
[16:08:32] <wiesand> I was just about to mention that, yes, review on https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x+topic:linux-5.7 would be helpful
[16:08:54] <wiesand> as well as on the finalize-1.8.6pre3 bits
[16:09:41] <cwills> I added a new commit (14217) that fixes building on fedora32
[16:09:54] <wiesand> I'm slightly inclined to include 14104
[16:10:16] <wiesand> (especially because there's a path conflict with 14217 already)
[16:11:15] <kaduk@jabber.openafs.org/barnowl> Yadav would probably appreciate having 14104 (but you did write
"inclined", not "disinclined", so I'm not sure what the path-conflict
note implies)
[16:11:53] <wiesand> I'm a bit confused about 14130 - how important is that? It applies to 3.17 but not 4.x and 5.x?
[16:12:31] <kaduk@jabber.openafs.org/barnowl> I think it applies to 4.x and 5.x
[16:12:33] <cwills> It's 3.17 or higher
[16:12:50] <yadayada> right > 3.17
[16:12:50] <kaduk@jabber.openafs.org/barnowl> So we operate with degraded functionality on "recent" linux
[16:13:07] <wiesand> Yes, inclined. The path conflict note implies that it would help to get one of the conflicting changes merged rather sooner than later.
[16:14:47] <wiesand> since 3.17 is not that recent, I'ld like to defer that to 1.8.7 as discussed last week
[16:15:23] <yadayada> 14104 change is quite simple and important for ppc64le, so better it get merged soon
[16:15:54] <wiesand> cwills: thanks for 14217; I just love those sweeping changes...
[16:17:08] <wiesand> ok, 14104 to make pre3, plus linux 5.7, the rest deferred to 1.8.7, hope that's ok with everyone
[16:17:19] <cwills> The new compilers are causing grief in other places as well.  Linux kernel had to deal with clang not recognizing the "/* fall through */" comments
[16:17:42] <cwills> Without 14217 openafs will not build on fedora32
[16:18:41] <cwills> (fedora 32 has gcc 10 as it's default compiler)
[16:18:43] <wiesand> bleeding edge fedora would have to wait for 1.8.6pre4 then…
[16:19:16] <wiesand> 14217 is just a bit too large for my taste for inclusion at this stage
[16:19:51] <wiesand> I also understand it's not quite the same as on master due to code skew?
[16:20:06] <kaduk@jabber.openafs.org/barnowl> It looks like fedora 32 was released just under a month ago?
[16:20:31] <cwills> Correct.  Had to revert a couple of hunks and rename the offending globals so there would not be a duplicate
[16:20:51] <wiesand> But sorting such issues out is why we're meeting here…
[16:21:40] <cwills> Also.. building with gcc 10 and --enable-checking still fails on 1.8.x without 14207
[16:23:08] <wiesand> My usual preference is to pull up the changes from master causing the need make changes different on stable.
[16:23:25] <kaduk@jabber.openafs.org/barnowl> I just merged 14207 on master a few minutes ago
[16:24:20] <wiesand> 14207 merged on master 11m ago… I'd really like to get 1.8.6pre3 out within a few days now and leave the rest to 1.87pre1
[16:24:32] <kaduk@jabber.openafs.org/barnowl> Cheyenne, do you know which changes would need to be pulled up from
master as prerequisites in order to avoid needing to tweak 14217
w.r.t. the master version?
[16:24:46] <cwills> Get rid of LWP
[16:25:00] <kaduk@jabber.openafs.org/barnowl> Oh.
[16:25:02] <wiesand> yikes
[16:25:04] <cwills> the conflict is due to the "terminationEvent" flag that is passed to LWP
[16:25:50] <cwills> oneShotCode = LWP_SignalProcess(&fs_terminationEvent);
[16:26:26] <wiesand> in this case I'll agree that modifying the change is unavoidable - don't think we want to remove LWP from the current stable series
[16:27:36] <kaduk@jabber.openafs.org/barnowl> Would it be tolerable to defer 14217 to 1.8.7 and note the issue in
the release notes, with setting -fcommon as a workaround?  (We'd need
to test that just passing CFLAGS=-fcommon to configure would actually
work, of course.)
[16:27:48] <cwills> On master terminationEvent was unreferenced/unused so the master commit just deleted the variable.  With 1.8.x I needed to simply rename the variables because afsmonitor pulls in from both cm and fs
[16:28:34] <cwills> I'll give that a try to see if passing CFLAGS=-fcommon works and will update 14217 with a note
[16:28:45] <kaduk@jabber.openafs.org/barnowl> It looks like Andrew just commented on 14217 as well
[16:29:31] <wiesand> looks like, yes
[16:30:27] <kaduk@jabber.openafs.org/barnowl> Cheyenne, do you have a sense for how soon you could get the
CFLAGS=-fcommon data point?
[16:30:39] <cwills> I'm about to do a test build
[16:30:58] <wiesand> we'll obviously have to take it sooner or later, but I'm leaning towards rather a bit later and in any case after due review
[16:31:06] <kaduk@jabber.openafs.org/barnowl> Right
[16:31:47] <wiesand> last week there was mention of a possible macOS build fix required due to Xcode changes - any news on that?
[16:32:02] <kaduk@jabber.openafs.org/barnowl> So I'd propose: if the test is successful, proceed with Stephan's
current plan; if the test fails, we get a lot of eyes on 14217
ASAP and try to trust that the review will be good enough and put it
in 1.8.6
[16:32:37] <yadayada> There was issue with my SDK on 10.15.4. I reinstalled xcode and with that build on 10.15.4 succeeded. So we are good with Catalina
[16:32:41] <wiesand> sounds like a plan
[16:33:01] <wiesand> yadav: thanks!
[16:33:24] <wiesand> anything else on stable for now?
[16:33:31] <meffie> thanks yadayada
[16:33:45] <kaduk@jabber.openafs.org/barnowl> I don't think I have anything else for stable
[16:33:56] <kaduk@jabber.openafs.org/barnowl> But I'm not the usual suspect there, I suppose...
[16:34:37] <meffie> i think mark v pushed something for the tumbleweed ?
[16:34:38] <wiesand> Let's go on with master/1.9 then?
[16:34:52] <meffie> the 32 bit time thing?
[16:35:06] <kaduk@jabber.openafs.org/barnowl> Yeah, 14216
[16:35:36] <kaduk@jabber.openafs.org/barnowl> which is (at present) part of a big stack
[16:35:36] <meffie> ah, thank you.
[16:36:05] <kaduk@jabber.openafs.org/barnowl> (though each part of the stack is pretty small)
[16:37:08] <wiesand> pity
[16:37:18] <kaduk@jabber.openafs.org/barnowl> Not too much from my end this week on master -- I had allocated a few
hours yesterday for openafs but fell asleep instead
[16:37:39] <meffie> looks like it does not need to be in that stack tho? maybe i can be a separate commit?
[16:37:42] <wiesand> [gone for a minute - have to move the sprinkler]
[16:38:04] <kaduk@jabber.openafs.org/barnowl> I expect it would be pretty easy to extricate from the stack, yes.
[16:38:25] <mvita2> I would be glad to pull it out if you like
[16:38:46] <mvita2> can I just remove the topic?
[16:39:06] <mvita2> or do you want me to resubmit?
[16:39:15] mbarbosa leaves the room
[16:39:17] <kaduk@jabber.openafs.org/barnowl> I think that would make wiesand happier, though no guarantees about
1.8.6 inclusion.
I think you probably want to rebase/cherry-pick it to just have
current master as parent
[16:39:30] <mvita2> okay
[16:39:55] <mvita2> unfortunately the other cache-metrics stack won't pass buildbot without it
[16:39:55] <wiesand> [back]
[16:40:08] <meffie> you can change the topic on any gerrit you created.
[16:40:22] <mvita2> but I guess I could leave it in that stack as well and just mark it -1
[16:40:54] <wiesand> does it have to sit in the middle of the stack?
[16:40:56] <mvita2> well, no, that's not true - we don't have a 32bit builder, so it's fine
[16:40:59] <meffie> so if you cherry-pick that one to master, rebase the other stack on top of it.
[16:41:14] <kaduk@jabber.openafs.org/barnowl> That probably works.  The "right" thing to do is to rebase the
cache-metrics stack on top of the independent other change, but it's a
bit of churn
[16:41:16] <wiesand> that's what I meant ;-)
[16:41:32] <mvita2> sorry for the churn
[16:41:36] <kaduk@jabber.openafs.org/barnowl> I think meffie, wiesand, and myself are basically saying the same
thing.  Hopefully not too confusing
[16:41:44] <meffie> heh.
[16:42:08] <wiesand> if ti is, neglect my comments and go with those of Ben and Mike
[16:42:08] <meffie> thank you mark.
[16:42:24] <kaduk@jabber.openafs.org/barnowl> It's a long weekend here, so hopefully I can get at least 14216 merged
[16:43:17] <wiesand> seconded - thanks Mark
[16:43:27] <kaduk@jabber.openafs.org/barnowl> Anyway, it sounds like 32-bit linux was the last 1.8.x topic
[16:43:39] <wiesand> right
[16:43:51] <cwills> first "check" on using CFLAGS=-fcommon seems to work.. doing a quick build on a fedora32 system just to reverify
[16:44:20] <kaduk@jabber.openafs.org/barnowl> So the main master/1.9 news is that Cheyenne reports success with the
rxgk testing (as I mentioned at the start of the meeting), which
unblocks 1.9.0
[16:45:12] <kaduk@jabber.openafs.org/barnowl> I don't know if anyone has other considerations to mention w.r.t.
1.9.0 -- should I just cut the release when I have a chunk of time?
[16:46:27] <meffie> i think so.
[16:47:06] <kaduk@jabber.openafs.org/barnowl> Okay, thanks.
[16:48:16] <wiesand> +1
[16:48:28] <kaduk@jabber.openafs.org/barnowl> Any other master topics?
[16:48:52] <cwills> I'm just about done with the fcommon test on fedora
[16:49:01] <meffie> none from me.
[16:49:24] <yadayada> none from my side too
[16:49:27] <cwills> CFLAGS=-fcommon ./configure .... ;make    -- okay on fedora32
[16:49:45] <kaduk@jabber.openafs.org/barnowl> Cool, thanks
[16:50:02] <cwills> (just can't use --enable-checking either since there is another warning/error)
[16:50:19] <kaduk@jabber.openafs.org/barnowl> --enable-checking is mostly for us devs :)
[16:50:32] <kaduk@jabber.openafs.org/barnowl> Motion to adjourn?
[16:50:47] <meffie> second. have a safe weekend all.
[16:51:00] <cwills> It's Friday.. everyone have a safe weekend
[16:51:06] mbarbosa joins the room
[16:51:08] <yadayada> Thanks All
[16:51:09] <kaduk@jabber.openafs.org/barnowl> Thanks everyone, and have a safe weekend
[16:51:44] <wiesand> Thanks a lot everyone!
[17:26:17] meffie leaves the room
[19:08:20] mbarbosa leaves the room
[19:08:38] mbarbosa joins the room
[20:31:03] wiesand leaves the room
[21:26:42] cwills leaves the room
[21:51:52] mbarbosa leaves the room
[23:26:41] kaduk@jabber.openafs.org/barnowl leaves the room