17:14:34 <spot> #startmeeting
17:14:34 <zodbot> Meeting started Wed Dec  2 17:14:34 2009 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:14:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:14:48 <spot> #topic Fedora Packaging Committee Meeting
17:15:20 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires
17:15:29 <spot> okay, that's item #1 for today
17:15:48 <spot> seems pretty much common sense to me.
17:15:52 <Rathann> that's pretty straightforward, +1
17:15:55 <spot> +1
17:15:59 <limburgher> +1
17:16:02 <tibbs|h> +1
17:16:13 <tibbs|h> Though, is there actually a page for EPEL-specific guidelines?
17:16:19 <spot> tibbs|h: yes, its empty am
17:16:22 <spot> atm, rather
17:16:25 <spot> but I did create it
17:16:41 <tibbs|h> Who is actually responsible for managing it?
17:16:47 <abadger1999> +1
17:16:50 <tibbs|h> Us or the EPEL folks?
17:17:20 <limburgher> I'd think us, since it's a Fedora subproject, no?
17:17:39 <spot> i think it probably should be in the Packaging namespace unless there is some good reason to not have it there
17:17:57 <spot> Packaging/EPEL seems like a logical place
17:18:23 <spot> (and i thought I had made a placeholder there, but it looks like i was wrong)
17:18:26 * abadger1999 doesn't care -- do the EPEL people care?
17:18:30 <spot> racor: if you want to vote on this, you can.
17:18:47 <tibbs|h> I'd think that ultimately it wouldn't be our decision, but nobody is likely to complain if we maintain Packaging/EPEL.
17:19:38 <tibbs|h> So we're probably better off just doing it now.
17:19:41 <spot> #agreed PkgconfigAutoRequires passes, 5 +1 votes, goes to FESCo for ratification.
17:19:50 <racor> +1 (sorry, got distracted for a couple of minutes)
17:20:15 <spot> okay, next item
17:20:19 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised
17:20:57 <rdieter> hi, just noticed the meeting going.
17:21:02 <tibbs|h> These don't seem to have changed since I was +1 on the list.
17:21:17 <spot> rdieter: no worries, we're not at the proper time because i'm slow. :)
17:22:13 <spot> i think this cleanup is pretty nice, +1 from me
17:22:25 <tibbs|h> Still +1.
17:22:35 <racor> +1
17:22:39 <Rathann> +1
17:22:42 <abadger1999> +1
17:22:48 <tibbs|h> Note that this will probably require an entry on the EPEL page since these guidelines simply will not work for EPEL.
17:22:52 <rdieter> +1
17:23:21 <limburgher> +1
17:23:24 <spot> tibbs|h: good point, i'll be sure to note that
17:23:38 <limburgher> It does say FC-12+, but a note would still be good.
17:23:48 <tibbs|h> I'm pretty sure the old guidelines did work.
17:23:59 <tibbs|h> Theoretically F11 could get an emacs update that would provide the macros.
17:24:30 <spot> #agreed EmacsPackagingRevised passes with +7 (also, note for EPEL)
17:24:58 <spot> #topic https://fedoraproject.org/wiki/User:Varekova/man-pages/missing-man-pages
17:24:59 <tibbs|h> We should probably just save the old guidelines page until F11 goes away, unless it acquires the macros.
17:25:08 <tibbs|h> I'm not sure about this one.
17:25:11 <spot> tibbs|h: yeah, that was my plan
17:25:27 <tibbs|h> Honestly I'm not sure it's up to us; this seems like a policy decision that should come from elsewhere.
17:26:04 <spot> Yeah, i think that this one needs to go through either the board or FESCo
17:26:20 <tibbs|h> Not that I disagree, and debian is a great source for manpages.
17:26:40 <spot> there is nothing in the guidelines which prevents packagers from adding manpages
17:26:46 <rdieter> fesco/policy++
17:26:48 <spot> so, this change isn't necessary.
17:27:01 <abadger1999> Yeah -- there was something about adding manpages if they existed in other distributions... what happened to that?
17:27:08 <Rathann> it's a common sense guideline
17:27:12 <abadger1999> Well... I don't think this is fesco policy.
17:27:17 <Rathann> abadger1999: https://fedoraproject.org/wiki/MAN_pages_which_exists_in_other_places(draft) ?
17:27:19 <abadger1999> It's not prohibiting something.
17:27:24 <abadger1999> Yeah, that's it.
17:27:32 <spot> i'm pretty sure that one didn't pass.
17:27:50 <spot> "This draft conflicts with the general practice that Fedora packagers should be working to send improvements directly to upstream. Anyone who feels motivated to dig in other distributions for patches or improvements should feel free to do so, but it is not something that the FPC felt should be codified into the guidelines. "
17:28:26 <spot> (those were my notes when we rejected the older proposal)
17:28:51 <abadger1999> Excellent.
17:28:54 * SmootherFrOgZ just steps in (forgot we have one today)
17:29:13 <abadger1999> So is there anything that makes this proposal different?
17:29:19 <spot> i don't think so.
17:30:02 <abadger1999> Cool.
17:30:16 <abadger1999> -1
17:30:17 <Rathann> adding a warning to rpmlint might have some merit, though
17:30:39 <spot> Rathann: i'd agree with that
17:30:50 <tibbs|h> Not that we control rpmlint.
17:30:54 <spot> -1 to this proposal, with the same notes as the previous rejection
17:30:57 <abadger1999> And if it doesn't pass, I'll send a message to varocova with the notes from the other draft.
17:31:07 <spot> abadger1999: thanks
17:31:17 <abadger1999> And try to work out a place on the wiki that things like this could live at fudcon.
17:31:21 <Rathann> -1 as well
17:31:28 <limburgher> -1
17:31:32 <tibbs|h> -1
17:32:05 <racor> 0, this proposal is much weaker than the old one, IMO.
17:32:45 <spot> #agreed Missing-man-pages does not pass, 5 -1 votes, one 0 vote, abadger1999 will follow up with varekova about why
17:32:45 <tibbs|h> If someone that decides Fedora policy wants to make manpage coverage a goal, we can add it to the guidelines.
17:33:01 <spot> tibbs|h: that matches up to my feelings as well.
17:33:50 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/Python3
17:33:55 <spot> okay, this one is the fun one. :)
17:34:11 <tibbs|h> That's.... not on the list.
17:34:26 <Rathann> tibbs|h: sure it is
17:34:35 * dmalcolm is here FWIW
17:35:04 <spot> tibbs|h: its on the list in the email i sent out (several times)
17:35:09 <tibbs|h> I don't see it on http://fedoraproject.org/wiki/Packaging:GuidelinesTodo; what did I miss?
17:35:18 <Rathann> tibbs|h: https://www.redhat.com/archives/fedora-packaging/2009-November/msg00099.html
17:35:37 <spot> tibbs|h: you're right, its not there. i scooped up that one from the mailing list
17:35:37 <limburgher> Oh.  God.  I support several Python2.x at work. So. . .yeah.  This might actually help me, down the road.
17:36:13 <tibbs|h> Did FESCo already reverse their outright ban on doing this?
17:36:41 <tibbs|h> Or are we just discussing the guidelines assuming that they will do so?
17:37:01 <spot> tibbs|h: that is a good point.
17:37:18 <tibbs|h> I mean, I voted against the ban when I was on FESCo, but still.
17:37:18 <spot> perhaps we should table this, and wait for FESCo to permit the python duality
17:37:28 <abadger1999> I think they did when they accepted the python3 feature for f13
17:37:39 <tibbs|h> Consistency.  Nice.
17:38:07 * spot believes that consists of a reversal of the ban. :)
17:38:18 <spot> okay, lets go on those grounds unless FESCo tells us otherwise
17:38:26 <spot> they'll have to ratify this, after all
17:38:36 <limburgher> True.
17:38:53 <tibbs|h> Although these guidelines seem to go beyond just python3.
17:39:01 <spot> really, there are two things i think should be pulled out here
17:39:04 <tibbs|h> "There will be multiple python runtimes, one for each supported major/minor release combination."
17:39:32 <Rathann> the (re)naming of python3 modules will be fun, too
17:39:36 <spot> tibbs|h: that could easily be reworded to say something like:
17:39:46 * dmalcolm tried not to specify what the "supported combinations" would be when he wrote that
17:39:57 <abadger1999> <nod>
17:40:03 <spot> "Fedora supports multiple python runtimes, one for each major/minor release combination."
17:40:09 <limburgher> I assumed it would just be python2, python3, and maybe someday a python4, etc, not python26, 27, 31, 32. . .
17:40:26 <tibbs|h> There was an on-list proposal for multiple python2 versions, at least.
17:41:09 <tibbs|h> BTW, if we're going to do this, can we actually fix things so that the arch-independent stuff goes into /usr/share?
17:41:41 <rdieter> tibbs|h: that's a longer-term goal, that abadger1999 is banging on upstream for (iirc)
17:41:49 <abadger1999> actually.
17:42:01 <abadger1999> dmalcolm:  What do you think of what tibbs|h said?
17:42:18 <dmalcolm> (my proposal for multiple python2* runtimes was here (and thoroughly shot down :-() https://www.redhat.com/archives/fedora-packaging/2009-November/msg00063.html )
17:42:31 <abadger1999> use /usr/share/python3.x instead of /usr/lib/python3.x for pythonsitelib
17:42:46 <abadger1999> sitearch would stay in %{_libdir}/python3.x
17:43:29 <dmalcolm> abadger1999: I haven't looked at the feasibility of doing that.  Off the top of my head, sounds doable; file an RFE in bz please
17:43:30 <abadger1999> rdieter, dmalcolm: It should be possible... the argument before was whether it would break third parties that did not use python's distutils to tell where to install packages.
17:43:54 <abadger1999> dmalcolm, tibbs|h: Okay, RFE in bz is the way forward on that.
17:44:01 <racor> abadger1999: Provided you are talking about python3.x would you consider a package prefix python3 (as in the proposal) to be correct?
17:44:04 * abadger1999 will do that.
17:44:37 <abadger1999> racor: So... I've been thinking about that.  I think we should make a general decision across the guidelines.
17:44:46 <abadger1999> What do we value more:
17:44:59 <Rathann> as for building multiple python modules from one specfile or from separate ones, I guess it should depend on whether upstream supports both python major versions in their tarball or has a separate tarball for py3
17:45:06 <abadger1999> organization/namespacing: python3-foo, php-foo, perl-foo
17:45:35 <abadger1999> or ease of filing bugzilla's: if the subpackage starts with the srpm package name, it's easier to find the proper component.
17:45:46 <abadger1999> ?
17:45:52 <spot> I think the common vs split approaches need to be fleshed out some more, specifically, it seems to me like there are situations in which both are plausible.
17:46:11 <tibbs|h> I think we've already lost the "ease of filing bugs" battle, if we were even trying to fight it.
17:46:19 <spot> I would like to see that section reworked to include explanations of when to use each scenario, and how to use it
17:46:52 <racor> abadger1999: Yep. python3 would imply a python3 release series in parallel to a python2 series, i.e. not python3.1, 3.2, .. 3.n
17:46:53 <abadger1999> dmalcolm: Layout needs changes.  Programs will install to private locations like %{_datadir}/yum ... I think those are valid locations.
17:47:39 <abadger1999> racor: Ah, that's a very good point.
17:47:51 <spot> my concern about the proposed namespacing is that it will also hinder some searches
17:48:05 <spot> if i'm looking for the python3 pygtk, i will probably search on "pygyk"
17:48:37 <dmalcolm> abadger1999: a concrete example I ran into: python-coverage installs a /usr/bin/coverage script; for python3-coverage I renamed it to /usr/bin/coverage3
17:48:47 <Rathann> well if not in package name, then it should at least be in Provides:
17:49:04 <spot> but, there is some value in having a unified namespace, i suppose.
17:49:40 <spot> I'd say that the upstream name should be preserved though,
17:49:47 <Rathann> does python3-pygtk look bad?
17:49:53 <dmalcolm> (another possibility is "python3-pygtk2" i.e. use python2 rpm name)
17:50:02 <spot> so python3-gnome-python (even though that is repetitive-kindof-repetitive)
17:51:15 <racor> Rathann: No, but python3-gstreamer contradicts the "subpackage/language-binding" guidelines (<package>-<binding>)
17:52:02 <abadger1999> Rathann: I have some notes of drawbacks to single srpm for python2 and python3 here: https://bugzilla.redhat.com/show_bug.cgi?id=531895
17:52:04 <bugbot_> Bug 531895: medium, low, ---, a.badger, NEW, RFC: Support for both python 2 and python 3 from one srpm build
17:52:14 * abadger1999 should copy that info back into the guideline draft.
17:52:29 <Rathann> racor: but even current guidelines tell you to use python-foo (with the exception of pyfoo)
17:52:34 <spot> abadger1999: do you and dmalcolm want to take another run at this draft before we approve it?
17:52:42 <spot> (or rather, before we consider it)
17:52:52 <Rathann> ah, unless it's not a python module
17:53:06 <abadger1999> I think a lot of eyes bringing up issues is good right now.
17:53:09 <Rathann> is gst-python a python module or just an interface to run python scripts?
17:53:18 <abadger1999> But it's not going to pass at this point.
17:53:30 <tibbs|h> At least this lets us get rid of the "py anywhere in the name" exception.
17:53:44 * spot notes that we are approaching an hour and we have one more draft to go
17:54:06 * abadger1999 also has a straw poll question he wants to ask.
17:54:15 <racor> Rathann: then the python guidelines already are broken. We are enforcing package-binding almost everywhere else.
17:54:35 <Rathann> racor: what do you mean by binding?
17:54:47 <abadger1999> Okay, so there's a few things to decide -- one srpm per python2+3, two srpms, or a mixture of both?
17:55:17 <abadger1999> Whether naming should go with namespacing (python3-) or stay closed to what we currently have with python2 (at least for subpackages).
17:55:30 <spot> since i think the php changes are less controversial, i propose we table the python3 draft and revisit it next week (which is after FUDCon), with a request that the srpm handling and naming sections be fleshed out and clarified a bit.
17:55:36 <racor> Rathann: gcc-fortran vs. fortran-gcc, mypackage-c++ vs. c++-mypackage (c++ wrapper for mypackage)
17:55:38 <abadger1999> Other things are technical problems that need to be fixed.
17:56:15 <abadger1999> err... I was more ofthe opinion that those two decision need FPC input.
17:56:21 <tibbs|h> From a package review perspective, I really like the possibility of building both variants from one srpm.
17:56:26 <Rathann> racor: gcc-fortran isn't a good example, because it's not a fortran module
17:56:31 <abadger1999> ie: either way will work.  But which do we think is better for Fedora as a whole.
17:56:44 <rdieter> abadger1999: I think the one vs. two srpm should be left up to the maintainers of them (circumstances can dictate one being better than the other)
17:56:50 <Rathann> single srpm is less overhead if it "just works"
17:57:08 <spot> abadger1999: is it feasible that one way will work for all situations? if not, then the two options should be documented, with guidance as to when to choose each.
17:57:09 <racor> Rathann: It's a subpackage of gcc
17:57:23 <abadger1999> Rathann: OTOH, when it doesn't work, end users have to download an update even though it only changed for the other python version.
17:57:37 <Rathann> racor: exactly, but the current guidelines speak only of python modules
17:57:46 <Rathann> abadger1999: true
17:57:56 * dmalcolm notes that some upstreams are trying to support both 2 and 3 from one tarball, others from separate tarballs, and that should guide the choice
17:58:19 <abadger1999> spot: I think that either two srpms or either 2 or 1 at maintainers discretion (with guidance) works.
17:58:22 <tibbs|h> Yes, certainly; if it's a different upstream project then it shouldn't really be in the same srpm.
17:58:23 * dmalcolm also notes that he's just lurking in this meeting
17:58:29 <abadger1999> Always a single srpm will not.
17:58:42 <Rathann> abadger1999: +1
17:58:49 <racor> python is a language, fortran is a language
17:58:50 <limburgher> abadger1999 +1
17:59:16 <spot> abadger1999: so, i think that we should rework the guideline text to reflect that.
17:59:26 <abadger1999> spot: Which one do we want, though?
17:59:41 <abadger1999> Always two srpms or maintainers discretion?
17:59:45 <Rathann> racor: yes, but gcc-fortran is not a fortran module
17:59:51 <limburgher> maint. desc.
17:59:55 <Rathann> (why do I have to repeat that?)
18:00:18 * spot is inclined to say maintainers discretion
18:00:22 <racor> Rathann: Because you are missing the point
18:00:34 <Rathann> apparently
18:00:52 <spot> perhaps, with the exception of situations where the python2 & python3 bindings are in the same tarball
18:01:08 <spot> or rather, only in the same tarball
18:01:22 <rdieter> that would be an easy choice then, one tarball => one srpm
18:01:35 <abadger1999> maintainers discretion means extra work for someone who only cares about python2 or python3; harder to figure out what needs to be cvs co'ed; end users must download anew module even if it only affected python3.
18:02:14 <rdieter> let's worry less about the extra download... stuff, that's a much smaller issue, imo.
18:02:32 <abadger1999> But less work for maintainers and reviewers that do want to support both python2 and 3.
18:02:46 <spot> if i were writing that section, i would probably say that if the python 2 and 3 bindings exist only in the same tarball, they should be generated from a single SRPM. If the python 3 bindings are part of a separate upstream source package, they should be in their own SRPM.
18:03:23 <rdieter> common sense for the win
18:03:37 <SmootherFrOgZ> abadger1999: we can add a fake-module in cvs side but will require more cvsadmin work
18:04:02 <limburgher> Also, single-srpm will ease the transition when python2 is retired.
18:04:30 <abadger1999> that's what we'll go with then.
18:04:32 <abadger1999> naming?
18:05:56 <abadger1999> or were all tired of this and will think about it next time :-)
18:06:01 <abadger1999> *we're
18:06:06 <Rathann> I think we should mirror current python module naming guidelines (i.e. python3-<upstream module name>)
18:06:13 <spot> my inclination on naming is that the prefix should be python3, the "py" exception to prefixing should die, and we should honor upstream names.
18:06:36 <Rathann> as for applications... should we ship just one build against latest python?
18:06:53 <Rathann> or do we allow two builds of the same app for both python stacks?
18:07:05 <spot> Rathann: that is a good question, the draft doesn't really cover that
18:07:26 <abadger1999> Rathann: I think dmalcolm and I were both envisioning ship one version
18:07:45 <limburgher> abadger1999: So was I.
18:07:57 <dmalcolm> my thought was: port applications one at a time from 2 to 3, and only ship one
18:08:34 <limburgher> dmalcom: Right, use the dual stack to facilitate the transition.
18:08:50 <Rathann> I'm leaning in the same direction
18:09:48 <dmalcolm> (though e.g. if gedit wants to support both (iirc it can embed a python runtime), it may have to fix things to build two plugins, one against 2, one against 3; you wouldn't be able to run both at once within one process)
18:10:23 <Rathann> hm yeah
18:10:32 <Rathann> Conflicts: ?
18:11:27 <abadger1999> Ugh.  I think we're just going to have to devote developer resources to porting things at some point.
18:11:29 * dmalcolm feels that that's a long-term thing; in the short-term if we're going to have python 3 it needs to be fully independent of python 2, and adding "Conflicts" goes against that
18:11:30 <tibbs|h> I suspect common sense will work out most of these issues.
18:11:36 <abadger1999> ie: allgedit plugins go to python3 in F14
18:11:49 <abadger1999> All web appsusing mod_wsgi go to python3 in F20, etc.
18:12:06 <spot> is there any opposition to tabling this for now and moving on to the last item?
18:12:19 <abadger1999> +1 table
18:12:21 <Rathann> not at all, this needs a bit of work still :)
18:12:27 <abadger1999> Lots of stuff for us to work on on the fudbus.
18:12:48 <spot> okay.
18:12:51 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/PHP
18:12:51 <dmalcolm> abadger1999: I'll be happy to work through the log of this meeting with you on the fudbus
18:12:57 <spot> this is the last item on the agenda
18:13:06 <abadger1999> dmalcolm: Excellent.  SOunds like a good p0an
18:13:17 <tibbs|h> I'm afraid I don't fully understand the "-" vs "_" issue.
18:13:19 * abadger1999 has a straw poll too
18:13:19 * RemiFedora here is any question
18:13:45 <spot> tibbs|h: that issue is really not relevant.
18:13:54 <RemiFedora> tibbs|h, - vs _ is no more in the draft
18:14:00 <spot> i explained how that works on the list, i don't think there is any guideline change necessary
18:14:16 <Rathann> There is no way of checking the ABI with packages for Fedora EPEL 5. <- I'm confused about this line
18:14:48 <Rathann> should it be "... checking the Zend ABI ..." instead?
18:14:52 <spot> Rathann: pretty sure that means that the PHP in EPEL 5 is too old to support the API scrape from php -i
18:15:12 <abadger1999> Rathann: I think that means that the ABI checking code needs to be conditionalized out on EL-5.
18:15:21 <RemiFedora> yes
18:15:24 <Rathann> ahh
18:15:27 <Rathann> ok I get it
18:15:58 <spot> So, it all looks good to me otherwise, +1
18:16:08 <abadger1999> +1
18:16:17 <Rathann> yup - some of it is EPEL-only though
18:16:20 <Rathann> +1
18:16:51 <SmootherFrOgZ> +1
18:16:52 <rdieter> +1
18:16:54 <limburgher> +1
18:17:07 <tibbs|h> +1 for the changes, but I guess we should split the EPEL stuff out to the EPEL pages now that they exist.
18:17:20 <spot> tibbs|h: i'll do that when i do the writeup
18:17:22 <limburgher> tibbs|h: +1
18:17:27 <spot> tibbs|h: i was going to do some of that at FUDCon anyways
18:17:56 <spot> #agreed PHP changes pass with 7 +1
18:18:04 <abadger1999> Okay, my straw poll: Do we want to make the policy around when to use alternatives stronger? Right now it only recommends that alternatives is meant for non-end user applications that are commandline compatible.  Do we want to make that a prohibition against using it for end-user apps?
18:18:07 <spot> #topic abadger1999's straw poll
18:18:49 <abadger1999> The package in question is jack2 which is commandine compatible with the present jack but is an enduser app.
18:19:06 <abadger1999> https://bugzilla.redhat.com/show_bug.cgi?id=542288
18:19:07 <bugbot_> Bug 542288: medium, low, ---, andy.shevchenko, NEW, Alternatizing JACK
18:19:16 <tibbs|h> Do we have an alternative?
18:19:22 <abadger1999> environment-modules
18:19:30 <abadger1999> Conflicts
18:19:45 <tibbs|h> I know about environment modules, but until they're actually enshrined in guidelines I don't think we can just tell people to use them.
18:19:54 <tibbs|h> Alternatives should always beat Conflicts.
18:19:57 <abadger1999> We have the guidelines now.
18:20:04 <abadger1999> they just haven't been moved.
18:20:28 <abadger1999> http://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules
18:20:49 <tibbs|h> At least I know why that isn't fresh in my memory.
18:22:07 * abadger1999 notes that there's a bunch of stuff that's approved but hasn't gotten all the way to announced... I did clean up the writeup stage a while back but it's grown again.
18:22:25 <tibbs|h> Honestly I'm not sufficiently familiar with environment modules to know if they're actually a reasonable solution for the jack issue.
18:22:38 <tibbs|h> We should get the relevant people in contact so that can be determined.
18:22:51 <abadger1999> The other solution is -- don't ship both using the same name.
18:23:07 <tibbs|h> Well, you can't do that either way.
18:23:12 <abadger1999> ie: don't use alternatives to switch between the two versions of jack.
18:23:38 <spot> abadger1999: that's on my FUDCon todo list
18:23:44 <tibbs|h> environment modules don't actually seem all that useful.
18:23:47 <spot> (the announce and writeups)
18:23:55 <abadger1999> Just put them on the fs under jack and jack2 and make people choose. (where, in this case, it might mean the package source code has to be changed).
18:24:10 <abadger1999> (package == application using jack)
18:24:14 <tibbs|h> You have to stick things in subdirectories so that path appending will work.  I guess that's the only cross-shell way that it could work.
18:24:36 <abadger1999> <nod>
18:24:56 <abadger1999> And jack has libraries ... which means LD_LIBRARY_PATH as well.
18:25:11 <tibbs|h> At least that's already supported.
18:25:31 <tibbs|h> I guess the relevant folks should talk and determine whether environment modules is a reasonable solution.
18:25:44 <Rathann> are the libraries API and ABI-compatible?
18:26:44 <tibbs|h> Better asked of the jack folks, I guess.
18:26:52 <abadger1999> According to fernando and oget, yes.  the jack2 service does not provide all the same features as jack1 but they are compatible.
18:28:00 <tibbs|h> I have two minor points to make if we're done.
18:28:46 <abadger1999> So -- no opinions on whether alternatives is okay?
18:28:59 <tibbs|h> I think it's better than Conflicts, certainly.
18:29:07 <tibbs|h> I think a per-user thing is better if it works.
18:29:18 <Rathann> if per-user then env-mods
18:29:25 <Rathann> alternatives are system-wide
18:30:21 <abadger1999> k  I'll write a stronger guideline on alternatives for next time.
18:30:50 <rdieter> abadger1999: shrug, I'd tend to -1 the staw poll, maintainers should know best.  If someone knows the pain alternatives bring, and still want to do it... then so be it (I guess)
18:31:12 <rdieter> otoh, use of alternatives perhaps should require a bit of justification
18:31:33 <rdieter> how's that for an official waffle?
18:31:56 <abadger1999> hehe, were you minister of opensource for the clinton admin?
18:32:02 <abadger1999> tibbs|h: You're up.
18:32:13 <tibbs|h> We will probably need to look over the rpm 4.8 changes and make sure there are no issues we need to address via guidelines.
18:32:18 <spot> #topic tibbs|h two minor points
18:32:59 <tibbs|h> Second point: rpmlint will seemingly forever complain about lack of buildroot, and I wonder if that bothers anyone else.
18:33:28 <abadger1999> Yeah, bothers me.
18:33:37 <spot> tibbs|h: that probably deserves a bugzilla
18:33:39 <rdieter> why is that? rpmlint folks refused to squelch it ?
18:33:52 <tibbs|h> Loads of bugs open on it; mine (with patch) is https://bugzilla.redhat.com/show_bug.cgi?id=537430
18:33:53 <abadger1999> Although... we did decide we needed to document the things that people can usually ignore in rpmlint at one time years ago...
18:33:54 <bugbot_> Bug 537430: low, low, ---, ville.skytta, CLOSED WONTFIX, no-buildroot-tag and no-cleaning-of-buildroot are no longer issues
18:34:07 <tibbs|h> rpmlint maintainer indicates that it will not be fixed.
18:34:15 <abadger1999> rdieter: It's still needed for EPEL was Ville's reasoning.
18:34:29 <rdieter> so, keep it for epel then.
18:34:39 <tibbs|h> Lots of things are still needed for EPEL and will be for, what, another five years at least?
18:35:51 <tibbs|h> I would hate to think that we'll just accumulate rpmlint complaints that should just be completely ignored.
18:35:59 <rdieter> rpmlint on fedora really should be following fedora's current support/guidelines
18:36:02 <tibbs|h> At some point it diminishes the utility of the tool.
18:36:08 <rdieter> tibbs|h: +1
18:36:13 * spot agrees
18:36:18 <racor> tibbs|h: +1
18:36:44 <limburgher> Yes.  Maybe have different versions for each release?
18:36:59 <tibbs|h> I wonder if FPC should consider making an official request (assuming we think that we can even do that).
18:37:29 <tibbs|h> I wouldn't want to assume to tell any package maintainer what to do, of course.
18:37:29 <rdieter> limburgher: ie, fork the package, but that's the maintainers call (unless someone else is willing/offering to do the work)
18:37:32 <limburgher> Sure we can.  ;)  Nothing like a good power grab.
18:37:36 <racor> or rpmlint be equipped with a --distro=... option to switch between rule sets?
18:37:57 <abadger1999> racor: +1 ... we'd need to code it though.
18:37:58 <limburgher> rdieter: Not really a fork, per se.  We already do this for practically everything.
18:38:06 <tibbs|h> racor: That's a reasonable point.  Probably not much python to write.
18:38:07 <abadger1999> The distro switch could just switch between config files.
18:38:19 <limburgher> racor: Defaulting to the running distro.  I like that.
18:38:27 * spot also likes that idea
18:38:33 <tibbs|h> But someone could spend the effort and still have it rejected by the maintainer.
18:39:02 <SmootherFrOgZ> tibbs|h: ha :). but we tried
18:39:46 <rdieter> tibbs|h: I'd agree a formal request of some sort should be made, on the committee's behalf.  I don't see anyone here disagreeing with 537430
18:40:04 <tibbs|h> There are also another half-dozen bugs open on the same thing.
18:40:27 <tibbs|h> I'll do some triage, reopen the bug and ask if a patch for --distro= would be acceptable.
18:40:46 <rdieter> I suppose that means someone being tasked as arbitrator/representative.
18:41:13 <abadger1999> thanks tibbs|h.
18:41:45 <tibbs|h> Well, I opened the bug; I'm happy to at least propose it.  Coding it shouldn't be beyond my abilities but I haven't actually looked at the rpmlint code.
18:41:48 <spot> yes, thanks tibbs|h
18:41:52 <racor> sorry boys, I've got to leave, bye.
18:42:02 <spot> racor: thanks for staying late
18:42:07 <tibbs|h> I believe we're done anyway.
18:42:15 <spot> i think so too
18:42:22 <spot> any other last minute items before we close out?
18:42:55 <limburgher> Nope.
18:44:14 <spot> okay, thanks everyone
18:44:17 <spot> #endmeeting