- Friday, May 29, 2020

release-team@conference.openafs.org

Friday, May 29, 2020< ^ >

meffie has set the subject to: openafs release team

Room Configuration

Room Occupants

GMT+0
[11:27:17] meffie joins the room
[12:06:38] mbarbosa joins the room
[13:02:19] mbarbosa leaves the room
[13:02:35] mbarbosa joins the room
[15:46:34] yadayada joins the room
[15:55:16] cwills joins the room
[16:00:13] <meffie> greetings
[16:00:22] <cwills> Hello
[16:01:46] kaduk@jabber.openafs.org/barnowl joins the room
[16:01:58] kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team
[16:02:00] <yadayada> Hello All
[16:03:54] <kaduk@jabber.openafs.org/barnowl> I see Stephan sent his regrets
[16:04:07] <meffie> indeed.
[16:04:16] <kaduk@jabber.openafs.org/barnowl> Any additional news on the 1.8.6 front?
[16:04:53] <meffie> i dont think so?
[16:05:33] <cwills> With the pending gcc10 and linux-5.7 commits 1.8.x builds cleanly on linux-5.7 and fedora32
[16:05:48] <kaduk@jabber.openafs.org/barnowl> cool
[16:06:04] <cwills> with one optional commit that cleans up gcc10 with --enable-checking
[16:06:39] <kaduk@jabber.openafs.org/barnowl> I got a PR to the debian packaging with pullups of the 5.7 support
bits; I guess 5.7 is in experimental (and ubuntu?) already
[16:07:02] <cwills> 5.7 isn't out of rc yet
[16:08:37] <kaduk@jabber.openafs.org/barnowl> right, but I think the respective maintainer teams like to give early
exposure and look for breakage
[16:10:21] <cwills> clang 10 has grief on master.. the /* fall through */ and a flagged statement that has been mentioned before
[16:11:40] wiesand joins the room
[16:12:04] <cwills> The "problem" with the fall through is to do a "proper" patch, a fix for autoconf-archive is needed (one of the autoconf tests fails due to other errors being flagged in the test)
[16:12:30] <cwills> Hello Stephan.  How is your neighbor?
[16:12:40] <kaduk@jabber.openafs.org/barnowl> Oof, that's annoying (needing to patch the autoconf tests)
[16:12:42] <wiesand> I'm here, but completely unprepared. Just go on please
[16:13:06] <kaduk@jabber.openafs.org/barnowl> I hope your neighbor is stable
[16:13:19] <cwills> I've submitted a patch to the autoconf-archive folks.. but haven't heard back from them
[16:14:31] <wiesand> My neighbour is fine. She just returned from the hospital where the ambulance I called brought her a couple of hours ago. Still in a wheelchair, but she waved at me and yelled a loud "thank you".
[16:14:37] <meffie> (this is why i'm not a fan of "external)
[16:15:35] <kaduk@jabber.openafs.org/barnowl> I guess we could temporarily swap out the copy from external for one
with local patches...
[16:16:48] <kaduk@jabber.openafs.org/barnowl> I can also ask my clang contacts if there's a reason why respecting
the fallthrough comments is not done
[16:17:39] <cwills> There was a discussion about it, they even reverted a commit that had support for it :(
[16:17:51] <kaduk@jabber.openafs.org/barnowl> Oh, so maybe I don't need to do that, then.
[16:18:14] <kaduk@jabber.openafs.org/barnowl> If you have the link handy, the gory details might be of morbid
curiousity, but it's not a big deal if you don't have it handy
[16:18:26] <cwills> I think I have the link.. give me a sec
[16:20:31] <kaduk@jabber.openafs.org/barnowl> Anyway, it sounds like 1.8.6 is proceeding according to plan other
than the clang/fallthrough stuff
[16:20:52] <cwills> here's a good start for the fallthrough "thread" -> https://patchwork.kernel.org/patch/11115903/
[16:21:01] <kaduk@jabber.openafs.org/barnowl> Thanks!
[16:22:07] <kaduk@jabber.openafs.org/barnowl> I did manage to retain my chunk of allocated time last night and
reviewed a bunch of stuff.
For the timeval32 stuff, it looks like I only merged the 32-bit linux
fix but not the darwin one, the way the commits were ordered
[16:23:10] <kaduk@jabber.openafs.org/barnowl> Andrew had raised on [gerrit number to be looked up] that we should
just use our own types for osi_GetTime on all arches and that the mess
of different typedefs is not good for maintainability.
[16:24:37] <mvita2> I agree it's a mess, but I don't think the benefits of his suggested change outweigh the risks
[16:24:39] <meffie> do we need to pull up the 32-bit linux fix to 1.8.x branch?
[16:25:03] <kaduk@jabber.openafs.org/barnowl> I'm inclined to agree with Andrew -- the complexity gets pushed into
the per-platform osi_GetTime implementations, and the conversion from
the current state should be pretty mechanical.  So perhaps we should
take him up on his offer to put the change together, and see what it
looks like.
[16:25:15] <kaduk@jabber.openafs.org/barnowl> I think the intent was to pull the 32-bit linux fix to 1.8.x, yes
[16:25:25] <mvita2> yes, I put the i586 fix at the bottom so it could get merged and then ported to 1.8.x - exactly
[16:25:56] <kaduk@jabber.openafs.org/barnowl> Is there a reason why we shouldn't do the same for the darwin analogue
(14212)?
[16:26:21] <kaduk@jabber.openafs.org/barnowl> (The change on which this discussion with Andrew was happening is
14194)
[16:26:21] <wiesand> I think so, though, frankly, I personally couldn't possibly care less about 32-bit Linux…
[16:26:30] <mvita2> oh, you mean pull it to the bottom?  I could do that
[16:26:52] <kaduk@jabber.openafs.org/barnowl> It's a dying breed, yes ... there has been talk in FreeBSD of demoting
32-bit x86 to "tier 2" status.  It's just not getting tested/used very
much.
[16:27:46] <kaduk@jabber.openafs.org/barnowl> Mark: given that you think that the risks for the "unify
osi_GetTime() API" proposal are worse than the benefits, it sounds
like you don't want to implement it yourself, so we should ask Andrew
to do it?
[16:28:49] <mvita2> yes, I don't want to  push what I can't build or test myself.
[16:29:15] <kaduk@jabber.openafs.org/barnowl> Okay.  I'll reply on 14194 to that effect.
[16:29:16] <mvita2> I was able to do the testing for both DARWIN and i586
[16:29:24] <meffie> remote: New Changes:
remote:   https://gerrit.openafs.org/14234 LINUX 5.6: define osi_timeval32_t for 32-bit Linux
[16:29:38] <meffie> i hope i did it right.
[16:30:59] <kaduk@jabber.openafs.org/barnowl> Looks right from here.  Hopefully I did not misrepresent the intent
and draw Stephan's ire by making a new gerrit too early...
[16:31:54] <kaduk@jabber.openafs.org/barnowl> Cheyenne, did you see my question on 14223?  I am not actually sure
about EINVAL vs. ENOENT there
[16:32:06] <kaduk@jabber.openafs.org/barnowl> (Other opinions also welcome, of course)
[16:33:05] <cwills> Yes -- If you want I can make the change..
[16:33:33] <kaduk@jabber.openafs.org/barnowl> In the absence of other data I'd prefer to make the change, thanks.
[16:33:57] <cwills> It's simple enough
[16:34:40] <kaduk@jabber.openafs.org/barnowl> I was also hoping that someone could have a chance to look at 14230 (a
sweeping "remove IRIX pre-6.5" change).  It's not urgent, but a lot of
stuff, and maybe I should not be the first reviewer on it.
[16:35:34] <kaduk@jabber.openafs.org/barnowl> And one other "more review requested" change came out of my activity
last night: I created 14233 based on a comment I left on a change as I
merged it, so the comment didn't get lost.  But I don't feel a need to
merge my own change without additional review, there.
[16:36:56] <kaduk@jabber.openafs.org/barnowl> And on to the "1.9.x" front (vs. "master"): chances are looking good
that I'll have time to cut a 1.9.0 this weekend, since we think all
the pieces are in place already.  Which means it's maybe not premature
to think about what would go in 1.9.1 :)
[16:37:54] <cwills> 14223 just updated..
[16:38:10] <kaduk@jabber.openafs.org/barnowl> Thanks!
[16:39:35] <meffie> i guess 1.9.1 should have a pthreaded bosserver?
[16:40:34] <kaduk@jabber.openafs.org/barnowl> That would be nice, yes ... more things waiting for my review to be
reminded of
[16:40:41] <kaduk@jabber.openafs.org/barnowl> I know Andrew has some stuff up already with the "rxgk-phase2" topic,
but I was also pondering another idea: have a configure option to only
build rxgk and not have any rxkad support at all.  That would, at
least for now, assume that all fileservers support rxgk and have the
cell-wide rxgk key, since we don't have the vldb update ready, but
would allow for testing of client/fileserver interactions and such.
[16:40:58] <kaduk@jabber.openafs.org/barnowl> I'm not really sure how invasive the patch to make that happen would
need to be, though.
[16:41:39] <kaduk@jabber.openafs.org/barnowl> (Maybe that's more of a 1.9.3 or 1.9.5 goal, for example.)
[16:41:58] <meffie> hmm, i'd have to give that some thought.
[16:42:27] <kaduk@jabber.openafs.org/barnowl> Right.
[16:42:32] <meffie> seems like a good idea at first glance though.
[16:42:38] <kaduk@jabber.openafs.org/barnowl> Not urgent and pressing, but something to keep in mind
[16:43:31] <kaduk@jabber.openafs.org/barnowl> And of course other thoughts for things we can increment in 1.9.x are
always welcome, too
[16:43:42] <kaduk@jabber.openafs.org/barnowl> But that's all I had come up with for this week :)
[16:44:32] <yadayada> Some update from my side on DAFS salvager
[16:44:48] <mvita2> <perks up>
[16:44:51] <kaduk@jabber.openafs.org/barnowl> Please go ahead, Yadav
[16:44:58] <yadayada> recently our team faced strange deadlock usinf DAFS fileserver.
[16:45:29] <yadayada> during analysis it came out issues with thread dong fork and not initializing locks
[16:45:37] <mvita2> eeg
[16:45:53] <kaduk@jabber.openafs.org/barnowl> That sounds like a recipe for trouble, yes
[16:45:59] <yadayada> we have seen couple of cases and will be submitting gerrit for same in coming week
[16:46:29] <kaduk@jabber.openafs.org/barnowl> Thanks for the heads-up; we will be on the lookout for that
[16:47:21] <meffie> thank you yadayada
[16:47:22] <wiesand> It's the fileserver locking up, not the client, right?
[16:47:31] <mvita2> I've been doing salvager work myself for the last few days but I have not seen that yet
[16:47:58] <mvita2> I did wedge the SALVSYNC channel once, no other details
[16:48:29] <wiesand> I guess all it takes is the "right" usage pattern…
[16:48:29] <yadayada> it is salvagerserver deadlock, and due that fileserver doesn;t start
[16:48:50] <mvita2> hmm…
[16:48:59] <mvita2> thank you yadav
[16:49:31] <meffie> there have been such issues in the past, so it could be
[16:49:51] <yadayada> src/vol/salvaged.c , cases are around Fork
[16:50:13] <yadayada> we will create gerrit with more details
[16:50:32] <meffie> thank you!
[16:52:15] <yadayada> Also tried afsd.fuse this week, looks very interesting. As you mentioned it do not support authenticated access
[16:53:53] <yadayada> had some minor issues with way we set stack size, but that was minor, will create gerrit for same
[16:54:52] <yadayada> I tried fuse client on centos 8 and 1.8.5 codebase
[16:56:39] <kaduk@jabber.openafs.org/barnowl> will keep an eye out for the gerrits
[16:57:00] <kaduk@jabber.openafs.org/barnowl> Any other topics for today?
[16:57:57] <meffie> i am still looking at the new buildbot master log.
[16:58:16] <meffie> seems to be an issue with the new version i need to sort out.
[16:58:21] <kaduk@jabber.openafs.org/barnowl> Ah, yes, I need to get the firewall request in and do the systemctl
thing
[16:58:51] <meffie> yes, we need a port for the clients to connect to the master.
[16:59:35] <meffie> then i should be able to test with a new buildbot worker before we cut over.
[16:59:42] <kaduk@jabber.openafs.org/barnowl> *nods*
[17:00:12] <meffie> that's all i have.
[17:00:41] <kaduk@jabber.openafs.org/barnowl> Thanks for remembering about buildbot!
[17:01:30] <yadayada> nothing from my side for today
[17:01:49] <meffie> have a good weekend all. stay safe.
[17:02:32] <cwills> Have a safe weekend everyone
[17:02:37] <yadayada> Thanks
[17:02:44] <kaduk@jabber.openafs.org/barnowl> Thanks everyone; have a good weekend!
[17:03:06] meffie leaves the room
[17:32:12] yadayada leaves the room
[18:00:51] yadayada joins the room
[18:03:54] yadayada leaves the room
[19:12:58] kaduk@jabber.openafs.org/barnowl leaves the room
[19:15:34] mbarbosa leaves the room
[19:15:54] mbarbosa joins the room
[20:00:43] cwills leaves the room
[21:56:00] mbarbosa leaves the room
[22:45:03] cwills joins the room
[22:45:58] cwills leaves the room