16:06:10 <abadger1999> #startmeeting fpc
16:06:10 <zodbot> Meeting started Thu May 15 16:06:10 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:06:15 <abadger1999> #topic Roll Call
16:06:16 * geppetto is here
16:06:20 <abadger1999> Who's around?
16:06:25 <abadger1999> #chair geppetto
16:06:25 <zodbot> Current chairs: abadger1999 geppetto
16:06:52 * abadger1999 notes that he has a phone meeting on the hour so he won't be here to run the meeting then.
16:07:04 <abadger1999> If someone else wants to run it into the second hour, that's fine with me.
16:07:47 <geppetto> we'll see if we have quorum etc.
16:07:55 <abadger1999> ping spot, racor, RemiFedora, limburgher, Smoother1rOgZ: FPC meeting time
16:08:14 <abadger1999> ping tibbs: FPC meeting time
16:08:16 * RemiFedora here (sorry, quite late)
16:08:25 * racor is here
16:08:30 * abadger1999 thinks tibbs is probably not here until his work nick shows up
16:08:37 <abadger1999> #chair RemiFedora racor
16:08:37 <zodbot> Current chairs: RemiFedora abadger1999 geppetto racor
16:09:35 * jsmith lurks
16:09:56 <abadger1999> Waits another minute... if we don't get quorum we can discuss some tickets and try to get remaining votes in ticket.
16:11:25 * limburgher is here and apparently not paying attention.
16:11:44 <abadger1999> #chair limburgher
16:11:44 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher racor
16:12:07 <geppetto> woo, and then there were 5
16:12:12 <abadger1999> #topic  #339     software collections in Fedora
16:12:17 <abadger1999> https://fedorahosted.org/fpc/ticket/339
16:12:39 <abadger1999> geppetto: Did you get a chance to finish your testing/work/creation of SCL?
16:12:49 <abadger1999> I've been thinking about what you said last week.
16:13:44 <geppetto> no, I thought I would … but fail.
16:13:55 <abadger1999> I think it would be a big change to the already approved portion of the guidelines if we made changes to accomodate those.  But it shouldn't affect the area that I'm working on now (the actual packaging of scls).
16:14:03 <geppetto> I've banged my head against it a bit more though … and maybe understand a tiny bit more.
16:14:24 <abadger1999> So -- if you'd like to work up a new proposal of how we should break up scls, we can vote on the changes independent of the rest.
16:14:25 <abadger1999> k
16:14:52 <geppetto> it's not really a change to how we break them up … I don't think.
16:14:57 <abadger1999> k
16:15:24 <abadger1999> Since we're under time pressure this week, let's discuss this next week.
16:15:28 <abadger1999> #topic #382     Go Packaging Guidelines Draft
16:15:34 <abadger1999> https://fedorahosted.org/fpc/ticket/382
16:15:42 <abadger1999> vbatts had some answers and updates.
16:16:58 <abadger1999> the library situation continues to be the sticking point.
16:17:20 <abadger1999> Does anyone want to take point on that?  (And/or the go draft in general?)
16:18:02 <geppetto> has anyone written any go?
16:18:22 <abadger1999> I mean, using source has precedent and it basically equates to static linkage as proposed... but recursively checking the dep tree if there's a problem seems kinda icky.
16:18:28 * abadger1999 has not
16:18:38 <racor> no, not me
16:18:46 <geppetto> s/kindy icky/completely insane/
16:20:01 <limburgher> Me neither.
16:20:46 <geppetto> I mean … it seems bad enough if for every bugfix (security or not) we need to rebuild the thing, and then rebuild (really relink) every app. that deps. on it.
16:20:59 <abadger1999> I guess -- does it make more sense that we require rebuilds of all dependent packages anytime a dependency is updated, enforced by rpm, or that we allow things to keep working but have to do a bit more work if a security issue occurs?
16:21:10 <geppetto> But this is like … we need to rebuild the entire chain, from the bottom up … for every app.
16:21:44 <abadger1999> Oh... and for packagers, on getting a bug report, will one of the  first htings they need to do is recompile the package to pick up the updates in all of their deps and ask "does that bug still happen?"
16:22:09 <geppetto> My guess is they'll ask if it happens in rawhide
16:22:30 <geppetto> one good point is that with all the static linking it'll be easy to install rawhide packages on a release :)
16:22:44 <limburgher> Oh bother. . .
16:24:44 <geppetto> My guess is that requiring rebuilds will mean nobody ever updates a dep. … and that not requiring updates means that everything will be broken all the time, and nobody will update leaves.
16:24:55 <geppetto> So I'm tempted to require them.
16:25:00 <abadger1999> <nod>
16:25:17 <geppetto> Bonus … that makes the pain more obvious, so someone might fix it.
16:25:33 <abadger1999> In fedora, that seems like the lesser of two evils.
16:25:49 <racor> geppetto: Isn't this the same situation we already have for ghc and perl? For perl modules, we require an exact version match.
16:26:23 <geppetto> racor: for what?
16:27:39 <geppetto> racor: I see a bunch of perl requires that aren't package = E:V-R
16:27:52 <racor> geppetto: For the version of the perl-interpreter. It's the reason for "Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))"
16:28:06 <racor> each perl-module is supposed to carry.
16:28:09 <geppetto> Oh, yeh, for the interp. … but that's only one thing
16:29:26 <racor> yep, there are no "build-ids" or similar to be considered.
16:29:35 <geppetto> ghc is similar … but that is haskell … go is supposed to be mainstream.
16:31:53 <geppetto> abadger1999: do we want to vote on any parts of it?
16:32:01 <abadger1999> I don't know that we can.
16:32:11 <abadger1999> the library thing is pretty intrinsic.
16:32:21 <limburgher> <nods>
16:32:42 <abadger1999> I mean the rest of it might be fine but they can't actually package go packages without the library portion.
16:34:07 <abadger1999> So.. I guess I can update the ticket with the info that we see drawbacks in both but we're presently leaning towards prefering hte front-end, obvious, packager pain to hidden, more work in an emergency  pain and explain a little of our thinking there.
16:35:16 <abadger1999> #topic #418     Bundling exception for reaver-wps
16:35:24 <abadger1999> https://fedorahosted.org/fpc/ticket/418
16:35:26 <racor> abadger1999: Would it be inappropriate to ask the go folks for 2 specs (A lib + a binary using this lib) to experiment with?
16:35:52 <abadger1999> #topic  #382     Go Packaging Guidelines Draft
16:36:00 <abadger1999> That sounds good.  and something we've done before
16:36:24 <abadger1999> #info abadger1999 to ask for some go spec files to look at as well.  (A library and a binary using the library)
16:36:32 <abadger1999> #topic #418     Bundling exception for reaver-wps
16:36:37 <abadger1999> https://fedorahosted.org/fpc/ticket/418
16:36:49 <abadger1999> So this one looks even forkier to me :-)
16:37:12 <RemiFedora> yes
16:37:36 <abadger1999> The value of virtual provides seems to drop off here (I mean, we don't require libreoffice to virtual provide openoffice even though they share a bunch of code)
16:39:07 <abadger1999> Shall we vote to allow this without virtual provides?
16:39:23 <geppetto> sure, I'm +1
16:39:45 <abadger1999> Proposal: reaver-wps usage of wpa-supplicant code is a fork: thus allowed and no need for virtual provides.
16:39:46 <abadger1999> +1
16:39:48 <limburgher> +1
16:40:21 <abadger1999> RemiFedoram racor: votes on reaver-wps
16:41:03 <racor> +1
16:41:13 <RemiFedora> +1
16:41:31 <abadger1999> #info reaver-wps usage of wpa-supplicant code is a fork: thus allowed and no need for virtual provides. APPROVED: (+1:5, 0:0, -1:0)
16:42:34 <abadger1999> ruby193SCL I'll skip this week since geppetto's work will likely influence it.
16:42:46 <abadger1999> But we should look at it next week so we don't block them.
16:43:27 <abadger1999> systemd deps -- we asked for the fakesystemd solution and haven't heard back that that's acceptable/unacceptable.  So I think nothing to discuss this week.
16:43:33 <abadger1999> #topic #422     move an existing package to a different upstream fork
16:43:40 <abadger1999> https://fedorahosted.org/fpc/ticket/422
16:44:19 <abadger1999> I think the packager took this to fesco as requested.
16:44:24 <geppetto> ok
16:44:28 <abadger1999> I'll close it since it's a fesco issue anyhow.
16:44:40 <geppetto> depending on the details, I'm not even sure I'd care that much if he just changed the upstream.
16:44:47 <geppetto> but, yeh
16:44:49 <abadger1999> yeah.
16:45:06 <abadger1999> I'm remembering libjpegturbo as precedent.
16:45:24 <abadger1999> But that might have been a Fedora Change because libjpegturbo is used by so many dependent packages.
16:45:39 * geppetto nods
16:45:56 <abadger1999> #topic #423     Bundling exception request (copylib) for TommyDS library in SnapRAID
16:46:01 <abadger1999> https://fedorahosted.org/fpc/ticket/423
16:47:36 <abadger1999> To some extent, this seems like it would be okay to build as a static library rather than bundled.
16:47:55 <abadger1999> However, the library is provided by the same upstream as the package.
16:48:04 <abadger1999> So there would be precedent to bundle there.
16:49:31 <geppetto> it could maybe be a header library type thing, like some of boost
16:49:34 <abadger1999> the tweakable header values also point towards copylib
16:49:35 <geppetto> but meh.
16:49:37 <RemiFedora> sounds like more an internal lib
16:49:57 <geppetto> assuming there is only 1 user … I'm tempted to just let it go.
16:50:11 <abadger1999> <nod>
16:50:42 <racor> assuming there is only 1 user ... I'm tempted to ban TommyDS as separate lib
16:52:12 <abadger1999> Proposal: SnapRAID is allowed to bundle TommyDS library for the following reasons: Same upstream for both, tweaking header values to configure the library at buildtime (copylib), and only one user.  Please see us again if any of that changes.
16:52:27 <RemiFedora> +1
16:52:35 <abadger1999> +1
16:53:00 <racor> +1
16:53:29 <geppetto> +1
16:54:06 <abadger1999> limburgher: SnapRAID bundling TommyDS  vote
16:54:15 <limburgher> +1
16:54:46 <abadger1999> #info SnapRAID is allowed to bundle TommyDS library for the following reasons: Same upstream for both, tweaking header values to configure the library at buildtime (copylib), and SnapRAID is the only user of TommyDS. Please see us again if any of that changes. Approved (+1:5, 0:0, -1:0)
16:54:57 <abadger1999> Okay, I have to leave in 5 minutes.
16:55:03 <abadger1999> Anyone want to take over?
16:55:09 <limburgher> I can't
16:55:33 <abadger1999> #topic Open Floor
16:55:36 <abadger1999> Alright then.
16:55:55 <abadger1999> anyone want to bring something else up?  We have time for one more ticket or discussion item.
16:56:25 * abadger1999 sees remi submitted ticket 430, for instance.
16:56:47 <RemiFedora> simple should be fast
16:56:50 <geppetto> RemiFedora: ?
16:56:56 * geppetto nods … cool
16:57:04 <abadger1999> #topic #430     Minor PHP Guidelines change
16:57:08 <abadger1999> https://fedorahosted.org/fpc/ticket/430
16:57:20 <abadger1999> This just adds a line that tells where pecl documentation belongs.
16:57:26 <geppetto> +1
16:57:28 <limburgher> Do all relevant macros exit?
16:57:30 <limburgher> exist?
16:57:48 <RemiFedora> %{pecl_docdir} ? yes (even in EPEL-6)
16:58:14 <abadger1999> +1
16:58:49 <RemiFedora> +1 (of course)
16:59:02 <racor> +1
16:59:15 <limburgher> +1 then.
16:59:41 <abadger1999> #info https://fedorahosted.org/fpc/ticket/430 PHP Change for pecl_docdir approved: (+1:5, 0:0, -1:0)
16:59:52 <abadger1999> Alrighty  I have to run out now.
16:59:57 <abadger1999> Thanks for coming everyone!
16:59:59 <abadger1999> #endmeeting