17:00:16 <abadger1999> #startmeeting fpc
17:00:16 <zodbot> Meeting started Thu Dec  5 17:00:16 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:19 <abadger1999> #meetingname fpc
17:00:19 <zodbot> The meeting name has been set to 'fpc'
17:00:25 <abadger1999> #topic Roll Call
17:00:28 <abadger1999> Who's here?
17:01:39 * geppetto is here
17:01:52 <abadger1999> limburgher geppetto tibbs|w RemiFedora Smoother1rOgZ: fpc ping
17:01:55 <abadger1999> #chair geppetto
17:01:55 <zodbot> Current chairs: abadger1999 geppetto
17:02:00 <tibbs|w> Howdy.
17:02:13 * limburgher is here, after a fashion.
17:02:26 <abadger1999> #chair tibbs|w limburgher
17:02:26 <zodbot> Current chairs: abadger1999 geppetto limburgher tibbs|w
17:02:42 <abadger1999> Might be a short meeting :-/
17:02:48 * RemiFedora is here (but will have to go as soon as his phone rings in the next hour)
17:02:56 <abadger1999> #chair RemiFedora
17:02:56 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher tibbs|w
17:03:08 <tibbs|w> Yeah, I'll be in and out today as I'm alone in the office.
17:03:09 <abadger1999> Okay... that's just enough for quorum... let's see what we can get done.
17:03:46 <abadger1999> #topic #339     software collections in Fedora
17:03:50 <abadger1999> https://fedorahosted.org/fpc/ticket/339
17:04:26 <abadger1999> I reworked the https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval section a talked about last meeting
17:04:42 <abadger1999> I didn't get to anything else.
17:05:35 <abadger1999> Although I thought of another problem (it's the admon/question at the end of that section.... not sure where to take that at all...)
17:05:45 <abadger1999> randomuser: greetings
17:05:48 <abadger1999> Err sorry
17:05:52 <abadger1999> Rathann: greetings
17:05:57 <Rathann> hi
17:06:00 <abadger1999> #chair Rathann
17:06:00 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher tibbs|w
17:06:16 <geppetto> abadger1999: Not sure what the diff. is but it looks fine now :-o
17:06:20 <abadger1999> Rathann: We're just looking at how I reworded https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval  from last meeting.
17:07:55 <abadger1999> The two changes are: that Remi moved the Vendor admon/note up from a lower section and that I added the parts about extra General SCL packages that aren't supported by the SCL Owners to the paragraph
17:08:08 <abadger1999> If there aren't any more coments, let's vote.
17:08:21 <RemiFedora> abadger1999, IIUC the last question is about enabling RHSCL / RHDTS for EPEL build ?
17:08:25 <abadger1999> Approve changes to the SCL Approval Section.
17:08:34 <abadger1999> RemiFedora: For EPEL and for Fedora builds.
17:08:48 <Rathann> what's "SCL Request"?
17:08:53 <tibbs|w> +1 pretty sure I was OK with this before and the changes don't break anything.
17:08:56 <RemiFedora> sorry, but I can't understand which other "vendor" can provides dep for Fedora
17:09:03 <Rathann> it doesn't seem to be defined anywhere
17:09:08 <tibbs|w> Although I have no idea at all what RHDTS is.
17:09:23 <RemiFedora> tibbs|w, RHDTS Dev ToolSet, mostly gcc 4.8
17:09:31 <abadger1999> RemiFedora: Since people seem to want to use SCLs as a platform that they can build on top of with different OS/distros underneath, we'd have to be able to support that same use case in Fedora as well.
17:09:46 <abadger1999> RemiFedora: Which is.... I don't have a solution yet.
17:10:54 <abadger1999> Rathann: SCL Request probably should be renamed to something like "SCL Definition".  It's laid out more in the SCL Approval Process section: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval_Process
17:11:05 <geppetto> +1
17:11:22 <abadger1999> Rathann: It's the equivalent of a fedora Feature Page.
17:11:41 <abadger1999> +1
17:11:48 <limburgher> +1
17:11:57 <RemiFedora> +1
17:12:20 <abadger1999> That's +5.  Rathann, you can still vote for the record.
17:12:47 <Rathann> the paragraph is not clear in my opinion, I had to read it three times and I still don't quite understand what it says
17:13:25 <Rathann> i.e. what's the difference between SCL packages that are part of SCL and those that aren't
17:13:48 <Rathann> and why the "external" SCL packages can't carry any official compat guarantee
17:14:09 <Rathann> so I'm -1 to it in current form
17:14:22 <abadger1999> Rathann: So.. I'm thinking there's two categories of General SCL packages that can be in an SCL.
17:14:38 <abadger1999> Those which the SCL Owners are specifically supporting to make up the platform.
17:15:02 <abadger1999> These need to be listed in the SCL Request/Definition by the SCL Owners.
17:15:33 <abadger1999> They can carry backwards compat guarantees if the Owners wantthem to -- the owners are putting themselves on the hook to maintain compatibility for those specific general scl packages.
17:15:46 <abadger1999> The second category are "addons" to the SCL.
17:16:28 <abadger1999> For instance, the SCL might be a Rails2 stack but that might not have builtin support for talking to LDAP.
17:17:06 <abadger1999> A few packagers within Fedora might want to add the packages to support LDAP so that they can share the maintainance burden between them.
17:18:10 <abadger1999> The LDAP packages should not affect what the SCL Owners want to define as their platform (otherwise it would be someone else signing them up for more work).
17:18:39 <abadger1999> But we also don't want to prohibit these non-owner packagers from contributing their work on that LDAP package.
17:18:44 <abadger1999> Rathann: Does that make sense?
17:19:01 <Rathann> ok, but why forbid compat guarantee for the second category?
17:19:15 <geppetto> It makes sense … but I'm not sure it's a good idea, or that it's viable … or that it'll even be tried in practice.
17:19:20 <Rathann> also, is there a path to "promote" a package to the first category?
17:19:22 <abadger1999> Rathann: Several reasons: because compat guarantees establish the platform.
17:20:02 <Rathann> abadger1999: but what stops the maintainers from actually keeping the compatibility even if they are forbidden?
17:20:03 <abadger1999> Rathann: and there's not a place for those compat guarantees to be recorded that won't infringe on what the SCL Owners themselves want to define their platform as.
17:20:06 <Rathann> doesn't make sense to me
17:20:21 <abadger1999> Rathann: nothing.  It's just a prohibition against making the guarantee.
17:20:40 <Rathann> so they can do it, they just can't say they're doing it?
17:20:45 <Rathann> ...
17:20:59 <Rathann> still doesn't make sense
17:21:00 <abadger1999> Rathann: If they want to make a guarantee, then they should be creating a different SCL that has a inter-SCL dependency on the Rails2 SCL.
17:21:33 <Rathann> I think we're talking past each other
17:21:56 <limburgher> I think my head hurts.
17:22:04 <abadger1999> Rathann: The promotion question should be handled in: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#Changing_a_Guarantee
17:22:44 <Rathann> right, ok
17:23:26 <abadger1999> We're at +5 but I would certainly be okay with making the language more clear... Rathann do you want to talk with me after hte meeting about making the section better and we can vote on that next meeting?
17:23:35 <Rathann> hm, do you actually simply want to say that "add-on" SCL packages can't and won't be listed in the compat guarantee list of the SCL?
17:23:43 <Rathann> that I can agree with
17:24:14 <abadger1999> Rathann: Both that and that the SCL Owners can't block the "add-on" packages from entering Fedora.
17:24:47 <Rathann> well, as long as it doesn't break the SCL compat guarantees I think the add-on maintainers should be free to do whatever they want
17:24:53 <abadger1999> Cool.
17:25:03 <abadger1999> let's talk more after the meeting to make the wording more clear.
17:25:16 <Rathann> I'd suggest splitting into two parts
17:25:27 <Rathann> one for packages which are part of the SCL request
17:25:33 <Rathann> and the other for add-ons
17:25:48 <abadger1999> #info Changes to SCL Approval section approved... rathann and abadger1999 to further refine the wording later (+1:5, 0:0, -1:1)
17:26:30 <abadger1999> Rathann: yeah, making it explicit that we have two categories of general scl packages would be good.
17:26:33 <abadger1999> #topic #358     Please make some autotools guidelines.
17:26:38 <abadger1999> https://fedorahosted.org/fpc/ticket/358
17:26:52 <abadger1999> I started on this: https://fedoraproject.org/wiki/User:Toshio/Autotools_(draft)
17:28:37 <tibbs|w> To be honest I'm surprised you're spending your time on this.
17:29:13 <abadger1999> yeah... not my prefered way to spend an evening :-/
17:29:33 <abadger1999> but it comes up a lot.
17:29:50 <tibbs|w> Should have just been "someone send us a draft and we'll look at it".
17:30:26 <limburgher> abadger1999: Thanks for writing this, I just learned a surprising amount reading it.
17:31:03 <tibbs|w> I think the first thing we should do is make sure there's agreement on the "just run configure unless something's actually broken" rule.
17:31:04 <abadger1999> <nod>  I guess the problem is that people are in one camp or the other and we won't approve something that is only one-camp or the other.
17:31:14 <abadger1999> tibbs|w: +1 to that.
17:32:04 <abadger1999> Anyone disagree with tibbs|w's rule?
17:32:20 <tibbs|w> I'm happy with the "should not" that's in there but I suspect that some would want "must not".
17:32:53 <Rathann> usually you need BR: libtool as well
17:33:02 <Rathann> well, if there are shared libraries
17:33:30 <Rathann> and +1 to the if it works don't fix it rule
17:34:08 <Rathann> well, draft wording is fine
17:34:22 <geppetto> Sure, +1 on that.
17:34:35 <RemiFedora> yes, +1
17:35:10 <limburgher> +1
17:35:26 <abadger1999> Cool.  We're in agreement on that portion then.
17:35:36 * abadger1999 adds libtool as a BR
17:35:57 <geppetto> I mean … I understand some people "like" to be able to run autoreconf 100% of the time … but I'm very happy tell them to take a long walk off a short pier.
17:36:00 <tibbs|w> Kind of sucks that racor isn't around, since I know he has strong opinions here.
17:36:19 <abadger1999> Yeah... I'm okay to table this... it's been outstanding for a long long time.
17:36:20 <Rathann> geppetto: I wouldn't forbid it if it doesn't break anything either
17:36:39 <geppetto> Rathann: Isn't that what tibbs|w's rule is?
17:36:40 <abadger1999> maybe I'll ask leamas if he'd be willing to fill in the patching section from the page he mentioned.
17:36:47 <Rathann> geppetto: yes it is
17:36:57 <Rathann> but it sounded like you wanted to forbid it
17:37:11 <leamas> abadger1999: I'm here. Not really, I prefer patdhing the sources ;)
17:37:21 <abadger1999> leamas: ah okay :-)
17:37:27 <geppetto> Rathann: I mean … doesn't the tibbs|w's rule forbid running autoconf … if it works, don't break it == if it works, don't run autoreconf.
17:37:48 <geppetto> tibbs|w: Isn't that what you meant?
17:37:51 <tibbs|w> Well, it's should not must.
17:37:56 <geppetto> I guess.
17:38:17 <tibbs|w> But hell, even "must" really means justify it if you do something differently.
17:38:54 <abadger1999> <nod> and fixing the build can be stretched to encompass some non-essential things
17:39:05 <abadger1999> (like fixing rpath)
17:39:17 <tibbs|w> This is really about how much arguing package reviewers are supposed to do.
17:40:29 <geppetto> abadger1999: So, for the first section … I think it needs to be stressed much harder that you are relying on autoconf being the same version (or compat. with that version).
17:41:12 <abadger1999> geppetto: k
17:41:21 <geppetto> I'd even suggest that the BR: should include an = version in it … but I bet nobody who uses this method currently does that and they'll all come for me with pitchforks if I suggest it :)
17:42:17 <geppetto> The main part of "patching the generated files" is that you don't need to do this testing … you autreconf on your machine, test it once and then you are good to go forever.
17:42:46 <abadger1999> geppetto: well... not really -- the patch needs to be regenerated every upstream release.
17:42:55 <geppetto> Well, until upstream does a new release … and then your patch is almost guaranteed to fail.
17:43:01 <abadger1999> since configure.ac has the version in it.
17:43:03 <abadger1999> yeah.
17:43:41 <leamas> Isn't this partly what kind of upstream  we are dealing with? One who maintains their autoconf sources, or not?
17:44:09 <abadger1999> geppetto: One thing I don't remember -- If you patch just the Makefile.in/configure script, does the generated Makefile detect timestamps out of date and try to rerun autools to regenerate those?
17:45:05 <geppetto> abadger1999: No, your patched Makefile.in will be higher mtime than your Makefile.am … dito. configure/configure.ac
17:46:15 <geppetto> leamas: It depends … they could be "maintained" … but the release machine have an older version of autoconf, at which point neither option will work (but the "patch generated" will always fail loudly).
17:47:53 * Rathann notices we do have autoconf213 packaged still
17:48:04 <abadger1999> Okay... so at the moment, the draft needs finishing and there's some prior work that might be helpful.
17:50:39 <abadger1999> I'll see if anyone wants to work on it in the ticket and try to merge the prior work if no one else steps forward.
17:50:55 <abadger1999> #topic #364     exception for bundled library ccan in ocserv
17:51:01 <abadger1999> https://fedorahosted.org/fpc/ticket/364
17:51:19 <abadger1999> So we know this is a copylib... but the Virtual Provides are trickier than normal.
17:53:17 <abadger1999> geppetto (or anyone): want to just make a decision about the names for those?  pretty sure if someone just makes a decision we can vote on it and approve.
17:53:44 <geppetto> I'd guess use ccan-<blah> for all of them except the hash one and use it's name for that.
17:53:53 <Rathann> geppetto: +1
17:53:54 <geppetto> jenkins/lookup3/whatever.
17:54:54 <tibbs|w> +1 this isn't even worth bikeshedding.
17:55:08 <limburgher> +1
17:55:29 <RemiFedora> (sorry, was disconnected, which ticket ?)
17:55:37 <geppetto> RemiFedora: https://fedorahosted.org/fpc/ticket/364
17:56:36 <abadger1999> I pasted the virtual provides in: https://fedorahosted.org/fpc/ticket/364#comment:8
17:56:50 <abadger1999> I'm supposing that there's no way to version these... I'll mention that in the comments.
17:56:58 <abadger1999> (the comments i nthe exception table)
17:57:04 <abadger1999> +1
17:57:31 <RemiFedora> +1
17:58:30 <Rathann> +1
17:58:50 <geppetto> +1
17:59:39 <abadger1999> #info exception for bundled library ccan in ocserv approved (+1:7, 0:0, -1:0)
18:00:08 <abadger1999> lpf was taken care of
18:00:21 <abadger1999> #topic #367     Another bundled MD5 implementation originally by Ulrich
18:00:30 <abadger1999> https://fedorahosted.org/fpc/ticket/367
18:01:14 <tibbs|w> I'm glad people are looking for these, but damn.
18:02:25 <geppetto> I mean … I kind of feel like someone should send an email to Ulrich and ask him which md5 he'd prefer to keep and which to delete :)
18:02:46 <abadger1999> <nod>
18:02:46 <tibbs|w> Unless someone thinks they should change implementation we just need to pick what the provide should be and move on.
18:02:55 <limburgher> <headdesk>
18:03:22 <tibbs|w> Though it would be really nice if, you know, the damn C library exported a function for this.
18:03:24 <geppetto> I guess it's bundled(md5-Drepper2) = busybox … or something.
18:03:39 <tibbs|w> Rather than the guy who maintained the C library to make two separate implementations of his own.
18:03:49 <abadger1999> geppetto: I haven't looked at the implementation but that would work for me.
18:03:49 <geppetto> indeed
18:03:58 <geppetto> yeh, me either.
18:04:37 <RemiFedora> sorry, have to go
18:08:40 <abadger1999> Proposal: use bundled(md5-Drepper2) and please see if busybox would be willing to use the version from glibc
18:08:43 <abadger1999> +1
18:08:46 <geppetto> +1
18:08:51 <Rathann> +1
18:09:24 <limburgher> +1
18:09:46 <tibbs|w> +1
18:10:39 <abadger1999> #info Approved use of bundled(md5-Drepper) and asked the reporter to continue to find out if busybox will switch implementations (+1:5, 0:0, -1:0)
18:11:07 <abadger1999> Are people good to continue or are we going to lose quorum soon?
18:11:31 <limburgher> I have a little longer.
18:12:49 <abadger1999> #topic #369     Guidance on dealing with the bundled libev in perl-EV
18:12:54 <abadger1999> https://fedorahosted.org/fpc/ticket/369
18:13:11 <tibbs|w> This has been a mess for a long time now.
18:14:27 <tibbs|w> The last comment sort of indicates that Fedora's choices create at least some of the incompatibilities.
18:15:06 <geppetto> tibbs|w: Why do you say that … the stat struct bit?
18:15:30 <tibbs|w> The last sentence in the ticket.
18:16:20 <tibbs|w> I am not sure why we'd pick the smaller stat struct on purpose, but who knows.
18:17:21 <geppetto> yeh, that seems like an error in the libev building.
18:18:46 <geppetto> So given libev is required by a bunch of stuff, I'm tempted to tell upstream "no"
18:18:57 <abadger1999> If we decide we need to go the -source route... I think we'd treat it like a static library rather than a bundled library
18:19:04 <geppetto> So they either fix perl-EV or we dump it.
18:19:31 <abadger1999> and rxvt-unicode
18:19:43 * geppetto shrug … sure.
18:20:26 <geppetto> I have no problem with that.
18:20:29 <tibbs|w> perl-EV is a dependency of a few things.
18:20:31 <Rathann> question is, maybe libev can simply be rebuilt with different options so that it's ABI compatible with perl-EV?
18:20:50 <Rathann> and not break all dependent packages in the process, of course
18:20:52 <tibbs|w> Incliding perl-DBI, which is kind of a dependency of a whole lot of things.
18:21:14 <geppetto> perl-DBI depends on perl-EV??
18:21:31 <tibbs|w> via perl-Coro, at least in F19.
18:21:37 <geppetto> Ahh
18:21:54 <tibbs|w> So this is kind of a big dea.
18:21:56 <tibbs|w> deal.
18:22:04 * geppetto didn't follow the deps. … just saw perl-Coro and I didn't recognize it.
18:23:07 * geppetto sighs … we probably can't ban it then.
18:23:15 <abadger1999> So... is there any information that we can ask for that would help us here?
18:23:20 <tibbs|w> So what I'm seeing is that this _might_ be fixable if someone works out whether the incompatibilities are due to choices we made as a distro.
18:23:42 <abadger1999> .whoowns libev
18:23:42 <zodbot> abadger1999: bochecha (cassmodiah in Fedora EPEL)
18:23:58 <tibbs|w> Otherwise I think we're going to have to live with this.
18:25:12 <Rathann> well in the worst case perl-EV should take the BR: libev-source route
18:25:19 <tibbs|w> Indeed.
18:27:11 <abadger1999> <nod>
18:27:14 <geppetto> yeh
18:27:29 <abadger1999> Okay, I'll ask in ticket if we could build libev in a way that would make it compatible.
18:28:03 <abadger1999> If not, next week we can evaluate how it could use the static library or bundled library guidelines to do what it does.
18:28:20 * abadger1999 believes limburgher had a similar case at one point where we eventually used a -sources library as well.
18:28:44 <abadger1999> #topic #372     Temporary bundling exception for kernel event library
18:29:19 <abadger1999> https://fedorahosted.org/fpc/ticket/372
18:29:28 <abadger1999> I'm inclined to grant a temporary exception here.
18:29:41 <tibbs|w> There was some talk in the -kernel channel.
18:30:04 <limburgher> abadger1999: lzma, I think
18:30:10 <geppetto> yeh, they gave a timeline for real library … so I'm happy to +1 until 3.15 is released.
18:30:14 <abadger1999> I'd just need to know how "kernel-3.15" matches up with Fedora releases
18:30:28 <limburgher> abadger1999:  get a ouija board. :)
18:30:58 <abadger1999> I guess the kernel is major enough that saying "until kernel-3.15 enters Fedora" would be okay.
18:31:04 <limburgher> Prolly.
18:32:02 <abadger1999> Proposal: the event library from the kernel may be bundled in other applications until kernel-3.15 enters fedora.
18:32:05 <abadger1999> +1
18:32:10 <limburgher> +1
18:32:18 <geppetto> +1
18:32:27 <Rathann> +1
18:32:33 <tibbs|w> Until the point where it enters Fedora, or when a Fedora release ships with that kernel or newer?
18:32:36 <geppetto> I don't mind saying "until F22", if you want to put it in Fedora terms. …
18:32:49 <tibbs|w> Just wondering if the bundling ends in the middle of a release or not.
18:33:18 <geppetto> I'm fine with it not having to end in the middle of a release.
18:33:36 <limburgher> So, like, 3.15 enters in f21, and they can unbundle in f22?
18:33:48 <geppetto> sure
18:33:49 * abadger1999 agrees... that seems to be the precedent (although not breaking library api mid-release is probably part of that precedent)
18:34:14 <abadger1999> tibbs|w: So what's the clearer wording?
18:34:27 <tibbs|w> Sorry, I'm trying to find the discussion I saw in my IRC logs.
18:34:38 <tibbs|w> Turns out if was on fedora-admin.  You were chatting with jwb on Monday.
18:35:00 <tibbs|w> Wasn't he going to investigate this further?
18:35:19 * jwb looks up
18:35:26 <geppetto> Proposal: the kernel event library from the kernel may be bundled in other applications through F22, if you still need to bundle in F23 come back to us.
18:35:35 <tibbs|w> http://fpaste.org/59333/26853113/
18:35:50 <tibbs|w> Or is this about something different?
18:35:54 <jwb> oh, yeah.  i replied on the lists
18:36:11 <tibbs|w> Too many lists, too much traffic.  Ugh.
18:36:26 <jwb> basically, it's not consumable as a shared lib from the kernel until probably 3.15
18:36:36 <geppetto> Yeh, that's what the ticket says :)
18:36:38 <jwb> around then we can subpackage it
18:36:52 <jwb> so i like geppetto's proposal
18:36:52 <Rathann> but could it be consumable as a static lib earlier? does that even make sense?
18:37:04 <jwb> yes
18:37:08 <geppetto> from quick math of 3 months per. release I figure 3.15 should be out before F23 … right?
18:38:55 <jwb> with the current fedora.next stuff... no idea
18:39:02 <jwb> but i would think approximately yes
18:39:57 <Rathann> ok, I'm +1 to geppetto's proposal either way
18:40:12 <Rathann> having the ability to unbundle it earlier would be nice to have
18:40:28 <Rathann> but I guess jwb's time is better spent on other stuff :)
18:40:48 <abadger1999> geppetto: +1
18:43:28 <tibbs|w> Anyway, I have no problem with a temporary exception here, and I'm happy to either say F23 or "until a kernel is available which provides a proper shared library".
18:43:58 <geppetto> I figure saying F23, or ask if it got delayed, is much easier on people following the rules.
18:44:06 <abadger1999> <nod>
18:44:34 <geppetto> limburgher: you still around?
18:44:53 <abadger1999> So we're at abadger1999, tibbs|w, Rathann, geppetto +1.  Need one more
18:45:09 <geppetto> remi got the call and had to leave
18:45:37 <abadger1999> #info  the kernel event library from the kernel may be bundled in other applications through F22, if you still need to bundle in F23 come back to us.  Current votes: (+1:4, 0:0, -1:0)  will get one more vote in ticket
18:45:54 <abadger1999> #topic Open Floor
18:46:02 <abadger1999> Anyone have anything to bring up?
18:46:05 <tibbs|w> Wow, we made it to an open floor.
18:46:09 <Rathann> \o/
18:46:13 <abadger1999> Yeah -- quite amazing :-)
18:46:15 <tibbs|w> In under two hours.
18:46:18 * Rathann has nothing
18:46:54 <limburgher> geppetto:  Sort of, sorry.
18:47:25 <limburgher> I vote +1, want it in the ticket?
18:47:35 <abadger1999> limburgher: Nope, that's fine.
18:47:52 <abadger1999> #info  Update: the kernel event library from the kernel may be bundled in other applications through F22, if you still need to bundle in F23 come back to us.  Approved: (+1:5, 0:0, -1:0)
18:48:13 <abadger1999> Okay, thanks for coming everyone and plowing through the queue.
18:48:24 <geppetto> and now lunch time :)
18:48:29 <limburgher> w00t!
18:48:31 <abadger1999> #endmeeting