Meeting summary/minutes from 2011-01-03

Mon Jan 3 21:37:14 UTC 2011

==================================
#fedora-meeting: EPEL (2011-01-03)
==================================

Meeting started by nirik at 20:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-01-03/epel.2011-01-03-20.30.log.html

Meeting summary
---------------
* init process/agenda  (nirik, 20:30:02)

* EPEL provenpackagers  (nirik, 20:35:41)
  * will discuss ideas on the list and revisit.  (nirik, 20:56:39)

* What can be in EPEL6?  (nirik, 20:56:50)
  * AGREED: "EPEL6 will not ship any packages that have src.rpms on
    public mirrors under 6* directories with the following exception: If
    the binary rpm is only shipped in some arches in RHEL, EPEL may ship
    a package as close as possible to the RHEL version with a leading
    package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL
    maintainer must keep up exactly with the RHEL src.rpm where
    possible).  (nirik, 21:08:14)

* Broken EPEL6 deps  (nirik, 21:08:26)
  * AGREED: please fix your broken deps or untag until you can.  (nirik,
    21:14:54)

* EPEL6 moving out of beta 2011-01-11  (nirik, 21:15:05)
  * folks would still like more time, so 2011-01-11 doesn't seem likely
    at this point.  (nirik, 21:28:05)
  * nirik will try and mail out a list of packages and versions in epel6
    now with maintainer  (nirik, 21:29:28)

* Open floor  (nirik, 21:31:24)

Meeting ended at 21:35:23 UTC.

Action Items
------------

Action Items, by person
-----------------------
* **UNASSIGNED**
  * (none)

