- Wednesday, March 9, 2016

release-team@conference.openafs.org

Wednesday, March 9, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[02:15:36] kaduk leaves the room
[03:01:45] kadukoafs@gmail.com/barnowlD2481C74 leaves the room
[03:01:55] kadukoafs@gmail.com/barnowlD2481C74 joins the room
[03:10:06] kadukoafs@gmail.com/barnowlD2481C74 leaves the room
[03:10:16] kadukoafs@gmail.com/barnowlD2481C74 joins the room
[03:29:56] Jeffrey Altman leaves the room
[03:53:09] Jeffrey Altman joins the room
[06:21:06] Jeffrey Altman leaves the room
[06:21:06] Jeffrey Altman joins the room
[13:51:50] meffie joins the room
[14:27:56] wiesand joins the room
[14:45:59] shadow joins the room
[14:55:24] kadukoafs@gmail.com/barnowlD2481C74 leaves the room
[14:56:43] kadukoafs@gmail.com/barnowlE5725D0E joins the room
[15:00:39] <wiesand> Hi Daria
[15:01:32] <wiesand> Hello all
[15:01:32] <mvita> hello all
[15:03:19] <wiesand> I gave Michael D. a patch that should remove all uses of splice() . He’s working on getting a module built with it actually applied.
[15:03:40] <mvita> I saw that, nice.
[15:04:03] <wiesand> The one you saw on the list wasn’t quite complete, as Chas noted.
[15:04:29] <mvita> actually I'm behind on my list reading, I only saw it in gerrit
[15:05:36] <wiesand> http://www-zeuthen.desy.de/~wiesand/openafs-1.6.17-avoid-splice.patch2
[15:06:13] <wiesand> It probably does more than needed. (using splice_read should be safe?)
[15:06:31] <mvita> my first workaround patch didn't work - I forced the code to use the non-splice afs_linux_storeproc but it uses an api that''s no longer present in 4.4. so it wouldn't build
[15:07:10] <mvita> I did some work on how we could deal with the signals/ERESTARTSYS but didn't get very far yet.
[15:07:25] <mvita> so it's good you came up with a different idea
[15:07:58] <wiesand> It wasn’t me to be honest. I just did what was suggested on the list.
[15:08:08] <Jeffrey Altman> gm
[15:08:15] <mvita> have you gotten any feedback on it?
[15:08:23] <wiesand> The patch2 above actually works. I have it running on EL5/6/7 clients.
[15:08:31] <Jeffrey Altman> As Michael indicates in his latest mail to openafs-info, it doesn't work
[15:08:35] <wiesand> Hello Jeffrey.
[15:09:06] <wiesand> See above, I gave him a new patch.
[15:09:27] <Jeffrey Altman> as I mentioned here last week, removing splice is not sufficient to solve the problem
[15:09:32] <wiesand> That one also allows to check that it was successfully applied.
[15:11:01] <wiesand> "avoiding splice() is not going to be sufficient.  its not the only kernel api that openafs calls that performs signal handling"
[15:11:15] <wiesand> But I guess that’s not new as of Linux 4.4?
[15:12:37] <kadukoafs@gmail.com/barnowlE5725D0E> "You mean we've been silently shipping broken code for years?"
[15:12:47] <shadow> shock
[15:14:44] <wiesand> NB do we think sendfile is safe?
[15:15:30] <mvita> sendfile's the one that's no longer in linux
[15:16:19] <mvita> commit d96e6e71647846e0dab097efd9b8bf3a3a556dca
Author: Jens Axboe <jens.axboe@oracle.com>
Date:   Mon Jun 11 12:18:52 2007 +0200
    Remove remnants of sendfile()

    There are now zero users of .sendfile() in the kernel, so kill
    it from the file_operations structure and in do_sendfile().

    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
