Home
release-team@conference.openafs.org
Friday, March 1, 2019< ^ >
Room Configuration
Room Occupants

GMT+0
[13:21:48] <kaduk@jabber.openafs.org/barnowl> [testing; please ignore]
[13:44:07] meffie joins the room
[13:59:06] <mvita> good morning
[13:59:12] <meffie> hello mvita
[13:59:41] <kaduk@jabber.openafs.org/barnowl> greetings
[14:00:44] <mvita> Good morning Ben
[14:01:19] wiesand joins the room
[14:01:20] <meffie> good day kaduk@jabber.openafs.org/barnowl
[14:01:27] <meffie> good day wiesand
[14:01:35] <wiesand> good morning
[14:02:28] <wiesand> so… I just merged two more changes on 1.8.x and updated NEWS accordingly
[14:02:30] <mvita> Yay!
[14:02:48] <kaduk@jabber.openafs.org/barnowl> "Does that mean I have to review NEWS again?" :-p
[14:02:57] <wiesand> the autoconf stack hasn't had review yet
[14:03:14] <wiesand> well, the diff against the previous PS shouldn't be that hard to review ;-)
[14:04:25] <wiesand> the last one that seems kind of ready is 13487
[14:05:15] <kaduk@jabber.openafs.org/barnowl> It probably is, but it's also a bit annoying to review, since it gets
its fingers all over the place.
[14:05:47] <wiesand> right, and that's why I'd like to have more +1s before merging it
[14:06:28] <mvita> okay
[14:06:39] <mvita> I'm familiar with this one, I will review it
[14:06:44] <meffie> maybe mvita can confirm it works too.
[14:06:52] <mvita> yes
[14:07:00] <meffie> i've tried the master version of this one, but not since it was backportd.
[14:07:10] <mvita> (surprised I didn't already review it)
[14:07:26] <wiesand> there are also some path conflicts with remove-automake
[14:08:05] <meffie> it looks like there's a stack here.
[14:08:41] <wiesand> right, it was submitted on top of 13486
[14:09:00] <mvita> "There is a stack here."
[14:09:07] <wiesand> so it will have to wait until the whole stack is reviewed
[14:09:24] <meffie> $ git l --graph
* 0e4029efd7 (HEAD, scm/sna/master/cwills/sn44977, gerrit/changes/87/13487/1) Run ctfconvert/ctfmerge for all objects
* 87af269a48 (scm/sna/master/cwills/sn45560, gerrit/changes/86/13486/1) autoconf: do not reference the missing script
* 6cc8ff7965 (gerrit/changes/85/13485/1) Remove obsolete retsigtype
* 376ef0e811 (gerrit/changes/84/13484/1) autoconf: reformat long lines
* 5119432925 (gerrit/changes/83/13483/1) autoconf: autoupdate macros
* 1f6536ac41 (gerrit/changes/82/13482/1) autoconf: update curses.m4
* 33b4521960 (gerrit/changes/81/13481/1) autoconf: update pthread checks
* e5c73df4bc (gerrit/changes/80/13480/1) autoconf: updates and cleanup
* 232bd12b07 (up/openafs-stable-1_8_x, scm/openafs-stable-1_8_x, gerrit/changes/59/13459/2) Avoid format truncation warnings
[14:10:06] <wiesand> I'm inclined not to block on those
[14:10:24] <kaduk@jabber.openafs.org/barnowl> They don't feel like release blockers, yeah
[14:10:42] <wiesand> was anything merged on master recently that should still make 1.8.3?
[14:10:56] <kaduk@jabber.openafs.org/barnowl> Not much merged on master recently, no. :(
[14:10:59] <meffie> ok, should these be rebases to change the merge order?
[14:11:11] <kaduk@jabber.openafs.org/barnowl> I'm just starting to get the gcc8-checking ones in and those have been
(mostly) "ready" for weeks
[14:11:48] <kaduk@jabber.openafs.org/barnowl> I'm not sure what Mike is thinking about with rebases and merge order
[14:12:50] <meffie> well, i'm not sure if 13487 will apply without those other commits.
[14:13:22] <meffie> so, move it to the bottom of that stack to be sure?
[14:13:54] <wiesand> let's simply merge them in the current order
[14:14:06] <meffie> HEAD is now at 232bd12b07 Avoid format truncation warnings
bismark:openafs$ git cp gerrit/changes/87/13487/1
error: could not apply 0e4029efd7... Run ctfconvert/ctfmerge for all objects
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
[14:14:24] <meffie> oh, yes, that would be great. thanks stephan.
[14:15:08] <meffie> sorry for the mis understanding.
[14:16:39] <wiesand> I remember a "Solaris vnodes" topic being on the wish list for 1.8.3 - with 12696 now merged, would this be ready?
[14:16:46] <wiesand> or can it wait?
[14:18:08] <kaduk@jabber.openafs.org/barnowl> My current thoughts are that we've accumulated a fair bit of good
stuff or 1.8.3 already, so it may not be worth holding off longer.
[14:18:34] <kaduk@jabber.openafs.org/barnowl> But I also don't have a Solaris deployment itching to get on a stable
release of openafs, so maybe others will think differently.
[14:19:28] <mvita> this isn't required for that.
[14:19:45] <mvita> this just reduces the need to recompile for solaris 11.4
[14:19:56] <mvita> s/reduces/removes
[14:20:37] <mvita> (although, there may be _other_ reasons to have separate builds for 11.3 and 11.4)
[14:21:18] <meffie> i believe mvita is correct.
[14:21:53] <meffie> also, sites on solaris probably have yet to migrate to 1.8.x.
[14:21:58] <wiesand> ok, I'll put it on the 1.8.4 list - and hopefully, we'll get that done a bit faster than 1.8.3
[14:22:07] <meffie> thank you
[14:23:22] <wiesand> so, after checking once more for other changes I possibly lost track of, I would then merge NEWS and version strings, prepare tarbalss and ask our volunteers for smoke testing
[14:23:38] <wiesand> and get 1.8.3pre1 out swiftly then
[14:23:46] <kaduk@jabber.openafs.org/barnowl> Sounds like a plan.
[14:24:03] <mvita> to be very clear:  an OpenAFS kmod built for 11.3 with this commit will work without change on 11.4.
[14:24:31] <mvita> if you try that without this commit:  hilarity ensues
[14:25:19] <meffie> those spoiled solaris users thinking kmods work across kernel versions!
[14:25:30] <mvita> Aye.
[14:26:58] <kaduk@jabber.openafs.org/barnowl> I only get in trouble on BSD because I don't run released versions...
[14:29:51] <wiesand> ok, sounds bad, and the whole stack seems to touch (almost) entirely solaris specific code
[14:30:40] <mvita> oh, perhaps you misunderstood, I was not arguing for inclusion in pre1
[14:30:57] <wiesand> ah, ok
[14:31:19] <mvita> the site that needs this already has it ;-)
[14:31:37] <wiesand> I figure :-)
[14:31:52] <wiesand> But yes, clearly a candidate for 1.8.4
[14:32:01] <mvita> +1
[14:32:21] <meffie> yes, thank you.
[14:33:24] <wiesand> on 1.6.x, I rebased 13493 on top of gcc-warnings-1.6.x, and buildbot +1'ed it 5 minutes ago
[14:34:25] <wiesand> so, that stack will go in next, followed by the Linux changes
[14:35:05] <wiesand> then let's see, maybe next week
[14:35:28] <wiesand> I still plan getting 1.8.3pre1 out first before spending much time on 1.6.x
[14:35:38] <kaduk@jabber.openafs.org/barnowl> 1.6.x, I almost forgot how to count that low
[14:35:42] <mvita> heh
[14:36:19] <kaduk@jabber.openafs.org/barnowl> Sounds like a good plan
[14:36:41] <wiesand> but getting buildbot verifies and succcessful linux-next builds again would be nice, so I'll try to get merged what's needed for that soon
[14:37:41] <wiesand> anything else on the stable series?
[14:38:11] <meffie> yes, getting buildbot verifies would be nice. thanks.
[14:38:16] <wiesand> if not, on to master?
[14:38:29] <kaduk@jabber.openafs.org/barnowl> Okay, let's see...
[14:38:32] <mvita> yes please: question about 13042:  it has a +2 from Ben, what does it lack to be merged to master?
[14:39:26] <kaduk@jabber.openafs.org/barnowl> gerrit thinks it cannot merge [without rebase]
[14:39:41] <mvita> I can rebase it.
[14:39:42] <kaduk@jabber.openafs.org/barnowl> Also it's on top of 13041 which only has +1 and I forget if they can
be merged out of order
[14:39:53] <mvita> ah
[14:40:33] <kaduk@jabber.openafs.org/barnowl> rebase would also get it to the top of the gerrit "recent changes"
view, which tends to be how things get prioritized :(
[14:40:35] <mvita> maybe I can split them - I'll check when I rebase
[14:41:59] <kaduk@jabber.openafs.org/barnowl> But thank you for mentioning them -- that one is good to have, and I
had forgotten about it
[14:42:55] <kaduk@jabber.openafs.org/barnowl> On the bosserver-no-client-dirs stack, I see Andrew left a bunch of
comments on 13398 but no +1; are those just style notes on the commit
message so that I can still review the code, or is it going to need
another rev?
(Mike's change)
[14:43:44] <meffie> oh, i missed his last batch of comments. i'll look, thanks!
[14:44:34] <kaduk@jabber.openafs.org/barnowl> 10571 and 13489 are racing, since they have path conflicts.  If 10571
needs more changes I'll merge the 'make dest' fix first
[14:45:49] <kaduk@jabber.openafs.org/barnowl> 13470 had a note about maybe behaving poorly on terminal resize, but
also has +1s from Mike and Cheyenne.  Am I supposed to merge it, or
wait for further testing?
[14:46:58] <meffie> i tried it back in feb 5th, on narrow terminals, and it seemed no worse.
[14:47:17] <kaduk@jabber.openafs.org/barnowl> Okay, cool; thanks for checking
[14:47:23] <meffie> and wide windows too.
[14:47:37] <meffie> so, i stand by my +1
[14:48:03] <kaduk@jabber.openafs.org/barnowl> Then on 13469, should I just merge the smail-notifier band-aid or do
we think there is something in the works  to just remove
smail-notifier entirely that I should wait for?
[14:48:40] <meffie> cheyenne is going to nuke the smail-notifier
[14:48:49] <meffie> i'll ping him.
[14:49:05] <mvita> from orbit?
[14:49:16] <mvita> (it's the only way to be sure)
[14:49:20] <kaduk@jabber.openafs.org/barnowl> It's not super-close to being the last thing blocking  enable-checking
builds with gcc8, so no need to drop other projects for this  one
[14:49:21] <meffie> it's the only way to be sure.
[14:49:51] <mvita> jinx
[14:50:59] <kaduk@jabber.openafs.org/barnowl> Hopefully I can  look at Cheyenne's restorevol asprintfication and
Andrew's v5der reimport soon
[14:51:24] <meffie> (cheyenne pinged)
[14:51:34] <mvita> Sorry, I must step away…
[14:51:50] <kaduk@jabber.openafs.org/barnowl> Whenever I try to start looking at Pat's static-analysis topic I end
up on some giant commit that requires tedious review.  I must have
really bad luck, I guess.
[14:51:56] <kaduk@jabber.openafs.org/barnowl> Thanks, Mark
[14:52:10] <kaduk@jabber.openafs.org/barnowl> I am running out of topics anyway, I think.
[14:53:13] <kaduk@jabber.openafs.org/barnowl> I see that Cheyenne came up with 13491 to get LockTimestamp from the
vlservers.
[14:53:33] <meffie> ah, yes.
[14:53:52] <kaduk@jabber.openafs.org/barnowl> I am leaning towards needing proper a Capabilities framework before
adding this sort of feature, even if it's internal to OpenAFS, just on
general architectural grounds.
[14:53:53] <meffie> that one seems reasonable, no?
[14:54:27] <kaduk@jabber.openafs.org/barnowl> I know we don't currently implement the Capabilities RPCs even for all
the standardized services, though.
[14:54:56] <meffie> it's not possible to claim one of the spares?
[14:55:24] <kaduk@jabber.openafs.org/barnowl> From a technical level, it's ... mostly possible
[14:55:58] <kaduk@jabber.openafs.org/barnowl> (In that we used to have bugs that would send uninitialized memory in
the spares field)
[14:56:23] <meffie> ah.
[14:56:53] <kaduk@jabber.openafs.org/barnowl> But from an architecture perspective, claiming spare fields
sequentially and then only interpreting them if they have non-default
values is a somewhat fragile pattern, when it's possible to get
explicit signalling about what "extensions" from the common baseline
are in use
[14:58:13] <meffie> hmm.
[14:58:18] <kaduk@jabber.openafs.org/barnowl> On a more general trend, the AFS community seems to have opted for the
explicit Capabilities negotiation, for 64-bit file support, etc.
[15:00:08] <kaduk@jabber.openafs.org/barnowl> But I also am not sure that I want to make Cheyenne implement that
stuff for vlserver.
[15:00:09] <meffie> i dont see how we can have a capabilities nego here.
[15:01:03] <meffie> but i suppose we will need such to move to 64 bit volume ids, etc. right?
[15:01:28] <kaduk@jabber.openafs.org/barnowl> The pattern I remember is something like: before attempting to make an
RPC call that would use the new capbility, attempt a
foo_GetCapabilities call.  If that fails, assume no capabilities are
supported and use the compat codepath.  If it succeeds, you can check
for whether the feature you want is supported, and behave accordingly.
[15:01:42] <meffie> ok, thanks.
[15:01:50] <kaduk@jabber.openafs.org/barnowl> Long-lived processes will of course cache the capabilities along with
the connection objects
[15:02:23] <kaduk@jabber.openafs.org/barnowl> We do use RXAFS_GetCapabilities, which would be my default go-to
example for how to start from scratch towards VL_GetCapabilities
[15:02:25] <meffie> right. this is vos though, so it would need to do that nego every time.
[15:02:43] <kaduk@jabber.openafs.org/barnowl> Right, ish.
[15:03:08] <meffie> ish, yes, we should be caching stuff for other reasons too.
[15:03:12] <kaduk@jabber.openafs.org/barnowl> It only needs to ask if it wants to use the new field, so we could
gate it on the new -lockedts option
[15:03:31] <meffie> interesting!
[15:04:09] <kaduk@jabber.openafs.org/barnowl> I guess my actual question here is whether I can sucker anyone into
implementing VL_GetCapabilities for Cheyenne to use.
[15:04:26] <kaduk@jabber.openafs.org/barnowl> I don't know what kind of timeline commitment I could make, if it was
left to me.
[15:04:57] <kaduk@jabber.openafs.org/barnowl> And I just noticed that we're well past the hour, whoops.
[15:05:16] <kaduk@jabber.openafs.org/barnowl> I  think I just have one other thing to note; does anyone else have
other topics?
[15:05:24] <meffie> but having a VL_Capabilities rpc would requires afs3 stds work, and that would block indefinitely
[15:05:34] <meffie> the implementation would not be too bad.
[15:07:13] <kaduk@jabber.openafs.org/barnowl> I think jhutz has told me long ago that we defined GetCapabilities for
all the services, and it's just that openafs didn't implement all of
them yet
[15:08:13] <kaduk@jabber.openafs.org/barnowl> I will try to look for that and/or ask jhutz, after this meeting
[15:08:38] <kaduk@jabber.openafs.org/barnowl> My other thing to note was that I did make some progress towards
websocket proxy support on the buildbot master.
[15:09:33] <kaduk@jabber.openafs.org/barnowl> There's a random github gist  with code and RPM spec, linked from a
random stackoverflow page.  I grabbed the code and am trying to piece
together some corresponding bits from upstream apache, so that I can
do code review on it before building+running it in production.
[15:10:10] <kaduk@jabber.openafs.org/barnowl> (It's like one 750-line file, so not so bad.  And it  lines up fairly
well with the bits in 2.4 upstream)
[15:10:57] <kaduk@jabber.openafs.org/barnowl> It's been a while since I had to read apache code, though, so there
may be a little bit of  a re-learning curve.
[15:12:04] <kaduk@jabber.openafs.org/barnowl> Anyway, I think that's all I have.
[15:12:09] <kaduk@jabber.openafs.org/barnowl> Anything else for this meeting?
[15:12:20] <wiesand> not from me
[15:13:12] <wiesand> Let's adjourn then. Thanks a lot everyone!
[15:13:20] <kaduk@jabber.openafs.org/barnowl> Yes, thanks everyone!
[15:43:57] meffie leaves the room
[15:53:58] wiesand leaves the room
[16:18:20] mvita leaves the room
[17:11:41] mvita joins the room
[19:14:31] mvita leaves the room
[19:35:08] mvita joins the room
[22:01:29] mvita leaves the room
[22:01:32] mvita joins the room
[22:01:34] mvita leaves the room