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

GMT+0
[07:57:07] meffie joins the room
[08:01:47] meffie leaves the room
[08:01:47] meffie joins the room
[10:17:09] meffie leaves the room
[10:17:09] meffie joins the room
[10:21:02] meffie leaves the room
[10:21:03] meffie joins the room
[11:11:56] meffie leaves the room
[11:11:56] meffie joins the room
[11:21:12] meffie leaves the room
[11:21:13] meffie joins the room
[12:19:23] mbarbosa joins the room
[15:26:47] cwills joins the room
[15:53:22] wiesand joins the room
[15:56:33] yadayada joins the room
[15:59:58] <wiesand> moinmoin
[16:00:10] <cwills> Hello
[16:00:25] <meffie> hello
[16:00:29] <kaduk@jabber.openafs.org/barnowl> greetings
[16:01:19] <yadayada> Hi All
[16:01:23] <wiesand> I finally managed to send the 1.8.6pre2 announcement today. Shame on me.
[16:02:20] <wiesand> I also asked Berthold to  give it a try in RT #135098
[16:02:34] <wiesand> Any test results yet?
[16:03:26] <wiesand> I'll take the silence as a no…
[16:03:30] <meffie> i've not heard anything. cwills put rpms for 1.8.6pre2 on our download site.
[16:03:34] <kaduk@jabber.openafs.org/barnowl> I only just pulled the mail from Berthold out of my spam quarantine,
so thanks for the quick reply to him
[16:04:51] <wiesand> The top open issues for 1.8.6 final on my list are Linux 5.7 and that i586 Tumbleweed thing.
[16:05:04] <wiesand> They're still being worked on, right?
[16:05:52] <cwills> As soon as both the commits are merged into master I will create the 1.8.x version for linux 5.7
[16:05:58] <kaduk@jabber.openafs.org/barnowl> I looked at the chain of patches that touched the 32-bit timeval
structs, which IIUC is relevant for the i586 tumbleweed thing
[16:06:10] <wiesand> NB #135084 contains a proposed patch for the latte:
[16:06:14] <wiesand> diff --git a/src/afs/afs_osi.h b/src/afs/afs_osi.h
index 5e21cfdd2..807062066 100644
--- a/src/afs/afs_osi.h
+++ b/src/afs/afs_osi.h
@@ -177,7 +177,7 @@ extern void osi_AttachVnode(struct vcache *, int seq);
* In 64 bit HP-UX the timeval structure has a 64 bit member.
*/
-#if defined(AFS_HPUX_ENV) || defined(AFS_LINUX_64BIT_KERNEL) || (defined(AFS_SGI61_ENV) && defined(KERNEL) && defined(_K64U64))
+#if defined(AFS_HPUX_ENV) || defined(AFS_LINUX26_ENV) || (defined(AFS_SGI61_ENV) && defined(KERNEL) && defined(_K64U64))
typedef struct {
afs_int32 tv_sec;
afs_int32 tv_usec;
[16:06:31] <kaduk@jabber.openafs.org/barnowl> The second linux 5.7 commit had to be rebased and wait for buildbot;
I'm not sure why gerrit wouldn't let me merge it right away
[16:07:50] <kaduk@jabber.openafs.org/barnowl> I think that 14194 will have roughly the same effect as the patch that
wiesand just posted
[16:10:00] <kaduk@jabber.openafs.org/barnowl> Okay, second linux 5.7 change merged to master
[16:10:32] <cwills> I will get those pushed up to 1.8.x in just a bit
[16:11:48] <wiesand> that second linux 5.7 commit had a path conflict with 14132 I guess
[16:12:38] <kaduk@jabber.openafs.org/barnowl> so it seems, good eye
[16:12:59] <yadayada> I think 1.8.6pre2 has some issues with latest version of Catalina 10.15.4 due to latest SDK I think. Has anyone tried 1.8.6pre2 on Catalina 10.15.4 ?
[16:13:05] <kaduk@jabber.openafs.org/barnowl> "It's almost like you hav ea lot of practice with this issue" :)
[16:13:51] <wiesand> Ben: right :-) And eventually all that pain must be good for something ;-)
[16:14:37] <kaduk@jabber.openafs.org/barnowl> With respect to Yadav's question, I have not really been pulling out
my macOS machine much lately, so no data from here.
[16:14:43] <meffie> yadayada: you should ask mvita2
[16:15:14] <wiesand> There's no SDK on my Macs…
[16:15:14] <yadayada> ok, i will drop a note on that
[16:15:37] <yadayada> Also recently I came across some strange issue
[16:16:03] <wiesand> A macOS-only to change to cope with the new SDK would wualify for 1.8.6pre3
[16:17:17] <mvita2> I'm not here, but if I were I would say I have not built on Catalina 10.15.4 and so am not aware of changes.  Marcio and I would welcome any details you can provide.
[16:17:51] <yadayada> sure mark, will drop a note on that
[16:18:01] <mvita2> thanks
[16:19:41] <yadayada> There was a RW volume mounted in two different paths. So Directory Inode will have two dentry alias. In situation when both dentry are in use and we cannot prune the dentry, the current working directory is not proper. I will drop a note on this and from my debugging. This is caused due to gerrirt https://gerrit.openafs.org/#/c/7951/.
[16:19:58] <wiesand> we expect a successful nightly build of master now, right?
[16:21:00] <kaduk@jabber.openafs.org/barnowl> This dentry aliasing issue is a long-standing pain point, yes.
[16:21:19] <kaduk@jabber.openafs.org/barnowl> wiesand: the next one should run clean, yes, we think
[16:21:31] <yadayada> This is so common case, where cwd is not proper. Linux gives correct dentry. I will drop a note with more details.
[16:21:48] <cwills> the rc builder? -- I believe so.  However gcc-10.1 and clang-10 are throwing fits
[16:22:22] <kaduk@jabber.openafs.org/barnowl> Yadav: have you ween the "linux-native-mounts" topic in gerrit?
That's intended to be the long-term solution to the dentry aliasing
issues
[16:22:28] <kaduk@jabber.openafs.org/barnowl> (https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:master+topic:linux-native-mounts)
[16:22:51] <wiesand> I think most instances of getcwd() issues are not related to volumes being mounted more than once.
[16:23:39] <wiesand> (Which is a "don't do that" anyqay AFAIK and should be solved once and for all with the bind-mount topic if we ever get that read?)
[16:24:27] <kaduk@jabber.openafs.org/barnowl> I'm not convinced that multiple mountpoints for an RW is in "don't do
that" territory
[16:24:46] <yadayada> sure Ben, I have tried native mounts from Andrew and yeah it looks that is a way to go.
[16:24:53] <wiesand> qualified by "on Linux"
[16:25:39] <kaduk@jabber.openafs.org/barnowl> thanks Yadav
[16:25:55] <wiesand> (I thought Linux "knows" that a filesystem hierarchy is a directed acyclic graph…)
[16:26:26] <yadayada> One more query I had recently was, do we support afsd.fuse ?
[16:26:41] <yadayada> is anyone maintaining it actively ?
[16:27:22] <meffie> yes?
[16:27:55] <kaduk@jabber.openafs.org/barnowl> I don't think anyone is particularly actively maintaining it, but it
sees attention from time to time
[16:27:58] <meffie> by maintaining, we actively avoid breaking it, i'd say
[16:28:16] <wiesand> I know it builds on EL ;-)
[16:28:35] <meffie> i use the debian package for it in some places.
[16:28:40] <yadayada> yeah, looks somehow container story might need it as openshift on Z do not allow and kernel modules to be loaded
[16:28:53] <yadayada> will drop more details on this in coming days
[16:29:05] <kaduk@jabber.openafs.org/barnowl> Ah, interesting
[16:29:12] <meffie> hmm, i'll ask neale.
[16:29:20] <meffie> send info.
[16:29:29] <yadayada> sure thanks mmike
[16:29:32] <yadayada> *mike
[16:30:07] <kaduk@jabber.openafs.org/barnowl> Perhaps there would be some impetus to add
tokens/authenticated-operation support to afsd.fuse, then -- it
doesn't currently do that, right?
[16:30:17] <meffie> correct
[16:36:35] <meffie> anything else today?
[16:37:06] <wiesand> a question: shall we aim for a pre3 next friday?
[16:37:28] <kaduk@jabber.openafs.org/barnowl> pre3 would add linux 5.7 and any macOS thing that appears?
[16:37:41] <wiesand> (it takes a schedule to let it slip ;-)
[16:37:52] <kaduk@jabber.openafs.org/barnowl> ;) indeed
[16:38:00] <wiesand> 5.7/i586 Tumbleweed, and yes Catalina SDK if ready
[16:38:40] <wiesand> anything else I'd prefer to defer to 1.8.7 and rather do that one a bit more swiftly
[16:38:50] <meffie> (btw, i've asked everyone here to avoid pushing non-critical gerrits to the 1.8.x branch until we have a final 1.8.6)
[16:39:12] <wiesand> (of course I/ve been convinced to accept "one more change" before ;-)
[16:39:26] <wiesand> thanks Mike
[16:39:42] <meffie> you are very welcome.
[16:40:11] <kaduk@jabber.openafs.org/barnowl> Aiming for pre3 next friday sounds fine
[16:40:18] <wiesand> keeping a list of what you'd like to get into the next release, and bringing it up here (even regularly) would be appreciated though
[16:40:51] <meffie> i could post a list to the release team mailling list.
[16:41:01] <wiesand> fine too
[16:41:11] <kaduk@jabber.openafs.org/barnowl> it took me a bit to gather my thoughts about other master stuff to
discuss; I had looked at the cache-stats topic and have actually put
some time into the chroot-sysname topic, trying to understand the bits
that confused me the last time I looked.
[16:41:34] <kaduk@jabber.openafs.org/barnowl> Thanks Yadav and John for the triple-DES fix; DES causes nothing but
trouble for us here :)
[16:41:35] <cwills> (doing test build with 1.8.x against linux 5.7)
[16:41:58] <wiesand> :)
[16:42:27] <kaduk@jabber.openafs.org/barnowl> I did want to mention one point from 14200, though -- does anyone
remember whether the CM stats RPCs are particularly standardized vs.
being pretty implementation-dependent?
[16:43:25] <meffie> i feel stats are implementation defined, by nature.
[16:43:45] <kaduk@jabber.openafs.org/barnowl> I'm pretty sure this topic has come up before; I just am not sure how
to effectively search for it
[16:44:22] <meffie> i dont recall any definitive statements about it.
[16:46:49] <meffie> but i feel we should be able to support new collection ids for xstats, it will not break anything if we are not changing an existing collection.
[16:47:30] <kaduk@jabber.openafs.org/barnowl> It seems pretty plausible, but I would like to find a more solid
backing before merging
[16:47:37] <cwills> ::sigh:: looks like clang is not going to support the '/* fall through */'  comment as a way of disabling the implicit-fallthrough warning
[16:48:14] <kaduk@jabber.openafs.org/barnowl> Do they insist on /* FALLTHROUGH */ or something?
[16:48:24] <cwills> No.. an attribute
[16:48:34] <kaduk@jabber.openafs.org/barnowl> gross
[16:50:12] <kaduk@jabber.openafs.org/barnowl> One other topic:
I had also posted on one of the cache-stats patches: we currently have
osi_timeval_t and osi_timeval32_t, but apparently expect both to
always have 32-bit fields.  Is there a reason to not just rename all
the consumers of osi_timeval_t to use the width-specific type instead?
[16:51:21] <meffie> sorry i dont remember.
[16:51:47] <mvita2> I'll look into that Ben, but I believe they are interchangeable and one could be eliminated
[16:51:47] <kaduk@jabber.openafs.org/barnowl> I mean, we can always do it and then revert it when we remember the
reason to not have done it :)
[16:51:50] <meffie> i'll have to defer to mark
[16:52:26] <mvita2> I think one of my patches does typedef one to the other with no harm noted yet
[16:52:33] <kaduk@jabber.openafs.org/barnowl> Having the two makes me expect there to be an osi_timeval64_t to
match, but that doesn't seem to exist at present
[16:52:50] <mvita2> some day there will be, but not any time soon
[16:55:02] <mvita2> oooh, I think I just fixed timeval problem in DARWIN - one test passed, ship it!
[16:55:38] <kaduk@jabber.openafs.org/barnowl> Is this 14194 or something else?
[16:56:02] <mvita2> something else
[16:56:12] <mvita2> related, but in macOS (DARWIN)
[16:56:22] <kaduk@jabber.openafs.org/barnowl> [breath bated]
[16:56:41] <mvita2> oh, sorry, I misunderstood your quesiton
[16:56:58] <mvita2> yes 14194 is where I did the aforementioned typedef
[16:57:28] <kaduk@jabber.openafs.org/barnowl> I think you were right the first time: I was asking if the macOS
timeval fix was 14194
[16:57:44] <mvita2> or no - https://gerrit.openafs.org/#/c/14193/
[16:57:57] <mvita2> sorry, lots of timeval stuff in my head right now
[16:58:25] <kaduk@jabber.openafs.org/barnowl> understandable!
[16:58:30] <mvita2> there's nothing for macOS in that stack yet
[16:58:45] <mvita2> but there needs to be to pass the macOS builders
[16:59:01] <kaduk@jabber.openafs.org/barnowl> Anyway, we seem to be winding down/wandering into the weeds a bit.  Do
we have more topics for the group or shall we go off to our respective
tasks?
[16:59:05] <mvita2> that's what I've been working on for the past 28 weeks it seems
[16:59:09] <kaduk@jabber.openafs.org/barnowl> (Stephan: how's the garden doing?)
[16:59:21] <mvita2> yes, we need the garden report!
[16:59:41] <wiesand> last year's water bill was frightening ;-)
[16:59:58] <mvita2> two words:  drip irrigation
[17:00:23] <wiesand> today I have to water again, and remove the latest stuff the walnut tree dropped ;-)
[17:00:29] <mvita2> two more words:  rain barrel
[17:00:36] <wiesand> and I'll need to mow tomorrow
[17:00:54] <kaduk@jabber.openafs.org/barnowl> Oof, I remember the walnut tree in my parents' back yard
[17:00:59] <wiesand> what's the point of a rain barrel if there's no rain?
[17:01:07] <mvita2> just in case
[17:01:24] <wiesand> our soil is too dry several meters deep!
[17:01:39] <kaduk@jabber.openafs.org/barnowl> The point is that you have the rain barrel so that when you get rid of
it in frustration, it rains to spite you
[17:01:57] <wiesand> built up over the last years, and this one seems to be just as bad
[17:01:57] <cwills> :: clean 1.8.x build w/linux-5.7-rc5
[17:02:14] <wiesand> thanks Cheyenn!
[17:02:25] <kaduk@jabber.openafs.org/barnowl> I am not sure I'm reading my water bill properly, but it looks like
I'm paying 2N for the privilege of being connected to the water
system, and only N for the water I actually used
[17:03:33] <wiesand> Same here. And yes, I was about to get a separate meter for garden water this spring (though it's not cheap either). Then came Corona.
[17:04:00] <kaduk@jabber.openafs.org/barnowl> Indeed
[17:04:23] <mvita2> stephan:   now I understand what you are dealing with:  https://www.ufz.de/index.php?en=37937
[17:05:42] <wiesand> Nice find. Yes, that's what I'm dealing with.
[17:09:18] <wiesand> I'll try to get a garden water meter again next week. The problem: I not only have to find a plumber certified by the water supplier to install it, I also have to get the water supplier to approve and seal it. It's the latter part that may prove impossible during Corona times.
[17:09:53] <kaduk@jabber.openafs.org/barnowl> I would believe that, yes.
[17:11:00] <meffie> plenty of rain in Ohio. too much in fact.
[17:11:09] <wiesand> SHEER ENVY
[17:12:22] <meffie> well, good luck with the garden, have a good weekend.
[17:12:31] <wiesand> (NB to be exact, I pay N per litre of fresh water and 2N per litre of waste water I dispose, which is assumed to be the same amount as the fresh water I consume, and only that is metered)
[17:12:55] <wiesand> Right, enough whining for today. Let's adjourn?
[17:13:12] <kaduk@jabber.openafs.org/barnowl> Sounds like a plan.  Good luck getting the water meter!
[17:13:27] <yadayada> Thanks all
[17:13:27] <wiesand> Thanks a lot everyone. Have a nice weekend!
[17:14:08] <cwills> you too
[17:14:18] wiesand leaves the room
[17:52:48] yadayada leaves the room
[18:55:19] cwills leaves the room
[19:39:16] mbarbosa leaves the room
[19:39:42] mbarbosa joins the room
[19:56:32] meffie leaves the room
[21:45:56] mbarbosa leaves the room