- Wednesday, September 3, 2014

release-team@conference.openafs.org

Wednesday, September 3, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[06:43:04] Simon Wilkinson joins the room
[07:42:54] Simon Wilkinson leaves the room
[09:29:59] Simon Wilkinson joins the room
[12:05:07] Simon Wilkinson leaves the room
[12:17:00] Simon Wilkinson joins the room
[12:22:26] Simon Wilkinson leaves the room
[13:08:25] Simon Wilkinson joins the room
[13:38:30] meffie joins the room
[13:42:26] stephan.wiesand joins the room
[13:43:21] meffie leaves the room
[13:43:22] meffie joins the room
[13:45:01] <stephan.wiesand> Ha. Made it.
[13:49:42] stephan.wiesand leaves the room
[13:52:05] stephan.wiesand joins the room
[14:01:07] <stephan.wiesand> Hello
[14:01:21] deason joins the room
[14:01:32] <deason> hi
[14:01:47] <stephan.wiesand> Marc mailed me the Linux 3.17 status: 3.17 will need at least a few fixes:
1. A minor build issue around sysctl files, for which I already have a
fix. I will push to gerrit at some point next week once things settle
down.
2. An issue with d_splice_alias that requires more thought. Calls
that would result in creating a directory now fail with EIO, so use of
2 different paths for a directory can easily result in EIO errors
visible to the end user.
[14:01:48] <meffie> hello
[14:02:35] <stephan.wiesand> ETA for 3.17 is ~5 weeks I believe.
[14:02:52] <stephan.wiesand> Makes me wonder whether 1.6.10 should block on this?
[14:04:10] <stephan.wiesand> Thoughts?
[14:04:34] <deason> I would think a platform-specific release could be made if we need to
[14:05:22] <stephan.wiesand> That's the other option. But if we know we have to o it very soon, why not wait?
[14:06:22] <stephan.wiesand> But I guess if no problems are found during testing, 1.6.10 should be released r.s.n.
[14:07:45] <stephan.wiesand> So let's jsut jump to "pre1" testing on the agenda.
[14:07:51] <stephan.wiesand> Any new results?
[14:07:54] <deason> without actually seeing fixes or a full description of the problems, it's hard to make an informed decision :)
[14:08:24] <stephan.wiesand> Right, and Marc, is pretty busy these days. I don't envy him.
[14:08:52] <deason> yes, and an issue was found with rhel7, as mentioned
[14:09:36] <stephan.wiesand> So, I think, if we consider 1.6.10 ready and don't have the Linux changes available for review, let's release it. Otherwise, look at the new situation
[14:09:59] <stephan.wiesand> rhel7 = the unit file problem?
[14:10:25] <deason> yes; er, I suppose not rhel7-specific, but that's where it was found
[14:10:47] <stephan.wiesand> Likely to affect F>=18 too.
[14:11:12] <stephan.wiesand> That's another one I'd accept w/o pre2.
[14:11:54] <stephan.wiesand> And to answer your question: i think there is no acceptable downstream packaging for RHEL.
[14:12:29] <stephan.wiesand> And I don't think this will change.
[14:13:42] kaduk joins the room
[14:14:11] <kaduk> Sorry I'm late.
[14:14:21] <stephan.wiesand> Hi
[14:15:42] <deason> well, why? what happened? we're retracting what we said earlier about the packaging?
[14:15:57] <stephan.wiesand> I wouldn't want to break the packaging we have in the stable series at least.
[14:16:37] <stephan.wiesand> Nothing happened. Everything is the very same.
[14:16:57] <kaduk> We can carry different spec files for different sets of RHEL releases, right?
[14:17:11] <stephan.wiesand> The only (general) downstream packaging is elrepo.
[14:17:16] <stephan.wiesand> Ben: no.
[14:17:25] <stephan.wiesand> Single one with lots of %ifs.
[14:18:22] <stephan.wiesand> elrepo does the kabi-tracking-kmod thing, which isn't acceptable to the experts. qed.
[14:19:56] <stephan.wiesand> BTW: is there an option to run afsd in the foreground?
[14:21:01] <stephan.wiesand> Let's put the RHEL packaging situation in the minutes, and see if we get some feedback.
[14:21:12] <kaduk> I'm not sure that that (afsd in foreground) is even a concept that makes sense.
[14:21:31] <stephan.wiesand> NB Stephen does build for EL7. We just don't  upload the packages.
[14:21:38] <stephan.wiesand> Ben: why not?
[14:21:52] <deason> afsd doesn't even run "in the background"; there's nothing to foreground
[14:22:04] <kaduk> afsd's role in life is (mostly) to create a bunch of kernel processes; there's not much going on in userland.
[14:22:05] <meffie> afsd bootstraps the kernel module
[14:22:10] <deason> without some daemons like afsdb, it just runs some pioctls
[14:22:15] <deason> and then exits
[14:22:51] <stephan.wiesand> Ah.
[14:22:59] <deason> the only persistent processes are only there in certain configurations (afsdb, rmtsys, maybe others)
[14:23:39] <deason> but there needs to be some discussion of the rpm packaging if we what we told users earlier is not happening; is -devel where that will occur?
[14:23:55] <stephan.wiesand> Ok. I was jut asking because using type=simple seems the most natural thing with systemd.
[14:24:21] <stephan.wiesand> -devel will read get the minutes.
[14:24:49] <stephan.wiesand> But again, I pointed it all out when we discussed it, but everyone yelled "downstream". Nothing has changed.
[14:25:35] <deason> you're going to have to point to where you said that for me to know what you're talking about
[14:26:32] <deason> the only reason I had not been brining it up is because I thought I was told it was being handled, but apparently that's not true
[14:26:46] <stephan.wiesand> I'll have to find the transcript... but I'm sure I did. There's only elrepo, and that can't be endorsed.
[14:27:02] <shadow@gmail.com/barnowlE5B64A04> i did patches so you can run afsd "in the foreground" on macos, so
launchd can run it. but all it does is run the afsdb loop in the
foreground, and if afsdb is disabled, decline to do lookups
[14:27:10] <stephan.wiesand> And every time you try to talk about the kmd packaging with them, they simply shut down.
[14:28:35] <stephan.wiesand> Daria: thanks, but it doesn't sound like a big win in the Linux case.
[14:29:43] <deason> okay, it would have been nice to hear about any issues earlier
[14:29:47] <shadow@gmail.com/barnowlE5B64A04> it's not a big win.
[14:29:55] <deason> because as far as I or probably most other people knew, everything was fine and we were just waiting
[14:30:51] <stephan.wiesand> Well, you can use the elrepo packages. Most of the time, they'll work.
[14:33:19] <stephan.wiesand> But you all said the project should stop to care about packaging. So why do we care?
[14:33:55] <deason> then we should stop fixing bugs in the packaging and should "disable" it for rhel >= 7 and fedora >= 18 or whatever
[14:34:34] Simon Wilkinson leaves the room
[14:34:39] <deason> and while we, openafs.org may not care about packaging, it is certainly very rude to just... stop providing them without an alternative and without much notice
[14:35:29] <deason> you may have had others trying to work on this damn thing if what was going on was clear at all
[14:35:35] <deason> I would have been working on it if I had known
[14:35:47] <stephan.wiesand> On what?
[14:36:05] <deason> on the packaging; getting it in some other repository
[14:36:15] <deason> we should be able to not care after a "hand-off" is done, but not before
[14:36:59] <stephan.wiesand> I'm not aware of any repository that could be used.
[14:38:08] <deason> then that is the first I'm hearing about that; maybe some description or proof of that, saying why each 3rd-party repo is unsuitable, could be posted to -devel or -info?
[14:40:46] Simon Wilkinson joins the room
[14:41:53] <deason> but yes, sorry, any discussion can be on a mailing list; that doesn't need to be here
[14:41:56] <deason> moving on, if you want...
[14:42:44] <stephan.wiesand> btw, we had these discussions: http://comments.gmane.org/gmane.comp.file-systems.openafs.general/34986
[14:43:25] <stephan.wiesand> There's not much left on the agenda.
[14:43:48] <stephan.wiesand> The objdir/fbsd ones I'll merge soon.
[14:44:30] <stephan.wiesand> One open item is whether there's anything special to include in 1.6.11?
[14:45:30] <stephan.wiesand> Bug fixes, sure. But anything else? Or are we hoping for 1.6.x going very conservative now that we're looking forward to 1.8?
[14:45:52] <stephan.wiesand> Which brings us to the last topic: 1.8. Any news?
[14:46:39] <kaduk> I've been pretty swamped and haven't gotten to do any verification on the current master
[14:47:51] <stephan.wiesand> Same here. And the next couple of days, I'll have a beautiful surrounding and perfect weather...
[14:48:04] <kaduk> Don't spoil it by worrying about software!
[14:48:25] <stephan.wiesand> That's what I wanted to express ;-)
[14:48:45] <stephan.wiesand> Son't expect me to try building master for the rest of the week...
[14:49:07] <meffie> i build, run master frequently. but just in my sandbox.
[14:49:34] <stephan.wiesand> Well, it's a useful data point. Which platform?
[14:49:56] <meffie> debian linux and centos 5 and 6
[14:49:59] <stephan.wiesand> [OT: the program for this evening is this at sunset: http://www.kap-arkona.de/] <http://www.kap-arkona.de/%5D>
[14:50:22] <stephan.wiesand> Oh, good. Any quirks?
[14:51:31] <kaduk> debian stable or testing?
[14:52:02] <meffie> well, like ben told me last week, setting the key is slightly different.
[14:52:15] <meffie> testing
[14:53:06] <stephan.wiesand> Looks like a check mark behind the "basic verification" item to me.
[14:53:26] <kaduk> Oh, and client or server?
[14:53:40] <meffie> both
[14:53:52] <stephan.wiesand> (check check)
[14:54:09] <meffie> but like i said, just my sandbox.
[14:54:58] <stephan.wiesand> What exactly is your "sandbox"?
[14:55:03] <stephan.wiesand> Some VM?
[14:55:40] <meffie> my personal virtual private server and my vm's here.
[14:56:06] <stephan.wiesand> Fine.
[14:56:42] <meffie> (i remember the bad old days, before gerrit and buildbot... arg, that was no fun :)
[14:57:57] <stephan.wiesand> Ok. That whitespace cleanup is already in gerrit, and probably just a bit out of date?
[14:59:16] <meffie> it is just for makefiles. i'll resubmit, skipping the extra space in the comment header, like ben suggested (good idea). it will be much a smaller patchset.
[14:59:47] <meffie> i already abandoned the old one.
[15:00:13] <stephan.wiesand> It seems we're getting closer...
[15:00:29] <stephan.wiesand> Simon, Jeffrey, are you actually here?
[15:00:34] <Jeffrey Altman> I am
[15:00:47] <meffie> andrews comment about doxygen is interesting. we now have a make target to generate docs.
[15:01:40] <stephan.wiesand> Jeffrey: Thanks. Just wondering whether we would hear objections of there were any.
[15:02:23] <Jeffrey Altman> There really isn't anything to object to.   Setting deadlines is fine provided that there are resources available to meet them.
[15:03:39] <stephan.wiesand> Things look not so bad at this point to me.
[15:04:14] <stephan.wiesand> Of course, the branch will still need to be created. And it hasn't been discussed how it will be handled.
[15:04:41] <Jeffrey Altman> I remembering seeing a list of to do items for master before a branch that was sent by Simon.   I don't remember if in e-mail or here last week.
[15:05:04] <stephan.wiesand> I think it was here last week.
[15:06:14] <meffie> ben also put some notes on wiki.openafs.org, http://wiki.openafs.org/OpenAFS18Notes/
[15:06:40] <stephan.wiesand> Simon last week: "a few things that will need attention with libtool - I don't think we do the right thing with roken or hcrypto, and there's absolutely no packaging for any of it."
[15:06:44] <Jeffrey Altman> From Simon: libtool, roken, hcrypto, packaging
[15:07:14] <kaduk> I will confess I don't really understand what was meant by that.
[15:10:20] <stephan.wiesand> And I will confess I don't understand why any of that would be easier before branching.
[15:10:57] <Jeffrey Altman> It will be easier before branching because rxgk is going to alter libraries and dependencies
[15:11:37] <kaduk> It's not immediately clear that rxgk will drop the day after the branch is created, or that it would even be a good idea to try to do so.
[15:12:06] <Jeffrey Altman> I believe that Red Hat is pretty loose with libtool requirements and that Debian, Solaris and AIX are going to be where the remaining issues are.
[15:13:07] <Jeffrey Altman> We use git.   Until there is something new to fork there is no need for a new branch.
[15:13:55] <kaduk> We had talked about getting rid of non-pthreaded versions of many (all?) things on master.
[15:14:16] <kaduk> (post-branch)
[15:14:38] <Jeffrey Altman> there is much work to be done before that can happen
[15:16:44] <stephan.wiesand> Ok. 1.8 branch may happen around christmas 2015.
[15:16:53] <stephan.wiesand> Anything else to discuss today?
[15:18:10] <Jeffrey Altman> I believe that the libtool issues are going to become evident on Debian, Solaris, and AIX.  Red Hat EL/Fedora.
[15:18:32] <kaduk> How are they expected to become evident?  Just by building?
[15:18:43] <Jeffrey Altman> By building, packaging and running
[15:19:39] <Jeffrey Altman> Debian is much stricter than RHEL/Fedora when it comes to symbol management and Solaris and AIX libtools are somewhat special
[15:20:03] <Jeffrey Altman> Dependency failures might not be revealed until the binaries are executed.
[15:20:03] <kaduk> As a matter of fact, I am reading debian policy about symbol versioning in another window right now :)
[15:29:26] <Simon Wilkinson> Yeah, symbol versioning is an issue, as are their rules on transitive dependencies.
[15:29:46] <Simon Wilkinson> Those end up affecting the whole tree, because you have to fix it when you build the library, not just in the packaging
[15:30:03] <kaduk> transative dependencies?
[15:30:38] <Simon Wilkinson> Say you have a binary that needs symbols from library b. It links against library a, which links against library b.
[15:30:59] <kaduk> "Wait, that sounds like something you shouldn't do."
[15:31:00] <Simon Wilkinson> In Debian, you need the binary to link against both a and b. Everywhere else, you just link against a.
[15:31:38] <Simon Wilkinson> It may be something you shouldn't do, but it's something you don't discover the problem with until you try to build a Debian package.
[15:31:53] <kaduk> *nods*
[15:32:25] <Simon Wilkinson> The roken and hcrypto issues are that they aren't built with libtool (IIRC), so you have all of the shared library pain that you have when you aren't using libtool.
[15:33:43] <kaduk> "Instead, you get the fun that is dealing with libtool; pick your poison"
[15:35:17] <Jeffrey Altman> Or you get both poisons.
[15:41:59] meffie leaves the room
[15:46:03] <stephan.wiesand> Not sure what to make of the 1.8 discussion. Simply nothing, probably. Going for a long walk now.  Thanks for your participation.
[15:46:11] stephan.wiesand leaves the room
[15:47:53] deason leaves the room
[15:50:10] <Jeffrey Altman> Enjoy the walk.
[16:05:47] Simon Wilkinson leaves the room
[16:11:02] <shadow@gmail.com/barnowlE5B64A04> for things where debian builds the binary and needs a full set of
libraries, debian's libtool requirements (dependent libs, symbols) are
strictly correct. once you get debian happy, everything on other
platforms is platform-specific code, or mop-up
[16:15:58] Jeffrey Altman leaves the room
[16:20:18] Jeffrey Altman joins the room
[17:16:48] Jeffrey Altman leaves the room
[17:19:42] Jeffrey Altman joins the room
[17:35:05] Jeffrey Altman leaves the room
[17:38:36] Jeffrey Altman joins the room
[17:49:52] Simon Wilkinson joins the room
[18:56:09] Simon Wilkinson leaves the room
[19:16:18] Simon Wilkinson joins the room
[20:57:57] Jeffrey Altman leaves the room
[21:01:29] Jeffrey Altman joins the room
[21:37:57] Simon Wilkinson leaves the room
[21:47:30] Simon Wilkinson joins the room
[22:37:52] Simon Wilkinson leaves the room
[22:40:59] kaduk leaves the room