- Wednesday, June 4, 2014

release-team@conference.openafs.org

Wednesday, June 4, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[09:56:07] shadow@gmail.com/barnowlC1E71073 joins the room
[10:08:31] shadow@gmail.com/barnowlC1E71073 leaves the room
[10:10:29] shadow@gmail.com/barnowlC1E71073 joins the room
[10:11:33] shadow@gmail.com/barnowlC1E71073 leaves the room
[13:37:22] wiesand joins the room
[13:37:36] <wiesand> test
[13:39:02] <jhutz@jis.mit.edu/owl> SKIP
[13:48:23] Marc Dionne joins the room
[13:51:25] meffie joins the room
[14:00:30] <wiesand> Hi
[14:00:44] <Marc Dionne> hi Stephan
[14:01:40] <wiesand> Marc, any news on 3.15  or 3.16?
[14:01:52] deason joins the room
[14:02:15] <deason> hi
[14:02:31] <wiesand> I didn't get the minutes done again :-(
[14:02:50] <Marc Dionne> we're still good for 3.15.  merging has started for 3.16 (separate branch), but i will wait until the vfs changes appear there before pushing anything
[14:02:56] <wiesand> Incomplete todo list is here: http://www.zeuthen.desy.de/~wiesand/rt0604.txt
[14:03:07] <Marc Dionne> of not is that 3.15 will have a 16k stack for x86_64
[14:03:13] <Marc Dionne> (of note)
[14:03:49] <wiesand> Marc: ok, thanks. 16k stacks will help us? Do we still need the stack reduction changes?
[14:04:21] kaduk joins the room
[14:04:27] <Marc Dionne> it will help, but obviously only for these newer kernels
[14:04:33] <kaduk> Sorry I'm late.
[14:04:44] <wiesand> Right.
[14:04:53] <wiesand> Hi Ben.
[14:06:57] <wiesand> Ok. I was hoping to merge the 3 bozo-catchup ones today:
[14:07:24] <wiesand> 11192 10891 10867
[14:08:02] <meffie> (hi all)
[14:10:35] <wiesand> Andrew, your comment on 10867 should be addressed by 10891. Are those ok to merge together?
[14:12:55] <deason> probably; but I'd like to get a chance to +1
[14:13:22] <wiesand> Here it is :-)
[14:15:59] <wiesand> 11192 is really simple, and 10864 was already merged.
[14:18:07] <wiesand> merged 10867
[14:23:37] <wiesand> merged the other two - thanks.
[14:24:47] <wiesand> How about 11014? Abandon?
[14:25:33] <shadow@gmail.com/barnowlC1E71073> hi. sorry i'm late
[14:25:52] <wiesand> Hi Daria
[14:26:04] <kaduk> The point of 11014 was to quiet a coverity warning, so "abandon" is probably not the right choice.
[14:26:26] <kaduk> "cast to void" looks fairly reasonable, though, from just reading the discussion on the change.
[14:27:00] <shadow@gmail.com/barnowlC1E71073> if that's not the right solution (and maybe it isn't) we should fix on
master and merge that directly over this
[14:27:09] <deason> well, assuming that's what the flagged warning was
[14:27:33] <deason> I can't imagine coverity flags every value-returning function whose return we ignore; otherwise there would be a lot more (void) casts
[14:28:20] <deason> I was going to do something like
if (code) { memset(akeyinfo->keyCheckSum, 0, ...); }
[14:28:26] <deason> er, and 'code = 0'
[14:28:36] <kaduk> Who has access to the coverity reports?
[14:29:41] <shadow@gmail.com/barnowlC1E71073> i kno i do, i wonder if i still have the info on how to get it
[14:30:34] <shadow@gmail.com/barnowlC1E71073> ok. looking...
[14:32:45] <jhutz@jis.mit.edu/owl> Presumably it doesn't flag ignored return values when they are known not to
matter.
[14:33:44] <shadow@gmail.com/barnowlC1E71073> it's not the most recent scan, so i have to fish around. hang on
[14:33:50] <jhutz@jis.mit.edu/owl> The change in 11014 masks the error code from the previous stat.
[14:38:22] <jhutz@jis.mit.edu/owl> I agree with Ben; cast-to-void seems like the right answer, at least in the
noauth case.
[14:40:01] <shadow@gmail.com/barnowlC1E71073> it won't show me defect reports for old snapshots. so let's fix it
right on master and merge through, either erging both or by reverting
on master
[14:40:25] <kaduk> Sounds like a plan.
[14:40:29] <kaduk> Who wants to fix master?
[14:40:50] <deason> I'm submitting one in a moment
[14:41:10] <shadow@gmail.com/barnowlC1E71073> ok. then i won't bother. git fetch was still running ;)
[14:41:36] <wiesand> Daria, may I bother you to look at 11054?
[14:47:11] <wiesand> merged 11054. thanks.
[14:47:45] <wiesand> 11048: who's right?
[14:47:50] <deason> 11194
[14:47:58] <Jeffrey Altman> sad to hear that 11054 was merged
[14:48:38] <kaduk> Er, what's wrong with 11054, Jeffrey?
[14:49:02] <Jeffrey Altman> readlink on Linux can return success with a truncated string.
[14:49:09] <kaduk> I just commented on 11048.
[14:49:56] <Jeffrey Altman> If the returned length is the same as the specified buffer I believe we should treat it as a truncated response.
[14:50:11] <shadow@gmail.com/barnowlC1E71073> 11048: dan must not have looked at the macro
[14:53:02] <wiesand> I just pushed 11193 for the logrotate change Christof wanted. Not quite a clean cherry pick.
[14:53:21] <kaduk> It doesn't look like we have code to handle a truncated readlink response in a sane way, anyway.
[14:55:54] <wiesand> Is there anything on master that makes 25011b correct there?
[14:56:09] <wiesand> (which is what 11054 was derived from)
[14:56:25] <kaduk> MAXPATHLEN does have some guaranteed semantics.
[14:57:00] <kaduk> But I would not say that there is anything which guarantees that the code will give correct behavior.
[15:00:15] <kaduk> In particular, pathconf(.., _PC_PATH_MAX) is not required to have any fixed limit.
[15:00:35] <Jeffrey Altman> 11054 addresses the potential use of a non-NUL terminated string.   To that extent it is correct as is the change on master.
[15:02:59] <wiesand> So, what now?
[15:04:52] <kaduk> It is "good enough" and we forget about it until someone stumbles over the marginally correct behavior.
[15:05:22] <Jeffrey Altman> not handling link targets that are longer than 1023 is not a regression for 1.6 so I think the release manager should ignore it
[15:06:03] <wiesand> Ok, thanks.
[15:07:48] <wiesand> 11193: Ben, the change on master doesn't split the line either.
[15:07:59] <jhutz@jis.mit.edu/owl> Yup.  11054 is not wrong; it just doesn't fix the problem that we don't
check for truncated responses, or dynamically size the buffer.
[15:09:21] <kaduk> 11193: okay, fair enough.
[15:11:10] <wiesand> I was hoping Ken would look at 11171, but he seems to be busy lately?
[15:12:45] <kaduk> "It's probably fine."
[15:13:23] <wiesand> It probably is, but it's kind of Ken's turf.
[15:14:02] <wiesand> It seems we need 11168 to finish the stack reduction topic?
[15:15:50] <wiesand> Ok, the pullup of 11194 will replace 11014?
[15:16:58] <kaduk> 11168 is not strictly needed, but would be good to have for completeness.  (Note that it is not merged to master yet.)
[15:17:17] <wiesand> That's why I bring it up here.
[15:17:52] <kaduk> 11194 would apply more cleanly on top of 11014 than as a replacement.
[15:17:56] <deason> 11194 can either replace 11014 or just go in after it
[15:18:03] <deason> but yeah, it would apply more cleanly if 11014 is there
[15:18:28] <wiesand> I'll leave that to you ;-)
[15:23:55] <wiesand> 11195/6 are pullups of two changes I pushed to adress comments on some of the coverity changes. Simple ones.
[15:25:00] <wiesand> Mike, we talked about volscan for 1.6.9. Is it ready?
[15:26:21] <Jeffrey Altman> there will probably be more stack reduction changes hitting master over the next few weeks
[15:26:31] <wiesand> I'm a bit surprised that there were no objections to 10984 . Last chance...
[15:27:35] <wiesand> Andrew: huge thanks once more for all that work on the coverity stack!
[15:27:42] <Jeffrey Altman> why do you think folks should object to 10984?
[15:29:12] <wiesand> It's a behaviour change.
[15:29:36] <Jeffrey Altman> We lie.  We still lie.
[15:29:46] <kaduk> Everybody lies.
[15:30:06] <wiesand> There were complaints about much less exciting changes going into "stable" releases.
[15:30:21] <wiesand> I'm going to merge it anyway ;-) Just wondering.
[15:30:21] <Jeffrey Altman> There is nothing exciting about 10984
[15:30:29] <Jeffrey Altman> its a number
[15:30:39] <Jeffrey Altman> it isn't used within AFS itself.
[15:31:23] <wiesand> And it works :)
[15:31:27] <wiesand> ~ % df -h .
Filesystem      Size  Used Avail Use% Mounted on
AFS             2.0T     0  2.0T   0% /afs
[15:32:54] <wiesand> merged 10984
[15:32:59] <Jeffrey Altman> the underlying issue is that the entire /afs name space is exposed as a single device it is impossible to return a meaningful value for total space or free space.   The 1.7 Windows CM doesn't have this problem because it reports AFS volumes as individual devices; it can therefore return the real size and available quota for a given volume or directory.
[15:34:19] <wiesand> Would the bind mount changes fix this as a byproduct?
[15:35:14] <Jeffrey Altman> probably not by themselves but would open the door to reporting real values
[15:35:54] <wiesand> One more reason why this would be good in the long run.
[15:36:30] <wiesand> But I think that's not for 1.6 unless we have no choice.
[15:37:28] <wiesand> Ok. Thanks for 11168. I'll pull it up later, unless anyone beats me.
[15:37:54] <wiesand> And it's getting late... anything else to discuss today?
[15:38:11] <kaduk> you mentioned the warning messages commits in your list
[15:38:38] <kaduk> 11181/2/3.  They idea seems fine for 1.6.9 in principle, to me, but I haven't reviewed the actual patches yet.
[15:39:25] <deason> I'd also like to bring up the 1.6.8 repo(s)
[15:39:37] <deason> I'm not clear on if they're being fixed....?
[15:39:43] <wiesand> I haven't had a closer look yet either. They seem fairly large.
[15:40:05] <kaduk> Oh, the yum repos?
[15:40:25] <wiesand> They'll fix themselves with the next kernel update.
[15:41:15] <deason> when is that?
[15:41:33] <wiesand> Which is why I haven't given this any priority. I could create new repodata, but had to drop something else for it.
[15:41:45] <wiesand> Overdue.
[15:42:30] <deason> ah, you mean "when we update the repo for new kernels", not "when fedora releases a new kernel?"
[15:43:29] <wiesand> When Fedora releases a new kernel, a module for it is built and added to the repo, and the metadata recreated.
[15:44:20] <deason> yes, but how long is that going to take?
[15:44:48] <wiesand> Last updates were a while ago. It can't take long.
[15:45:22] <deason> I mean, can't we just regenerate the repo data for the existing packages? is this more involved than just running a command to generate the repo data?
[15:45:48] <deason> (er, the 1.6.8 fedora rpms, at least some of them, are uninstallable via yum, for anyone missing context)
[15:47:01] <meffie> wiesand: sorry, was distracted here. i can push the volscan patchest to gerrit this week.
[15:47:39] <wiesand> I said I can create new metadata. Is it more important than catching up with the minutes?
[15:48:48] <wiesand> Mike: ok, thanks.
[15:49:35] <deason> I would vote 'yes'
[15:49:40] <deason> I can do minutes, if you want
[15:50:14] <wiesand> Accepted :-)
[15:51:07] <meffie> wiesand: it looks like we need 11186 for 1.6.9?
[15:52:18] <wiesand> I don't think it's very urgent. But I'm fine with it once it's ready.
[15:52:25] <deason> I don't see why we "need" it for 1.6.9
[15:52:57] <wiesand> It would make buildbot results more reliable?
[15:55:08] <deason> I didn't think it affected that; the way I've noticed it is when developing: changing something and rebuilding
[15:55:23] <deason> I thought the build still eventually failed for a completely new build, but I may be remembering incorrectly
[15:55:55] <meffie> i suppose it's possible to mask a buildbot error, but what andrew said.
[15:56:38] <wiesand> I wouldn't delay 1.6.9 for it. But that's not a worry yet.
[15:58:37] <wiesand> There are quite a few changes left to dicuss (the todo list was what I got written before 2pm utc...). But I think this can wait a bit.
[15:58:55] <wiesand> We made some nice progress today. Thanks.
[15:59:02] <wiesand> Anything else for today?
[16:00:14] <shadow@gmail.com/barnowlC1E71073> not here
[16:00:20] <deason> nah
[16:02:36] <wiesand> Ok. Thanks a lot everyone.
[16:03:12] wiesand leaves the room
[16:03:45] meffie leaves the room
[16:41:34] Marc Dionne leaves the room
[21:38:45] kaduk leaves the room
[23:27:52] deason leaves the room