Home
release-team@conference.openafs.org
Friday, March 27, 2020< ^ >
meffie has set the subject to: openafs release team
Room Configuration
Room Occupants

GMT+0
[12:08:41] mbarbosa joins the room
[13:14:51] meffie joins the room
[15:31:40] cwills joins the room
[16:02:36] <meffie> good afternoon
[16:02:44] <cwills> Hello
[16:04:16] <kaduk@jabber.openafs.org/barnowl> Greetings
[16:07:05] <kaduk@jabber.openafs.org/barnowl> I will plead that I was looking at Cheyenne's code to excuse my
lateness :)
[16:07:43] <cwills> Puts one to sleep O_o
[16:08:17] <kaduk@jabber.openafs.org/barnowl> It was actually kind of interesting, to see what further cobwebs are
lurking in the dark corners of the tree
[16:08:47] <kaduk@jabber.openafs.org/barnowl> Also I will note that I updated 13673 (1.9.0 NEWS), though I did not
do a full check for whether anything listed there is also listed in
the 1.8.x portion
[16:08:52] <cwills> I did find another problem with gcc-10 that will have to be addressed
[16:08:52] wiesand joins the room
[16:08:57] <kaduk@jabber.openafs.org/barnowl> Oh?
[16:09:22] <cwills> there is an expression that is failing.. I need to ask andrew about it.
[16:11:43] <cwills> The commit that I had already pushed was "recreatable" with current "ga" levels of gcc (e.g. gcc-9.2.0)
[16:13:40] <kaduk@jabber.openafs.org/barnowl> Right, since it's just changing the default behavior
[16:13:50] <kaduk@jabber.openafs.org/barnowl> of the one option
[16:13:54] <cwills> right.
[16:14:48] <cwills> oops.. sorry.. the bug is with clang-10.. sorry..
[16:15:53] <kaduk@jabber.openafs.org/barnowl> Oh hey, it looks like I can get both gcc-10 and clang-10 via debian;
that's handy.
[16:16:57] <cwills> clang-10 is just about at a "stable" release I believe..
[16:18:29] <kaduk@jabber.openafs.org/barnowl> I think so, yes.
[16:20:25] <kaduk@jabber.openafs.org/barnowl> (I think I saw Stephan join?  Feel free to cut off our idle
chatter...)
[16:22:03] <wiesand> Just chatter on. I'm here. I'm physically ok, mentally I'm not.
[16:22:39] <kaduk@jabber.openafs.org/barnowl> It's almost the weekend; you can make it!
[16:23:35] <cwills> Oh.. here's the clang-10 error: UKERNEL/osi_vfsops.c line 132 in master. complains about shifting and boolean
[16:24:23] <wiesand> New changes were pulled up to 1_8_x - anything crucial amon those?
[16:25:12] <kaduk@jabber.openafs.org/barnowl> The two I made (14104..5) are not really crucial
[16:25:55] <kaduk@jabber.openafs.org/barnowl> I just pushed them because I incorporated them into the debian package
(for 1.8.6pre1), and there is no rush to have them disappear from the
debian patches
[16:26:25] <wiesand> thanks
[16:27:03] <kaduk@jabber.openafs.org/barnowl> As it turns out, 14105 wasn't even enough to resolve the test failure
on the armhf buildd, which leaves me a bit puzzled as to what about
its network configuration makes the test fail.  I got a friend to try
on a debian armhf machine and the tests ran fine there...
[16:27:43] <meffie> is it the test that starts a vlserver?
[16:28:02] <kaduk@jabber.openafs.org/barnowl> It's volser-t, which I think means "yes".
[16:28:18] <kaduk@jabber.openafs.org/barnowl> But I *also* pulled in the "don't start if we can't bind the port"
patch.
[16:28:21] <meffie> yes, maybe 14109 helps
[16:28:31] <kaduk@jabber.openafs.org/barnowl> And it *still* failed.
[16:28:41] <meffie> there's a race condition that makes that test fail sometimes
[16:29:15] <meffie> andrew pushed 14109 to hopefully make it better
[16:29:52] <kaduk@jabber.openafs.org/barnowl> I thought 14109 was just about superuser-t?
[16:30:11] <kaduk@jabber.openafs.org/barnowl> (Which I do recall seeing puzzling non-reproducible failures on the
buildds from, some time ago.)
[16:30:15] <meffie> doh, wrong number.
[16:31:12] <kaduk@jabber.openafs.org/barnowl> (I'm almost done reviewing 14109; just convincing myself that
getppid() is right, not getpid().)
[16:32:07] <meffie> nevermind, i was remembering wrong. i thought 14109 was for the vos-t test. sorry.
[16:32:28] <kaduk@jabber.openafs.org/barnowl> No worries; I'm happy to see all these improvements coming in :)
[16:32:57] <meffie> maybe we need a way to really know if a server has started :)
[16:33:19] <kaduk@jabber.openafs.org/barnowl> I hear systemd has some IPC calls that can be used for this...
[16:33:19] <meffie> gosh that would be nice for a number of reasons.
[16:35:29] <kaduk@jabber.openafs.org/barnowl> Hmm, the clang-10 thing doesn't like
abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID;
and AFS_VFSMAGIC is defined as 0x1234 (highly creative and unique
choice...).  I could imagine complaints about shifting an 'int' into
the sign bit, but that's a constant and doesn't have the bit set that
would be shifted into the high bit by <<16, so nothing is really
jumping out at me.
[16:36:31] <cwills> Yeah.. that's the error that I got.  The question is.. should the logical OR (||) be a binary OR (|)
[16:37:28] <kaduk@jabber.openafs.org/barnowl> I quite expect so (binary OR)
[16:37:47] <kaduk@jabber.openafs.org/barnowl> (and in fact I missed that the first time I looked at it)
[16:38:04] <meffie> me too. good catch cwills.
[16:38:10] <cwills> That's the error.. the result of the expression is "true" or "false" -- 1 or 0
[16:38:40] <cwills> not AFS_VFSMAGIC shifted followed by AFS_VFSFSID
[16:38:46] <kaduk@jabber.openafs.org/barnowl> Right
[16:39:04] <cwills> there are a couple of other locations with the same "error"
[16:39:11] <meffie> fascinating.
[16:39:51] <kaduk@jabber.openafs.org/barnowl> The intent is clear, and fsid is not reallly required to be stable
across reboots, IIRC, so I think we should just fix it to bitwise-OR.
[16:39:52] <cwills> dang compilers are going to soon be writing their own code..
[16:40:20] <kaduk@jabber.openafs.org/barnowl> Clang has been suggesting alternative code with warnings for a while,
I thought.
[16:41:09] <meffie> i wonder what the hp-ux and sun compiles did.
[16:41:19] <meffie> src/afs/SOLARIS/osi_vfsops.c:    abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID;
[16:41:27] <meffie> src/afs/HPUX/osi_vfsops.c:    abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID;
[16:41:42] <meffie> maybe they did bitwise or here?
[16:42:12] <cwills> I suspect the same thing .. just blindly did the "well.. if that's what you want to do"..
[16:42:33] <kaduk@jabber.openafs.org/barnowl> I guess that per the spec the compiler can get away with making both
ORs implemented the same way...
[16:43:43] <kaduk@jabber.openafs.org/barnowl> Anyway, we seem to be still on this topic because no one else had
anything to bring up...
[16:43:52] <kaduk@jabber.openafs.org/barnowl> I guess we're all tired and ready for the weekend :)
[16:44:00] <meffie> yes, i'll be the solaris compiler just did a bitwise or, and that code was copied to HP-UX, then ukernel.
[16:44:17] <meffie> yes :)
[16:44:27] <kaduk@jabber.openafs.org/barnowl> motion to adjourn?
[16:44:41] <meffie> yes.
[16:44:41] <cwills> oh.. gcc-9.2.0 evaluates it to a 0 or a 1
[16:45:31] <meffie> oh, btw, the wiki howto build rpms clean up, inspired me to make some cleanups in makesrpm and friends.
[16:45:37] <meffie> :)
[16:45:45] <kaduk@jabber.openafs.org/barnowl> Thanks Mike :)
[16:46:14] <cwills> ./test 42 ==> (||) 00000001   (|)  1234002a
[16:46:19] <meffie> also, there are some rpmbuild warnings on fedora and centos8. i'll be pushing changes to openafs.spec. not urgent.
[16:46:45] <meffie> that's all i got. have a good weekend! please stay safe everyone!
[16:46:59] <kaduk@jabber.openafs.org/barnowl> Yes, stay safe everyone!
[16:47:10] <kaduk@jabber.openafs.org/barnowl> Thanks and have a good weekend
[16:47:17] <cwills> Thanks everyone
[16:47:23] <cwills> stay safe
[16:47:41] meffie leaves the room
[16:50:11] wiesand leaves the room
[18:05:09] mbarbosa leaves the room
[18:05:57] mbarbosa joins the room
[20:48:52] kaduk@jabber.openafs.org/barnowl leaves the room
[21:47:04] mbarbosa leaves the room
[22:52:21] cwills leaves the room