[15:17:23] <wiesand> Ah right. So, no worries ;-)
[15:19:14] <wiesand> Avoiding splice is all we have to go on. If it’s not sufficient, oh well.
[15:20:04] <wiesand> Does anyone know whether more breakage is upon us with 4.5?
[15:20:58] <mvita> that's not the only alternative - there's still the more difficult (possible) solution of signal masking and/or handling ERESTARTSYS in OpenAFS.
[15:21:47] <wiesand> Sure, but that’s way beyond anything I should attempt to do ;-)
[15:24:02] <mvita> haven't looked at 4.5 myself
[15:24:07] <wiesand> On to 1.6.17?
[15:24:37] <mvita> okay
[15:24:37] <Jeffrey Altman> 4.5 has its own set of required changes
[15:25:00] <wiesand> Is there anything in the candidate list I sent that clearly doen’st belong into the next stable release?
[15:25:16] <wiesand> Jeff: Thanks for the great news. :-/
[15:25:34] <Jeffrey Altman> I mentioned it back in December.
[15:26:13] <mvita> stephan - didn't see anything that should be left out.
[15:26:36] <wiesand> Jeff: Probably. Events in Jan/Feb have reset my mind...
[15:26:36] <Jeffrey Altman> proposed changes for 4.6 are likely to require modifications to openafs as well.
[15:27:57] <meffie> i think your list for 1.6.17 was good
[15:28:32] <wiesand> Thanks. Review would help.
[15:28:56] <wiesand> Especially those rather trivial ones at the top of the list.
[15:28:56] <meffie> ok, i'll review too.
[15:29:29] <wiesand> Rebasing a change is my workaround to get buildbot runs triggered.
[15:29:50] <meffie> was there a commit for csdb updates?
[15:30:01] <kadukoafs@gmail.com/barnowlE5725D0E> There was a csdb update commit, yes.
[15:30:07] <wiesand> Obviously that’s easier if I have something to merge occasionally.
[15:30:45] <wiesand> I took the liberty to merge that with just a +1 from Chas.
[15:30:52] <kadukoafs@gmail.com/barnowlE5725D0E> (12188)
[15:30:59] <meffie> excellent
[15:32:08] <wiesand> Ben, do you think the replication to the standalone git may work now after your latest configuration changes?
[15:32:55] <kadukoafs@gmail.com/barnowlE5725D0E> I don't believe that any of the *configuration* changes I have made in
the past three months have had any affect on the replication to
standalone git.
[15:33:28] <wiesand> OK...
[15:33:35] <kadukoafs@gmail.com/barnowlE5725D0E> I think that the upgrade to gerrit 2.12 brought about this behavior
change (okay, I'll call it a bug), and am occasionally mentioning it
on #gerrit trying to get developer interest.
[15:34:03] <wiesand> Interestingly, only new changes have that problem. Rebasing, either through the web interface of by repushing over ssh works fine.
[15:34:57] <kadukoafs@gmail.com/barnowlE5725D0E> Seems like https://code.google.com/p/gerrit/issues/detail?id=3767 then
[15:35:59] <wiesand> NB I also tried to push to /drafts/ and the hit the publish button.
[15:36:13] <wiesand> But that workflow seems not to trigger buildbot at all.
[15:36:26] <kadukoafs@gmail.com/barnowlE5725D0E> Oh hey, there's a 2.12.1 now.  I guess being in #gerrit does not serve
as a notification channel for new releases :(
[15:36:51] <kadukoafs@gmail.com/barnowlE5725D0E> I'm not entirely sure how our buildbot config would interact with
drafts, and how they show up in the event stream.
[15:37:43] <wiesand> No big deal, I just wanted to mention it.
[15:38:27] <kadukoafs@gmail.com/barnowlE5725D0E> And the release notes say that 2.12.1 is supposed to fix the
replication thing.  Yay.
Luckily, this upgrade should be a lot easier than the one I did around
Christmas...even if I do have to misspell "certificate" while manually
updating the database schema.
[15:39:07] <kadukoafs@gmail.com/barnowlE5725D0E> Well, it's something for the buildbot maintainers to take a look at
when they get a chance, I suppose.
(N.B. that I am not a buildbot maintainer; I just thwak it when it
becomes sufficiently annoying.)
[15:40:34] <wiesand> That issue looks like it’s our problem, yes. So let’s hope for 2.12.1.
[15:41:17] <wiesand> Except for that issue, I started to appreciate the new gerrit.
[15:42:24] <meffie> (i like that gerrit uses gerrit for their own reviews)
[15:42:28] <kadukoafs@gmail.com/barnowlE5725D0E> (Oh, apparently the new release was just announced a couple hours ago,
though the tag existed for a week.)
[15:42:57] <kadukoafs@gmail.com/barnowlE5725D0E> (nvm, it was announced a week ago, the timestamp on google groups was
just confusing.)
[15:44:04] <wiesand> Ok, 1.6.17 looks straightforward at this point. Review, merge, smoke test, prerelease.
[15:44:30] <wiesand> If we have something for 4.4 we believe we can ship, fine. If not, fine too.
[15:45:01] <kadukoafs@gmail.com/barnowlE5725D0E> Okay.
[15:45:14] <wiesand> SO, on to 1.8?
[15:45:15] <meffie> ok, thank you wiesand
[15:45:53] <kadukoafs@gmail.com/barnowlE5725D0E> By the way, I re-enabled the apache-level redirect from http://gerrit
to https, and gerrit.openafs.org/NNNNN still works for me even in
safari -- are you having any issues today?
[15:46:25] <kadukoafs@gmail.com/barnowlE5725D0E> I keep finding memory leaks in akeyconvert as I'm about to merge it.
"This time for sure"
[15:46:36] <kadukoafs@gmail.com/barnowlE5725D0E> (I put a new version up; not sure if Mike saw that or not.)
[15:46:46] <meffie> yes, i did this time.
[15:46:46] <wiesand> No, redirects work for me. Thanks.
[15:47:32] <kadukoafs@gmail.com/barnowlE5725D0E> In 12115, does anyone want to comment on the potential for truncating
when we assign from size_t to the 32-bit local variable?
[15:47:56] <kadukoafs@gmail.com/barnowlE5725D0E> I think it's fine, but wanted to give people a chance to object before
merging the series.
[15:49:23] <mvita> looking...
[15:49:53] <meffie> i think it is ok.
[15:50:50] <kadukoafs@gmail.com/barnowlE5725D0E> Okay, thanks.
[15:51:10] <kadukoafs@gmail.com/barnowlE5725D0E> (It is reassuring, since you had raised the issue initially.)
[15:51:36] <kadukoafs@gmail.com/barnowlE5725D0E> The latest version of 11654 (shake-loose harder) is pretty simple.
[15:52:16] <meffie> thanks. i'd like to make a comment there.
[15:53:06] <meffie> this requires 12206 first, as andrew pointed out.
[15:54:59] <kadukoafs@gmail.com/barnowlE5725D0E> *nods*
[15:55:58] <kadukoafs@gmail.com/barnowlE5725D0E> (I have another meeting at the hour, if anyone is holding onto
questions for me.)
[15:56:25] <kadukoafs@gmail.com/barnowlE5725D0E> Mike, I also wanted to check in with you about the
external-log-rotation stuff
[15:57:19] <kadukoafs@gmail.com/barnowlE5725D0E> If I pull up the search at
https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:master+topic:externalize-log-rotation,
most things are in good shape, but I wanted to check in on what you
had listed as left to do.
[15:57:36] <meffie> ok
[15:59:08] <meffie> i think i've address everything i know about.
[15:59:21] <meffie> s/address/addressed/
[15:59:34] <kadukoafs@gmail.com/barnowlE5725D0E> Okay, so the idea is that 12168 is going to satisfy the comment that
elicited a -1 on 11726?
[16:00:07] <kadukoafs@gmail.com/barnowlE5725D0E> (Or are we supposed to use my attempt in 12135?)
[16:00:14] <meffie> oh, yes. i can abandon 11726
[16:00:40] <kadukoafs@gmail.com/barnowlE5725D0E> Ah, thanks
[16:01:03] <kadukoafs@gmail.com/barnowlE5725D0E> (I am waiting until I can merge the whole rest of the stack at once.)
[16:01:25] <meffie> i hope 12168 would replace 12135
[16:02:11] <kadukoafs@gmail.com/barnowlE5725D0E> That was my guess, but I haven't looked at it in long enough that I
wanted to double-check.  Maybe comment on 12135 that your version is
in 12168?
[16:02:30] <kadukoafs@gmail.com/barnowlE5725D0E> GONE
[16:02:32] <meffie> i would be happy to rebase the stack now, to fix the merges
[16:03:49] <meffie> would that be helpful?
[16:04:45] <wiesand> I guess there’ll be no answer today...
[16:05:10] <wiesand> Anything else to discuss?
[16:05:27] <meffie> oh, yes, he is gone. i'll rebase locally just in case the answer is yes. :)
[16:07:57] <meffie> thanks wiesand.
[16:08:11] <wiesand> Looks like that’s it for today.
[16:08:18] <wiesand> Thanks a lot everyone!
[16:08:31] <mvita> thank you Stephan
[16:08:40] <wiesand> Goodbye
[16:08:44] wiesand leaves the room
[16:08:59] meffie leaves the room
[17:29:08] shadow leaves the room
[19:28:22] shadow joins the room
[19:45:11] mvita leaves the room
[19:45:12] mvita joins the room
[20:54:09] mvita leaves the room
[20:57:10] mvita joins the room
[22:04:13] shadow leaves the room