People Present (lines said)
---------------------------
* nirik (113)
* dgilmore (59)
* stahnma (39)
* sgallagh (25)
* abadger1999 (21)
* rsc (21)
* Jeff_S (4)
* zodbot (3)
* smooge (2)
* hicham (1)
--
20:30:01 <nirik> #startmeeting EPEL (2011-01-03)
20:30:01 <zodbot> Meeting started Mon Jan  3 20:30:01 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:30:02 <nirik> #meetingname epel
20:30:02 <zodbot> The meeting name has been set to 'epel'
20:30:02 <nirik> #topic init process/agenda
20:30:40 <nirik> smooge / abadger1999 / dgilmore / stahnma / tremble / rsc (any others interested in epel meeting)
20:31:12 * dgilmore is here
20:31:17 * rsc is also around
20:31:34 <nirik> anayone have agenda items?
20:31:37 * stahnma is here
20:31:43 * sgallagh lurks, as usual
20:31:49 <nirik> * EPEL6 moving out of beta 2011-01-11
20:32:02 <nirik> * What can be in EPEL6
20:32:12 <nirik> any other agenda items?
20:32:21 <stahnma> Dealing with broken deps in epel6
20:32:44 <sgallagh> I've suggested it before, but can we get a separate provenpackager status for EPEL?
20:33:02 <sgallagh> (Separate from Fedora, I mean)
20:33:07 <dgilmore> sgallagh: why?
20:33:17 <smooge> sorry late for everything today
20:33:18 <rsc> sgallagh: sounds interesting, but why?
20:33:20 <dgilmore> Id think anyone trusted for one woul d be trusted for the other
20:33:46 <sgallagh> dgilmore: Not necessarily. EPEL is supposed to be much stricter about updates, for example
20:34:08 <dgilmore> sgallagh: prvovenpackager has nothing to do with that
20:34:09 <smooge> supposed to be
20:34:19 <rsc> nirik: will CentOS 6 be ready till 2011-01-11?
20:34:24 <nirik> rsc: no idea.
20:34:28 <stahnma> I would be in favor of that
20:34:29 <sgallagh> Also, I for one would not want that responsibility in Fedora, but I'd be okay with it in EPEL (since it's a slower-pace)
20:34:40 <nirik> ok, so I have:
20:34:41 * abadger1999 here
20:34:42 <dgilmore> sgallagh: implementing a second provenpackager status greatly complicates the git acls also
20:34:59 <nirik> EPEL provenpackager
20:34:59 <nirik> What can be in EPEL6
20:34:59 <nirik> Broken EPEL6 deps
20:34:59 <nirik> EPEL6 moving out of beta 2011-01-11
20:35:12 <nirik> any other topics/agenda items before we start/
20:35:13 <nirik> ?
20:35:23 <dgilmore> nirik: not that i can think of
20:35:29 <stahnma> sounds reasonable for today
20:35:41 <nirik> #topic EPEL provenpackagers
20:35:59 <nirik> so yeah, this could make things complex with the acls...
20:36:15 <dgilmore> the acl file is already massive
20:36:26 <dgilmore> this would add greatly to it
20:36:56 <rsc> I think a provenpackager is a knowledged packager, so ï¿½ckager as previously called. A provenpackager should be aware how to handle EPEL. Otherwise he shouldn't be a provenpackager
20:37:00 <dgilmore> since im assuming fedora provenpackager means your not an epel provenpackager
20:37:01 <nirik> I think also when asking to be a provenpackager, noting that you want to use your powers for epel might sway votes.
20:37:03 <dgilmore> and vice versa
20:37:07 <stahnma> maybe we should discuss the process behind the idea rather than the implementation specifics first
20:37:27 <nirik> I know that tremble was granted provenpackager after working on stuff in epel.
20:37:32 <stahnma> I also was
20:37:35 <dgilmore> rsc: i agree with you
20:38:05 <rsc> and if somebody heavily violates, he should be removed from provenpackager simply.
20:38:06 * dgilmore wants to know what we gain by having it seperate?
20:38:28 <sgallagh> dgilmore: Well, my main concern is this: those working on EPEL are a very small subset of the general Fedora community
20:39:00 <dgilmore> sgallagh: being small doesnt mean much
20:39:02 <sgallagh> Especially during beta periods, there are a lot of broken dependency issues that can be solved with more provenpackager access
20:39:21 <sgallagh> Rather than the time-consuming process of acquiring comaintainership on every package
20:39:29 <dgilmore> sgallagh: sure
20:39:30 <hicham> because not all community members have access to it
20:39:31 <nirik> perhaps we should look at having a policy that allows us to add people as comaintainers more easily.
20:39:38 <stahnma> I spend 90% of my time in EPEL. Me having rights to mess with Fedora might not be the best idea, but I chose not to mess with Fedora packages for the most part
20:39:53 <sgallagh> So I think it should be easier to get provenpackager status on EPEL but not necessarily grant that same power over Fedora as a whole
20:39:57 <dgilmore> but i dont see anyof this precluding having general provenpackager access
20:40:54 <dgilmore> sgallagh: easier access and 20:33 < sgallagh> dgilmore: Not necessarily. EPEL is supposed to be much stricter about updates, for example
20:40:59 <dgilmore> contradict
20:41:12 <stahnma> I can sgallagh's point.  Many people don't fix issues with things in EPEL.
20:41:15 <sgallagh> Yes, I know it's a contradiction
20:41:17 <dgilmore> there is no reason that because you have provenpackager access you have to do anything in fedora
20:41:20 <stahnma> If a few more people had access to fix them, it would help overall
20:41:32 <stahnma> regardless of if they have it in Fedora proper or not
20:41:45 <sgallagh> I'm trying to put my thoughts into words, and my thoughts are still on holiday :)
20:42:03 <dgilmore> sgallagh: :) i get what your saying
20:42:13 <dgilmore> i just dont know that it gets us anything
20:42:15 <sgallagh> dgilmore: If we have two separate sets of standards for how a provenpackager is supposed to behave, shouldn't they be two separate groups?
20:42:38 <nirik> one problem is that if provenpackages wander around and just fix deps, we don't realize that we have packages that are not being maintained.
20:42:44 <dgilmore> sgallagh: why dont we have seperate epel-packager then
20:42:52 <nirik> so, getting co-maintainers is much better than provenpackagers usually.
20:42:57 <nirik> IMHO
20:42:57 <dgilmore> we expect packagers to behave differently in epel to fedora
20:43:24 <dgilmore> nirik: right thats the other side of the coin
20:43:30 <sgallagh> nirik: That's a good point. But as I mentioned, our comaintainership process is pretty tricky to navigate
20:43:44 <sgallagh> If the primary maintainer is non-responsive, that process is very slow
20:43:49 <rsc> if we start with epel-packager vs. fedora-packager, we need epel-packager-sponsor vs. fedora-packager-sponsor... ;-)
20:43:54 <nirik> yeah. So, perhaps we could make it easier in epel.
20:44:12 <rsc> nirik: you're thinking about shortening AWOL in EPEL?
20:44:24 <nirik> I'd love to see most/all/more packages with co-maintainers in epel.
20:44:51 <nirik> well, shortening what it takes to add someone as a co-maintainer.
20:45:37 <nirik> I'm not sure I have a concrete thing to vote on now, just a thought.
20:46:30 <dgilmore> nirik: perhaps we could have something autoapprove co-maintainer requests after 3-5 days if the maintainer hasnt acted on it
20:46:44 <sgallagh> nirik: Might I propose that we change co-maintainership from an approval process to an auto-grant process (where the primary owner can revoke it if necessary)?
20:46:53 <sgallagh> dgilmore: You read my mind :)
20:47:07 <nirik> or have a process for requesting them/discussing at meetings?
20:47:23 <rsc> no auto-grant, but some delay before auto-grant if primary is not opting out
20:47:44 <rsc> I dislike auto-grant because we also have people that simply add themself as comaintainers without having a clue about the package :(
20:47:54 <dgilmore> nirik: id rather not have discussions on each and everyone
20:47:57 <nirik> I'd be a bit afraid of going to fast... you might get someone who is overeager, gets commit, and pushes a incompatible update before the maintainer can see them and ask them not to.
20:48:03 <dgilmore> only have discussions in the case of conflict
20:48:19 <rsc> nirik: I agree with you
20:48:33 <sgallagh> nirik: Well, we still have a minimum time in epel-testing in effect
20:48:33 <nirik> so, it's all a balancing act.
20:48:39 <nirik> true.
20:48:39 <sgallagh> That should catch most issues like that
20:48:40 <rsc> maintainer and co-maintainer should work hand in hand...
20:49:26 <nirik> agreed.
20:49:37 <dgilmore> cd
20:49:54 <nirik> So, not sure what we can do here. Does anyone feel strongly on any of the proposed ideas? Or perhaps we discuss on list and revisit?
20:50:34 <sgallagh> I'd back dgilmore's auto-approval proposal if it came to a vote
20:51:05 * dgilmore is not sure what it would take to implement
20:51:08 <nirik> that would likely require changes to pkgdb... not sure how feasable that would be
20:51:10 <nirik> abadger1999: ?
20:51:29 * abadger1999 figures out the parameters of dgilmore's proposal
20:52:00 <dgilmore> abadger1999: have somthing go though and auto approve comaintainer requests after 3-5 days
20:52:00 <abadger1999> Okay so it wouldn't be a major overhaul of the system but it would take work
20:52:17 <dgilmore> i guess it could be scripted as a cron job
20:52:26 <abadger1999> I think the parts are: store in the pkgdb when an acl is changed to request comaint.
20:52:31 <dgilmore> it would depend on pkgdb exposing when the request was made
20:53:10 <abadger1999> Write a cron job/scheduled task that scans forr acls with status "Awaiting" that are more than X days old
20:53:20 <abadger1999> And changes them to Approved.
20:53:45 <abadger1999> Oh -- and make that differ between Fedora EPEL and Fedora... but I think you could do that as part of the cron task
20:53:58 <abadger1999> So... Who likes this enough to write code?
20:54:16 * nirik doesn't feel too strongly on it.
20:54:22 * dgilmore doesnt either
20:54:29 <dgilmore> was just offering it as an option
20:54:34 <abadger1999> I don't see anything that would make me reject the feature... just don't have the time to implement
20:54:40 <dgilmore> anyway its something to ponder
20:54:41 <sgallagh> abadger1999: In what language is pkgdb written?
20:54:45 <stahnma> I think you summed up all of epel
20:54:51 <dgilmore> sgallagh: python
20:54:51 <nirik> Another idea is that we could auto allow co-maintainer on any packages that have not yet been bult for epel6.
20:54:55 <abadger1999> sgallagh: python -- TurboGears1 at the moment
20:55:08 <nirik> ie, if the maintainer didn't build so far, they likely don't care or are missing anyhow.
20:55:30 <stahnma> or are waiting for deps
20:55:36 <stahnma> or versions to be worked out
20:56:14 <nirik> yeah, I suppose so.
20:56:27 <sgallagh> I suggest we take this to the list and stop burning up our meeting time on it. We have other agenda items to look at too.
20:56:29 <nirik> so, lets discuss more on list and revisit next week then?
20:56:39 <nirik> #info will discuss ideas on the list and revisit.
20:56:50 <nirik> #topic What can be in EPEL6?
20:56:58 <nirik> I posted a proposal to the list a while back.
20:57:22 <nirik> Subject: Proposal on what packages can be in EPEL6
20:57:50 <stahnma> nirik: it was quite confusing to me, even with the explanations, but I don't think that's your fault
20:58:02 <nirik> yeah, rhel6 is confusing. ;)
20:58:41 <nirik> so I guess I came down with:
20:59:09 <nirik> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship that exact same version (note that EPEL maintainer must keep up exactly with the RHEL src.rpm).
20:59:25 <nirik> of course there are problems with that too.
20:59:39 <nirik> java being the biggest corner
20:59:40 <dgilmore> nirik: that im ok with
20:59:55 <sgallagh> What about packages with a dep in Workstation vs. Server?
21:00:25 <dgilmore> sgallagh: AFAIK workstation + optional and server+optional should be the same content
21:00:30 <dgilmore> but i could be wrong
21:00:35 <nirik> other problem: what if rhel shipps libfoobar for one arch. So, we add it to epel and build it for all arches, but it needs patches/fixes/different version to work on the other arches?
21:00:37 <sgallagh> I'm pretty sure you're wrong :(
21:01:26 <nirik> sgallagh: well, we had in beta time some packages that were only in workstation-optional or the like that were needed, but as far as I know all of them are in serveral optional now.
21:01:37 <dgilmore> nirik: as long as we keep it older we should be ok
21:01:37 <sgallagh> ah ok
21:01:53 <dgilmore> we can say anything in rhel have to have a release that starts with 0.
21:02:04 <nirik> dgilmore: so, should we always keep such things older?
21:02:14 <dgilmore> nirik: right
21:02:15 <nirik> that seems reasonable to me.
21:02:50 <dgilmore> abadger1999: would the fpc be ok with that ?
21:02:55 <nirik> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a package version of 0. (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible).
21:03:08 <dgilmore> though i guess an epel only packging guideline doesnt need to go though fpc
21:04:10 <abadger1999> dgilmore: fpc let's epel define things beyond the standard guidelines and I think the 0. release would be fine.
21:04:17 <sgallagh> Seems sensible to me
21:04:28 <nirik> anyone have wording changes or other changes to the above?
21:04:45 <rsc> nirik: the working above means -0.*, right?
21:04:46 <abadger1999> Just be sure you word it so that people know that Release: 0.1.snap in RHEL means in EPEL it needs: Release: 0.0.1.snap
21:04:58 <nirik> rsc: yeah.
21:05:17 <rsc> nirik, abadger1999: Please add some examples - especially one like from abadger1999 around the wording
21:05:46 <nirik> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible).
21:05:59 <nirik> rsc: yeah.
21:06:29 <nirik> we may already have packages in that would need to do this.
21:06:45 <nirik> I think tremble had a script to find them.
21:07:13 <nirik> ok, so the above sounds ok?
21:07:18 <stahnma> +1
21:07:24 <rsc> +1
21:08:14 <nirik> #agreed "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible).
21:08:26 <nirik> #topic Broken EPEL6 deps
21:08:34 <nirik> so, we still have a fair number of broken deps.
21:08:42 * dgilmore just fixed up the koji one
21:08:47 <rsc> yeah, heartbeat is missing! ;-)
21:08:52 <nirik> should we look at untagging things that are broken? or let maintainers have more time?
21:08:59 * stahnma has some ruby cleaning/work to do
21:09:03 <nirik> rsc: given the above, I think I can build hb now. ;)
21:09:16 <rsc> nirik: then please give some more time before untagging
21:09:23 <dgilmore> rsc: we dont have the cluster stuff available to the buildroot. dep checker
21:09:38 <nirik> dgilmore: given the above, we could ship it in epel...
21:10:03 <dgilmore> nirik: yeah or we add the channel to the buildroot
21:10:16 <dgilmore> nirik: if the srpms are public we should add the channel
21:10:19 <nirik> but there are no mirrored srpms for it.
21:10:19 <rsc> dgilmore: how about CentOS users?
21:10:21 <nirik> they are not.
21:10:38 <dgilmore> nirik: oh ok well then i guess we can ship it
21:10:40 <nirik> rhel5 had srpms from the various other AP channels.
21:10:46 <nirik> rhel6 doesn't as far as I can see.
21:11:36 <dgilmore> nirik:they might all be dumped in one place
21:11:55 * Jeff_S checks in late for the meeting
21:12:01 <nirik> dgilmore: is there any way we could find out?
21:12:36 <nirik> pacemaker src.rpm is in server-optional, but that might be due to it's -docs and -cts subpackages being shipped there.
21:13:14 <dgilmore> nirik: yeah
21:13:41 <nirik> if they are putting the HA and Cluster and other src.rpms in optional, that will be even more confusing to us. ;)
21:13:58 <nirik> so, give another week, revisit then, urge maintainers to fix things?
21:14:26 <stahnma> maintainers should probably start fixing now
21:14:27 <stahnma> :)
21:14:54 <nirik> #agreed please fix your broken deps or untag until you can.
21:15:05 <nirik> #topic EPEL6 moving out of beta 2011-01-11
21:15:14 <nirik> So, we thought this might be a good date a while back.
21:15:23 <nirik> do we stil? what do we need to do before then?
21:15:31 <nirik> * no broken deps
21:15:39 <nirik> * press release/announcements
21:15:44 <nirik> * add to bodhi
21:15:45 <stahnma> more packages
21:16:21 <stahnma> we're short on lots of stuff from what I can tell.  Perl/ruby at least.  I don't use a ton of python or php so I'm not sure on that
21:16:52 <stahnma> and many of us still lack a test area to ensure packages are working properly
21:17:02 <nirik> yeah.
21:17:23 <stahnma> the number one complaint I get about epel5 is lack of packages
21:17:25 <rsc> all my packages except three or so are in EPEL 6... :)
21:17:28 <stahnma> and 6 has less than 5 currently
21:18:09 <nirik> well, we need maintainers willing to step up to maintain. ;)
21:18:25 <stahnma> yes we do
21:18:39 <stahnma> it's a never ending battle for me
21:18:56 <Jeff_S> centos release of 6 should help a lot for getting more 6 packagers
21:19:03 <nirik> yeah, it could...
21:19:20 <stahnma> it doesn't help with new packages coming into Fedora and the maintainer not branching for epel
21:19:27 <nirik> does everyone still want to target 2011-01-11?
21:19:28 <Jeff_S> :(
21:19:32 <stahnma> or asking if anybody would be willing to do an epel branch
21:19:45 <stahnma> I run into that a bunch
21:19:52 <rsc> nirik: I'm also happy if we delay a bit, because CentOS 6 is also not there so far...
21:20:11 <stahnma> I too would rather wait for CentOS
21:20:45 <rsc> nirik: to be honest...all my package builds for EPEL 6 are assumed to work...not more. I don't have RHEL 6...
21:20:55 <Jeff_S> same here
21:20:59 <nirik> well, I have been using rhel6b2 to test...
21:21:19 * abadger1999 is okay with epel6 being small... We can build it up as we go along
21:21:31 <abadger1999> I'd rather be short packages than to have obsolete packages
21:21:38 <abadger1999> when we first release
21:21:51 <nirik> yeah.
21:22:41 <stahnma> either way it hurts the epel brand.  If we don't have many packages or if we're late
21:22:44 <nirik> so do people have big changes they are still waiting to land until centos?
21:22:56 <stahnma> nirik: I have much ruby sorting to do.
21:23:04 <stahnma> about 100 packages
21:23:23 <nirik> and those are things that would change if you had a centos?
21:23:32 <stahnma> I could test some of it a little more
21:23:57 <stahnma> we're also waiting for rails3 to hit rawhide, in some respects.  I just don't think I have the man-power/time to maintain two whole stacks of ruby stuff
21:23:58 <nirik> as a reminder, going out of beta doesn't mean everything stops... it just means we go to our normal 2 weeks of testing, buildroot overrides, etc.
21:24:16 <nirik> sure, but you can land that when it happens right?
21:24:28 <stahnma> yeah but until then most of the ruby stack will be absent
21:24:46 <stahnma> or will have incompatible upgrades
21:25:02 <nirik> right, but if we wait for everything we would never go out of beta.
21:25:04 * abadger1999 has TG-1.1.1 so not too bad.
21:25:21 <abadger1999> What I'd really love is a listing of all the packages that I nominally own that are in EPEL-6 right now.
21:25:48 <nirik> and their versions?
21:25:48 <abadger1999> Then I could check those and see if there's any I think need to get an incompatible update before the deadline.
21:25:52 <abadger1999> yeah.
21:26:07 <nirik> yeah, such a report would be great. ;)
21:26:49 <nirik> so, sounds like people are weak on 2011-01-11 now...
21:27:02 <nirik> would anyone be willing to do such a report and mail it to the list?
21:27:44 * nirik listens to the chirping. ;)
21:28:05 <nirik> #info folks would still like more time, so 2011-01-11 doesn't seem likely at this point.
21:28:09 <stahnma> I'd volunteer, but then not get it done and be a disappointment to myself and everybody around me
21:28:28 <stahnma> can we get epel interns?
21:28:33 <nirik> I guess I could try and whip up something.
21:29:12 <dgilmore> nirik: ill be flying to australia on jan 11
21:29:28 <nirik> #info nirik will try and mail out a list of packages and versions in epel6 now with maintainer
21:29:47 <nirik> dgilmore: cool. How long will you be out there?
21:29:55 <dgilmore> nirik: jan 28
21:30:01 <dgilmore> coming back for fudcon
21:30:11 <dgilmore> its all work
21:30:22 <dgilmore> ill be working from the brisbane office while there
21:30:32 <dgilmore> except for when lca is on
21:30:59 <abadger1999> nirik: I'll try and whip up something but If I can't finish it I'll hand what I have done off to you tomorrow.
21:31:12 <nirik> dgilmore: ok.
21:31:12 <rsc> stahnma: isn't Ruby on Rails dead? :)
21:31:13 <abadger1999> So i'm not a bottleneck
21:31:16 <nirik> abadger1999: ok.
21:31:24 <nirik> #topic Open floor
21:31:30 <nirik> anyone have open floor items?
21:32:04 <nirik> ah bummer. I was thinking I might be able to just use koji tag history, but a bunch of epel6 stuff was tagged in by nobody when it was setup in koji. Oh well.
21:32:57 <dgilmore> nirik: everything in epel-6 was built in koji
21:33:04 <dgilmore> and tagged at build
21:33:20 <nirik> dgilmore: why are some things showing as tagged in by nobody?
21:33:28 <stahnma> rsc: ?
21:33:35 <nirik> anyhow, we can continue this over on #epel...
21:33:40 <nirik> anything else before we close out the meeting?
21:35:12 <nirik> thanks for coming everyone.
21:35:13 * dgilmore has nothing
21:35:23 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20110103/eb139ab4/attachment.sig>