From fedora at leemhuis.info Wed Aug 1 04:40:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 01 Aug 2007 06:40:52 +0200 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <1185913180.3521.158.camel@erato.phig.org> References: <1185913180.3521.158.camel@erato.phig.org> Message-ID: <46B00ED4.7040803@leemhuis.info> On 31.07.2007 22:19, Karsten Wade wrote: > Is this inaccurate/old? > > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e It's IMHO accurate, but they wording maybe could be improved. > If so, what do we want to say instead? "We are doing EPEL4 and if you look for a SRPM to take as base besides looking at the FC-3 branch please also take a look at those from http://centos.karan.org/, as those packages are known to work for EL4 and tested there. " CU thl From sundaram at fedoraproject.org Wed Aug 1 13:50:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Aug 2007 19:20:11 +0530 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <46B00ED4.7040803@leemhuis.info> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> Message-ID: <46B08F93.3000801@fedoraproject.org> Thorsten Leemhuis wrote: > > On 31.07.2007 22:19, Karsten Wade wrote: >> Is this inaccurate/old? >> >> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e > > It's IMHO accurate, but they wording maybe could be improved. > How is it considered accurate when there are hundreds of packages in the EL 4 branch? Rahul From fedora at leemhuis.info Wed Aug 1 14:15:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 01 Aug 2007 16:15:24 +0200 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <46B08F93.3000801@fedoraproject.org> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> <46B08F93.3000801@fedoraproject.org> Message-ID: <46B0957C.5040902@leemhuis.info> On 01.08.2007 15:50, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 31.07.2007 22:19, Karsten Wade wrote: >>> Is this inaccurate/old? >>> >>> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e >> It's IMHO accurate, but they wording maybe could be improved. > How is it considered accurate when there are hundreds of packages in the > EL 4 branch? Seems you read something totally different into it then I do. Anyway, the stuff got borked over time. I added the below to the FAQ and removed the other stuff. === Should I take old or up2date software as a base for EPEL4? === The packages from Fedora Core and Extras 3 are a good staring base for EPEL 4. The packages from Fedora Extras 3 were even rebuild for EL4 already and shipped by and external repo -- consider to look there for additional fixes before building your package for EPEL4. CU thl From fedora at leemhuis.info Wed Aug 1 16:15:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 01 Aug 2007 18:15:46 +0200 Subject: Plan for tomorrows (20070801) EPEL SIG meeting In-Reply-To: <46AF7228.7020703@leemhuis.info> References: <46AF7228.7020703@leemhuis.info> Message-ID: <46B0B1B2.8010507@leemhuis.info> Hi all! Sorry, I have to leave the keyboard in some minutes and will miss the meeting. Nothing urgent, but a was not foreseeable. Some comments for todays meeting: On 31.07.2007 19:32, Thorsten Leemhuis wrote: > > find below the list of topics that are planed to come up in the next > EPEL SIG meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC > in #fedora-meeting on irc.freenode.org. > > > EPEL announcement happened -- are we satisfied with how everything > worked out? So far: yes. I'd hoped we would have had some more packages and more media coverage, but it's a good start afaics. The broken deps problem was worked around just in time afaics. > branch for EPEL if Fedora maintainer does not react -- dgilmore I'd really like to get this of the table. If somebody has concerns with the latest proposal write them up please or (preferred) write a new proposal that solves the problem that was raised with the current one in the wiki -- if no ones does it soon I'd say let's go for https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html as that's better then what we have > new push scripts for pushing to testing, adjust mock configs to use > testing -- dgilmore Status? RHEL 5.1 is approaching and I'd say we copy the testing repo to stable then again. > EPEL announcement happened -- what next? I'd like to see this discussed on the list. I have some ideas, but not enough time to write all of the down now. So: What do you guys want? Note. I forgot the "yum for EPEL4" issue. Could you guys discuss this as well? Jeff_S prepares some stuff iirc, we just need to say "go for it" afaics. Someone raised concerns in the last meeting, but never took them to the list which isn't helpful to get the problem solved. I'd say if the concerns doesn#t make it to the list let's go for what Jeff proposed. Cu thl From kwade at redhat.com Wed Aug 1 16:33:21 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 01 Aug 2007 09:33:21 -0700 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <46B00ED4.7040803@leemhuis.info> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> Message-ID: <1185986001.3521.255.camel@erato.phig.org> On Wed, 2007-08-01 at 06:40 +0200, Thorsten Leemhuis wrote: > > On 31.07.2007 22:19, Karsten Wade wrote: > > Is this inaccurate/old? > > > > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e > > It's IMHO accurate, but they wording maybe could be improved. D'oh! That wasn't what I meant to point to, but it looks like you removed the part that confused me. You did remove it, right? The changelog says, "move a part to the faq that belongs there". But this content is old, right? I see you didn't put it into the FAQ. - === What about EPEL for RHEL 4? === - - We start EPEL two years after RHEL4 started getting shipped. Pushing - out packages today that were up2date two years ago might look a bit - odd and will be hard to realize -- what version to choose exactly? So - we simply take a slightly different route for EPEL4 and suggest our - maintainers to consider using the stuff from http://centos.karan.org/ - (which are based on Fedora Extras 3) as base for packages in EPEL4 -- - that stuff is known to work and tested, so is a good base for the - EPEL4 branch. Sure, the outcome would have looked a bit different than - where we might have landed if we would have started EPEL two years - ago, but well, we start now. ;-) - -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed Aug 1 16:35:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Aug 2007 22:05:09 +0530 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <1185986001.3521.255.camel@erato.phig.org> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> <1185986001.3521.255.camel@erato.phig.org> Message-ID: <46B0B63D.7050306@fedoraproject.org> Karsten Wade wrote: > On Wed, 2007-08-01 at 06:40 +0200, Thorsten Leemhuis wrote: >> On 31.07.2007 22:19, Karsten Wade wrote: >>> Is this inaccurate/old? >>> >>> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e >> It's IMHO accurate, but they wording maybe could be improved. > > D'oh! That wasn't what I meant to point to, but it looks like you > removed the part that confused me. You did remove it, right? The > changelog says, "move a part to the faq that belongs there". But this > content is old, right? I see you didn't put it into the FAQ. It is there in the FAQ now. Check again. Rahul From dennis at ausil.us Wed Aug 1 16:35:41 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 1 Aug 2007 11:35:41 -0500 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> References: <4687C867.8060400@leemhuis.info> <469BDB92.5080508@fedoraproject.org> <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <200708011135.41391.dennis@ausil.us> On Monday 16 July 2007 4:08:42 pm rob myers wrote: > here is a complete version, with the co-maintainership changes rahul > suggested. comments? > > If an EPEL maintainer wants to get a Fedora package into EPEL, > first check the ContributorStatus document, located in the wiki at > http://fedoraproject.org/wiki/EPEL/ContributorStatus . > > If the Fedora maintainer of the package has indicated a desire not to > participate in EPEL then the EPEL maintainer can request the branch > directly via the standard procedures (e.g. via bugzilla currently). The > EPEL maintainer should CC the Fedora maintainer on the branch request, > so the Fedora maintainer knows that the package is maintained in EPEL as > well. > > If it is unclear if the Fedora maintainer of the package participates in > EPEL then the EPEL maintainer should mail the Fedora maintainer and ask > about their plans for EPEL in general and the package at hand. If there > is no answer within seven days the EPEL maintainer is free to request > the EPEL branch (CC the Fedora maintainer here as well). > > If the Fedora maintainer later decides to participate in EPEL, and no > more than one month has passed, then the EPEL maintainer of the package > must hand primary per release maintainership back to the Fedora > maintainer (and become comaintainer, if interested). If the Fedora > maintainer later decides to participate in EPEL, and more than one month > has passed, the EPEL maintainer of the package should strongly consider > co-maintainership, but does not have to. Here is what i propose. make it a bit simpler If an EPEL maintainer wants to get a Fedora package into EPEL, first check the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus . If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the proposed EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently). The proposed EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. If it is unclear if the Fedora maintainer of the package intends to participate in EPEL then the proposed EPEL maintainer should mail the Fedora maintainer and ask about their plans for EPEL in general and the package at hand. If there is no answer within seven days the proposed EPEL maintainer is free to request the EPEL branch and become the EPEL Maintainer (CC the Fedora maintainer here as well). If the Fedora maintainer decides not to be active in EPEL they should be added to the CC list for all bugs so that collaboration can happen where a bug effects Fedora and EPEL. If the Fedora maintainer later decides to participate in EPEL, Then both people will become co-maintainers for EPEL. (Of course it can be extended to Fedora) Dennis From orion at cora.nwra.com Wed Aug 1 16:39:08 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 01 Aug 2007 10:39:08 -0600 Subject: Plan for tomorrows (20070801) EPEL SIG meeting In-Reply-To: <46B0B1B2.8010507@leemhuis.info> References: <46AF7228.7020703@leemhuis.info> <46B0B1B2.8010507@leemhuis.info> Message-ID: <46B0B72C.6040903@cora.nwra.com> Thorsten Leemhuis wrote: >> branch for EPEL if Fedora maintainer does not react -- dgilmore > > I'd really like to get this of the table. If somebody has concerns with > the latest proposal write them up please or (preferred) write a new > proposal that solves the problem that was raised with the current one in > the wiki -- if no ones does it soon I'd say let's go for > https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html > as that's better then what we have I like this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From kwade at redhat.com Wed Aug 1 16:42:13 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 01 Aug 2007 09:42:13 -0700 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <46B0B63D.7050306@fedoraproject.org> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> <1185986001.3521.255.camel@erato.phig.org> <46B0B63D.7050306@fedoraproject.org> Message-ID: <1185986533.3521.260.camel@erato.phig.org> On Wed, 2007-08-01 at 22:05 +0530, Rahul Sundaram wrote: > Karsten Wade wrote: > > On Wed, 2007-08-01 at 06:40 +0200, Thorsten Leemhuis wrote: > >> On 31.07.2007 22:19, Karsten Wade wrote: > >>> Is this inaccurate/old? > >>> > >>> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e > >> It's IMHO accurate, but they wording maybe could be improved. > > > > D'oh! That wasn't what I meant to point to, but it looks like you > > removed the part that confused me. You did remove it, right? The > > changelog says, "move a part to the faq that belongs there". But this > > content is old, right? I see you didn't put it into the FAQ. > > It is there in the FAQ now. Check again. OK, I see the revised form. I read the original, and it made it sound like, "We aren't doing EPEL 4, use karan.centos.org instead." That is, the wording was confusing, and Thorsten cleaned it up, so good. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Aug 1 16:44:37 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 01 Aug 2007 09:44:37 -0700 Subject: Plan for tomorrows (20070801) EPEL SIG meeting In-Reply-To: <46AF7228.7020703@leemhuis.info> References: <46AF7228.7020703@leemhuis.info> Message-ID: <1185986677.3521.264.camel@erato.phig.org> On Tue, 2007-07-31 at 19:32 +0200, Thorsten Leemhuis wrote: > EPEL announcement happened -- are we satisfied with how everything > worked out? In retrospect ... * Someone else (not @redhat.com) could have sent the email and avoided some confusion. * A few people contacted me who had interest in being EPEL maintainers, so publicity was good. * I saw some Q&A go by that showed that many people clearly understand the reason and value of EPEL. * Timing it to also go to RHEL user lists would have been good, but that might have caused delay in arranging. * Be careful of last minute changes in content, they are the biggest risk to typos/incomplete sentences. -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Wed Aug 1 16:48:02 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 1 Aug 2007 11:48:02 -0500 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <200708011135.41391.dennis@ausil.us> References: <4687C867.8060400@leemhuis.info> <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> <200708011135.41391.dennis@ausil.us> Message-ID: <200708011148.02827.dennis@ausil.us> On Wednesday 01 August 2007 11:35:41 am Dennis Gilmore wrote: > If the Fedora maintainer later decides to participate in EPEL, Then both > people will become co-maintainers for EPEL. (Of course it can be extended > to Fedora) co-maintainership can be extended to Fedora also. Dennis From dennis at ausil.us Wed Aug 1 16:59:41 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 1 Aug 2007 11:59:41 -0500 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <200708011148.02827.dennis@ausil.us> References: <4687C867.8060400@leemhuis.info> <200708011135.41391.dennis@ausil.us> <200708011148.02827.dennis@ausil.us> Message-ID: <200708011159.41594.dennis@ausil.us> On Wednesday 01 August 2007 11:48:02 am Dennis Gilmore wrote: > On Wednesday 01 August 2007 11:35:41 am Dennis Gilmore wrote: > > If the Fedora maintainer later decides to participate in EPEL, Then both > > people will become co-maintainers for EPEL. (Of course it can be > > extended to Fedora) > > co-maintainership can be extended to Fedora also. Just to make it full and clear If an EPEL maintainer wants to get a Fedora package into EPEL, first check the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus . If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the proposed EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently). ?The proposed EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. If it is unclear if the Fedora maintainer of the package intends to participate in EPEL then the proposed EPEL maintainer should mail the Fedora maintainer and ask about their plans for EPEL in general and the package at hand. ?If there is no answer within seven days the proposed EPEL maintainer is free to request the EPEL branch and become the EPEL Maintainer (CC the Fedora maintainer here as well). ?If the Fedora maintainer decides not to be active in EPEL they should be added to the CC list for all bugs ?so that collaboration can happen where a bug effects Fedora and EPEL. If the Fedora maintainer later decides to participate in EPEL, Then both people will become co-maintainers for EPEL. ?(Of course co-maintainership can be extended to Fedora) From sundaram at fedoraproject.org Wed Aug 1 17:02:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Aug 2007 22:32:48 +0530 Subject: Plan for tomorrows (20070801) EPEL SIG meeting In-Reply-To: <1185986677.3521.264.camel@erato.phig.org> References: <46AF7228.7020703@leemhuis.info> <1185986677.3521.264.camel@erato.phig.org> Message-ID: <46B0BCB8.3020803@fedoraproject.org> Karsten Wade wrote: > On Tue, 2007-07-31 at 19:32 +0200, Thorsten Leemhuis wrote: > >> EPEL announcement happened -- are we satisfied with how everything >> worked out? > > In retrospect ... > > * Someone else (not @redhat.com) could have sent the email and avoided > some confusion. True. EPEL repository media coverage has not been bad but by no means large. http://www.linuxelectrons.com/news/application/10941/red-hat-launches-new-package-repository-enterprise-linux Linux electrons assumed it was a Red Hat effort since you send the mail and so did Distrowatch which used it as a reference in http://distrowatch.com/weekly.php?issue=20070730#news Linux.com had a article with extensive references to the EPEL FAQ http://www.linux.com/feature/118304 We have had some discussions in fedora marketing list and with some other product management folks about how it relates to RHEL. Short outlook is supportive but wait and watch for more input. If there are no announcements to RHEL announce lists being send out someone should atleast do it informally in the user lists. Rahul From sundaram at fedoraproject.org Wed Aug 1 17:04:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Aug 2007 22:34:55 +0530 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <200708011159.41594.dennis@ausil.us> References: <4687C867.8060400@leemhuis.info> <200708011135.41391.dennis@ausil.us> <200708011148.02827.dennis@ausil.us> <200708011159.41594.dennis@ausil.us> Message-ID: <46B0BD37.6050008@fedoraproject.org> Dennis Gilmore wrote: > If the Fedora maintainer later decides to participate in EPEL, Then both > people will become co-maintainers for EPEL. (Of course co-maintainership can > be extended to Fedora) Do we have a generic policy for resolving disputes? I guess the answer is go to FESCo and escalate to board if necessary but having that written down is good. Rahul From dennis at ausil.us Wed Aug 1 17:50:32 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 1 Aug 2007 12:50:32 -0500 Subject: Log from EPEL Meeting (20070801) Message-ID: <200708011250.33009.dennis@ausil.us> 10:01 * nirik looks around for the EPEL meeting. 10:02 * dgilmore is here 10:02 < dgilmore> mmcgrath: Ping 10:02 < mmcgrath> pong 10:03 < _blah_> dgilmore: i'd say upload what you've got to the wiki, and if people want to revise further we can. 10:04 -!- rayvd [i=rayvd at arthur.bludgeon.org] has joined #fedora-meeting 10:05 < dgilmore> done 10:05 < dgilmore> mmcgrath: meeting 10:05 < dgilmore> who else are we missing? 10:05 * mmcgrath is sort of here (also working on some infrastructure issues) 10:05 < mmcgrath> quaid: ping? 10:05 < mmcgrath> Jeff_S? 10:06 -!- notting [i=notting at redhat/notting] has joined #fedora-meeting 10:06 -!- Fabi [n=festifn at moinmoin/coreteam/florian] has joined #fedora-meeting 10:06 < dgilmore> Well what did everyone think of how things have gone since the announcement? 10:06 < notting> what sort of uptake do we have? do we have stats? 10:06 < mmcgrath> pretty good actually. 10:07 < warren> Is EPEL's homepage easy to find? 10:07 -!- nirik changed the topic of #fedora-meeting to: EPEL Meeting|EPEL announcement happened -- are we satisfied with how everything worked out? 10:07 -!- giallu [n=giallu at 81-174-26-126.static.ngi.it] has quit ["Leaving"] 10:07 * f13 peeks in 10:07 < mmcgrath> dgilmore: I saw a couple of articles done about epel 10:07 * _blah_ pushes f13 back to work on f8test1 10:07 < nirik> yeah, stats on repo usage would be nice... not sure how to gather those tho...like fedora I suppose? 10:08 * quaid is here, had to do some stuff that ran over 10:08 < dgilmore> warren: we probably should have a link on the front page of fp.o and fp.o/wiki 10:08 < mmcgrath> http://www.linux.com/feature/118304 10:08 < nirik> or perhaps a epel.fedoraproject.org cname? 10:08 < warren> redirect at least 10:08 < warren> too bad epel.org is taken 10:09 < dgilmore> nirik: that also 10:09 < dgilmore> mmcgrath: Red Hat's new Extra Packages for Enterprise Linux (EPEL) repository might be an excellent place to go fishing. 10:09 < dgilmore> i dont much like that 10:10 < rsc> is there a chance for epel.redhat.com? 10:10 < dgilmore> its Fedora's not Red Hat's 10:10 < warren> rsc, better to brand it with Fedora 10:10 < dgilmore> rsc: i dont want to go down that route 10:10 < rsc> dgilmore, warren: Accepted. 10:12 < nirik> who updates http://fedoraproject.org/wiki/Statistics ? mspevack ? perhaps we could add a epel section there and add the same stats for it? 10:12 < nirik> or do we collect the same data? 10:12 < warren> EPEL users are technically different from Fedora 10:12 < mmcgrath> nirik: we could collect that data, do we want epel in general or both epel-5 and epel-4? 10:12 < warren> maybe we could add them both together 10:13 < nirik> it might be nice to see both epel4 and epel5... but I dont know how hard it is to generate those stats... 10:13 < mmcgrath> nirik: those numbers actually come from - https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=253 10:13 < nirik> ah, from smolt? 10:13 < mmcgrath> nirik: its not hard but I think I'm the only one who understands it. 10:13 < mmcgrath> well, some from smolt, some from grabbing ip's from the logs. 10:14 < nirik> yeah, we don't have smolt data, but uniq ips would be nice to know... better than nothing... 10:14 < dgilmore> anyone have anything else to add? 10:15 < nirik> (although, I suppose smolt could be built for epel4/epel5 barring missing dependencies, etc) 10:15 < mmcgrath> nirik: actually its already in epel5 :) 10:15 < dgilmore> nirik: its in epel5 10:15 < nirik> cool. I should install it and run it on my 5 machines. ;) 10:15 < mmcgrath> nirik: you should :) 10:16 < nirik> might be worth a mailing list post/blog mentioning that to let people know its out there for epel5. 10:16 -!- daMaestro [n=jon at fedora/damaestro] has joined #fedora-meeting 10:16 < nirik> anyhow, nothing else on this topic for me. 10:16 < mmcgrath> 10:16 < mmcgrath> nothing else here. I think its gone well. 10:16 -!- alexxed [n=alex at dyn-89.136.44.20.tm.upcnet.ro] has joined #fedora-meeting 10:16 -!- k0k [n=k0k at fedora/k0k] has joined #fedora-meeting 10:16 < _blah_> mmcgrath: are all dependencies resolved now that things have been moved to testing? 10:16 * nirik sees 15 centos5 and 10 rhel5 entries in smolt. 10:17 -!- dgilmore changed the topic of #fedora-meeting to: EPEL Meeting| branch for EPEL if Fedora maintainer does not react -- dgilmore 10:17 < mmcgrath> _blah_: I think some are left (though its not many, last check it was 3 and the owners were notified). 10:17 < _blah_> dgilmore: i like the version you mailed and put into the wiki. 10:17 < mmcgrath> I think it was 2 in rhel4 and 1 in rhel5 10:17 < dgilmore> sorry it took so long i sent my proposal just before the meeting 10:17 < mmcgrath> dgilmore: I think your suggestion is very reasonable. 10:18 < nirik> dgilmore: +1 from me on your proposal. We can modify later if we need to. 10:18 < _blah_> for the record a link to the current version in the wiki is: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-00c9e731bb7bc5bb78caf8d124da3a329400fcd8 10:18 < dgilmore> If there are no objections we will take that as accepted 10:19 -!- bpepple|lt [n=bpepple|@adsl-75-42-209-184.dsl.wotnoh.sbcglobal.net] has quit ["Ex-Chat"] 10:20 -!- alexxed [n=alex at dyn-89.136.44.20.tm.upcnet.ro] has left #fedora-meeting [] 10:20 < nirik> shall we move on? 10:20 < dgilmore> I think so 10:20 -!- dgilmore changed the topic of #fedora-meeting to: new push scripts for pushing to testing, adjust mock configs to use 10:20 -!- bpepple [n=bpepple at adsl-75-42-209-184.dsl.wotnoh.sbcglobal.net] has joined #fedora-meeting 10:20 < dgilmore> i still need to do this 10:21 < dgilmore> I will do it tonight 10:21 < dgilmore> mmcgrath: can you remind me if i dont please 10:21 < nirik> so for security (if any) we are going to manually move packages as needed? 10:21 < mmcgrath> will do 10:21 < dgilmore> yes 10:21 < dgilmore> security will need manual handling 10:22 < nirik> sounds good. Let me know if I can assist any with that. 10:22 < dgilmore> will do 10:22 -!- dgilmore changed the topic of #fedora-meeting to: EPEL Meeting: EPEL announcement happened -- what next? 10:23 < mmcgrath> dgilmore: good question. 10:23 < mmcgrath> Things are going pretty well. 10:23 < dgilmore> OK what now? 10:23 < nirik> more packages, more maintainers, more users. ;) 10:23 -!- rwmjones [n=rwmjones at 87.127.66.208] has quit ["Closed connection"] 10:23 < nirik> if we could move to koji at some point and bodhi that would be good... 10:24 < dgilmore> that needs to be done but requires coders 10:24 < nirik> yeah. ;( 10:25 < dgilmore> does anyone have ideas on how to get more packages in EPEL 10:26 < nirik> I have some more I am going to do, but haven't had time... hopefully soon I will get munin in and possibly will look at Xfce (matching the centos extra versions so we don't conflict if possible) 10:27 < dgilmore> i think xfce would be good to have 10:27 < dgilmore> i think silug has yet to build alot of his perl modules due to missing deps 10:27 < mmcgrath> 10:28 < mmcgrath> There are a lot of things we'd like to branch that deps are missing for 10:28 < nirik> just takes time to make sure things are branched and then work right, etc... 10:29 < dgilmore> yep 10:29 < _blah_> i'd like to see rt3 and bugzilla 3 in there 10:29 < dgilmore> it would be nice for someone to see whats branched and not built 10:30 < nirik> 11 open epel bugs... so we have some users at least. ;) 10:31 < nirik> shall we talk yum for epel4 ? 10:31 -!- rwmjones [n=rwmjones at 87.127.66.208] has joined #fedora-meeting 10:31 < nirik> and move what next? to the mailing list? 10:33 < dgilmore> i think we should talk about yum on the list 10:34 < dgilmore> I personally think we provide the version thats in CentOS but without a /etc/yum.conf file 10:34 < mmcgrath> dgilmore: do you agree with the 0. in release? 10:36 < dgilmore> mmcgrath: i see the point of it yeah 10:37 < nirik> yeah, it seems fine to me... 10:37 -!- AravindSeshadri [n=AravindS at 0-11-43-71-59-38.ceat.okstate.edu] has joined #fedora-meeting 10:38 < mmcgrath> I guess we want to ship yum with no yum configs. 10:38 < mmcgrath> maybe a /etc/yum.conf that contains a comment to note that it shouldn't be used. 10:39 < nirik> yeah... 10:42 < dgilmore> yep 10:42 < dgilmore> that seems sane 10:42 < dgilmore> lets put it on the list get buy in from everyone 10:42 -!- dgilmore changed the topic of #fedora-meeting to: EPEL Meeting: Free chat 10:42 < dgilmore> anyone have anything to add? 10:42 * mmcgrath has nothing 10:43 * dgilmore will close in 60 10:43 * dgilmore will close in 30 10:43 * dgilmore will close in 20 10:44 * dgilmore will close in 10 10:44 -!- notting [i=notting at redhat/notting] has left #fedora-meeting ["Ex-Chat"] 10:44 < dgilmore> ==== Meeting closed ===== From mmahut at fedoraproject.org Wed Aug 1 18:18:29 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Wed, 01 Aug 2007 20:18:29 +0200 Subject: Plan for tomorrows (20070801) EPEL SIG meeting In-Reply-To: <46AF7228.7020703@leemhuis.info> References: <46AF7228.7020703@leemhuis.info> Message-ID: <46B0CE75.3040206@fedoraproject.org> Hello all, I'm very sorry. I missed this meeting, I just screw up the timezone and came one hour later :( Thorsten Leemhuis wrote: > Hi all, > > find below the list of topics that are planed to come up in the next > EPEL SIG meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC > in #fedora-meeting on irc.freenode.org. > > > EPEL announcement happened -- are we satisfied with how everything > worked out? > > branch for EPEL if Fedora maintainer does not react -- dgilmore > > new push scripts for pushing to testing, adjust mock configs to use > testing -- dgilmore > > EPEL announcement happened -- what next? > > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics at the end of the meeting itself. > > If your name/nick is on above list please give a update. That way all > the interested parties know what up ahead of the meeting; that will > avoid long delays and "status update monologues in the meeting. > > Thanks! > > CU > knurd -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From smooge at gmail.com Wed Aug 1 18:57:48 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 1 Aug 2007 12:57:48 -0600 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <46B00ED4.7040803@leemhuis.info> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> Message-ID: <80d7e4090708011157n4efeb494q4cee647ac95649be@mail.gmail.com> On 7/31/07, Thorsten Leemhuis wrote: > > > On 31.07.2007 22:19, Karsten Wade wrote: > > Is this inaccurate/old? > > > > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e > > It's IMHO accurate, but they wording maybe could be improved. > > > If so, what do we want to say instead? > > "We are doing EPEL4 and if you look for a SRPM to take as base besides > looking at the FC-3 branch please also take a look at those from > http://centos.karan.org/, as those packages are known to work for EL4 > and tested there. " > What about 3 and 2 :)? [As I have to take a bunch of 5 stuff and recompile it on 2 because the 3rd party software runs on 2 but wants newer stuff... whee.] -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sundaram at fedoraproject.org Wed Aug 1 19:58:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 01:28:39 +0530 Subject: el-4 confusion, misstatement on Wiki? In-Reply-To: <80d7e4090708011157n4efeb494q4cee647ac95649be@mail.gmail.com> References: <1185913180.3521.158.camel@erato.phig.org> <46B00ED4.7040803@leemhuis.info> <80d7e4090708011157n4efeb494q4cee647ac95649be@mail.gmail.com> Message-ID: <46B0E5EF.9010606@fedoraproject.org> Stephen John Smoogen wrote: > What about 3 and 2 :)? > > [As I have to take a bunch of 5 stuff and recompile it on 2 because > the 3rd party software runs on 2 but wants newer stuff... whee.] Just noted that EPEL doesn't provide packages for these releases in the EPEL FAQ. Rahul From AKLYACHKIN at raiffeisen.ru Thu Aug 2 06:25:39 2007 From: AKLYACHKIN at raiffeisen.ru (Andrey KLYACHKIN) Date: Thu, 2 Aug 2007 10:25:39 +0400 Subject: RHN software channels & EPEL Message-ID: Hallo all, how EPEL will deal with so called software channels in RHN? E.g., RHEL4 has channel Red Hat Web Application Stack and it contains httpd-2.0.55 (which replaces standard httpd-2.0.52 from RHEL4) and mysql-connector-odbc-3.51.12 (there is no such package in the standard RHEL4 distribution). Will EPEL packages be built without replacing packages only from standard distribution or also from additional software channels and Red Hat products (such as RHCS, GFS, ...)? -- Sincerely yours, Andrey Klyachkin UNIX Systems Administrator, RaiffeisenBank Austria, Moscow This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient any use, distribution, copying or disclosure is strictly prohibited. If you have received this message in error, please notify the sender immediately either by telephone or by e-mail and delete this message and any attachment from your system. Correspondence via e-mail is for information purposes only. ZAO Raiffeisenbank Austria neither makes nor accepts legally binding statements by e-mail unless otherwise agreed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Aug 2 06:41:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 12:11:57 +0530 Subject: RHN software channels & EPEL In-Reply-To: References: Message-ID: <46B17CB5.2010905@fedoraproject.org> Andrey KLYACHKIN wrote: > > Hallo all, > > how EPEL will deal with so called software channels in RHN? E.g., RHEL4 > has channel Red Hat Web Application Stack and it contains httpd-2.0.55 > (which replaces standard httpd-2.0.52 from RHEL4) and > mysql-connector-odbc-3.51.12 (there is no such package in the standard > RHEL4 distribution). Will EPEL packages be built without replacing > packages only from standard distribution or also from additional > software channels and Red Hat products (such as RHCS, GFS, ...)? These are called layered products and they won't be replaced by EPEL either. This is answered in the EPEL FAQ at http://fedoraproject.org/wiki/EPEL/FAQ Rahul From fedora at leemhuis.info Thu Aug 2 06:48:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Aug 2007 08:48:23 +0200 Subject: RHN software channels & EPEL In-Reply-To: <46B17CB5.2010905@fedoraproject.org> References: <46B17CB5.2010905@fedoraproject.org> Message-ID: <46B17E37.1060202@leemhuis.info> On 02.08.2007 08:41, Rahul Sundaram wrote: > Andrey KLYACHKIN wrote: > >> how EPEL will deal with so called software channels in RHN? E.g., RHEL4 >> has channel Red Hat Web Application Stack and it contains httpd-2.0.55 >> (which replaces standard httpd-2.0.52 from RHEL4) and >> mysql-connector-odbc-3.51.12 (there is no such package in the standard >> RHEL4 distribution). Will EPEL packages be built without replacing >> packages only from standard distribution or also from additional >> software channels and Red Hat products (such as RHCS, GFS, ...)? > These are called layered products and they won't be replaced by EPEL > either. This is answered in the EPEL FAQ at > http://fedoraproject.org/wiki/EPEL/FAQ Just wondering: would it be fine for EPEL to ship for example mysql-connector-odbc under a different name ("mysql-connector-odbc-epel")? Then we would not replace packages from layered products, just provide something (without support) that's also provided by a layered product (which has support). I'd tend to answer my question from above with "yes". CU thl From sundaram at fedoraproject.org Thu Aug 2 08:08:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 13:38:37 +0530 Subject: RHN software channels & EPEL In-Reply-To: <46B17E37.1060202@leemhuis.info> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> Message-ID: <46B19105.8030504@fedoraproject.org> Thorsten Leemhuis wrote: > Just wondering: would it be fine for EPEL to ship for example > mysql-connector-odbc under a different name > ("mysql-connector-odbc-epel")? Then we would not replace packages from > layered products, just provide something (without support) that's also > provided by a layered product (which has support). That depends on how comfortable you are letting EPEL be a way to bypass a product requirement essentially. If it is for libraries it might still be required and useful for other reasons but what about say fedora directory server in EPEL? Rahul From sankarshan.mukhopadhyay at gmail.com Thu Aug 2 08:28:41 2007 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Thu, 02 Aug 2007 13:58:41 +0530 Subject: RHN software channels & EPEL In-Reply-To: <46B17E37.1060202@leemhuis.info> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> Message-ID: <46B195B9.8050601@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis wrote: > Just wondering: would it be fine for EPEL to ship for example > mysql-connector-odbc under a different name > ("mysql-connector-odbc-epel")? Then we would not replace packages from > layered products, just provide something (without support) that's also > provided by a layered product (which has support). Well it could become a support nightmare though at the worst case. What would prevent the entropy from increasing is a nice definition of what is "Extra Packages" when it comes to "Enterprise Linux" and what are the essential facts one should consider when going forward adding the EPEL repository and adding the packages to a subscribed and supportable Enterprise Linux system > I'd tend to answer my question from above with "yes". - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGsZW5XQZpNTcrCzMRAm4sAJ0caU6+ph/TGJbovVagaCtY8JGxAgCfRRAR vteQ+e6Z+AOa5ha8OWVaSZM= =r5g9 -----END PGP SIGNATURE----- From fedora at leemhuis.info Thu Aug 2 08:33:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Aug 2007 10:33:44 +0200 Subject: RHN software channels & EPEL In-Reply-To: <46B19105.8030504@fedoraproject.org> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> <46B19105.8030504@fedoraproject.org> Message-ID: <46B196E8.5080307@leemhuis.info> On 02.08.2007 10:08, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > >> Just wondering: would it be fine for EPEL to ship for example >> mysql-connector-odbc under a different name >> ("mysql-connector-odbc-epel")? Then we would not replace packages from >> layered products, just provide something (without support) that's also >> provided by a layered product (which has support). > That depends on how comfortable you are letting EPEL be a way to bypass > a product requirement essentially. Complicated topic. > If it is for libraries it might still be required and useful for other > reasons Exactly. Not having some libs just because some layered product ships them as well could be problematic for EPEL and hurt it a lot. > but what about say fedora directory server in EPEL? I'm unsure myself about this one. A *short* version and just a fragment of the thoughts in my head: people pay Red Hat for the support, but some people might just want the support for the OS, but not for a specific software they install. Should we try to force those people into the existing model (users nevertheless can just rebuild the Fedora-DS or RHEL-DS SRPM) or do we simply offer what we have and let them chose if they want payed support or not? CU knurd From fedora at leemhuis.info Thu Aug 2 08:42:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Aug 2007 10:42:55 +0200 Subject: RHN software channels & EPEL In-Reply-To: <46B195B9.8050601@gmail.com> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> <46B195B9.8050601@gmail.com> Message-ID: <46B1990F.3010002@leemhuis.info> On 02.08.2007 10:28, Sankarshan Mukhopadhyay wrote: > Thorsten Leemhuis wrote: > >> Just wondering: would it be fine for EPEL to ship for example >> mysql-connector-odbc under a different name >> ("mysql-connector-odbc-epel")? Then we would not replace packages from >> layered products, just provide something (without support) that's also >> provided by a layered product (which has support). > > Well it could become a support nightmare though at the worst case. Well, we'd need to make sure the different packages don't get installed at the same time. But yeah, point taken. *If* we ever should need a *library* in EPEL that's currently part of a layered product then it might be the best for all parties involved to ship that library in RHEL proper, and not in the layered product. CU thl From wolfy at nobugconsulting.ro Thu Aug 2 08:46:57 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 02 Aug 2007 11:46:57 +0300 Subject: RHN software channels & EPEL In-Reply-To: <46B196E8.5080307@leemhuis.info> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> <46B19105.8030504@fedoraproject.org> <46B196E8.5080307@leemhuis.info> Message-ID: <46B19A01.8090900@nobugconsulting.ro> Thorsten Leemhuis wrote: > On 02.08.2007 10:08, Rahul Sundaram wrote: > >> Thorsten Leemhuis wrote: >> >> >>> Just wondering: would it be fine for EPEL to ship for example >>> mysql-connector-odbc under a different name >>> ("mysql-connector-odbc-epel")? Then we would not replace packages from >>> layered products, just provide something (without support) that's also >>> provided by a layered product (which has support). >>> >> That depends on how comfortable you are letting EPEL be a way to bypass >> a product requirement essentially. >> > > Complicated topic. > > >> If it is for libraries it might still be required and useful for other >> reasons >> > > Exactly. Not having some libs just because some layered product ships > them as well could be problematic for EPEL and hurt it a lot. > > >> but what about say fedora directory server in EPEL? >> > > I'm unsure myself about this one. A *short* version and just a fragment > of the thoughts in my head: people pay Red Hat for the support, but some > people might just want the support for the OS, but not for a specific > software they install. Should we try to force those people into the > existing model (users nevertheless can just rebuild the Fedora-DS or > RHEL-DS SRPM) or do we simply offer what we have and let them chose if > they want payed support or not? How about using the yum protectbase plugin ? With it, it would be trivial to make sure we never replace core/layered/other important products -- Manuel Wolfshant linux registered user #131416 IT manager NoBug Consulting SRL http://www.brainbench.com/transcript.jsp?pid=40317 From fedora at leemhuis.info Thu Aug 2 08:53:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Aug 2007 10:53:01 +0200 Subject: RHN software channels & EPEL In-Reply-To: <46B1990F.3010002@leemhuis.info> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> <46B195B9.8050601@gmail.com> <46B1990F.3010002@leemhuis.info> Message-ID: <46B19B6D.5070109@leemhuis.info> On 02.08.2007 10:42, Thorsten Leemhuis wrote: > > On 02.08.2007 10:28, Sankarshan Mukhopadhyay wrote: >> Thorsten Leemhuis wrote: >> >>> Just wondering: would it be fine for EPEL to ship for example >>> mysql-connector-odbc under a different name >>> ("mysql-connector-odbc-epel")? Then we would not replace packages from >>> layered products, just provide something (without support) that's also >>> provided by a layered product (which has support). >> Well it could become a support nightmare though at the worst case. > > Well, we'd need to make sure the different packages don't get installed > at the same time. But yeah, point taken. > > *If* we ever should need a *library* in EPEL that's currently part of a > layered product then it might be the best for all parties involved to > ship that library in RHEL proper, and not in the layered product. In addition: maybe we should in fact discuss this further when this "*if*" case actually shows up and then look out for a individual solution together with Red Hat that serves both sides needs somehow. CU thl From sundaram at fedoraproject.org Thu Aug 2 08:56:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 14:26:18 +0530 Subject: RHN software channels & EPEL In-Reply-To: <46B196E8.5080307@leemhuis.info> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> <46B19105.8030504@fedoraproject.org> <46B196E8.5080307@leemhuis.info> Message-ID: <46B19C32.1070602@fedoraproject.org> Thorsten Leemhuis wrote: > > Exactly. Not having some libs just because some layered product ships > them as well could be problematic for EPEL and hurt it a lot. In this talk to Daniel Riek and see if it feasible to add that library to the base product. It won't happen immediately. New packages are added only when required in the sync updates which was previously quarterly and still somewhat follows that schedule. Even then some customers consider the changes in between these updates large and stick with a older version (ie) 4.2 though 4.4 has been released and Red Hat has announced recently a separate support and updates stream for that case so packages added in the later revisions will be excluded for them. As you can imagine there is a lot of complexity in managing all these but you can probably ignore this case since customers using this update stream are highly sensitive to changes and are unlikely to just pull in packages from any external source without commercial support guarantees. > > I'm unsure myself about this one. A *short* version and just a fragment > of the thoughts in my head: people pay Red Hat for the support, but some > people might just want the support for the OS, but not for a specific > software they install. Should we try to force those people into the > existing model (users nevertheless can just rebuild the Fedora-DS or > RHEL-DS SRPM) or do we simply offer what we have and let them chose if > they want payed support or not? I am all in for providing more flexibility here but I don't really want to create more support pains. Since the base product that we are complimenting has support has one of the core values this has a high priority. Rahul From kanarip at kanarip.com Thu Aug 2 09:12:32 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 02 Aug 2007 11:12:32 +0200 Subject: RHN software channels & EPEL In-Reply-To: <46B19A01.8090900@nobugconsulting.ro> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> <46B19105.8030504@fedoraproject.org> <46B196E8.5080307@leemhuis.info> <46B19A01.8090900@nobugconsulting.ro> Message-ID: <46B1A000.30700@kanarip.com> Manuel Wolfshant wrote: > How about using the yum protectbase plugin ? With it, it would be > trivial to make sure we never replace core/layered/other important products > That wouldn't prevent machine X having subscribed to no software channels at all installing EPEL foo(-epel).rpm and then subscribing to a channel providing RHEL foo.rpm. IMHO, EPEL should stick to what it does best: Extra Packages for Enterprise Linux, not Extra Packages for Enterprise Linux and The Software of Those Channels You Didn't Subscribe to With RH. If anywhere along the path say foo needs a lib or dep that is not in RHEL, imho, foo shouldn't be in EPEL either -regardless of how EPEL /could/ make it work. Rather make an effort to get the lib or dep in the next RHEL release. Just my $0.02 Kind regards, Jeroen van Meeuwen -kanarip From rmy at tigress.co.uk Thu Aug 2 18:46:03 2007 From: rmy at tigress.co.uk (Ron Yorston) Date: Thu, 2 Aug 2007 19:46:03 +0100 Subject: yum update problem on CentOS 5 Message-ID: <200708021846.l72Ik3gi016737@tigress.co.uk> Since I added the EPEL repository to my CentOS 4.5 system I've been having trouble with 'yum update'. It reports: --> Running transaction check --> Processing Dependency: perl-libxml-enno >= 1.02 for package: foomatic --> Processing Dependency: perl(XML::RegExp) for package: perl-XML-DOM --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package perl-XML-RegExp.noarch 0:0.03-2.el4 set to be updated --> Running transaction check --> Processing Dependency: perl-libxml-enno >= 1.02 for package: foomatic --> Finished Dependency Resolution Error: Missing Dependency: perl-libxml-enno >= 1.02 is needed by package foomatic I can make it work either by disabling the EPEL repo (yum --disablerepo=epel update) or by specifying explicitly what needs to be updated (yum update tetex). But I shouldn't have to. Apparently perl-XML-DOM (from EPEL) obsoletes perl-libxml-enno <= 1.02, but CentOS has perl-libxml-enno-1.02-31 which is required by foomatic. Result misery. Ron From sundaram at fedoraproject.org Thu Aug 2 18:54:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Aug 2007 00:24:00 +0530 Subject: yum update problem on CentOS 5 In-Reply-To: <200708021846.l72Ik3gi016737@tigress.co.uk> References: <200708021846.l72Ik3gi016737@tigress.co.uk> Message-ID: <46B22848.1000805@fedoraproject.org> Ron Yorston wrote: > I can make it work either by disabling the EPEL repo (yum --disablerepo=epel > update) or by specifying explicitly what needs to be updated (yum update > tetex). But I shouldn't have to. Right. > > Apparently perl-XML-DOM (from EPEL) obsoletes perl-libxml-enno <= 1.02, > but CentOS has perl-libxml-enno-1.02-31 which is required by foomatic. > > Result misery. Can you file a bug report in http://bugzilla.redhat.com against the perl module package? Thanks for the report. Rahul From rmy at tigress.co.uk Thu Aug 2 18:59:12 2007 From: rmy at tigress.co.uk (Ron Yorston) Date: Thu, 02 Aug 2007 19:59:12 +0100 Subject: yum update problem on CentOS 5 In-Reply-To: <46B22848.1000805@fedoraproject.org> References: <200708021846.l72Ik3gi016737@tigress.co.uk> <46B22848.1000805@fedoraproject.org> Message-ID: <200708021859.l72IxDJ9015403@tiffany.internal.tigress.co.uk> Rahul Sundaram wrote: >Ron Yorston wrote: >> Apparently perl-XML-DOM (from EPEL) obsoletes perl-libxml-enno <= 1.02, >> but CentOS has perl-libxml-enno-1.02-31 which is required by foomatic. >> >> Result misery. > >Can you file a bug report in http://bugzilla.redhat.com against the perl > module package? Thanks for the report. Too late. It's already there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249901 Ron From herrold at owlriver.com Fri Aug 3 02:42:47 2007 From: herrold at owlriver.com (R P Herrold) Date: Thu, 2 Aug 2007 22:42:47 -0400 (EDT) Subject: RHN software channels & EPEL In-Reply-To: <46B17E37.1060202@leemhuis.info> References: <46B17CB5.2010905@fedoraproject.org> <46B17E37.1060202@leemhuis.info> Message-ID: On Thu, 2 Aug 2007, Thorsten Leemhuis wrote: > Just wondering: would it be fine for EPEL to ship for example > mysql-connector-odbc under a different name > ("mysql-connector-odbc-epel")? and this form of 'at the end of the package name' marking would be an improvement, compared to a repotag at the end of release, just how? It is just as unsightly, and just as much, if not worse, namespace clutter, but worse, as it now would need to carry an explicit (and manual, hence error-prone) spec file mungeing: Provides: mysql-connector-odbc entry for dependency resolution. Just wait until a versioned Provides is needed which cannot be well expressed. -- Russ Herrold From mastahnke at gmail.com Fri Aug 3 16:28:55 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 3 Aug 2007 11:28:55 -0500 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <46B0BD37.6050008@fedoraproject.org> References: <4687C867.8060400@leemhuis.info> <200708011135.41391.dennis@ausil.us> <200708011148.02827.dennis@ausil.us> <200708011159.41594.dennis@ausil.us> <46B0BD37.6050008@fedoraproject.org> Message-ID: <7874d9dd0708030928j4ea1c9d5yfb82486d1627e5fd@mail.gmail.com> I like the overall message now. +1 for my vote on the message. stahnma From florin at andrei.myip.org Fri Aug 3 23:03:44 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 03 Aug 2007 16:03:44 -0700 Subject: add to wish list: ucarp Message-ID: <46B3B450.1070606@andrei.myip.org> Can't edit the Wiki. Please add ucarp to the wish list. # rpm -qi ucarp Name : ucarp Relocations: (not relocatable) Version : 1.2 Vendor: Fedora Project Release : 7.fc7 Build Date: Mon 05 Feb 2007 05:10:02 AM PST Install Date: Thu 02 Aug 2007 06:51:01 PM PDT Build Host: hammer2.fedora.redhat.com Group : System Environment/Daemons Source RPM: ucarp-1.2-7.fc7.src.rpm Size : 67359 License: BSD Signature : DSA/SHA1, Mon 21 May 2007 11:18:05 AM PDT, Key ID b44269d04f2a6fd2 Packager : Fedora Project URL : http://www.ucarp.org/ Summary : Common Address Redundancy Protocol (CARP) for Unix Description : UCARP allows a couple of hosts to share common virtual IP addresses in order to provide automatic failover. It is a portable userland implementation of the secure and patent-free Common Address Redundancy Protocol (CARP, OpenBSD's alternative to the patents-bloated VRRP). Strong points of the CARP protocol are: very low overhead, cryptographically signed messages, interoperability between different operating systems and no need for any dedicated extra network link between redundant hosts. Thanks, -- Florin Andrei http://florin.myip.org/ From sundaram at fedoraproject.org Fri Aug 3 23:22:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Aug 2007 04:52:30 +0530 Subject: add to wish list: ucarp In-Reply-To: <46B3B450.1070606@andrei.myip.org> References: <46B3B450.1070606@andrei.myip.org> Message-ID: <46B3B8B6.4040802@fedoraproject.org> Florin Andrei wrote: > Can't edit the Wiki. > > Please add ucarp to the wish list. Done. Rahul From wolfy at nobugconsulting.ro Sat Aug 4 15:45:57 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 04 Aug 2007 18:45:57 +0300 Subject: add to wish list: ucarp In-Reply-To: <46B3B450.1070606@andrei.myip.org> References: <46B3B450.1070606@andrei.myip.org> Message-ID: <46B49F35.2090201@nobugconsulting.ro> On 08/04/2007 02:03 AM, Florin Andrei wrote: > Can't edit the Wiki. > > Please add ucarp to the wish list. > Florin, why don't you bug directly matthias (at rpmforge) ? From pertusus at free.fr Sun Aug 5 17:10:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 5 Aug 2007 19:10:44 +0200 Subject: relations with other repos in practice Message-ID: <20070805171044.GA4861@free.fr> Hello, I am about to import most of my packages in EPEL. Some are in other repos (dag, dries). For the packages I have looked at (acpitool, gnochm), there is no specific need for coordination (no different name, split...). I can contact the people maintaining the packages in other repos, but do youhave an idea on what should be coordinated? One thing I see is the release. It seems to me that the repos should play nice and avoid updating over other repo packages. So maybe we could have rules like avoid upgrading dag repo by making sure that the release in epel is lower? Any idea about this issue, and any idea about other area where coordination is needed? What is the status of the agreement betwen repos? -- Pat From mmcgrath at redhat.com Sun Aug 5 17:23:34 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 05 Aug 2007 12:23:34 -0500 Subject: relations with other repos in practice In-Reply-To: <20070805171044.GA4861@free.fr> References: <20070805171044.GA4861@free.fr> Message-ID: <46B60796.40108@redhat.com> Patrice Dumas wrote: > Hello, > > I am about to import most of my packages in EPEL. Some are in other > repos (dag, dries). For the packages I have looked at (acpitool, > gnochm), there is no specific need for coordination (no different name, > split...). I can contact the people maintaining the packages in other > repos, but do youhave an idea on what should be coordinated? One thing I > see is the release. It seems to me that the repos should play nice and > avoid updating over other repo packages. So maybe we could have rules > like avoid upgrading dag repo by making sure that the release in epel is > lower? Any idea about this issue, and any idea about other area where > coordination is needed? > > What is the status of the agreement betwen repos? > Please see the mailing list history, there is already a great deal of discussion on this topic. There are quite a few repos out there (dag is just one of them). -Mike From pertusus at free.fr Sun Aug 5 17:56:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 5 Aug 2007 19:56:15 +0200 Subject: relations with other repos in practice In-Reply-To: <46B60796.40108@redhat.com> References: <20070805171044.GA4861@free.fr> <46B60796.40108@redhat.com> Message-ID: <20070805175615.GB4861@free.fr> On Sun, Aug 05, 2007 at 12:23:34PM -0500, Mike McGrath wrote: > Patrice Dumas wrote: >> Hello, >> > > Please see the mailing list history, there is already a great deal of > discussion on this topic. There are quite a few repos out there (dag is > just one of them). I remember reading the posts, but I don't remember anything practical being said, especially that responds to my questions. I used dag as a fictitious example. Another question (quite unrelated), is there a place where the repos are listed? -- Pat From florin at andrei.myip.org Sun Aug 5 22:08:46 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 05 Aug 2007 15:08:46 -0700 Subject: add to wish list: ucarp In-Reply-To: <46B49F35.2090201@nobugconsulting.ro> References: <46B3B450.1070606@andrei.myip.org> <46B49F35.2090201@nobugconsulting.ro> Message-ID: <46B64A6E.40200@andrei.myip.org> Manuel Wolfshant wrote: > On 08/04/2007 02:03 AM, Florin Andrei wrote: >> Can't edit the Wiki. >> >> Please add ucarp to the wish list. >> > Florin, why don't you bug directly matthias (at rpmforge) ? Actually, I did. :-) -- Florin Andrei http://florin.myip.org/ From sundaram at fedoraproject.org Sun Aug 5 23:18:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 06 Aug 2007 04:48:52 +0530 Subject: relations with other repos in practice In-Reply-To: <20070805175615.GB4861@free.fr> References: <20070805171044.GA4861@free.fr> <46B60796.40108@redhat.com> <20070805175615.GB4861@free.fr> Message-ID: <46B65ADC.3000900@fedoraproject.org> Patrice Dumas wrote: > I remember reading the posts, but I don't remember anything practical > being said, especially that responds to my questions. I used dag as a > fictitious example. I don't think anything was decided upon along those lines you were asking for. Tim wrote up a draft for a high level agreement and I made some changes he seemed to be unhappy with. http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration You can find the original draft in a previous revision. I haven't had time to followup through FESCo or other repository maintainers yet though Rex Dieter did add a acknowledgment. If they find this or the previous draft useful, we can push through this. If other repository maintainers are watching the discussions, do provide some feedback. > Another question (quite unrelated), is there a place where the > repos are listed? We generally avoid pointing to third party repositories to avoid any potential legal risks. EPEL FAQ mentions centos.karan.org (in a positive way) since it is a simple rebuild of Fedora Extras and would only contain patent encumbered Free and open source software just like Fedora. Rahul From sheltren at cs.ucsb.edu Mon Aug 6 14:04:32 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 6 Aug 2007 07:04:32 -0700 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <46AA13EB.6050609@redhat.com> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> Message-ID: <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote: > > I haven't looked at these packages yet, but I'm really glad to see > this work being done. I mentioned this on #epel a few days ago -- > lots of folks will be looking for yum to be there. > > The selfish reason for me to want it is that Cobbler (http:// > cobbler.et.redhat.com) uses it for repository management and is > otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not > so selfish reason is tons of RHEL4 users are already using yum for > various things (including maintaining their own repositories of > lots of stuff, including, sometimes, updates) and it would be nice > if they could get their yum from EPEL and use yum with EPEL if they > wanted. > > Thanks! > > --Michael DeHaan During the EPEL meeting on July 25 -- log here: https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html There was some discussion about problems including yum in EPEL. The first issue was that these packages don't mess up CentOS users. Since these packages all have a lower release than those found in CentOS, that should not be a problem since they should never get installed in the first place. The second issue was that RHEL 4 users can't use yum for system updates. Do we need to provide a wiki page explaining to RHEL users that yum is available only to fill dependencies and shouldn't be used directly? What are people's thoughts on this -- especially those that use RHEL? Is it confusing to have yum if RHEL can't use it to do system updates? I'd like to get this discussed here on the list so that we can make a decision about it at the next EPEL meeting if needed. Thanks, Jeff From dag at wieers.com Mon Aug 6 14:21:56 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 6 Aug 2007 16:21:56 +0200 (CEST) Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> Message-ID: On Mon, 6 Aug 2007, Jeff Sheltren wrote: > On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote: > > >I haven't looked at these packages yet, but I'm really glad to see this work > >being done. I mentioned this on #epel a few days ago -- lots of folks will be > >looking for yum to be there. > > > >The selfish reason for me to want it is that Cobbler > >(http://cobbler.et.redhat.com) uses it for repository management and is > >otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish > >reason is tons of RHEL4 users are already using yum for various things > >(including maintaining their own repositories of lots of stuff, including, > >sometimes, updates) and it would be nice if they could get their yum from > >EPEL and use yum with EPEL if they wanted. > > The second issue was that RHEL 4 users can't use yum for system updates. Do > we need to provide a wiki page explaining to RHEL users that yum is available > only to fill dependencies and shouldn't be used directly? What are people's > thoughts on this -- especially those that use RHEL? Is it confusing to have > yum if RHEL can't use it to do system updates? They can, with a tool called mrepo. mrepo can mirror repositories and RHN channels and provide update packages for different RHEL versions, channels and archs to an internal network (or the local system). For a single system this may be overkill (wrt. harddisk space) but for a small network of RHEL (or CentOS) systems, the ability to mirror, manage and browse repositories is a joy. Besides, in no production environment do you want to enable a repository like RPMforge or EPEL (or even RHEL) without first testing these packages. So you need a way to move packages from a mirrored repository to a staging/testing/production repository on a case to case basis. mrepo allows you to do that with little configuration. You can find mrepo at: http://dag.wieers.com/home-made/mrepo/ (there is work underway to also support NLD/SLES automatically, which is currently only mildly supported or requires manual steps) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From rob.myers at gtri.gatech.edu Mon Aug 6 14:52:02 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 06 Aug 2007 10:52:02 -0400 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> Message-ID: <1186411922.21438.49.camel@rxm-581b.stl.gtri.gatech.edu> On Mon, 2007-08-06 at 16:21 +0200, Dag Wieers wrote: > On Mon, 6 Aug 2007, Jeff Sheltren wrote: > > > On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote: > > > > >I haven't looked at these packages yet, but I'm really glad to see this work > > >being done. I mentioned this on #epel a few days ago -- lots of folks will be > > >looking for yum to be there. > > > > > >The selfish reason for me to want it is that Cobbler > > >(http://cobbler.et.redhat.com) uses it for repository management and is > > >otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish > > >reason is tons of RHEL4 users are already using yum for various things > > >(including maintaining their own repositories of lots of stuff, including, > > >sometimes, updates) and it would be nice if they could get their yum from > > >EPEL and use yum with EPEL if they wanted. > > > > The second issue was that RHEL 4 users can't use yum for system updates. Do > > we need to provide a wiki page explaining to RHEL users that yum is available > > only to fill dependencies and shouldn't be used directly? What are people's > > thoughts on this -- especially those that use RHEL? Is it confusing to have > > yum if RHEL can't use it to do system updates? > > They can, with a tool called mrepo. mrepo can mirror repositories and RHN > channels and provide update packages for different RHEL versions, channels > and archs to an internal network (or the local system). They can, and they do. We currently use mrepo to mirror RHEL4 and RHEL5 repositories of interest from our campus RHN satellite server. We use yum to pull in our local, home-grown repos, as well as the RHN updates. Furthermore, up2date seems to coexist just fine with yum. rob. From fedora at leemhuis.info Mon Aug 6 15:10:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Aug 2007 17:10:50 +0200 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> Message-ID: <46B739FA.8040405@leemhuis.info> On 06.08.2007 16:04, Jeff Sheltren wrote: > On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote: >> I haven't looked at these packages yet, but I'm really glad to see >> this work being done. I mentioned this on #epel a few days ago -- >> lots of folks will be looking for yum to be there. >> >> The selfish reason for me to want it is that Cobbler (http:// >> cobbler.et.redhat.com) uses it for repository management and is >> otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not >> so selfish reason is tons of RHEL4 users are already using yum for >> various things (including maintaining their own repositories of >> lots of stuff, including, sometimes, updates) and it would be nice >> if they could get their yum from EPEL and use yum with EPEL if they >> wanted. > > During the EPEL meeting on July 25 -- log here: > https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html > There was some discussion about problems including yum in EPEL. > > The first issue was that these packages don't mess up CentOS users. > Since these packages all have a lower release than those found in > CentOS, that should not be a problem since they should never get > installed in the first place. +1 > The second issue was that RHEL 4 users can't use yum for system > updates. Or install packages from EPEL that require deps from RHEL4, as long as they don't set up their own RHEL-repo (see the other mails from dag on this topic). > Do we need to provide a wiki page explaining to RHEL users > that yum is available only to fill dependencies and shouldn't be used > directly? What are people's thoughts on this -- especially those > that use RHEL? Is it confusing to have yum if RHEL can't use it to > do system updates? My preferred solution: add a patch that makes yum *on RHEL only* display a warning like "you should use up2date on RHEL4 to install packages from EPEL or update RHEL itself" and add a config option to disabled that warning for those that use mrepo to set up a RHEL-updates repo. > I'd like to get this discussed here on the list List is preferred for such discussions, as it's IMHO to time consuming to discuss all details in a IRC meeting if they havened been discussed on the list yet -- if they have and no consensus could be found then it's in my experience easier to come to an agreement in a IRC meeting. > so that we can make a > decision about it at the next EPEL meeting if needed. +1 -- it's still on the schedule. Cu knurd From fedora at leemhuis.info Mon Aug 6 15:27:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Aug 2007 17:27:36 +0200 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <200708011159.41594.dennis@ausil.us> References: <4687C867.8060400@leemhuis.info> <200708011135.41391.dennis@ausil.us> <200708011148.02827.dennis@ausil.us> <200708011159.41594.dennis@ausil.us> Message-ID: <46B73DE8.2030208@leemhuis.info> On 01.08.2007 18:59, Dennis Gilmore wrote: > On Wednesday 01 August 2007 11:48:02 am Dennis Gilmore wrote: >> On Wednesday 01 August 2007 11:35:41 am Dennis Gilmore wrote: >>> If the Fedora maintainer later decides to participate in EPEL, Then both >>> people will become co-maintainers for EPEL. (Of course it can be >>> extended to Fedora) >> co-maintainership can be extended to Fedora also. > > Just to make it full and clear > > If an EPEL maintainer wants to get a Fedora package into EPEL, > first check the ContributorStatus document, located in the wiki at > http://fedoraproject.org/wiki/EPEL/ContributorStatus . > > If the Fedora maintainer of the package has indicated a desire not to > participate in EPEL then the proposed EPEL maintainer can request the branch > directly via the standard procedures (e.g. via bugzilla currently). The > proposed EPEL maintainer should CC the Fedora maintainer on the branch > request, so the Fedora maintainer knows that the package is maintained in > EPEL as well. > > If it is unclear if the Fedora maintainer of the package intends to > participate in EPEL then the proposed EPEL maintainer should mail the Fedora > maintainer s/maintainer/& or open a bug/ > and ask about their plans for EPEL in general and the package at > hand. If there is no answer within seven days the proposed EPEL maintainer > is free to request the EPEL branch and become the EPEL Maintainer (CC the > Fedora maintainer here as well). If the Fedora maintainer decides not to be > active in EPEL they should be added to the CC list for all bugs so that > collaboration can happen where a bug effects Fedora and EPEL. Up to here (with or without the addition from above): +1 > If the Fedora maintainer later decides to participate in EPEL, Then both > people will become co-maintainers for EPEL. (Of course co-maintainership can > be extended to Fedora) If I understand the last para correctly we have two maintainers one the same level -- e.g. no primary per-release maintainer? That's not in line with the co-maintainership policy, which makes sure there is always one person as per-release primary maintainer which is responsible in the end for the packages (and has the last word in case of disputes). I prefer such a scheme, because two people co-maintaining a package in the end could quickly lead to situation where each other thought the other one will take care of the package. So: -1 for this. I'm all for something like that as last para: If the Fedora maintainer later decides to participate in EPEL, then he and the EPEL maintainer should discuss which one takes care of the package. One should become primary per release maintainer, which is kind of responsible for the package in that release; the other should become co-maintainer; how those two share the work is up to them. CU thl From fedora at leemhuis.info Mon Aug 6 15:55:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Aug 2007 17:55:02 +0200 Subject: relations with other repos in practice In-Reply-To: <20070805171044.GA4861@free.fr> References: <20070805171044.GA4861@free.fr> Message-ID: <46B74456.2020807@leemhuis.info> On 05.08.2007 19:10, Patrice Dumas wrote: > > I am about to import most of my packages in EPEL. Some are in other > repos (dag, dries). For the packages I have looked at (acpitool, > gnochm), there is no specific need for coordination (no different name, > split...). I can contact the people maintaining the packages in other > repos, but do youhave an idea on what should be coordinated? In such a case where names, spits are similar and as long as there are no reports from users about broken deps it can't hurt to contact the maintainers of other repos to exchange patches, discuss bugs or stuff like that if there is a need to. > One thing I > see is the release. It seems to me that the repos should play nice and > avoid updating over other repo packages. So maybe we could have rules > like avoid upgrading dag repo by making sure that the release in epel is > lower? I don't think that's possible. Different repos follow different ideas and different update strategies -- such rules would be problematic and hindering for everyone afaics. > [...] CU knurd From tcallawa at redhat.com Mon Aug 6 17:27:01 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 06 Aug 2007 13:27:01 -0400 Subject: el-5 builds failing? Message-ID: <1186421221.3839.27.camel@dhcp67.install.boston.redhat.com> http://buildsys.fedoraproject.org/logs/fedora-5-epel/35485-xsupplicant-1.2.8-3.el5/ppc/job.log Are the EL-5 builders ok? I'm getting the above failure when I try to build. EL-4 works fine. ~spot From mastahnke at gmail.com Mon Aug 6 19:01:44 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 6 Aug 2007 14:01:44 -0500 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <46B739FA.8040405@leemhuis.info> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> Message-ID: <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> Creating a repo for users of RHEL is a great solution that allows for YUM usage on RHEL, however it doesn't solve the exact problem with the package of YUM on RHEL. The issue is the package itself. EPEL has no way of shipping a 100% working version of YUM on RHEL 4. So, I still say we place something in yum.conf to let the RHEL user know that YUM won't "just work" until they help it out some. stahnma From pertusus at free.fr Mon Aug 6 20:43:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 6 Aug 2007 22:43:48 +0200 Subject: relations with other repos in practice In-Reply-To: <46B74456.2020807@leemhuis.info> References: <20070805171044.GA4861@free.fr> <46B74456.2020807@leemhuis.info> Message-ID: <20070806204348.GA2936@free.fr> On Mon, Aug 06, 2007 at 05:55:02PM +0200, Thorsten Leemhuis wrote: > On 05.08.2007 19:10, Patrice Dumas wrote: > > > > I am about to import most of my packages in EPEL. Some are in other > > repos (dag, dries). For the packages I have looked at (acpitool, > > gnochm), there is no specific need for coordination (no different name, > > split...). I can contact the people maintaining the packages in other > > repos, but do youhave an idea on what should be coordinated? > > In such a case where names, spits are similar and as long as there are > no reports from users about broken deps it can't hurt to contact the > maintainers of other repos to exchange patches, discuss bugs or stuff > like that if there is a need to. Ok, that I could do, but currently there are no such needs. Names and split are the same, no specific bugs or the like, so there is nothing specific to discuss with other repos except for coordination. I could just say, 'hey I will maintain that package in EPEL', but is it really coordination? in http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration there is: * Contributors need to make an effort to check if there are packages in third party repositories that would conflict with any new packages submitted to the official repository and if so establish contact with the maintainers of packages in other third party repositories. So it seems that the contact is asked for for contributors who want to coordinate with other repos, but I don't understand what it practically means in term of coordination. Once again if it is just 'hey I will maintain that package in EPEL', this just seems to be a waste of time if there is nothing more to propose to other repos for collaboration. (Of course when there are technical issues, it always pays to speak with other repo maintainers, but that's a completly different issue). > > One thing I > > see is the release. It seems to me that the repos should play nice and > > avoid updating over other repo packages. So maybe we could have rules > > like avoid upgrading dag repo by making sure that the release in epel is > > lower? > > I don't think that's possible. Different repos follow different ideas > and different update strategies -- such rules would be problematic and > hindering for everyone afaics. If repos upgrades each other is it still possible to speak about coordination/colaboration? As I stated several times before, EPEL can either try to collaborate with other repos or try to absorb them, I personally don't mind that much. But this should be consistently done. If there is no policy for collaboration, we shouldn't say that we are collaborating. -- Pat From opensource at till.name Mon Aug 6 21:53:59 2007 From: opensource at till.name (Till Maas) Date: Mon, 06 Aug 2007 23:53:59 +0200 Subject: relations with other repos in practice In-Reply-To: <20070805175615.GB4861@free.fr> References: <20070805171044.GA4861@free.fr> <46B60796.40108@redhat.com> <20070805175615.GB4861@free.fr> Message-ID: <200708062354.05483.opensource@till.name> On So August 5 2007, Patrice Dumas wrote: > Another question (quite unrelated), is there a place where the > repos are listed? Some repos are listed in the CentOS wiki: http://wiki.centos.org/Repositories Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lists at timj.co.uk Tue Aug 7 15:18:54 2007 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 07 Aug 2007 16:18:54 +0100 Subject: relations with other repos in practice In-Reply-To: <20070806204348.GA2936@free.fr> References: <20070805171044.GA4861@free.fr> <46B74456.2020807@leemhuis.info> <20070806204348.GA2936@free.fr> Message-ID: <46B88D5E.6090208@timj.co.uk> Patrice Dumas wrote: > in > http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration > there is: > > * Contributors need to make an effort to check if there are packages in > third party repositories that would conflict with any new packages > submitted to the official repository and if so establish contact with > the maintainers of packages in other third party repositories. That document was just a suggestion. Despite my efforts, there doesn't seem to be any particularly strong enthusiasm to make it something that is formally signed up to by anyone. I see that KDE-RedHat have indicated their interest which is cool, but it's not been ratified by anyone at the RHEL end, and the doc could do with reverting to a former version which is "neutral" and actually makes sense for everyone to sign up to (vs just EPEL) That's not to say it mightn't form the base of some "good practice" guidelines though, I suppose... Tim From lists at timj.co.uk Tue Aug 7 15:32:33 2007 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 07 Aug 2007 16:32:33 +0100 Subject: relations with other repos in practice In-Reply-To: <46B88D5E.6090208@timj.co.uk> References: <20070805171044.GA4861@free.fr> <46B74456.2020807@leemhuis.info> <20070806204348.GA2936@free.fr> <46B88D5E.6090208@timj.co.uk> Message-ID: <46B89091.8080508@timj.co.uk> I wrote: > That document was just a suggestion. Despite my efforts, there doesn't > seem to be any particularly strong enthusiasm to make it something that > is formally signed up to by anyone. I see that KDE-RedHat have indicated > their interest which is cool, but it's not been ratified by anyone at > the RHEL end, and the doc could do with reverting to a former version ^^^^ EPEL Tim From sheltren at cs.ucsb.edu Tue Aug 7 17:07:38 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 7 Aug 2007 10:07:38 -0700 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> Message-ID: <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> On Aug 6, 2007, at 12:01 PM, Michael Stahnke wrote: > > The issue is the package itself. EPEL has no way of shipping a 100% > working version of YUM on RHEL 4. So, I still say we place something > in yum.conf to let the RHEL user know that YUM won't "just work" until > they help it out some. I'm pretty happy with doing something like this. Of course, it'll be pretty clear that it doesn't work when they try to use it and it doesn't work ;) Maybe a small blurb on the wiki explaining yum within EPEL would help as well? -Jeff From sundaram at fedoraproject.org Tue Aug 7 17:10:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 07 Aug 2007 22:40:26 +0530 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> Message-ID: <46B8A782.3040700@fedoraproject.org> Jeff Sheltren wrote: > On Aug 6, 2007, at 12:01 PM, Michael Stahnke wrote: >> >> The issue is the package itself. EPEL has no way of shipping a 100% >> working version of YUM on RHEL 4. So, I still say we place something >> in yum.conf to let the RHEL user know that YUM won't "just work" until >> they help it out some. > > I'm pretty happy with doing something like this. Of course, it'll be > pretty clear that it doesn't work when they try to use it and it doesn't > work ;) Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if that works? Rahul From mastahnke at gmail.com Tue Aug 7 21:05:09 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 7 Aug 2007 16:05:09 -0500 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <46B8A782.3040700@fedoraproject.org> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> <46B8A782.3040700@fedoraproject.org> Message-ID: <7874d9dd0708071405h7426625bnbd43b7c18e863b49@mail.gmail.com> > Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if > that works? I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is still having a few growing pains, but it's getting better. That configuration is handled more via the plugin and RHN bootstrap than by anything EPEL is currently able to provide. stahnma From sundaram at fedoraproject.org Tue Aug 7 21:30:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 03:00:06 +0530 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <7874d9dd0708071405h7426625bnbd43b7c18e863b49@mail.gmail.com> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> <46B8A782.3040700@fedoraproject.org> <7874d9dd0708071405h7426625bnbd43b7c18e863b49@mail.gmail.com> Message-ID: <46B8E45E.2000009@fedoraproject.org> Michael Stahnke wrote: >> Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if >> that works? > > I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is > still having a few growing pains, but it's getting better. That > configuration is handled more via the plugin and RHN bootstrap than by > anything EPEL is currently able to provide. The point is that if you are pushing yum into EPEL and yum RHN plugin works in EPEL 4, you can as well as take it from RHEL 5 and push the plugin to the EPEL 4 branch and things will work more out of the box. Rahul From mastahnke at gmail.com Tue Aug 7 22:45:57 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 7 Aug 2007 17:45:57 -0500 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <46B8E45E.2000009@fedoraproject.org> References: <20070707140041.GF3144@free.fr> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> <46B8A782.3040700@fedoraproject.org> <7874d9dd0708071405h7426625bnbd43b7c18e863b49@mail.gmail.com> <46B8E45E.2000009@fedoraproject.org> Message-ID: <7874d9dd0708071545sf4bd71cx8d242a2006b4be55@mail.gmail.com> On 8/7/07, Rahul Sundaram wrote: > Michael Stahnke wrote: > >> Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if > >> that works? > > > > I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is > > still having a few growing pains, but it's getting better. That > > configuration is handled more via the plugin and RHN bootstrap than by > > anything EPEL is currently able to provide. > > The point is that if you are pushing yum into EPEL and yum RHN plugin > works in EPEL 4, you can as well as take it from RHEL 5 and push the > plugin to the EPEL 4 branch and things will work more out of the box. What RHN server do propose we register them with? > > Rahul > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From sundaram at fedoraproject.org Tue Aug 7 23:02:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 04:32:10 +0530 Subject: Yum in EPEL [Was: packages that conflict with centos?] In-Reply-To: <7874d9dd0708071545sf4bd71cx8d242a2006b4be55@mail.gmail.com> References: <20070707140041.GF3144@free.fr> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> <46AA13EB.6050609@redhat.com> <67B76CD0-86BA-4152-BB79-4FD05C17CA38@cs.ucsb.edu> <46B739FA.8040405@leemhuis.info> <7874d9dd0708061201o284632e3t162f38f38ba02ecc@mail.gmail.com> <774D6B67-BD5F-4B36-8CC4-F4CB36CAB34B@cs.ucsb.edu> <46B8A782.3040700@fedoraproject.org> <7874d9dd0708071405h7426625bnbd43b7c18e863b49@mail.gmail.com> <46B8E45E.2000009@fedoraproject.org> <7874d9dd0708071545sf4bd71cx8d242a2006b4be55@mail.gmail.com> Message-ID: <46B8F9F2.7060501@fedoraproject.org> Michael Stahnke wrote: > On 8/7/07, Rahul Sundaram wrote: >> Michael Stahnke wrote: >>>> Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if >>>> that works? >>> I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is >>> still having a few growing pains, but it's getting better. That >>> configuration is handled more via the plugin and RHN bootstrap than by >>> anything EPEL is currently able to provide. >> The point is that if you are pushing yum into EPEL and yum RHN plugin >> works in EPEL 4, you can as well as take it from RHEL 5 and push the >> plugin to the EPEL 4 branch and things will work more out of the box. > > What RHN server do propose we register them with? The existing RHEL ones. The idea behind is it that yum can then be used as a single tool for both RHEL base repository and EPEL. Rahul From fedora at leemhuis.info Wed Aug 8 16:30:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 08 Aug 2007 18:30:06 +0200 Subject: EPEL report week 31 2007 Message-ID: <46B9EF8E.1020108@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week31 (sorry, a bit late this time; was quite busy at work and a family visit) = Weekly EPEL Summary = Week 31/2007 == Most important happenings == * Noting major == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * nirik (KevinFenzi) (vacation) * mmcgrath (MikeMcGrath) * quaid (KarstenWade) Missing from the Steering Committee: * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * stahnma (MichaelStahnke) Others that participated the meeting: warren, rsc === Summary === * what did everyone think of how things have gone since the announcement? * we probably should have a link on the front page of fp.o and fp.o/wiki; or perhaps a epel.fedoraproject.org cname? * some discussions about collecting and publishing statistics * branch for EPEL if Fedora maintainer does not react * more discussions on the list * new push scripts for pushing to testing, adjust mock configs to use * dgilmore will take care of it * security will need manual handling; nirik is willing to help * EPEL announcement happened -- what next? * nirik> | more packages, more maintainers, more users. ;) * nirik> | if we could move to koji at some point and bodhi that would be good... dgilmore> | needs to be done but requires coders * dgilmore> | does anyone have ideas on how to get more packages in EPEL? nirik> | I have some more I am going to do, but haven't had time... hopefully soon I will get munin in and possibly will look at Xfce (matching the centos extra versions so we don't conflict if possible) === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00014.html == Stats == === General === Number of EPEL Contributors 6 We welcome 6 new contributors: chris_AT_chrisgrau.com james.antill_AT_redhat.com jhrozek_AT_redhat.com mccann0011_AT_hotmail.com smilner_AT_redhat.com tmraz_AT_redhat.com === EPEL 5 === Number of source packages: 510 Number of binary packages: 938 There are 26 new Packages: * bacula | Cross platform network backup for Linux, Unix, Mac and Windows * cairomm | Cairomm is the C++ API for the cairo graphics library * cfitsio | Library for manipulating FITS data files * fping | Scriptable, parallelized ping-like utility * freetds | Implementation of the TDS (Tabular DataStream) protocol * gtkmm24 | C++ interface for GTK2 (a GUI library for X) * irssi | Modular text mode IRC client with Perl scripting * iverilog | Icarus Verilog is a verilog compiler and simulator * nail | Enhanced implementation of the mailx command * net6 | A TCP protocol abstraction for library C++ * obby | A library which provides synced document buffers * octave | A high-level language for numerical computations * perl-AnyData | Easy access to data in many formats * perl-Apache-LogRegex | Parse a line from an Apache logfile into a hash * perl-Cache-Mmap | Shared data cache using memory mapped files * perl-Class-Accessor | Automated accessor generation * perl-Class-Data-Inheritable | Inheritable, overridable class data * perl-Clone | Recursively copy perl datatypes * perl-CPAN-DistnameInfo | CPAN::DistnameInfo Perl module * perl-MIME-Types | MIME types module for Perl * perl-Module-CoreList | Perl core modules indexed by perl versions * perl-Test-Tester | Ease testing test modules built with Test::Builder * perl-UNIVERSAL-require | Require() modules from a variable * perl-XML-XPath | XPath parser and evaluator for Perl * timidity++ | A software wavetable MIDI synthesizer. * wxGTK | GTK2 port of the wxWidgets GUI library === EPEL 4 === Number of source packages: 313 Number of binary packages: 621 There are 18 new Packages: * cfitsio | Library for manipulating FITS data files * fping | Scriptable, parallelized ping-like utility * freetds | Implementation of the TDS (Tabular DataStream) protocol * irssi | Modular text mode IRC client with Perl scripting * iverilog | Icarus Verilog is a verilog compiler and simulator * nail | Enhanced implementation of the mailx command * perl-AnyData | Easy access to data in many formats * perl-Apache-LogRegex | Parse a line from an Apache logfile into a hash * perl-Cache-Mmap | Shared data cache using memory mapped files * perl-Class-Accessor | Automated accessor generation * perl-Class-Data-Inheritable | Inheritable, overridable class data * perl-Clone | Recursively copy perl datatypes * perl-CPAN-DistnameInfo | CPAN::DistnameInfo Perl module * perl-Test-Tester | Ease testing test modules built with Test::Builder * perl-UNIVERSAL-require | Require() modules from a variable * perl-XML-XPath | XPath parser and evaluator for Perl * svnmailer | Tool to post subversion repository commit information * timidity++ | A software wavetable MIDI synthesizer. ---- ["CategoryEPELReports"] From fedora at leemhuis.info Wed Aug 8 16:36:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 08 Aug 2007 18:36:41 +0200 Subject: Plan for todays (20070808) EPEL SIG meeting Message-ID: <46B9F119.5080108@leemhuis.info> (late as well; sorry) Hi all, find below the list of topics that are planed to come up in the next EPEL SIG meeting which is scheduled for today, Wednesday at 17:00 UTC in #fedora-meeting on irc.freenode.org. /topic EPEL Meeting|EPEL announcement happened -- are we satisfied with how everything worked out? /topic EPEL Meeting|branch for EPEL if Fedora maintainer does not react -- dgilmore /topic EPEL Meeting|new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore /topic EPEL Meeting|yum for EPEL4 -- Jeff_S /topic EPEL Meeting|new meeting time? -- all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU knurd From fedora at leemhuis.info Wed Aug 8 17:28:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 08 Aug 2007 19:28:11 +0200 Subject: Log from todays (200700808) EPEL SIG Meeting Message-ID: <46B9FD2B.2000202@leemhuis.info> 00:00:16 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:16 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:22 < mmcgrath> | pong 00:01:00 * | dgilmore is here 00:01:01 < knurd> | quaid is traveling 00:01:05 --> | frozty_sa (frozt01100101) has joined #fedora-meeting 00:01:38 < knurd> | hmmm 00:01:40 < knurd> | that's not much 00:01:50 < knurd> | we maybe should do more stuff on the list 00:01:56 < knurd> | and less in the meeting 00:02:08 < mmcgrath> | or move meetings to every other week? 00:02:22 < knurd> | seems we don't get all hte importatn or interested people into the meeting 00:02:44 < knurd> | so maybe doing them only every two week and instead finish some stuff on the list might be easier for everyone 00:02:49 < knurd> | just a thought 00:02:52 < knurd> | mmcgrath, yeah 00:03:21 * | dgilmore like fortnightly meetings 00:03:57 --> | silug (S. Ill. Linux UG - http://www.silug.org/) has joined #fedora-meeting 00:04:11 < knurd> | and mailing lists don't have timezone-problems ;-) 00:04:25 < knurd> | I'll think about it some more and write to the list about it 00:04:25 < mmcgrath> | Thats true 00:04:53 < knurd> | anyway, let's do a quick meeting even with three people from the steering committee 00:05:01 --- | knurd has changed the topic to: EPEL Meeting|new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore 00:05:08 < knurd> | dgilmore, and progress? 00:06:08 < dgilmore> | knurd: not had a chance yet. i need pinging on it one night 00:06:09 --> | alexxed (purple) has joined #fedora-meeting 00:06:24 < dgilmore> | right now im concentrating on enabling secondary archs 00:06:32 < knurd> | dgilmore, I#d offer to help, but I don#t really know how things are working together 00:06:41 --> | sereinity_ (Sereinity) has joined #fedora-meeting 00:06:55 < dgilmore> | knurd: it should take about 30 mins or so work. 00:06:57 < knurd> | but I could update the builders if that is any help (and if I have access to the config files) 00:07:06 < dgilmore> | mostly i need reminding when i can do the work 00:07:08 <-- | sereinity has quit (Read error: 110 (Connection timed out)) 00:07:27 < dgilmore> | i cant do it during the day here 00:07:28 < knurd> | dgilmore, shall I ping you one every two days? 00:07:42 --- | sereinity_ is now known as sereinity 00:07:45 < knurd> | (no, I don#t take that serious) 00:07:52 < dgilmore> | knurd: if you can ping me first thing in the morning there would help 00:08:01 < knurd> | dgilmore, k, I'll try 00:08:03 < mmcgrath> | :) 00:08:07 < knurd> | dgilmore, thx for your help 00:08:38 < knurd> | mmcgrath, dgilmore, do we want to discuss "yum in EPEL4" or "branch for EPEL if Fedora maintainer does not react"? 00:09:07 < knurd> | or anything else? 00:09:21 --> | XulChris (Christopher Stone) has joined #fedora-meeting 00:09:41 < dgilmore> | knurd: we agreed on the Branch for EPEL issue last week 00:10:02 < knurd> | ohh, we did? 00:10:08 < dgilmore> | yum i think we should put it in make sure its less than CentOS version and not ship a yum.conf file 00:10:09 < knurd> | I thought the plan was to continue on the list 00:10:24 < knurd> | dgilmore and I raised some concerns 00:10:27 < dgilmore> | knurd: no we agreed to what i posted and what is in the wiki 00:10:36 < dgilmore> | with a revisit if we need to 00:10:44 < mmcgrath> | I think that was a miscommunication between the meeting and the list, I was under the impression it was settled as well. 00:10:47 < dgilmore> | knurd: i missed your concerns 00:11:02 < knurd> | dgilmore, send it to the list two days ago 00:11:24 < knurd> | dgilmore, well, take a look at it and tell me what you think 00:11:29 < knurd> | it's not that important 00:11:46 < knurd> | and can wait a bit more 00:11:55 < knurd> | so, shall we close the meeting for today? 00:12:15 < dgilmore> | knurd: sorry i wasnt clear the Fedora maintainer becomes comainter in EPEL 00:12:28 < dgilmore> | so the EPEL maintainer remains primary maintainer for EPEL 00:12:33 < knurd> | yeah, maybe I just got something wrong 00:12:41 < knurd> | ahh, okay; 00:13:05 < knurd> | was that just me beeing stupid or could/should the wording be improved? 00:13:12 < knurd> | if the latter: just do it 00:13:55 < dgilmore> | I assumed by Fedora Maintainer becomes Comaintainer that it was clear. 00:13:58 < knurd> | (no need to approve each and every detail in a meeting) 00:14:03 < dgilmore> | perhaps thats a language thing 00:14:07 < knurd> | dgilmore, I'll take another look 00:14:10 < knurd> | dgilmore, yeah, likely 00:14:13 < knurd> | anyway 00:14:18 * | knurd will close the meeting in 60 00:14:48 < knurd> | dgilmore, mmcgrath, I assume closing is fine for you? 00:14:51 * | knurd will close the meeting in 30 00:14:56 < dgilmore> | knurd: thats fine 00:15:02 < mmcgrath> | knurd: yeah, there's just not much going on that have decisions to be made I guess :) 00:15:10 < knurd> | yeah 00:15:13 * | knurd will close the meeting in 10 00:15:37 * | knurd will close the meeting in n 00:15:37 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:15:37 < knurd> | -- MARK -- Meeting end 00:15:41 --> | Jeff_S (Jeff) has joined #fedora-meeting 00:15:50 < mmcgrath> | buhahahah 00:15:58 < mmcgrath> | knurd: thanks for hosting the meeting 00:15:58 --- | knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule 00:16:06 < knurd> | dgilmore, mmcgrath thx 00:16:07 < mmcgrath> | Jeff_S: this amused me - 00:16:08 < Jeff_S> | grr 00:16:12 < mmcgrath> | 11:16 < knurd> -- MARK -- Meeting end 00:16:12 < mmcgrath> | 11:16 -!- Jeff_S has joined #fedora-meeting 00:16:13 < knurd> | mmcgrath, that was a quick one 00:16:17 --> | JSchmitt (Jochen Schmitt) has joined #fedora-meeting 00:16:19 < knurd> | hehe 00:16:23 < Jeff_S> | sorry guys, it's been a busy morning :( 00:16:25 < mmcgrath> | It was literally a second or two difference :) 00:16:27 < mmcgrath> | Jeff_S: no worries 00:16:36 < knurd> | Jeff_S, np 00:16:45 < knurd> | Jeff_S, we just discussed a bit to do more on the list 00:16:54 < Jeff_S> | ok 00:17:09 * | Jeff_S has very good or very bad timing depending on how you look at it ;) 00:17:09 < knurd> | dgilmore, mentioned "yum i think we should put it in make sure its less than CentOS version and not ship a yum.conf file" 00:17:27 < knurd> | Jeff_S, would that " not ship a yum.conf file" work? 00:18:15 < Jeff_S> | hmmm... maybe? :) I think that perhaps shipping it with an empty file with only a comment regarding "this is from EPEL, it won't work with RHEL unless you make some changes, blah blah" 00:18:31 < Jeff_S> | but we can discuss on list since I missed the meeting... 00:18:37 < knurd> | Jeff_S, could you just try so we know? 00:18:53 < Jeff_S> | well, I don't have any RHEL boxes, but I could try on centos 00:19:11 < knurd> | Jeff_S, should be good enough I'd say 00:19:13 < Jeff_S> | anyone have a RHEL box they would let me screw up? 00:19:35 * | knurd has no RHEL4 boxes 00:20:08 < Jeff_S> | no problem, I'll test it out on centos and see what happens From pertusus at free.fr Fri Aug 10 17:20:41 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 10 Aug 2007 19:20:41 +0200 Subject: openmotif in RHEL versus lesstif in fedora Message-ID: <20070810172041.GA32563@free.fr> Hello, There is a discrepancy between Fedora and RHEL, which is that there is lesstif in fedora and openmotif in RHEL. Is it temporary or will it be done the same in RHEL 6? -- Pat From dennis at ausil.us Fri Aug 10 18:48:52 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 10 Aug 2007 13:48:52 -0500 Subject: openmotif in RHEL versus lesstif in fedora In-Reply-To: <20070810172041.GA32563@free.fr> References: <20070810172041.GA32563@free.fr> Message-ID: <200708101348.52957.dennis@ausil.us> On Friday 10 August 2007 12:20:41 pm Patrice Dumas wrote: > Hello, > > There is a discrepancy between Fedora and RHEL, which is that there is > lesstif in fedora and openmotif in RHEL. Is it temporary or will it be > done the same in RHEL 6? openmotif is not licensed with an acceptable license for Fedora. what Red Hat Does for RHEL is up to Red Hat to decide. So to answer your question we will know what the status is when RHEL6 lands. Dennis From pertusus at free.fr Fri Aug 10 19:39:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 10 Aug 2007 21:39:01 +0200 Subject: openmotif in RHEL versus lesstif in fedora In-Reply-To: <200708101348.52957.dennis@ausil.us> References: <20070810172041.GA32563@free.fr> <200708101348.52957.dennis@ausil.us> Message-ID: <20070810193901.GC2745@free.fr> On Fri, Aug 10, 2007 at 01:48:52PM -0500, Dennis Gilmore wrote: > On Friday 10 August 2007 12:20:41 pm Patrice Dumas wrote: > > Hello, > > > > There is a discrepancy between Fedora and RHEL, which is that there is > > lesstif in fedora and openmotif in RHEL. Is it temporary or will it be > > done the same in RHEL 6? > > openmotif is not licensed with an acceptable license for Fedora. what Red Hat > Does for RHEL is up to Red Hat to decide. So to answer your question we will > know what the status is when RHEL6 lands. It would be nice to know before to be able to come up with something that helps packaging, if needed. If RHEL uses lesstif, then there is no need to do anything (in my opinion), if RHEL still uses openmotif, it may be nice to have virtual provides, so it would be interesting if Red Hat could communicate about that issue -- and better yet coordinate with people interested with motif in EPEL and Fedora (like me). And also (but it is quite unrelated) having openmotif used in RHEL may be a reason to bring back this issue in fedora. -- Pat From smooge at gmail.com Sat Aug 11 00:57:16 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 10 Aug 2007 18:57:16 -0600 Subject: openmotif in RHEL versus lesstif in fedora In-Reply-To: <20070810193901.GC2745@free.fr> References: <20070810172041.GA32563@free.fr> <200708101348.52957.dennis@ausil.us> <20070810193901.GC2745@free.fr> Message-ID: <80d7e4090708101757i1714e23eo34f8c58660f28581@mail.gmail.com> On 8/10/07, Patrice Dumas wrote: > On Fri, Aug 10, 2007 at 01:48:52PM -0500, Dennis Gilmore wrote: > > On Friday 10 August 2007 12:20:41 pm Patrice Dumas wrote: > > > Hello, > > > > > > There is a discrepancy between Fedora and RHEL, which is that there is > > > lesstif in fedora and openmotif in RHEL. Is it temporary or will it be > > > done the same in RHEL 6? > > > > openmotif is not licensed with an acceptable license for Fedora. what Red Hat > > Does for RHEL is up to Red Hat to decide. So to answer your question we will > > know what the status is when RHEL6 lands. > > It would be nice to know before to be able to come up with something > that helps packaging, if needed. If RHEL uses lesstif, then there is no > need to do anything (in my opinion), if RHEL still uses openmotif, it > may be nice to have virtual provides, so it would be interesting if Red > Hat could communicate about that issue -- and better yet coordinate with > people interested with motif in EPEL and Fedora (like me). > That would be best done on a list that has RHEL engineers and product managers on. Not sure if any of them are on here. It is usually something that I have seen done via customer interactiosn with sales/etc. versus mail lists. Also there isnt a discrepency in that Motif was in FC5, pre FC6 when RHEL-5 branched from Fedora. OpenMotif was dropped before FC6 I think when a license review was done about what met Fedora's license goals. > And also (but it is quite unrelated) having openmotif used in RHEL > may be a reason to bring back this issue in fedora. > I think the issue is dead in Fedora unless OpenMotif gets relicensed. More than likely if motif is shipped in EL-6 (maybe 1.5 years from now).. it would be done via what the paying customers have asked Red Hat to use. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Sat Aug 11 08:07:31 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 11 Aug 2007 10:07:31 +0200 Subject: openmotif in RHEL versus lesstif in fedora In-Reply-To: <80d7e4090708101757i1714e23eo34f8c58660f28581@mail.gmail.com> References: <20070810172041.GA32563@free.fr> <200708101348.52957.dennis@ausil.us> <20070810193901.GC2745@free.fr> <80d7e4090708101757i1714e23eo34f8c58660f28581@mail.gmail.com> Message-ID: <20070811080731.GA2674@free.fr> On Fri, Aug 10, 2007 at 06:57:16PM -0600, Stephen John Smoogen wrote: > > That would be best done on a list that has RHEL engineers and product > managers on. Not sure if any of them are on here. It is usually I hope so. EPEL is something they should definitely be interested in, not everyone of them, but at least some. And have seen quite a lot of posts that seemed to originate from people at Red Hat involved in RHEL. Maybe I am wrong, though. > something that I have seen done via customer interactiosn with > sales/etc. versus mail lists. EPEL is new, and hopefully will attract attention from RHEL people. > Also there isnt a discrepency in that Motif was in FC5, pre FC6 when > RHEL-5 branched from Fedora. OpenMotif was dropped before FC6 I think > when a license review was done about what met Fedora's license goals. Exactly. That's why I said that this discrepancy wasn't an issue as is, but since what is planned in RHEL 6 isn't clear to me, it may make > I think the issue is dead in Fedora unless OpenMotif gets relicensed. No, Fedora is open to change... Hopefully. This change wasn't consensual, openmotif could be considered more free than lesstif even though a clause renders it non free as defined by the OSI, this clause is about non interacting with proprietary software, so it may be seen as something that renders it even more radically free, something ala GPL vs BSD. I am not saying that it is my advice, but it is an exception that wouldn't hurt Fedora goals, accepting proprietary firmware is certainly (in my opinion) much more debatable. > More than likely if motif is shipped in EL-6 (maybe 1.5 years from > now).. it would be done via what the paying customers have asked Red > Hat to use. In that case it will likely be openmotif. But it would be nice to have somebody in charge to coordinate with/get informations from. -- Pat From tcallawa at redhat.com Mon Aug 13 02:08:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 12 Aug 2007 22:08:23 -0400 Subject: openmotif in RHEL versus lesstif in fedora In-Reply-To: <20070811080731.GA2674@free.fr> References: <20070810172041.GA32563@free.fr> <200708101348.52957.dennis@ausil.us> <20070810193901.GC2745@free.fr> <80d7e4090708101757i1714e23eo34f8c58660f28581@mail.gmail.com> <20070811080731.GA2674@free.fr> Message-ID: <1186970903.3997.13.camel@localhost.localdomain> On Sat, 2007-08-11 at 10:07 +0200, Patrice Dumas wrote: > > I think the issue is dead in Fedora unless OpenMotif gets relicensed. > > No, Fedora is open to change... Hopefully. This change wasn't > consensual, openmotif could be considered more free than lesstif even > though a clause renders it non free as defined by the OSI, this clause > is about non interacting with proprietary software, so it may be seen as > something that renders it even more radically free, something ala GPL vs > BSD. I am not saying that it is my advice, but it is an exception that > wouldn't hurt Fedora goals, accepting proprietary firmware is certainly > (in my opinion) much more debatable. The FSF considers OpenMotif non-free. OSI won't go near it, because it doesn't meet their criteria. Unless the "commercial" clause in the OpenMotif license is removed, its not going into Fedora. We've told the OpenMotif developers this, and they responded that they didn't care. If they relicense (or dual license), we'll happily revisit it. I'm not even going to try to predict RHEL 6, as I'm not involved in that process. ~spot From fedora at leemhuis.info Tue Aug 14 16:57:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Aug 2007 18:57:35 +0200 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <46B73DE8.2030208@leemhuis.info> References: <4687C867.8060400@leemhuis.info> <200708011135.41391.dennis@ausil.us> <200708011148.02827.dennis@ausil.us> <200708011159.41594.dennis@ausil.us> <46B73DE8.2030208@leemhuis.info> Message-ID: <46C1DEFF.7030800@leemhuis.info> On 06.08.2007 17:27, Thorsten Leemhuis wrote: > On 01.08.2007 18:59, Dennis Gilmore wrote: > [...] >> If the Fedora maintainer later decides to participate in EPEL, Then both >> people will become co-maintainers for EPEL. (Of course co-maintainership can >> be extended to Fedora) > > If I understand the last para correctly we have two maintainers one the > same level -- e.g. no primary per-release maintainer? That's not in line > with the co-maintainership policy, which makes sure there is always one > person as per-release primary maintainer which is responsible in the end > for the packages (and has the last word in case of disputes). I prefer > such a scheme, because two people co-maintaining a package in the end > could quickly lead to situation where each other thought the other one > will take care of the package. > > So: -1 for this. I'm all for something like that as last para: > > If the Fedora maintainer later decides to participate in EPEL, then he > and the EPEL maintainer should discuss which one takes care of the > package. One should become primary per release maintainer, which is kind > of responsible for the package in that release; the other should become > co-maintainer; how those two share the work is up to them. Ping -- I got no reactions on this. To let me rephrase: with the "Then both people will become co-maintainers for EPEL." it's afaics unclear who's the primary per-release maintainer and who's the co-maintainer in the end. That's not in line with the co-maintainership policy from Fedora, which requests there is a per-release (release=EPEL4 and EPEL5 in this case) maintainer. Cu knurd From fedora at leemhuis.info Tue Aug 14 17:03:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Aug 2007 19:03:47 +0200 Subject: EPEL report week 32 2007 Message-ID: <46C1E073.6030805@leemhuis.info> = Weekly EPEL Summary = Week 32/2007 == Most important happenings == * Noting major == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) (very late ;-) ) Missing from the Steering Committee: * quaid (KarstenWade) (traveling) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Others that participated the meeting: nobody === Summary === * meetings * some discussions around the format; some quotes: "we maybe should do more stuff on the list and less in the meeting" "move meetings to every other week?" "seems we don't get all the important or interested people into the meeting so maybe doing them only every two week and instead finish some stuff on the list might be easier for everyone. Discuss this on the list further * new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore * still on the todo-list * "branch for EPEL if Fedora maintainer does not react"? * some discussions if the wording is clear enough * yum for EPEL4 * Jeff_S will investigate if it's possible to ship yum without a yum.conf === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00062.html == Stats == Nothing new over the past days. ---- ["CategoryEPELReports"] From fedora at leemhuis.info Tue Aug 14 17:36:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Aug 2007 19:36:57 +0200 Subject: Meetings and mailiglists/decision finding process Message-ID: <46C1E839.4050002@leemhuis.info> Hi all! I'm wondering if we should optimize out decision finding and realizing process a bit. The weekly IRC meetings have some problems: - we often get only four or five people from the steering committee (sometimes only three) - sometimes there are periods where the meetings get stuck for one or two minutes because people often do other stuff in parallel - only rare attendance from non-steering committee members - the usual time-zone and real-life comes in between problems with IRC At the same time on the mailing lists - stuff gets discussed, but then often things seems to get stuck because everyone waits for the steering committee to make a decision; those are done in the meeting only (e.g. only once a week), and things then get stuck if no decision can be found easily or gets bumped between list and meetings - things get agreed on on the list and then suddenly out of the blue some steering committee member raises concerns in the meeting (but did not raise them on the list beforehand). That complicates things a lot, as explaining stuff ("I don't like foo bar and baz, but foobar, and want ...") in IRC often is boring for the others as they have to wait for the other to hack all that into the keyboard. All those (and likely some other stuff) slow EPEL down IMHO and are sometimes annoying. I'm wondering if we could improve the situation somehow with some changes, but I'm unsure myself how. Some ideas, from the top of my head: - only meet on IRC every second week - only meet on IRC all four week or when there is a need to - somehow accept stuff on the mailing lists if possible. Kind of "send a proposal, if some people give a "+1" on the list and no one objects from the SIG within some days consider it accepted". Sure, it's often not that easy and we needed to work out more details for such a scheme, but it could be or something into that direction. That way the SIG or EPEL contributors get more influence and we might need the Steering Committee only if a decision can't be found - weekly status mail from the owners of major tasks Other thoughts/idas? CU knurd From dennis at ausil.us Tue Aug 14 18:50:47 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 14 Aug 2007 13:50:47 -0500 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <46C1DEFF.7030800@leemhuis.info> References: <4687C867.8060400@leemhuis.info> <46B73DE8.2030208@leemhuis.info> <46C1DEFF.7030800@leemhuis.info> Message-ID: <200708141350.47545.dennis@ausil.us> On Tuesday 14 August 2007 11:57:35 am Thorsten Leemhuis wrote: > On 06.08.2007 17:27, Thorsten Leemhuis wrote: > > On 01.08.2007 18:59, Dennis Gilmore wrote: > > [...] > > > >> If the Fedora maintainer later decides to participate in EPEL, Then both > >> people will become co-maintainers for EPEL. (Of course > >> co-maintainership can be extended to Fedora) > > > > If I understand the last para correctly we have two maintainers one the > > same level -- e.g. no primary per-release maintainer? That's not in line > > with the co-maintainership policy, which makes sure there is always one > > person as per-release primary maintainer which is responsible in the end > > for the packages (and has the last word in case of disputes). I prefer > > such a scheme, because two people co-maintaining a package in the end > > could quickly lead to situation where each other thought the other one > > will take care of the package. > > > > So: -1 for this. I'm all for something like that as last para: > > > > If the Fedora maintainer later decides to participate in EPEL, then he > > and the EPEL maintainer should discuss which one takes care of the > > package. One should become primary per release maintainer, which is kind > > of responsible for the package in that release; the other should become > > co-maintainer; how those two share the work is up to them. > > Ping -- I got no reactions on this. > > To let me rephrase: with the "Then both people will become > co-maintainers for EPEL." it's afaics unclear who's the primary > per-release maintainer and who's the co-maintainer in the end. That's > not in line with the co-maintainership policy from Fedora, which > requests there is a per-release (release=EPEL4 and EPEL5 in this case) > maintainer. Sorry it was not clear to you. the Fedora maintainer will become the co-maintainer. they EPEL maintainer will remain primary. of course this can be switched if the maintainers agree. Dennis From buildsys at fedoraproject.org Wed Aug 15 02:40:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 14 Aug 2007 22:40:18 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-08-14 Message-ID: <20070815024018.9F536152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 77 NEW arj-3.10.22-3.el5 : Archiver for .arj files NEW audio-entropyd-1.0.0-4.el5.2 : Generate entropy from audio output NEW cabextract-1.1-5.el5 : Utility for extracting cabinet (.cab) archives cacti-0.8.6j-1.el5 NEW chmlib-0.39-3.el5 : Library for dealing with ITSS/CHM format files cobbler-0.6.0-1.el5 ctapi-common-1.1-3.el5 ctapi-cyberjack-3.0.3-3.el5 NEW freeze-2.5.0-7.el5 : freeze/melt/fcat compression utilities NEW gdal-1.4.2-4.el5 : GIS file format library NEW geos-2.2.3-3.el5 : GEOS is a C++ port of the Java Topology Suite glpk-4.20-2.el5 NEW gnome-screensaver-frogs-0.2-3.el5 : GNOME Screensaver Slideshow of Frogs NEW google-perftools-0.92-1.el5.2 : Very fast malloc and performance analysis tools NEW guile-cairo-1.4.0-4.el5 : The Cairo graphics library for Guile Scheme NEW guile-lib-0.1.4-4.el5 : A repository of useful code written in Guile Scheme koan-0.6.0-1.el5 NEW lasi-1.0.6-1.el5 : C++ library for creating Postscript documents NEW libdap-3.7.8-1.el5.1 : The C++ DAP2 library from OPeNDAP NEW libgeotiff-1.2.4-0.3.rc1.el5 : GeoTIFF format library NEW lzop-1.02-0.4.rc1.el5 : Real-time file compressor NEW mapserver-4.10.2-4.el5 : Environment for building spatially-enabled internet applications memcached-1.2.3-7.el5 NEW mfstools-2.0-11.snapshot050221.el5 : Utilities for TiVo drive upgrades NEW moodle-1.8.2-1.el5 : A Course Management System nagios-2.9-1.el5 NEW netgo-0.5-7.el5 : Networking profile manager NEW nomarch-1.4-2.el5 : GPLed Arc de-archiver NEW ogdi-3.2.0-0.5.beta1.el5 : Open Geographic Datastore Interface NEW oneko-1.2-4.el5 : Cat chases the cursor NEW pbzip2-1.0.2-2.el5 : Parallel implementation of bzip2 NEW perl-Convert-TNEF-0.17-7.el5 : Perl module to read TNEF files NEW perl-Convert-UUlib-1.09-1.el5 : Perl interface to the uulib library NEW perl-Danga-Socket-1.57-2.el5 : Event loop and event-driven async socket base class NEW perl-Device-SerialPort-1.002-3.el5 : Linux/POSIX emulation of Win32::SerialPort functions NEW perl-ExtUtils-F77-1.16-2.el5 : Simple interface to F77 libs NEW perl-Gearman-1.09-1.el5 : Distributed job system NEW perl-Gearman-Client-Async-0.94-3.el5 : Asynchronous Client for the Gearman distributed job system NEW perl-Gearman-Server-1.09-1.el5 : Function call "router" and load balancer NEW perl-Image-ExifTool-6.94-1.el5 : Utility for reading and writing image meta info NEW perl-IO-AIO-2.33-1.el5 : Asynchronous Input/Output NEW perl-Mail-SPF-Query-1.999.1-3.el5 : Query Sender Policy Framework NEW perl-MogileFS-Utils-2.12-1.el5 : Utilities for MogileFS NEW perl-Net-CIDR-Lite-0.20-2.1.el5 : Net::CIDR::Lite Perl module NEW perl-Razor-Agent-2.84-1.el5 : Use a Razor catalogue server to filter spam messages NEW perl-Sys-Syscall-0.22-2.el5 : Access system calls that Perl doesn't normally provide access to NEW Perlbal-1.59-1.el5 : Reverse-proxy load balancer and webserver NEW perltidy-20070801-1.el5 : Tool for indenting and reformatting Perl scripts NEW php-pear-PHP-CodeSniffer-0.7.0-1.el5 : PHP coding standards enforcement tool phpMyAdmin-2.10.3-1.el5 NEW physfs-1.0.1-5.el5 : Library to provide abstract access to various archives NEW plplot-5.7.3-3.el5.1 : Library of functions for making scientific plots NEW postgresql-pgpool-3.4-1.el5 : Pgpool is a connection pooling/replication server for PostgreSQL postgresql-pgpool-II-1.2-1.el5 NEW proftpd-1.3.0a-8.el5 : Flexible, stable and highly-configurable FTP server NEW proj-4.5.0-3.el5 : Cartographic projection software (PROJ.4) NEW pv-0.9.9-1.el5 : A tool for monitoring the progress of data through a pipeline NEW pychart-1.39-4.el5 : Python library for generating chart images NEW python-iniparse-0.2.1-1.el5 : Python Module for Accessing and Modifying Configuration Data in INI files NEW python-lxml-1.3.3-1.el5 : ElementTree-like Python bindings for libxml2 and libxslt NEW python-pygments-0.8.1-1.el5 : A syntax highlighting engine written in Python NEW pyxdg-0.15-5.el5.1 : Python library to access freedesktop.org standards NEW qhull-2003.1-7.el5 : General dimension convex hull programs NEW ser2net-2.4-1.el5 : Proxy that allows tcp connections to serial ports specto-0.2.2-1.el5 NEW stripesnoop-1.5-7.el5.1 : Magnetic Stripe Reader NEW svgalib-1.9.25-3.el5 : Low-level fullscreen SVGA graphics library NEW svnmailer-1.0.8-2.el5 : Tool to post subversion repository commit information NEW tcpxtract-1.0.1-8.el5 : Tool for extracting files from network traffic NEW tidy-0.99.0-14.20070615.el5 : Utility to clean up and pretty print HTML/XHTML/XML NEW udunits-1.12.4-11.el5.1 : A library for manipulating units of physical quantities NEW ustr-1.0.1-5.el5 : String library, very low memory overhead, simple to import NEW vpnc-0.4.0-2.el5 : IPSec VPN client compatible with Cisco equipment NEW xerces-c-2.7.0-6.el5 : Validating XML Parser NEW xkeycaps-2.46-6.el5.1 : Graphical front end to xmodmap NEW xsupplicant-1.2.8-3.el5 : Open Source Implementation of IEEE 802.1x zope-2.9.8-1.el5 Packages built and released for Fedora EPEL 4: 46 NEW arj-3.10.22-3.el4 : Archiver for .arj files NEW audio-entropyd-1.0.0-4.el4.2 : Generate entropy from audio output NEW chmlib-0.39-3.el4 : Library for dealing with ITSS/CHM format files cobbler-0.6.0-1.el4 ctapi-common-1.1-3.el4 ctapi-cyberjack-3.0.3-3.el4 NEW freeze-2.5.0-7.el4 : freeze/melt/fcat compression utilities NEW geos-2.2.3-2.el4 : GEOS is a C++ port of the Java Topology Suite NEW gnome-screensaver-frogs-0.2-3.el4 : GNOME Screensaver Slideshow of Frogs NEW google-perftools-0.92-1.el4.2 : Very fast malloc and performance analysis tools koan-0.6.0-1.el4 NEW libdap-3.7.8-1.el4.1 : The C++ DAP2 library from OPeNDAP NEW libgeotiff-1.2.4-0.3.rc1.el4 : GeoTIFF format library NEW lzop-1.02-0.4.rc1.el4 : Real-time file compressor NEW mfstools-2.0-11.snapshot050221.el4 : Utilities for TiVo drive upgrades NEW mod_security-2.1.1-1.el4 : Security module for the Apache HTTP Server NEW moodle-1.8.2-1.el4 : A Course Management System NEW netgo-0.5-7.el4 : Networking profile manager NEW nomarch-1.4-2.el4 : GPLed Arc de-archiver NEW oneko-1.2-3.el4 : Cat chases the cursor NEW pbzip2-1.0.2-2.el4 : Parallel implementation of bzip2 NEW perl-Convert-TNEF-0.17-7.el4 : Perl module to read TNEF files NEW perl-Convert-UUlib-1.09-1.el4 : Perl interface to the uulib library NEW perl-Danga-Socket-1.57-2.el4.1 : Event loop and event-driven async socket base class NEW perl-Device-SerialPort-1.002-3.el4 : Linux/POSIX emulation of Win32::SerialPort functions NEW perl-ExtUtils-F77-1.16-2.el4 : Simple interface to F77 libs NEW perl-Image-ExifTool-6.94-1.el4 : Utility for reading and writing image meta info NEW perl-IO-AIO-2.33-1.el4 : Asynchronous Input/Output NEW perl-Mail-SPF-Query-1.999.1-3.el4 : Query Sender Policy Framework NEW perl-Net-CIDR-Lite-0.20-2.1.el4 : Net::CIDR::Lite Perl module NEW perl-Razor-Agent-2.84-1.el4 : Use a Razor catalogue server to filter spam messages NEW perl-Sys-Syscall-0.22-2.el4 : Access system calls that Perl doesn't normally provide access to NEW physfs-1.0.1-4.el4 : Library to provide abstract access to various archives NEW postgresql-pgpool-3.4-1.el4 : Pgpool is a connection pooling/replication server for PostgreSQL postgresql-pgpool-II-1.2-1.el4 NEW proj-4.4.8-7 : Cartographic projection software (PROJ.4) NEW pychart-1.39-3.el4 : Python library for generating chart images NEW python-lxml-1.3.3-1.el4 : ElementTree-like Python bindings for libxml2 and libxslt NEW pyxdg-0.15-5.el4.1 : Python library to access freedesktop.org standards NEW ser2net-2.4-1.el4 : Proxy that allows tcp connections to serial ports NEW stripesnoop-1.5-7.el4.1 : Magnetic Stripe Reader NEW svgalib-1.9.25-3.el4.1 : Low-level fullscreen SVGA graphics library NEW udunits-1.12.4-11.el4.1 : A library for manipulating units of physical quantities NEW xerces-c-2.7.0-6.el4 : Validating XML Parser NEW xkeycaps-2.46-5.el4 : Graphical front end to xmodmap NEW xsupplicant-1.2.8-3.el4 : Open Source Implementation of IEEE 802.1x Changes in Fedora EPEL 5: arj-3.10.22-3.el5 ----------------- * Mon Aug 13 2007 Robert Scheck 3.10.22-3 - Rebuilt for EPEL branches (#250845) * Fri Aug 03 2007 Hans de Goede 3.10.22-2 - Update License tag for new Licensing Guidelines compliance audio-entropyd-1.0.0-4.el5.2 ---------------------------- * Thu Aug 02 2007 Tom "spot" Callaway 1.0.0-4 - selinux policy not needed cabextract-1.1-5.el5 -------------------- * Tue Aug 29 2006 Ville Skytt? - 1.1-5 - Rebuild. cacti-0.8.6j-1.el5 ------------------ * Sat May 05 2007 Mike McGrath - 0.8.6j-5 - Upstream released new version chmlib-0.39-3.el5 ----------------- * Sat Aug 04 2007 Peter Lemenkov 0.39-3 - Upstream URL changed * Thu Aug 02 2007 Oliver Falk 0.39-2 - Add alpha fix cobbler-0.6.0-1.el5 ------------------- * Thu Aug 09 2007 Michael DeHaan - 0.6.0-1 - Upstream changes (see CHANGELOG) * Thu Jul 26 2007 Michael DeHaan - 0.5.2-1 - Upstream changes (see CHANGELOG) - Tweaked description * Fri Jul 20 2007 Michael DeHaan - 0.5.1-1 - Upstream changes (see CHANGELOG) - Modified description - Added logrotate script - Added findks.cgi * Wed Jun 27 2007 Michael DeHaan - 0.5.0-1 - Upstream changes (see CHANGELOG) - Added dnsmasq.template * Fri Apr 27 2007 Michael DeHaan - 0.4.9-1 - Upstream changes (see CHANGELOG) ctapi-common-1.1-3.el5 ---------------------- * Sat Aug 04 2007 Frank B?ttner - 1.1-3 - fix creation of the group and don't remove it * Mon Jul 23 2007 Ville Skytt? - 1.1-2 - Change group to ctapiusers. - Don't hardcode a static gid. - Don't remove the group at all. - Require shadow-utils for group creation. * Sat Jul 21 2007 Frank B?ttner - 1.1-1 - set version to 1.1 so that other packages can require it * Sat Jul 21 2007 Frank B?ttner - 1.0-5 - fix for #220767 all users that will use card readers must be in the new group cardusers. ctapi-cyberjack-3.0.3-3.el5 --------------------------- * Mon Aug 06 2007 Frank B?ttner - 3.0.3-3 - apply fix only for F7 an newer * Sat Aug 04 2007 Frank B?ttner - 3.0.3-2 - fix #246842 (change udev rules) freeze-2.5.0-7.el5 ------------------ * Sun Aug 12 2007 Robert Scheck 2.5.0-7 - Rebuilt for EPEL branches gdal-1.4.2-4.el5 ---------------- * Thu Aug 09 2007 Balint Cristian 1.4.2-4 - realy disable gdall for now. * Thu Aug 09 2007 Balint Cristian 1.4.2-3 - bootstrap for EPEL without grass * Tue Jul 24 2007 Balint Cristian 1.4.2-2 - disable one more HFA test, HFA is unaviable due to license * Tue Jul 24 2007 Balint Cristian 1.4.2-1 - new upstream one - catch some more docs - fix ogr python module runtime - include testcases and run tests - enable geotiff external library we have new libgeotiff now - EPSG geodetic database is licensed OK since v6.13 so re-enable - enable it against grass by default, implement optional switches geos-2.2.3-3.el5 ---------------- * Mon Jan 08 2007 Shawn McCann - 2.2.3-3 - Rebuild for EPEL 5 glpk-4.20-2.el5 --------------- * Thu Aug 09 2007 Quentin Spencer 4.20-2 - Add pre and postun scripts to run ldconfig. gnome-screensaver-frogs-0.2-3.el5 --------------------------------- * Wed Aug 01 2007 Tom "spot" Callaway 0.2-3 - fixup licensing google-perftools-0.92-1.el5.2 ----------------------------- * Wed Aug 01 2007 Tom "spot" Callaway 0.92-1 - bump to 0.92 guile-cairo-1.4.0-4.el5 ----------------------- * Sat Aug 04 2007 Xavier Lamien - 1.4.0-4 - Fixed typo on pkgconfig. * Wed Aug 01 2007 Xavier Lamien - 1.4.0-3 - Added missing Requires. * Wed Aug 01 2007 Xavier Lamien - 1.4.0-2 - Minor Fixes. * Tue Jul 24 2007 Chitlesh Goorah - 1.4.0-1 - Initial Package guile-lib-0.1.4-4.el5 --------------------- * Wed Aug 01 2007 Xavier Lamien - 0.1.4-4 - Managed Timestamp. - Added guile as Requires. * Wed Aug 01 2007 Xavier Lamien - 0.1.4-3 - additional fix. * Tue Jul 31 2007 Chitlesh Goorah - 0.1.4-2 - minor fixes to make gwave work. * Sun Jul 22 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.1.4-1 - Initial RPM release. koan-0.6.0-1.el5 ---------------- * Thu Aug 09 2007 Michael DeHaan - 0.6.0-1 - Upstream changes (see CHANGELOG) * Thu Jul 26 2007 Michael DeHaan - 0.5.2-1 - Upstream changes (see CHANGELOG) * Fri Jul 20 2007 Michael DeHaan - 0.5.1-1 - Upstream changes (see CHANGELOG) * Wed Jun 27 2007 Michael DeHaan - 0.5.0-1 - Upstream changes (see CHANGELOG) lasi-1.0.6-1.el5 ---------------- * Tue Aug 29 2006 - Orion Poplawski - 1.0.6-1 - Update to 1.0.6 - Remove pkg-config patch applied upstream libdap-3.7.8-1.el5.1 -------------------- * Thu Jul 05 2007 Patrice Dumas 3.7.8-1.1 - update to 3.7.8 libgeotiff-1.2.4-0.3.rc1.el5 ---------------------------- * Tue Jul 24 2007 Balint Cristian 1.2.4-0.3.rc1 - codes are under MIT - pkg-config cflags return fix - epsg_csv ownership * Mon Jul 23 2007 Balint Cristian 1.2.4-0.2.rc1 - fix debuginfo usability - move header files to the subdirectory - specify the full URL of the source - leave *.inc headers included - libgeotiff-devel should require libtiff-devel - works to keep timestamps on the header files installed - docs proper triage * Mon Jul 23 2007 Balint Cristian 1.2.4-0.1.rc1 - initial pack for fedora - add pkgconfig file - add soname versioning patch lzop-1.02-0.4.rc1.el5 --------------------- * Sun Aug 12 2007 Robert Scheck 1.02-0.4.rc1 - Rebuilt for EPEL branches mapserver-4.10.2-4.el5 ---------------------- * Fri May 11 2007 Balint Cristian 4.10.2-4 - update require list properly. memcached-1.2.3-7.el5 --------------------- * Mon Aug 06 2007 Paul Lindner - 1.2.3-7 - Fix problem with -P and -d flag combo on x86_64 - Fix init script for FC-6 mfstools-2.0-11.snapshot050221.el5 ---------------------------------- * Thu Sep 14 2006 Tom "spot" Callaway 2.0-11.snapshot050221 - Do not use the _syscall5 macro -- use syscall(2) instead moodle-1.8.2-1.el5 ------------------ * Wed Jul 25 2007 Jon Ciesla - 1.8.2-1 - Update to 1.8.2. - Updated language packs to the 25 July 2007 versions. - Added Mongolian, Gujerati, Lao, Tongan, Maori (Waikato Uni), Samoan, Tamil. nagios-2.9-1.el5 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 netgo-0.5-7.el5 --------------- * Fri May 25 2007 Tom "spot" Callaway 0.5-7 - fix pam config to not use pam_stack nomarch-1.4-2.el5 ----------------- * Sun Aug 12 2007 Robert Scheck 1.4-2 - Rebuilt for EPEL branches ogdi-3.2.0-0.5.beta1.el5 ------------------------ * Thu Mar 01 2007 Balint Cristian 3.2.0-0.5.beta1 - fix fc-6 tag upstream fedora-extras oneko-1.2-4.el5 --------------- * Thu Sep 14 2006 Tom "spot" Callaway 1.2-4 - FC-6 rebuild pbzip2-1.0.2-2.el5 ------------------ * Thu Jul 26 2007 Jeff Gilchrist - 1.0.2-2 - Fixed symbolic link for pbunzip2 file * Wed Jul 25 2007 Jeff Gilchrist - 1.0.2-1 - Release 1.0.2 perl-Convert-TNEF-0.17-7.el5 ---------------------------- * Tue Apr 17 2007 Steven Pritchard 0.17-7 - Use fixperms macro instead of our own chmod incantation. - Reformat to more closely match cpanspec output. - BR MIME::Body instead of perl-MIME-tools. - BR ExtUtils::MakeMaker. perl-Convert-UUlib-1.09-1.el5 ----------------------------- * Sun Aug 12 2007 Robert Scheck 1:1.09-1 - Upgrade to 1.09 and rebuilt for EPEL branches (#250865) - Added build requirement to perl(ExtUtils::MakeMaker) perl-Danga-Socket-1.57-2.el5 ---------------------------- * Mon May 07 2007 Ruben Kerkhof 1.57-2 - Include examples in %doc perl-Device-SerialPort-1.002-3.el5 ---------------------------------- * Thu Oct 05 2006 Christian Iseli 1.002-3 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 perl-ExtUtils-F77-1.16-2.el5 ---------------------------- * Wed Aug 01 2007 Orion Poplawski 1.16-2 - Add BR: gcc-gfortran * Tue Jul 31 2007 Orion Poplawski 1.16-1 - Specfile autogenerated by cpanspec 1.73. perl-Gearman-1.09-1.el5 ----------------------- * Sat Jun 30 2007 Ruben Kerkhof 1.09-1 - Upstream released new version - New version now includes license information - Filter out just one of the two Provides for Gearman::Client perl-Gearman-Client-Async-0.94-3.el5 ------------------------------------ * Sat Jun 09 2007 Ruben Kerkhof 0.94-3 - Disable test which fails on x86_64 (#246356) perl-Gearman-Server-1.09-1.el5 ------------------------------ * Sun May 20 2007 Ruben Kerkhof 1.09-1 - Initial import perl-Image-ExifTool-6.94-1.el5 ------------------------------ * Wed Aug 01 2007 Tom "spot" Callaway 6.94-1 - bump to 6.94 perl-IO-AIO-2.33-1.el5 ---------------------- * Sun May 13 2007 Ruben Kerkhof 2.33-1 - Initial import perl-Mail-SPF-Query-1.999.1-3.el5 --------------------------------- * Wed Apr 18 2007 Steven Pritchard 1.999.1-3 - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. perl-MogileFS-Utils-2.12-1.el5 ------------------------------ * Thu Aug 09 2007 Ruben Kerkhof 2.12-1 - Upstream released new version perl-Net-CIDR-Lite-0.20-2.1.el5 ------------------------------- * Mon Aug 13 2007 Steven Pritchard 0.20-2.1 - Use fixperms macro instead of our own chmod incantation. - Temporarily disable Test::Pod* build dependencies. perl-Razor-Agent-2.84-1.el5 --------------------------- * Sat Aug 11 2007 Robert Scheck 2.84-1 - Upgrade to 2.84 (#250869) - Added build requirement to perl(ExtUtils::MakeMaker) perl-Sys-Syscall-0.22-2.el5 --------------------------- * Tue May 08 2007 Ruben Kerkhof 0.22-2 - Test::More added to BR (#239369) Perlbal-1.59-1.el5 ------------------ * Wed Jun 20 2007 Ruben Kerkhof 1.59-1 - Upstream released new version - Received patch from upstream for failing buffered upload test (240693) perltidy-20070801-1.el5 ----------------------- * Wed Aug 01 2007 Ville Skytt? - 20070801-1 - 20070801. php-pear-PHP-CodeSniffer-0.7.0-1.el5 ------------------------------------ * Mon Jun 11 2007 Konstantin Ryabitsev - 0.7.0-1 - Upstream 0.7.0 - Drop Requirement on php-common (php-pear pulls that in) phpMyAdmin-2.10.3-1.el5 ----------------------- * Mon Jul 23 2007 Mike McGrath 2.10.3-1 - Upstream released new version physfs-1.0.1-5.el5 ------------------ * Fri Sep 15 2006 Tom "spot" Callaway 1.0.1-5 - bump for fc6 plplot-5.7.3-3.el5.1 -------------------- * Mon Aug 06 2007 - Orion Poplawski - 5.7.3-3.1 - Revert BR to gnome-python2 for EL - pygtk2-devel is broken in EL-5, disable for now (bug #251029) - Disable octave support until plplot supports octave 2.9.11+ postgresql-pgpool-3.4-1.el5 --------------------------- * Wed Aug 01 2007 - Devrim GUNDUZ 3.4-1 - Update to 3.4 - Removed patches, they are now in upstream - Added pam-devel to BR postgresql-pgpool-II-1.2-1.el5 ------------------------------ * Wed Aug 01 2007 Devrim Gunduz 1.2-1 - Update to 1.2 proftpd-1.3.0a-8.el5 -------------------- * Sun Aug 12 2007 Matthias Saou 1.3.0a-8 - Fix logrotate entry to silence error when proftpd isn't running (#246392). * Mon Aug 06 2007 Matthias Saou 1.3.0a-7 - Include patch to fix "open" calls with recent glibc. * Mon Aug 06 2007 Matthias Saou 1.3.0a-6 - Update License field. proj-4.5.0-3.el5 ---------------- * Sun Aug 05 2007 Shawn McCann - 4.5.0-3 - Rebuild for EPEL 5 pv-0.9.9-1.el5 -------------- * Sun Jun 24 2007 Jakub Hrozek - 0.9.9-1 - Initial packaging loosely based on SRPM from project's home page by Andrew Wood pychart-1.39-4.el5 ------------------ * Fri Sep 15 2006 Tom "spot" Callaway 1.39-4 - bump for FC-6 python-iniparse-0.2.1-1.el5 --------------------------- * Tue Aug 07 2007 Paramjit Oberoi - 0.2.1-1 - Release 0.2.1 * Fri Jul 27 2007 Tim Lauridsen - 0.2-3 - relocated doc to /usr/share/doc/python-iniparse-0.2.1 * Thu Jul 26 2007 Tim Lauridsen - 0.2-2 - changed name from iniparse to python-iniparse * Tue Jul 17 2007 Tim Lauridsen - 0.2-1 - Release 0.2 - Added html/* to %doc python-lxml-1.3.3-1.el5 ----------------------- * Mon Jul 30 2007 Jeffrey C. Ollie - 1.3.3-1 - Update to 1.3.3 python-pygments-0.8.1-1.el5 --------------------------- * Thu Jun 28 2007 Steve 'Ashcrow' Milner - 0.8.1-1 - Initial packaging for Fedora. pyxdg-0.15-5.el5.1 ------------------ * Wed Jan 03 2007 Patrice Dumas - 0.15-5 - remove requires for python-abi (automatic now) and python directory - remove package name from summary - change tabs to spaces qhull-2003.1-7.el5 ------------------ * Wed Jun 20 2007 Ralf Cors?pius - 2003.1-7 - Remove *.la. ser2net-2.4-1.el5 ----------------- * Thu Aug 02 2007 Tom "spot" Callaway 2.4-1 - bump to 2.4 specto-0.2.2-1.el5 ------------------ * Thu Aug 02 2007 Xavier Lamien - 0.2.2-1 - Updated Release. stripesnoop-1.5-7.el5.1 ----------------------- * Thu May 17 2007 Tom "spot" Callaway 1.5-7.1 - ppc64 won't work here either svgalib-1.9.25-3.el5 -------------------- * Tue Aug 29 2006 Hans de Goede 1.9.25-3 - FE6 Rebuild svnmailer-1.0.8-2.el5 --------------------- * Sun Sep 03 2006 Michael Fleming 1.0.8-2 - Rebuild - No longer ghost .pyo files. tcpxtract-1.0.1-8.el5 --------------------- * Wed Aug 08 2007 lonely wolf 1.0.1-8 - license clarification tidy-0.99.0-14.20070615.el5 --------------------------- * Tue Jul 31 2007 Rex Dieter 0.99.0-14.20070615 - BR: libtool (again) udunits-1.12.4-11.el5.1 ----------------------- * Mon Aug 06 2007 Tom "spot" Callaway 1.12.4-11.1 - fix license (MIT) ustr-1.0.1-5.el5 ---------------- * Wed Aug 08 2007 James Antill - 1.0.1-5 - Import fix for ustr-import, wrt. repl <=> replace * Sun Aug 05 2007 James Antill - 1.0.1-4 - Patches for minor GIT HEAD documentation fixes. - Install mkdir_p and fgrep examples. * Sat Aug 04 2007 James Antill - 1.0.1-2 - First upload to Fedora repos. * Fri Aug 03 2007 James Antill - 1.0.1-0.10.fc7 - Re-fix dups in -devel and -debug file lists. - Change license to new format * Thu Aug 02 2007 James Antill - 1.0.1-0.9.fc7 - Fix dups in -devel and -debug file lists. * Wed Aug 01 2007 James Antill - 1.0.1-0.8.fc7 - Required to make DBG_ONLY_BAD_POLICIES_HAVE_THIS_EMPTY_CFLAGS empty - due to so called "review" * Fri Jul 27 2007 James Antill - 1.0.1-0.2.fc7 - Next test release of 1.0.1, lots of fixes from Fedora review. * Wed Jul 25 2007 James Antill - 1.0.1-0 - Test release of 1.0.1. vpnc-0.4.0-2.el5 ---------------- * Tue Mar 20 2007 Tomas Mraz - 0.4.0-2 - -fstack-protector miscompilation on x86_64 is back (#232565) xerces-c-2.7.0-6.el5 -------------------- * Sat Nov 25 2006 Peter Lemenkov 2.7.0-6 - typo fix xkeycaps-2.46-6.el5.1 --------------------- * Mon Aug 06 2007 Tom "spot" Callaway 2.46-6.1 - license cleanup xsupplicant-1.2.8-3.el5 ----------------------- * Mon Aug 06 2007 Tom "spot" Callaway 1.2.8-3 - fix xsupplicant to compile in devel (needs linux/if.h) - fix doc generation - fix license zope-2.9.8-1.el5 ---------------- * Mon Aug 06 2007 Jonathan Steffan 2.9.8-1 - Updated to 2.9.8 Changes in Fedora EPEL 4: arj-3.10.22-3.el4 ----------------- * Mon Aug 13 2007 Robert Scheck 3.10.22-3 - Rebuilt for EPEL branches (#250845) * Fri Aug 03 2007 Hans de Goede 3.10.22-2 - Update License tag for new Licensing Guidelines compliance audio-entropyd-1.0.0-4.el4.2 ---------------------------- * Thu Aug 02 2007 Tom "spot" Callaway 1.0.0-4 - selinux policy not needed chmlib-0.39-3.el4 ----------------- * Sat Aug 04 2007 Peter Lemenkov 0.39-3 - Upstream URL changed * Thu Aug 02 2007 Oliver Falk 0.39-2 - Add alpha fix cobbler-0.6.0-1.el4 ------------------- * Thu Aug 09 2007 Michael DeHaan - 0.6.0-1 - Upstream changes (see CHANGELOG) * Thu Jul 26 2007 Michael DeHaan - 0.5.2-1 - Upstream changes (see CHANGELOG) - Tweaked description * Fri Jul 20 2007 Michael DeHaan - 0.5.1-1 - Upstream changes (see CHANGELOG) - Modified description - Added logrotate script - Added findks.cgi * Wed Jun 27 2007 Michael DeHaan - 0.5.0-1 - Upstream changes (see CHANGELOG) - Added dnsmasq.template * Fri Apr 27 2007 Michael DeHaan - 0.4.9-1 - Upstream changes (see CHANGELOG) ctapi-common-1.1-3.el4 ---------------------- * Sat Aug 04 2007 Frank B?ttner - 1.1-3 - fix creation of the group and don't remove it * Mon Jul 23 2007 Ville Skytt? - 1.1-2 - Change group to ctapiusers. - Don't hardcode a static gid. - Don't remove the group at all. - Require shadow-utils for group creation. * Sat Jul 21 2007 Frank B?ttner - 1.1-1 - set version to 1.1 so that other packages can require it * Sat Jul 21 2007 Frank B?ttner - 1.0-5 - fix for #220767 all users that will use card readers must be in the new group cardusers. ctapi-cyberjack-3.0.3-3.el4 --------------------------- * Mon Aug 06 2007 Frank B?ttner - 3.0.3-3 - apply fix only for F7 an newer * Sat Aug 04 2007 Frank B?ttner - 3.0.3-2 - fix #246842 (change udev rules) freeze-2.5.0-7.el4 ------------------ * Sun Aug 12 2007 Robert Scheck 2.5.0-7 - Rebuilt for EPEL branches geos-2.2.3-2.el4 ---------------- * Sat Aug 04 2007 Shawn McCann - 2.2.3-2 - Rebuild for EPEL 4 gnome-screensaver-frogs-0.2-3.el4 --------------------------------- * Wed Aug 01 2007 Tom "spot" Callaway 0.2-3 - fixup licensing google-perftools-0.92-1.el4.2 ----------------------------- * Wed Aug 01 2007 Tom "spot" Callaway 0.92-1 - bump to 0.92 koan-0.6.0-1.el4 ---------------- * Thu Aug 09 2007 Michael DeHaan - 0.6.0-1 - Upstream changes (see CHANGELOG) * Thu Jul 26 2007 Michael DeHaan - 0.5.2-1 - Upstream changes (see CHANGELOG) * Fri Jul 20 2007 Michael DeHaan - 0.5.1-1 - Upstream changes (see CHANGELOG) * Wed Jun 27 2007 Michael DeHaan - 0.5.0-1 - Upstream changes (see CHANGELOG) libdap-3.7.8-1.el4.1 -------------------- * Thu Jul 05 2007 Patrice Dumas 3.7.8-1.1 - update to 3.7.8 libgeotiff-1.2.4-0.3.rc1.el4 ---------------------------- * Tue Jul 24 2007 Balint Cristian 1.2.4-0.3.rc1 - codes are under MIT - pkg-config cflags return fix - epsg_csv ownership * Mon Jul 23 2007 Balint Cristian 1.2.4-0.2.rc1 - fix debuginfo usability - move header files to the subdirectory - specify the full URL of the source - leave *.inc headers included - libgeotiff-devel should require libtiff-devel - works to keep timestamps on the header files installed - docs proper triage * Mon Jul 23 2007 Balint Cristian 1.2.4-0.1.rc1 - initial pack for fedora - add pkgconfig file - add soname versioning patch lzop-1.02-0.4.rc1.el4 --------------------- * Sun Aug 12 2007 Robert Scheck 1.02-0.4.rc1 - Rebuilt for EPEL branches mfstools-2.0-11.snapshot050221.el4 ---------------------------------- * Thu Sep 14 2006 Tom "spot" Callaway 2.0-11.snapshot050221 - Do not use the _syscall5 macro -- use syscall(2) instead mod_security-2.1.1-1.el4 ------------------------ * Tue Jun 19 2007 Michael Fleming 2.1.1-1 - New upstream release - Drop ASCIIZ rule (fixed upstream) - Re-enable protocol violation/anomalies rules now that REQUEST_FILENAME is fixed upstream. moodle-1.8.2-1.el4 ------------------ * Wed Jul 25 2007 Jon Ciesla - 1.8.2-1 - Update to 1.8.2. - Updated language packs to the 25 July 2007 versions. - Added Mongolian, Gujerati, Lao, Tongan, Maori (Waikato Uni), Samoan, Tamil. netgo-0.5-7.el4 --------------- * Fri May 25 2007 Tom "spot" Callaway 0.5-7 - fix pam config to not use pam_stack nomarch-1.4-2.el4 ----------------- * Sun Aug 12 2007 Robert Scheck 1.4-2 - Rebuilt for EPEL branches oneko-1.2-3.el4 --------------- * Tue Mar 07 2006 Tom "spot" Callaway 1.2-3 - remove includedir macro, not needed - rename japanese man page to not have .jp extension pbzip2-1.0.2-2.el4 ------------------ * Thu Jul 26 2007 Jeff Gilchrist - 1.0.2-2 - Fixed symbolic link for pbunzip2 file * Wed Jul 25 2007 Jeff Gilchrist - 1.0.2-1 - Release 1.0.2 perl-Convert-TNEF-0.17-7.el4 ---------------------------- * Tue Apr 17 2007 Steven Pritchard 0.17-7 - Use fixperms macro instead of our own chmod incantation. - Reformat to more closely match cpanspec output. - BR MIME::Body instead of perl-MIME-tools. - BR ExtUtils::MakeMaker. perl-Convert-UUlib-1.09-1.el4 ----------------------------- * Sun Aug 12 2007 Robert Scheck 1:1.09-1 - Upgrade to 1.09 and rebuilt for EPEL branches (#250865) - Added build requirement to perl(ExtUtils::MakeMaker) perl-Danga-Socket-1.57-2.el4.1 ------------------------------ * Thu Aug 09 2007 Ruben Kerkhof 1.57-3 - Add Time::HiRes to the BuildRequires to fix building on EL-4 perl-Device-SerialPort-1.002-3.el4 ---------------------------------- * Thu Oct 05 2006 Christian Iseli 1.002-3 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 perl-ExtUtils-F77-1.16-2.el4 ---------------------------- * Wed Aug 01 2007 Orion Poplawski 1.16-2 - Add BR: gcc-g77 * Tue Jul 31 2007 Orion Poplawski 1.16-1 - Specfile autogenerated by cpanspec 1.73. perl-Image-ExifTool-6.94-1.el4 ------------------------------ * Wed Aug 01 2007 Tom "spot" Callaway 6.94-1 - bump to 6.94 perl-IO-AIO-2.33-1.el4 ---------------------- * Sun May 13 2007 Ruben Kerkhof 2.33-1 - Initial import perl-Mail-SPF-Query-1.999.1-3.el4 --------------------------------- * Wed Apr 18 2007 Steven Pritchard 1.999.1-3 - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. perl-Net-CIDR-Lite-0.20-2.1.el4 ------------------------------- * Mon Aug 13 2007 Steven Pritchard 0.20-2.1 - Use fixperms macro instead of our own chmod incantation. - Temporarily disable Test::Pod* build dependencies. perl-Razor-Agent-2.84-1.el4 --------------------------- * Sat Aug 11 2007 Robert Scheck 2.84-1 - Upgrade to 2.84 (#250869) - Added build requirement to perl(ExtUtils::MakeMaker) perl-Sys-Syscall-0.22-2.el4 --------------------------- * Tue May 08 2007 Ruben Kerkhof 0.22-2 - Test::More added to BR (#239369) physfs-1.0.1-4.el4 ------------------ * Tue Mar 07 2006 Tom "spot" Callaway 1.0.1-4 - resolve man page conflicts (bz #183705) postgresql-pgpool-3.4-1.el4 --------------------------- * Wed Aug 01 2007 - Devrim GUNDUZ 3.4-1 - Update to 3.4 - Removed patches, they are now in upstream - Added pam-devel to BR postgresql-pgpool-II-1.2-1.el4 ------------------------------ * Wed Aug 01 2007 Devrim Gunduz 1.2-1 - Update to 1.2 proj-4.4.8-7 ------------ * Sat Aug 04 2007 Shawn McCann - 0:4.4.8-7 - Rebuild for EPEL 4 pychart-1.39-3.el4 ------------------ * Tue Jan 10 2006 Tom "spot" Callaway 1.39-3 - FC3 doesn't need latex2html python-lxml-1.3.3-1.el4 ----------------------- * Mon Jul 30 2007 Jeffrey C. Ollie - 1.3.3-1 - Update to 1.3.3 pyxdg-0.15-5.el4.1 ------------------ * Wed Jan 03 2007 Patrice Dumas - 0.15-5 - remove requires for python-abi (automatic now) and python directory - remove package name from summary - change tabs to spaces ser2net-2.4-1.el4 ----------------- * Thu Aug 02 2007 Tom "spot" Callaway 2.4-1 - bump to 2.4 stripesnoop-1.5-7.el4.1 ----------------------- * Thu May 17 2007 Tom "spot" Callaway 1.5-7.1 - ppc64 won't work here either svgalib-1.9.25-3.el4.1 ---------------------- * Thu Aug 02 2007 Orion Poplawski 1.9.25-3.1 - EL-4 gcc doesn't support -Wno-pointer-sign udunits-1.12.4-11.el4.1 ----------------------- * Mon Aug 06 2007 Tom "spot" Callaway 1.12.4-11.1 - fix license (MIT) xerces-c-2.7.0-6.el4 -------------------- * Sat Nov 25 2006 Peter Lemenkov 2.7.0-6 - typo fix xkeycaps-2.46-5.el4 ------------------- * Mon Aug 06 2007 Tom "spot" Callaway 2.46-5 - el-4 variant xsupplicant-1.2.8-3.el4 ----------------------- * Mon Aug 06 2007 Tom "spot" Callaway 1.2.8-3 - fix xsupplicant to compile in devel (needs linux/if.h) - fix doc generation - fix license For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dennis at ausil.us Wed Aug 15 02:45:49 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 14 Aug 2007 21:45:49 -0500 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <20070815024018.9F536152131@buildsys.fedoraproject.org> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> Message-ID: <200708142145.55835.dennis@ausil.us> Note, This push went to the testing Repo if you want package you need to enable it. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From fedora at leemhuis.info Wed Aug 15 04:41:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Aug 2007 06:41:18 +0200 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <200708141350.47545.dennis@ausil.us> References: <4687C867.8060400@leemhuis.info> <46B73DE8.2030208@leemhuis.info> <46C1DEFF.7030800@leemhuis.info> <200708141350.47545.dennis@ausil.us> Message-ID: <46C283EE.4090207@leemhuis.info> On 14.08.2007 20:50, Dennis Gilmore wrote: > On Tuesday 14 August 2007 11:57:35 am Thorsten Leemhuis wrote: >> On 06.08.2007 17:27, Thorsten Leemhuis wrote: >>> On 01.08.2007 18:59, Dennis Gilmore wrote: >>> [...] >>> >>>> If the Fedora maintainer later decides to participate in EPEL, Then both >>>> people will become co-maintainers for EPEL. (Of course >>>> co-maintainership can be extended to Fedora) >>> If I understand the last para correctly we have two maintainers one the >>> same level -- e.g. no primary per-release maintainer? That's not in line >>> with the co-maintainership policy, which makes sure there is always one >>> person as per-release primary maintainer which is responsible in the end >>> for the packages (and has the last word in case of disputes). I prefer >>> such a scheme, because two people co-maintaining a package in the end >>> could quickly lead to situation where each other thought the other one >>> will take care of the package. >>> >>> So: -1 for this. I'm all for something like that as last para: >>> >>> If the Fedora maintainer later decides to participate in EPEL, then he >>> and the EPEL maintainer should discuss which one takes care of the >>> package. One should become primary per release maintainer, which is kind >>> of responsible for the package in that release; the other should become >>> co-maintainer; how those two share the work is up to them. >> Ping -- I got no reactions on this. >> >> To let me rephrase: with the "Then both people will become >> co-maintainers for EPEL." it's afaics unclear who's the primary >> per-release maintainer and who's the co-maintainer in the end. That's >> not in line with the co-maintainership policy from Fedora, which >> requests there is a per-release (release=EPEL4 and EPEL5 in this case) >> maintainer. > > Sorry it was not clear to you. the Fedora maintainer will become the > co-maintainer. they EPEL maintainer will remain primary. of course this can > be switched if the maintainers agree. Could you please clarify the wording in the wiki then to make that more obvious? CU knurd From sankarshan.mukhopadhyay at gmail.com Tue Aug 14 17:41:58 2007 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Tue, 14 Aug 2007 23:11:58 +0530 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <46C1E839.4050002@leemhuis.info> References: <46C1E839.4050002@leemhuis.info> Message-ID: <7e3d3af30708141041u1d2a80b7t2828aa2758310012@mail.gmail.com> On 8/14/07, Thorsten Leemhuis wrote: [massive snip] Nearly all projects face the same problems (some do sometimes, others to often) > - only meet on IRC every second week *with* a defined agenda in place > - only meet on IRC all four week or when there is a need to experience (somewhat limited in my case) shows this to be an overkill sometimes > - somehow accept stuff on the mailing lists if possible. Kind of "send a > proposal, if some people give a "+1" on the list and no one objects from > the SIG within some days consider it accepted". Sure, it's often not > that easy and we needed to work out more details for such a scheme, but > it could be or something into that direction. That way the SIG or EPEL > contributors get more influence and we might need the Steering Committee > only if a decision can't be found If there's a set of points to be discussed with some initial seeding of pros and cons, the mailing list might function as a thermometer as to how an IRC meet would go if it were called for the same issue > - weekly status mail from the owners of major tasks This would actually serve well if summed up monthly as to "what was achieved" :Sankarshan -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw From fedora at leemhuis.info Wed Aug 15 09:21:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Aug 2007 11:21:07 +0200 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <7e3d3af30708141041u1d2a80b7t2828aa2758310012@mail.gmail.com> References: <46C1E839.4050002@leemhuis.info> <7e3d3af30708141041u1d2a80b7t2828aa2758310012@mail.gmail.com> Message-ID: <46C2C583.8060403@leemhuis.info> On 14.08.2007 19:41, Sankarshan Mukhopadhyay wrote: > On 8/14/07, Thorsten Leemhuis wrote: > > [massive snip] > Nearly all projects face the same problems (some do sometimes, others to often) Sure -- but I was in FESCo for one year and there it worked much better. Seems people were more interested in Extras then. >> - only meet on IRC every second week > *with* a defined agenda in place Well, the topic list is in the wiki. What precisely what you like to be more defined? What I'd like to see more: Status updates from the *task-owners* before the meetings, so we can talk about solving the problems only and can do so even if the owners is not around (if needed). >> - only meet on IRC all four week or when there is a need to > experience (somewhat limited in my case) shows this to be an overkill sometimes Likely. >> - somehow accept stuff on the mailing lists if possible. Kind of "send a >> proposal, if some people give a "+1" on the list and no one objects from >> the SIG within some days consider it accepted". Sure, it's often not >> that easy and we needed to work out more details for such a scheme, but >> it could be or something into that direction. That way the SIG or EPEL >> contributors get more influence and we might need the Steering Committee >> only if a decision can't be found > If there's a set of points to be discussed with some initial seeding > of pros and cons, the mailing list might function as a thermometer as > to how an IRC meet would go if it were called for the same issue > >> - weekly status mail from the owners of major tasks > This would actually serve well if summed up monthly as to "what was achieved" Well both things would be nice, but have a serious problem: someone would need to write such stuff up -- that's a boring task which often nobody really wants to do. CU knurd From mmcgrath at redhat.com Wed Aug 15 13:14:08 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 15 Aug 2007 08:14:08 -0500 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <46C2C583.8060403@leemhuis.info> References: <46C1E839.4050002@leemhuis.info> <7e3d3af30708141041u1d2a80b7t2828aa2758310012@mail.gmail.com> <46C2C583.8060403@leemhuis.info> Message-ID: <46C2FC20.9030005@redhat.com> Thorsten Leemhuis wrote: > On 14.08.2007 19:41, Sankarshan Mukhopadhyay wrote: > >> On 8/14/07, Thorsten Leemhuis wrote: >> >> [massive snip] >> Nearly all projects face the same problems (some do sometimes, others to often) >> > > Sure -- but I was in FESCo for one year and there it worked much better. > Seems people were more interested in Extras then. > I think its just that since the work we've done has already been through FESCo, that there's just less for us to do. -Mike From fedora at leemhuis.info Wed Aug 15 13:19:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Aug 2007 15:19:53 +0200 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <46C2FC20.9030005@redhat.com> References: <46C1E839.4050002@leemhuis.info> <7e3d3af30708141041u1d2a80b7t2828aa2758310012@mail.gmail.com> <46C2C583.8060403@leemhuis.info> <46C2FC20.9030005@redhat.com> Message-ID: <46C2FD79.4000408@leemhuis.info> On 15.08.2007 15:14, Mike McGrath wrote: > Thorsten Leemhuis wrote: >> On 14.08.2007 19:41, Sankarshan Mukhopadhyay wrote: >> >>> On 8/14/07, Thorsten Leemhuis wrote: >>> [massive snip] >>> Nearly all projects face the same problems (some do sometimes, others to often) >> Sure -- but I was in FESCo for one year and there it worked much better. >> Seems people were more interested in Extras then. > I think its just that since the work we've done has already been through > FESCo, that there's just less for us to do. Well, yes, there is curently not as much to do in EPEL as for Extras in the past. But let me rephrase: The workflow in FESCo was much better -- more and more active people in the meetings and decisions didn't take that long to get done/realized. CU knurd From sheltren at cs.ucsb.edu Wed Aug 15 15:18:52 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 15 Aug 2007 08:18:52 -0700 Subject: EPEL report week 32 2007 In-Reply-To: <46C1E073.6030805@leemhuis.info> References: <46C1E073.6030805@leemhuis.info> Message-ID: On Aug 14, 2007, at 10:03 AM, Thorsten Leemhuis wrote: > > * yum for EPEL4 > > * Jeff_S will investigate if it's possible to ship yum without a > yum.conf This looks like it won't be a problem. I just rebuilt the yum package without including a yum.conf and it installs fine. I also removed the requires on 'yumconf' as that is something which is provided by the centos-release package but it's not in RHEL-4. Here's what happens when you run yum without a /etc/yum.conf file: # yum update Config Error: Error accessing file for config file:///etc/yum.conf You can get my updated yum package here: http://www.sheltren.com/epel/packages/yum-2.4.3-0.4.EL4.src.rpm sha1sum is in: http://www.sheltren.com/epel/packages/sha1sums.txt which is signed with my gpg key. -Jeff From kwade at redhat.com Wed Aug 15 17:21:27 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 15 Aug 2007 10:21:27 -0700 Subject: [RFC] communication plan Message-ID: <1187198487.6168.20.camel@erato.phig.org> What think all ye of this? http://fedoraproject.org/wiki/EPEL/CommunicationPlan Anything to add? To subtract? As for the Red Hat part, I don't feel empowered to speak for Red Hat on that point, but I haven't had luck finding someone with enough interest and time to own that message. It would need to be a product manager of some time, I think. I have recommendations on what *I* think it could say, but that is neither here nor there. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Aug 15 17:28:36 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 15 Aug 2007 10:28:36 -0700 Subject: [RFC] job description Message-ID: <1187198916.6168.27.camel@erato.phig.org> This is content that can be used (modified) to fit into a job description. http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription Is it complete? Clear? Too much? Too little? The idea is to allow an organization to maintain packages as part of the community, without worrying that someone is going to leave a specific job and not maintain the package any longer. Just like a job description might include which systems and services the job role supports, it can also include community package maintenance. We'd like to ratify this job description so we can suggest it to people. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rayvd at bludgeon.org Wed Aug 15 17:32:10 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 15 Aug 2007 10:32:10 -0700 Subject: To update or not to update... Message-ID: <20070815173210.GA9700@bludgeon.org> Hi all, so the (only) package I maintain, remind, has released a new version (from 3.0.24 to 3.1.0). There are some new features and some bug fixes: http://www.bludgeon.org/~rayvd/WHATSNEW However, per the update guidelines and policies, it doesn't appear to meet the criteria as an update that should be pushed (although maybe to the 5.1 and 4.6 releases) -- none of the bug fixes are "critical" really. That said, from observing the build reports, it seems as if a lot of people are pushing new upstream releases of their packages into the current version of EPEL (updates, not the new builds). It doesn't seem that all of these updates are in harmony with the update policies. I realize that probably very few will care if I end up pushing my update to 4.5 and 5.0, and nothing will break; but is this the right thing to do? Thanks for the clarification, Ray From kwade at redhat.com Wed Aug 15 17:47:05 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 15 Aug 2007 10:47:05 -0700 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <46C1E839.4050002@leemhuis.info> References: <46C1E839.4050002@leemhuis.info> Message-ID: <1187200025.6168.41.camel@erato.phig.org> On Tue, 2007-08-14 at 19:36 +0200, Thorsten Leemhuis wrote: > - somehow accept stuff on the mailing lists if possible. Kind of "send a > proposal, if some people give a "+1" on the list and no one objects from > the SIG within some days consider it accepted". Sure, it's often not > that easy and we needed to work out more details for such a scheme, but > it could be or something into that direction. That way the SIG or EPEL > contributors get more influence and we might need the Steering Committee > only if a decision can't be found +1 We really can do everything on list. The meetings are a reminder and decision force -- having a time to "make decisions" helps busy people remember to make them. We could have a rule that anything brought up green/brand-new on the list within the previous 48 hours of a meeting cannot be decided upon in that meeting. All other items that are undecided from the list from before the 48 hour window are fair game for deciding in a meeting. The idea is to have as much discussion and decision making asynchroniously, but not let the mailing list time drift go on too long. > - weekly status mail from the owners of major tasks +1 Deadline is five minutes before the meeting. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Aug 15 17:50:43 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 15 Aug 2007 10:50:43 -0700 Subject: To update or not to update... In-Reply-To: <20070815173210.GA9700@bludgeon.org> References: <20070815173210.GA9700@bludgeon.org> Message-ID: <1187200243.6168.44.camel@erato.phig.org> On Wed, 2007-08-15 at 10:32 -0700, Ray Van Dolson wrote: > That said, from observing the build reports, it seems as if a lot of > people are pushing new upstream releases of their packages into the > current version of EPEL (updates, not the new builds). It doesn't seem > that all of these updates are in harmony with the update policies. > > I realize that probably very few will care if I end up pushing my > update to 4.5 and 5.0, and nothing will break; but is this the right > thing to do? I don't know the answer for sure, but I think you are asking the right question. I haven't been watching the builds for enforcement. Do we need to do that? Are we going to be constantly reminding people not to wantonly update in EPEL? We need to resolve this before we suddenly have a broken, sodden mess due to people following this policy differently. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Aug 15 17:51:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Aug 2007 19:51:13 +0200 Subject: To update or not to update... In-Reply-To: <20070815173210.GA9700@bludgeon.org> References: <20070815173210.GA9700@bludgeon.org> Message-ID: <46C33D11.9050604@leemhuis.info> On 15.08.2007 19:32, Ray Van Dolson wrote: > Hi all, so the (only) package I maintain, remind, has released a new > version (from 3.0.24 to 3.1.0). There are some new features and some > bug fixes: > > http://www.bludgeon.org/~rayvd/WHATSNEW > > However, per the update guidelines and policies, it doesn't appear to > meet the criteria as an update that should be pushed (although maybe to > the 5.1 and 4.6 releases) -- none of the bug fixes are "critical" > really. >From this description I'd say: don't update. > That said, from observing the build reports, it seems as if a lot of > people are pushing new upstream releases of their packages into the > current version of EPEL (updates, not the new builds). It doesn't seem > that all of these updates are in harmony with the update policies. I noticed that also and put a "poke those people and point them to the EPEL update guidelines" on my todo-list. The current behavior might be acceptable for the current phase where EPEL is still young, but if people really want a repo that ships more up2date packages I'd say we start EPEL-rolling in parallel with EPEL-stable (e.g. a repo on top of epel-stable). A repo where some packages stay stable while others are updated to the latest and greatest is a mix that won't make people happy, as those that are those that are interested in a "a stable base" and those that want "latest and greatest" both don't get what they want. IOW: we should pick a side (and we did), as something in between is bad. > [...] Cu thl From mastahnke at gmail.com Wed Aug 15 18:07:19 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 15 Aug 2007 13:07:19 -0500 Subject: [RFC] job description In-Reply-To: <1187198916.6168.27.camel@erato.phig.org> References: <1187198916.6168.27.camel@erato.phig.org> Message-ID: <7874d9dd0708151107w20bc60c8tc1a91fd90c8abbc5@mail.gmail.com> > The EPEL project synchronizes packages with specific release of Red Hat Enterprise Linux. >To maintain an EPEL package, you must help maintain the synchronization against at least >the one specific version of Red Hat Enterprise Linux. You can do this using Red Hat's build >or any other build, such as CentOS. > We may want to say or Red Hat derrived build. Ubuntu Server and such won't quite work with EPEL. I am not sure how than can be worded safely though. stahnma From kwade at redhat.com Wed Aug 15 18:43:12 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 15 Aug 2007 11:43:12 -0700 Subject: [RFC] job description In-Reply-To: <7874d9dd0708151107w20bc60c8tc1a91fd90c8abbc5@mail.gmail.com> References: <1187198916.6168.27.camel@erato.phig.org> <7874d9dd0708151107w20bc60c8tc1a91fd90c8abbc5@mail.gmail.com> Message-ID: <1187203392.6168.74.camel@erato.phig.org> On Wed, 2007-08-15 at 13:07 -0500, Michael Stahnke wrote: > > The EPEL project synchronizes packages with specific release of Red Hat Enterprise Linux. >To maintain an EPEL package, you must help maintain the synchronization against at least >the one specific version of Red Hat Enterprise Linux. You can do this using Red Hat's build >or any other build, such as CentOS. > > > We may want to say or Red Hat derrived build. Ubuntu Server and such > won't quite work with EPEL. I am not sure how than can be worded > safely though. Well, the wording I originally wrote assumes knowledge of the relation between RHEL and derivative/repackaging distributions. Obviously a bad assumption, feel free to correct it and move on. There really isn't a concern about safe wording. If you think it matters, include that there is not requirement to support non-RHEL-based distros (such as Debian derivatives, Gentoo derivatives, etc.) - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Wed Aug 15 20:06:03 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 15 Aug 2007 14:06:03 -0600 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <20070815024018.9F536152131@buildsys.fedoraproject.org> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> Message-ID: <46C35CAB.9040806@cora.nwra.com> buildsys at fedoraproject.org wrote: > Packages built and released for Fedora EPEL 5: 77 > > NEW arj-3.10.22-3.el5 : Archiver for .arj files > NEW audio-entropyd-1.0.0-4.el5.2 : Generate entropy from audio output > NEW cabextract-1.1-5.el5 : Utility for extracting cabinet (.cab) archives Perhaps NEW packages can get automatically moved from "testing" into the current release tree? I know I'm still trying to build up all of my Fedora packages for EPEL. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From mmcgrath at redhat.com Wed Aug 15 20:12:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 15 Aug 2007 15:12:00 -0500 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <46C35CAB.9040806@cora.nwra.com> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> <46C35CAB.9040806@cora.nwra.com> Message-ID: <46C35E10.600@redhat.com> Orion Poplawski wrote: > buildsys at fedoraproject.org wrote: >> Packages built and released for Fedora EPEL 5: 77 >> >> NEW arj-3.10.22-3.el5 : Archiver for .arj files >> NEW audio-entropyd-1.0.0-4.el5.2 : Generate entropy from audio output >> NEW cabextract-1.1-5.el5 : Utility for extracting cabinet (.cab) >> archives > > Perhaps NEW packages can get automatically moved from "testing" into > the current release tree? I know I'm still trying to build up all of > my Fedora packages for EPEL. This was brought up in #EPEL earlier today and I'd like to hear further discussion from people on the list. On the one hand. EPEL has to get installed and its not hard for people to install both the EPEL and testing repo at the same time. Some might argue that it discourages new contributors and new packages from being built. By pushing new packages, we are risking dep solving issues so our scripts would have to be changed (yet again). Anyway, I'm right on the line with this one (because I'm happy to enable the testing repo) What do you the rest of you think? -Mike From rob.myers at gtri.gatech.edu Wed Aug 15 21:21:25 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Wed, 15 Aug 2007 17:21:25 -0400 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <46C35E10.600@redhat.com> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> <46C35CAB.9040806@cora.nwra.com> <46C35E10.600@redhat.com> Message-ID: <1187212885.3882.25.camel@rxm-581b.stl.gtri.gatech.edu> On Wed, 2007-08-15 at 15:12 -0500, Mike McGrath wrote: > Orion Poplawski wrote: > > buildsys at fedoraproject.org wrote: > >> Packages built and released for Fedora EPEL 5: 77 > >> > >> NEW arj-3.10.22-3.el5 : Archiver for .arj files > >> NEW audio-entropyd-1.0.0-4.el5.2 : Generate entropy from audio output > >> NEW cabextract-1.1-5.el5 : Utility for extracting cabinet (.cab) > >> archives > > > > Perhaps NEW packages can get automatically moved from "testing" into > > the current release tree? I know I'm still trying to build up all of > > my Fedora packages for EPEL. > > This was brought up in #EPEL earlier today and I'd like to hear further > discussion from people on the list. > > On the one hand. EPEL has to get installed and its not hard for people > to install both the EPEL and testing repo at the same time. Some might > argue that it discourages new contributors and new packages from being > built. > > By pushing new packages, we are risking dep solving issues so our > scripts would have to be changed (yet again). Anyway, I'm right on the > line with this one (because I'm happy to enable the testing repo) > > What do you the rest of you think? I don't want to deal with dep solving issues. It is more important to me for EPEL to be stable than to have the latest foo package. That said, perhaps there should be a process by which overwhelmingly fantastic packages could make the transition from "testing" to "current" independent of RHEL minor releases. I'd prefer that to be the exception rather than the rule. rob. From mmcgrath at redhat.com Wed Aug 15 21:25:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 15 Aug 2007 16:25:19 -0500 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <1187212885.3882.25.camel@rxm-581b.stl.gtri.gatech.edu> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> <46C35CAB.9040806@cora.nwra.com> <46C35E10.600@redhat.com> <1187212885.3882.25.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <46C36F3F.70104@redhat.com> rob myers wrote: > On Wed, 2007-08-15 at 15:12 -0500, Mike McGrath wrote: > >> What do you the rest of you think? >> > > I don't want to deal with dep solving issues. It is more important to > me for EPEL to be stable than to have the latest foo package. That > said, perhaps there should be a process by which overwhelmingly > fantastic packages could make the transition from "testing" to "current" > independent of RHEL minor releases. I'd prefer that to be the exception > rather than the rule. > Well, in theory, you as a user shouldn't have dep solving issues. The problem is getting our scripts to realize proper dep solving (which includes logic and commands that we just aren't using now). -Mike From rob.myers at gtri.gatech.edu Wed Aug 15 21:30:23 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Wed, 15 Aug 2007 17:30:23 -0400 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <46C36F3F.70104@redhat.com> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> <46C35CAB.9040806@cora.nwra.com> <46C35E10.600@redhat.com> <1187212885.3882.25.camel@rxm-581b.stl.gtri.gatech.edu> <46C36F3F.70104@redhat.com> Message-ID: <1187213423.3882.26.camel@rxm-581b.stl.gtri.gatech.edu> On Wed, 2007-08-15 at 16:25 -0500, Mike McGrath wrote: > rob myers wrote: > > On Wed, 2007-08-15 at 15:12 -0500, Mike McGrath wrote: > > > >> What do you the rest of you think? > >> > > > > I don't want to deal with dep solving issues. It is more important to > > me for EPEL to be stable than to have the latest foo package. That > > said, perhaps there should be a process by which overwhelmingly > > fantastic packages could make the transition from "testing" to "current" > > independent of RHEL minor releases. I'd prefer that to be the exception > > rather than the rule. > > > > Well, in theory, you as a user shouldn't have dep solving issues. The > problem is getting our scripts to realize proper dep solving (which > includes logic and commands that we just aren't using now). good point. enhance the scripts, and i'll strike that part of my concerns. ;) rob. From fedora at leemhuis.info Thu Aug 16 04:49:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Aug 2007 06:49:43 +0200 Subject: Fedora EPEL Package Build Report 2007-08-14 In-Reply-To: <46C35E10.600@redhat.com> References: <20070815024018.9F536152131@buildsys.fedoraproject.org> <46C35CAB.9040806@cora.nwra.com> <46C35E10.600@redhat.com> Message-ID: <46C3D767.3000008@leemhuis.info> On 15.08.2007 22:12, Mike McGrath wrote: > Orion Poplawski wrote: >> buildsys at fedoraproject.org wrote: >>> Packages built and released for Fedora EPEL 5: 77 >>> >>> NEW arj-3.10.22-3.el5 : Archiver for .arj files >>> NEW audio-entropyd-1.0.0-4.el5.2 : Generate entropy from audio output >>> NEW cabextract-1.1-5.el5 : Utility for extracting cabinet (.cab) >>> archives >> Perhaps NEW packages can get automatically moved from "testing" into >> the current release tree? I know I'm still trying to build up all of >> my Fedora packages for EPEL. > > This was brought up in #EPEL earlier today and I'd like to hear further > discussion from people on the list. > > On the one hand. EPEL has to get installed and its not hard for people > to install both the EPEL and testing repo at the same time. Some might > argue that it discourages new contributors and new packages from being > built. > > By pushing new packages, we are risking dep solving issues so our > scripts would have to be changed (yet again). Anyway, I'm right on the > line with this one (because I'm happy to enable the testing repo) > > What do you the rest of you think? /me votes for "leave them in testing" The risk of broken deps is high with the current scripts. And even if the scripts would catch it -- all newly build packages can have problems on their own, so it's IMHO better to have a testing period for them. BTW, in RHEL you also get new packages only with the quarterly updates (like yum-utils in 5.1). CU knurd From sundaram at fedoraproject.org Thu Aug 16 08:39:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 14:09:58 +0530 Subject: To update or not to update... In-Reply-To: <46C33D11.9050604@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> Message-ID: <46C40D5E.3050701@fedoraproject.org> Thorsten Leemhuis wrote: > A repo where some packages stay stable while others are updated to the > latest and greatest is a mix that won't make people happy, as those that > are those that are interested in a "a stable base" and those that want > "latest and greatest" both don't get what they want. On the other hand this is what happens within the base product too. The desktop apps and treated different from system apps for example. You might want to consider having a policy that differentiates between them. Rahul From sundaram at fedoraproject.org Thu Aug 16 08:41:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 14:11:02 +0530 Subject: [RFC] job description In-Reply-To: <7874d9dd0708151107w20bc60c8tc1a91fd90c8abbc5@mail.gmail.com> References: <1187198916.6168.27.camel@erato.phig.org> <7874d9dd0708151107w20bc60c8tc1a91fd90c8abbc5@mail.gmail.com> Message-ID: <46C40D9E.6060904@fedoraproject.org> Michael Stahnke wrote: >> The EPEL project synchronizes packages with specific release of Red Hat Enterprise Linux. >To maintain an EPEL package, you must help maintain the synchronization against at least >the one specific version of Red Hat Enterprise Linux. You can do this using Red Hat's build >or any other build, such as CentOS. >> > We may want to say or Red Hat derrived build. Ubuntu Server and such > won't quite work with EPEL. I am not sure how than can be worded > safely though. "Red Hat Enterprise Linux and compatible derivatives" Rahul From fedora at leemhuis.info Thu Aug 16 09:02:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Aug 2007 11:02:26 +0200 Subject: To update or not to update... In-Reply-To: <46C40D5E.3050701@fedoraproject.org> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> Message-ID: <46C412A2.2040808@leemhuis.info> On 16.08.2007 10:39, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > >> A repo where some packages stay stable while others are updated to the >> latest and greatest is a mix that won't make people happy, as those that >> are those that are interested in a "a stable base" and those that want >> "latest and greatest" both don't get what they want. > > On the other hand this is what happens within the base product too. The > desktop apps and treated different from system apps for example. Could you or somebody else outline the scheme RHEL uses in more detail? Is it anywhere written down? > You > might want to consider having a policy that differentiates between them. AFAICS the current RHEL-scheme is similar to what the EPEL policy says already: If there are very strong reason to update something to a new major version then go for it with the next quarterly update. But the bulk of packages doesn't get updates to the latest major version. Further: I don't think a more detailed "policy" makes sense -- I'd say we should discuss all "major update: yes or no?" for EPEL on a case by case basis here on the list. In RHEL I suppose it's similar: a release-engineer (or whatever the individual or group is called) likely has to ACK major updates there as well. CU knurd From sundaram at fedoraproject.org Thu Aug 16 12:06:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 17:36:11 +0530 Subject: To update or not to update... In-Reply-To: <46C412A2.2040808@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> <46C412A2.2040808@leemhuis.info> Message-ID: <46C43DB3.70709@fedoraproject.org> Thorsten Leemhuis wrote: > > On 16.08.2007 10:39, Rahul Sundaram wrote: >> Thorsten Leemhuis wrote: >> >>> A repo where some packages stay stable while others are updated to the >>> latest and greatest is a mix that won't make people happy, as those that >>> are those that are interested in a "a stable base" and those that want >>> "latest and greatest" both don't get what they want. >> On the other hand this is what happens within the base product too. The >> desktop apps and treated different from system apps for example. > > Could you or somebody else outline the scheme RHEL uses in more detail? > Is it anywhere written down? Not anywhere publicly afaik but I don't think a lot of it would apply to EPEL anyway as we cannot expect EPEL maintainers to be doing a lot of backporting. If I maintain a package which is written in a language or code I am not very familiar with and it has a critical security along with other major changes, I am going to pull in all of that and fix the issue anyway. The general idea is that the risk of breakage in a core component or library is large and the benefit is small when compared to desktop or leaf applications so be more conservative in the former and slightly more liberal in the latter. > Further: I don't think a more detailed "policy" makes sense -- I'd say > we should discuss all "major update: yes or no?" for EPEL on a case by > case basis here on the list. In RHEL I suppose it's similar: a > release-engineer (or whatever the individual or group is called) likely > has to ACK major updates there as well. RHEL follows a model which involves engineers, product management (which depends on customer input) and QA and depending on the package, the individual backported patches has to be reviewed with multiple engineers other than the person doing the work. Obviously this requires resources we don't have in EPEL. Maintainers should probably be trusted to make the best judgments in EPEL keeping in mind that less churn is more desirable. If you aren't sure, don't update. Rahul From fedora at leemhuis.info Thu Aug 16 12:39:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Aug 2007 14:39:56 +0200 Subject: To update or not to update... In-Reply-To: <46C43DB3.70709@fedoraproject.org> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> <46C412A2.2040808@leemhuis.info> <46C43DB3.70709@fedoraproject.org> Message-ID: <46C4459C.9080504@leemhuis.info> On 16.08.2007 14:06, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 16.08.2007 10:39, Rahul Sundaram wrote: >>> Thorsten Leemhuis wrote: >>> >>>> A repo where some packages stay stable while others are updated to the >>>> latest and greatest is a mix that won't make people happy, as those that >>>> are those that are interested in a "a stable base" and those that want >>>> "latest and greatest" both don't get what they want. >>> On the other hand this is what happens within the base product too. The >>> desktop apps and treated different from system apps for example. >> Could you or somebody else outline the scheme RHEL uses in more detail? >> Is it anywhere written down? > Not anywhere publicly afaik but I don't think a lot of it would apply to > EPEL anyway as we cannot expect EPEL maintainers to be doing a lot of > backporting. "update to latest version instead of backporting" is allowed by the EPEL policy to fix a important bug. But the mail that started this thread wasn't about fixing a important bug. But we drift away. > [...] >> Further: I don't think a more detailed "policy" makes sense -- I'd say >> we should discuss all "major update: yes or no?" for EPEL on a case by >> case basis here on the list. In RHEL I suppose it's similar: a >> release-engineer (or whatever the individual or group is called) likely >> has to ACK major updates there as well. > RHEL follows a model which involves engineers, product management (which > depends on customer input) and QA and depending on the package, the > individual backported patches has to be reviewed with multiple engineers > other than the person doing the work. Obviously this requires resources > we don't have in EPEL. Sure. But we have a mailing list and sending a "what do you guys think: should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar" is not that much overhead IMHO. > Maintainers should probably be trusted to make the best judgments in > EPEL keeping in mind that less churn is more desirable. [...] I'd like to agree, but seems at least some people simply build new stuff for EPEL and don't care (or don't know) about the "only update to new version if there is a strong need to" policy which EPEL has. So we sooner or later need tell those maintainers to be more careful, adjust our policy/goals, start EPEL-rolling in parallel, or live with the fact that parts of the EPEL-stable repo follow the a rolling-release scheme similar to Fedora while other parts go for the careful RHEL-style. The latter would IMHO be quite bad, and I really don#t want us to go in that direction. CU knurd From sundaram at fedoraproject.org Thu Aug 16 12:47:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 18:17:14 +0530 Subject: To update or not to update... In-Reply-To: <46C4459C.9080504@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> <46C412A2.2040808@leemhuis.info> <46C43DB3.70709@fedoraproject.org> <46C4459C.9080504@leemhuis.info> Message-ID: <46C44752.8010009@fedoraproject.org> Thorsten Leemhuis wrote: > > Sure. But we have a mailing list and sending a "what do you guys think: > should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar" > is not that much overhead IMHO. Yes but in many cases the people most qualified to make that determination are those maintaining the packages. If you want to explicitly document that maintainers have the choice to ask in this list, that would be a good thing to do. > > I'd like to agree, but seems at least some people simply build new stuff > for EPEL and don't care (or don't know) about the "only update to new > version if there is a strong need to" policy which EPEL has. So we > sooner or later need tell those maintainers to be more careful, adjust > our policy/goals, start EPEL-rolling in parallel, possibilities> or live with the fact that parts of the EPEL-stable repo > follow the a rolling-release scheme similar to Fedora while other parts > go for the careful RHEL-style. The latter would IMHO be quite bad, and I > really don#t want us to go in that direction. Watch changes. If you see maintainers pushing updates where it isn't required then engage them in a private discussion. Maybe they have reasons to update which wasn't obvious. Maybe there wasn't aware of the policy or thought that this particular instance needed a exception for valid reasons. Lets see if there are problems to be solved before attempting to solve any. Rahul From mastahnke at gmail.com Fri Aug 17 13:46:47 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 17 Aug 2007 08:46:47 -0500 Subject: To update or not to update... In-Reply-To: <46C44752.8010009@fedoraproject.org> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> <46C412A2.2040808@leemhuis.info> <46C43DB3.70709@fedoraproject.org> <46C4459C.9080504@leemhuis.info> <46C44752.8010009@fedoraproject.org> Message-ID: <7874d9dd0708170646i47b3fd73we2b196c46504d138@mail.gmail.com> On 8/16/07, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > > > > Sure. But we have a mailing list and sending a "what do you guys think: > > should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar" > > is not that much overhead IMHO. > > Yes but in many cases the people most qualified to make that > determination are those maintaining the packages. If you want to > explicitly document that maintainers have the choice to ask in this > list, that would be a good thing to do. > > > > I'd like to agree, but seems at least some people simply build new stuff > > for EPEL and don't care (or don't know) about the "only update to new > > version if there is a strong need to" policy which EPEL has. So we > > sooner or later need tell those maintainers to be more careful, adjust > > our policy/goals, start EPEL-rolling in parallel, > possibilities> or live with the fact that parts of the EPEL-stable repo > > follow the a rolling-release scheme similar to Fedora while other parts > > go for the careful RHEL-style. The latter would IMHO be quite bad, and I > > really don#t want us to go in that direction. > > Watch changes. If you see maintainers pushing updates where it isn't > required then engage them in a private discussion. Maybe they have > reasons to update which wasn't obvious. Maybe there wasn't aware of the > policy or thought that this particular instance needed a exception for > valid reasons. Lets see if there are problems to be solved before > attempting to solve any. > > Rahul > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > I am enjoying this discussion. Both sides have very good points. As for my opinion, I think that new packages can go to stable (assuming deps are there) and updates, can sit until major update. I am sure this has flaws, (deps in particular). I feel that EPEL isn't too usable yet for an EL customer. There just are not enough packges. I don't think we should have more barriers to get packages in. I know customer could enable testing, but if they felt ok enabling testing, they probably wouldn't be running on RHEL/EL. I understand what EPEL/Fedora testing means, customers hear testing and stay away. stahnma From mastahnke at gmail.com Fri Aug 17 13:49:51 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 17 Aug 2007 08:49:51 -0500 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <1187200025.6168.41.camel@erato.phig.org> References: <46C1E839.4050002@leemhuis.info> <1187200025.6168.41.camel@erato.phig.org> Message-ID: <7874d9dd0708170649x301ff2acj244f388bedf0add2@mail.gmail.com> > > - weekly status mail from the owners of major tasks > > +1 > > Deadline is five minutes before the meeting. Was this part a joke? I couldn't tell from email :) I have no problems getting things done on the list. (At least I can read that when I get to it). stahnma From fedora at leemhuis.info Fri Aug 17 16:09:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Aug 2007 18:09:14 +0200 Subject: To update or not to update... In-Reply-To: <7874d9dd0708170646i47b3fd73we2b196c46504d138@mail.gmail.com> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> <46C412A2.2040808@leemhuis.info> <46C43DB3.70709@fedoraproject.org> <46C4459C.9080504@leemhuis.info> <46C44752.8010009@fedoraproject.org> <7874d9dd0708170646i47b3fd73we2b196c46504d138@mail.gmail.com> Message-ID: <46C5C82A.4070206@leemhuis.info> On 17.08.2007 15:46, Michael Stahnke wrote: > [...] > I am enjoying this discussion. Both sides have very good points. As > for my opinion, I think that new packages We more and more discuss two different things in this thread: "to update a existing package" and "ship new packages in stable directly" > can go to stable (assuming deps are there) I'd be fine with this, as long as they have been in testing for a while (some weeks maybe) -- I consider "testing" a kind of beta-stage, that allows packers as well as others interested in EPEL to test the software before it hits the proper repo. I really think such a timeperiod is needed to make sure packagers are actually working. > and updates, can sit until major update. I am sure > this has flaws, (deps in particular). Well, if someone volunteers to find a way (script, manually, ...) to push new packages that were in testing for a while from testing to stable while making sure all deps are still satisfied I'd say: go for it. > I feel that EPEL isn't too > usable yet for an EL customer. There just are not enough packges. I > don't think we should have more barriers to get packages in. I know > customer could enable testing, but if they felt ok enabling testing, > they probably wouldn't be running on RHEL/EL. I understand what > EPEL/Fedora testing means, customers hear testing and stay away. At the same time it's IMHO especially for EPEL very important to ship quality right from the start, as we are currently still "building the new brand 'EPEL'" phase. The view and impression others get about (?) us now and in hte next months will be our fame for the next years. CU knurd (?) -- s/about/on/ ? Sorry, seems I always get this wrong. From mmcgrath at redhat.com Fri Aug 17 16:18:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 17 Aug 2007 11:18:16 -0500 Subject: To update or not to update... In-Reply-To: <46C5C82A.4070206@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C33D11.9050604@leemhuis.info> <46C40D5E.3050701@fedoraproject.org> <46C412A2.2040808@leemhuis.info> <46C43DB3.70709@fedoraproject.org> <46C4459C.9080504@leemhuis.info> <46C44752.8010009@fedoraproject.org> <7874d9dd0708170646i47b3fd73we2b196c46504d138@mail.gmail.com> <46C5C82A.4070206@leemhuis.info> Message-ID: <46C5CA48.7070700@redhat.com> Thorsten Leemhuis wrote: > On 17.08.2007 15:46, Michael Stahnke wrote: > >> [...] >> I am enjoying this discussion. Both sides have very good points. As >> for my opinion, I think that new packages >> > > We more and more discuss two different things in this thread: "to update > a existing package" and "ship new packages in stable directly" > > >> can go to stable (assuming deps are there) >> > > I'd be fine with this, as long as they have been in testing for a while > (some weeks maybe) -- I consider "testing" a kind of beta-stage, that > allows packers as well as others interested in EPEL to test the software > before it hits the proper repo. > What we're really talking about here is QA. Leaving things in testing is sort of an automated way of doing QA. We call it "testing" and people know it might not work, they don't have any expectation that it will work. At the same time, hopefully, people are using the package and reporting bugs. Implementing an actual QA process is very difficult and requires a lot of commitment. And, unfortunately, shipping straight from build and high quality "enterprise" stuff (even if its new packages) are just conflicting ideas. Though I agree, leaving packages in testing might deter new contributors. Its a tricky situation. -Mike From mdehaan at redhat.com Fri Aug 17 19:03:00 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 17 Aug 2007 15:03:00 -0400 Subject: To update or not to update... In-Reply-To: <20070815173210.GA9700@bludgeon.org> References: <20070815173210.GA9700@bludgeon.org> Message-ID: <46C5F0E4.9040401@redhat.com> I'm in favor of having enabling a more frequent update process for those who choose it. Right now, that seems to be "testing" but it's not. As implemented "testing" can be a mix of very new untested packages and some that are probably in great shape. When an admin adds "testing" as a repo, he gets the possibility for both. Debian has solved this. This is why Debian has the multi-level system: experimental -- I just updated this package, it may eat your brane unstable -- I think this will work, it's been in experimental for __X__ unit time without problems testing -- I confidentially stand behind this package, it's been in unstable for __Y__ unit time without problems stable -- really really stable Please ignore the Debian release schedule. The process works very well for users, regardless of what "X" and "Y" are. As the community size increases, I imagine "X" and "Y" can be made smaller. Users get to pick how much they want to live on the edge. I can confidentally run "testing" at home knowing very little (if anything) will ever break. I can probably even run "unstable" and be pretty safe. So, what we are currently doing is treating EPEL's "testing" as Debian experimental and EPEL's "stable" as "stable". What I would propose is the following compromise: experimental --- all new updates go here testing -- pushable if no defects in experimental for 2 weeks stable -- pushed quarterly We can basically do most of this with bohdi now. Later, we can add the requirement that a package needs either "X" weeks in experimental or so many people vouching for it to go in stable. Or whatever. The point is -- folks run RHEL for a stable base. But it is not just a boxed product. It's a platform. People should be able to choose what they do with it, and not be stuck running old&stale EPEL packages if they want some assurance of stability, however minimal. This doesn't need a QA team to implement -- it just requires one extra level in bohdi, and a bit of practice around it. --Michael DeHaan From limb at jcomserv.net Fri Aug 17 18:49:20 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 17 Aug 2007 13:49:20 -0500 (CDT) Subject: To update or not to update... In-Reply-To: <46C5F0E4.9040401@redhat.com> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> Message-ID: <2999.65.192.24.164.1187376560.squirrel@mail.jcomserv.net> > I'm in favor of having enabling a more frequent update process for those > who choose it. Right now, that seems to be "testing" but it's not. As > implemented "testing" > can be a mix of very new untested packages and some that are probably in > great shape. > > When an admin adds "testing" as a repo, he gets the possibility for both. > > Debian has solved this. > > This is why Debian has the multi-level system: > > experimental -- I just updated this package, it may eat your brane > unstable -- I think this will work, it's been in experimental for __X__ > unit time without problems > testing -- I confidentially stand behind this package, it's been in > unstable for __Y__ unit time without problems > stable -- really really stable > > Please ignore the Debian release schedule. The process works very well > for users, regardless of what "X" and "Y" are. As the > community size increases, I imagine "X" and "Y" can be made smaller. > > Users get to pick how much they want to live on the edge. I can > confidentally run "testing" at home knowing very little (if anything) > will ever break. I can probably even run "unstable" and be pretty safe. > > So, what we are currently doing is treating EPEL's "testing" as Debian > experimental and EPEL's "stable" as "stable". > > What I would propose is the following compromise: > > > experimental --- all new updates go here > testing -- pushable if no defects in experimental for 2 weeks > stable -- pushed quarterly > > We can basically do most of this with bohdi now. > > Later, we can add the requirement that a package needs either "X" weeks > in experimental or so many people vouching > for it to go in stable. Or whatever. > > The point is -- folks run RHEL for a stable base. But it is not just a > boxed product. It's a platform. People should be able to > choose what they do with it, and not be stuck running old&stale EPEL > packages if they want some assurance of stability, however > minimal. > > This doesn't need a QA team to implement -- it just requires one extra > level in bohdi, and a bit of practice around it. +1. In the current world, how do we get a package out of testing? I know I still have one with a broken dep, but once that's fixed. .. > --Michael DeHaan > > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- novus ordo absurdum From rayvd at bludgeon.org Fri Aug 17 19:14:08 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 17 Aug 2007 12:14:08 -0700 Subject: To update or not to update... In-Reply-To: <46C5F0E4.9040401@redhat.com> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> Message-ID: <20070817191408.GA18063@bludgeon.org> > The point is -- folks run RHEL for a stable base. But it is not just a boxed > product. It's a platform. People should be able to > choose what they do with it, and not be stuck running old&stale EPEL > packages if they want some assurance of stability, however > minimal. >From a user standpoint, I think this is very true. I like the stability of RHEL, but sometimes I do end up wanting a feature of a recently updated upstream project, and either have to rebuild an SRPM from Fedora, go to another repo or build from source. Also, in my case with remind, it's not a library with an ABI that people are linking against that might break, it's just an application. I suppose a change in the feature-set could break remind scripts however. But having the option at least, and from a trustworthy source like EPEL, to track somewhat-latest versions of packages of our choosing would be nice. But maybe it makes for too much of a grey area? Ray From fedora at leemhuis.info Sat Aug 18 11:51:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Aug 2007 13:51:43 +0200 Subject: To update or not to update... In-Reply-To: <2999.65.192.24.164.1187376560.squirrel@mail.jcomserv.net> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <2999.65.192.24.164.1187376560.squirrel@mail.jcomserv.net> Message-ID: <46C6DD4F.9030305@leemhuis.info> Hi! On 17.08.2007 20:49, Jon Ciesla wrote: > [...] >> Debian has solved this. >> >> This is why Debian has the multi-level system: We IMHO have a multi-level-system as well if you look at the big picture. It's similar, but not exactly the same >> experimental -- I just updated this package, it may eat your brane Fedora rawhide. >> unstable -- I think this will work, it's been in experimental for __X__ >> unit time without problems Fedora test releases . >> testing -- I confidentially stand behind this package, it's been in >> unstable for __Y__ unit time without problems >> stable -- really really stable here we are more different. we have - stable Fedora releases (Core + Extras in the past), which gets update that come from testing, but not supporterd for longer time-periods - stable RHEL releases + stable EPEL releases; new RHEL releases (5.1, ...) get tested in Betas (RHEL 5.1 Beta is out now); new EPEL packages get tested in testing > [...] >> So, what we are currently doing is treating EPEL's "testing" as Debian >> experimental and EPEL's "stable" as "stable". Nope -- experimental is Fedora rawhide, Fedora release, where stuff that hits EPEL should get tested and shipped first. EPEL-testing is a kind of beta-phase before things that were tested in Fedora hit EPEL stable. >> What I would propose is the following compromise: >> >> experimental --- all new updates go here >> testing -- pushable if no defects in experimental for 2 weeks >> stable -- pushed quarterly I think it's to much overhead for a small gain. We have bigger problems to solve first IMHO. >> We can basically do most of this with bohdi now. Which we can't use without koji, which needs to be modifies before we can use it. > [...] > +1. In the current world, how do we get a package out of testing? I know > I still have one with a broken dep, but once that's fixed. .. It's written in the guidelines. New packages get into the repo with a quarterly update -- just as RHEL does it in RHEL updates now and then. I multiple times asked in the past to do it a bit more often (e.g. every two months maybe), but that's still under discussion. CU knurd From fedora at leemhuis.info Sat Aug 18 12:04:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Aug 2007 14:04:53 +0200 Subject: To update or not to update... In-Reply-To: <20070817191408.GA18063@bludgeon.org> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <20070817191408.GA18063@bludgeon.org> Message-ID: <46C6E065.5030707@leemhuis.info> On 17.08.2007 21:14, Ray Van Dolson wrote: >> The point is -- folks run RHEL for a stable base. But it is not just a boxed >> product. It's a platform. People should be able to >> choose what they do with it, and not be stuck running old&stale EPEL >> packages if they want some assurance of stability, however >> minimal. > >>From a user standpoint, I think this is very true. I like the > stability of RHEL, but sometimes I do end up wanting a feature of a > recently updated upstream project, and either have to rebuild an SRPM > from Fedora, go to another repo or build from source. The main problem IMHO is: what part of the "stable base" for user foo might be the package where user bar "wants a feature of a recently updated upstream project". There is no way with current tools to serve both users in one repo. But we could do it in two repos -- one stable EPEL repo and a "EPEL rolling" on top of it -- then users could individually select which software they want in newer versions. I think that's exactly what we should do in the long term, but I don't think we have the man-power yet to maintain both repos, so we concentrate on the EPEL stable stuff atm, as that's IMHO more important stuff users of RHEL or use CentOS want and are used to. Cu knurd From mastahnke at gmail.com Sat Aug 18 15:09:10 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 18 Aug 2007 10:09:10 -0500 Subject: To update or not to update... In-Reply-To: <46C6E065.5030707@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <20070817191408.GA18063@bludgeon.org> <46C6E065.5030707@leemhuis.info> Message-ID: <7874d9dd0708180809j42cd77b7o46c640542588f857@mail.gmail.com> > But we could do it in two repos -- one stable EPEL repo and a "EPEL > rolling" on top of it -- then users could individually select which > software they want in newer versions. If I want a rolling upstream, why am I using EL? You use a EL to avoid quick releases and be on supported ABI compatible versions of X,Y,Z for long periods of time. The notable exceptions are things like a LAMP stack, but RH provides subscriptions and updates to that more frequently on EL. A rolling repo should just be a symlink to Fedora. That's why Fedora exists. stahnma > From pertusus at free.fr Sat Aug 18 15:19:49 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 18 Aug 2007 17:19:49 +0200 Subject: To update or not to update... In-Reply-To: <7874d9dd0708180809j42cd77b7o46c640542588f857@mail.gmail.com> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <20070817191408.GA18063@bludgeon.org> <46C6E065.5030707@leemhuis.info> <7874d9dd0708180809j42cd77b7o46c640542588f857@mail.gmail.com> Message-ID: <20070818151949.GA2631@free.fr> On Sat, Aug 18, 2007 at 10:09:10AM -0500, Michael Stahnke wrote: > > But we could do it in two repos -- one stable EPEL repo and a "EPEL > > rolling" on top of it -- then users could individually select which > > software they want in newer versions. > > If I want a rolling upstream, why am I using EL? You use a EL to > avoid quick releases and be on supported ABI compatible versions of > X,Y,Z for long periods of time. The notable exceptions are things > like a LAMP stack, but RH provides subscriptions and updates to that > more frequently on EL. We cannot rely on RH for packages in EPEL that have are similar with LAMP stack with respect with updating. > A rolling repo should just be a symlink to Fedora. That's why Fedora exists. Not exaclty. It would maybe share some similarities with fedora but without a need to upgrade the base os. That's completly different. It isn't clear to me that it is very usefull, though, but it certainly adds something. And also you may also want to keep ABI compatibility while still updating more rapidly some parts, the desktop for example. -- Pat From fedora at leemhuis.info Sat Aug 18 15:33:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Aug 2007 17:33:51 +0200 Subject: To update or not to update... In-Reply-To: <7874d9dd0708180809j42cd77b7o46c640542588f857@mail.gmail.com> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <20070817191408.GA18063@bludgeon.org> <46C6E065.5030707@leemhuis.info> <7874d9dd0708180809j42cd77b7o46c640542588f857@mail.gmail.com> Message-ID: <46C7115F.8090309@leemhuis.info> On 18.08.2007 17:09, Michael Stahnke wrote: >> But we could do it in two repos -- one stable EPEL repo and a "EPEL >> rolling" on top of it -- then users could individually select which >> software they want in newer versions. > > If I want a rolling upstream, why am I using EL? You use a EL to > avoid quick releases and be on supported ABI compatible versions of > X,Y,Z for long periods of time. The notable exceptions are things > like a LAMP stack, but RH provides subscriptions and updates to that > more frequently on EL. > > A rolling repo should just be a symlink to Fedora. That's why Fedora exists. I'd mostly agree and that's why I don't think a rolling repo should be high on our todo-list. Nevertheless it seems people often are in the need to have a stable base with "newer version of foo and bar" on it. But everyone needs different "foo and bars" (and thus also defines the packageset of the stable base differently). I imagine a EPEL rolling add-one repo (on top of stable EPEL) together with a yum-plugin where people can configure to get "foo and bar" from EPEL rolling could serve those users. But that's atm nothing more then "dreaming how a solution for those users could look like". CU thl From kwade at redhat.com Sat Aug 18 23:25:35 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 18 Aug 2007 16:25:35 -0700 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <7874d9dd0708170649x301ff2acj244f388bedf0add2@mail.gmail.com> References: <46C1E839.4050002@leemhuis.info> <1187200025.6168.41.camel@erato.phig.org> <7874d9dd0708170649x301ff2acj244f388bedf0add2@mail.gmail.com> Message-ID: <1187479535.5699.311.camel@erato.phig.org> On Fri, 2007-08-17 at 08:49 -0500, Michael Stahnke wrote: > > > - weekly status mail from the owners of major tasks > > > > +1 > > > > Deadline is five minutes before the meeting. > Was this part a joke? I couldn't tell from email :) > > I have no problems getting things done on the list. (At least I can > read that when I get to it). Nope, not a joke, but maybe I fail to see any irony in the idea? It was a follow-on to the idea that one of the greatest benefits a weekly meeting gives you is a chance for everyone to catch up on writing and reading status reports. But if we're going to rely upon content from those reports to inform meetings, they need to be done before the meeting; I just think it's OK to say that the last minute before a meeting is OK. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mastahnke at gmail.com Sun Aug 19 05:41:57 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sun, 19 Aug 2007 00:41:57 -0500 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <1187479535.5699.311.camel@erato.phig.org> References: <46C1E839.4050002@leemhuis.info> <1187200025.6168.41.camel@erato.phig.org> <7874d9dd0708170649x301ff2acj244f388bedf0add2@mail.gmail.com> <1187479535.5699.311.camel@erato.phig.org> Message-ID: <7874d9dd0708182241o595af7ccg32daabea8fbce592@mail.gmail.com> On 8/18/07, Karsten Wade wrote: > On Fri, 2007-08-17 at 08:49 -0500, Michael Stahnke wrote: > > > > - weekly status mail from the owners of major tasks > > > > > > +1 > > > > > > Deadline is five minutes before the meeting. > > Was this part a joke? I couldn't tell from email :) > > > > I have no problems getting things done on the list. (At least I can > > read that when I get to it). > > Nope, not a joke, but maybe I fail to see any irony in the idea? > > It was a follow-on to the idea that one of the greatest benefits a > weekly meeting gives you is a chance for everyone to catch up on writing > and reading status reports. > > But if we're going to rely upon content from those reports to inform > meetings, they need to be done before the meeting; I just think it's OK > to say that the last minute before a meeting is OK. If a status report is given a minute before the meeting, then we have to take a break during the meeting to read and discuss. Either that, or we read it after the meeting and any discussion happens the next meeting or on list. It just seems ineffective to have a deadline a minute before we are in a forum to take action...unless everything only applies to the next meeting. stahnma > > - Karsten > -- > Karsten Wade ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.fedorapeople.org | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > From fedora at leemhuis.info Sun Aug 19 12:22:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Aug 2007 14:22:42 +0200 Subject: Log from this weeks (200700815) EPEL SIG Meeting Message-ID: <46C83612.8040108@leemhuis.info> Just a reminder: it's a SIG meeting, not a Steering Committee meeting. I'd be glad if SIG members and other EPEL contributors would join us more often! 00:00:04 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:04 < knurd> | Hi everybody; who's around? 00:00:04 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:07 * | knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:00:26 * | nirik is here, but on phone 00:00:27 * | stahnma is 00:00:31 * | Jeff_S_ here 00:00:31 --> | jgu__ (purple) has joined #fedora-meeting 00:00:35 --> | debarshi (Debarshi Ray) has joined #fedora-meeting 00:00:45 < debarshi> | names 00:01:00 < knurd> | sorry, seems I forgot to send the topic list out 00:01:09 < knurd> | (but of course it's always in the wiki) 00:01:12 < knurd> | debarshi ? 00:01:53 < mmcgrath> | pong! 00:02:02 * | knurd starts slowly 00:02:04 --- | knurd has changed the topic to: EPEL Meeting|new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore 00:02:10 < knurd> | dgilmore finished that 00:02:27 < debarshi> | knurd: Sorry. My mistake. 00:02:27 < knurd> | we need to do more stuff with the script to be able to push to stable 00:02:37 < knurd> | but for now it should be good enough 00:02:45 < knurd> | I'll take a look at it over the next few days 00:02:48 --> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:02:51 --- | knurd has changed the topic to: EPEL Meeting|branch for EPEL if Fedora maintainer does not react -- dgilmore 00:02:54 < knurd> | finsihed as well 00:03:02 < knurd> | see list and wiki for details 00:03:08 --- | knurd has changed the topic to: EPEL Meeting|yum for EPEL4 -- Jeff_S 00:03:14 < knurd> | Jeff_S ? 00:03:15 < stahnma> | Also finished :) 00:03:23 < Jeff_S_> | see mailing list -- it shold work fine 00:03:23 < stahnma> | I think 00:03:25 < Jeff_S_> | *should* 00:03:30 * | stahnma will test in a bit 00:03:34 < Jeff_S_> | thanks 00:03:36 < stahnma> | I have RHEL 4 sitting around 00:03:40 < knurd> | k 00:03:40 * | quaid is here after he finds his scroll down 00:03:48 < Jeff_S_> | stahnma: that's great 00:03:49 < knurd> | what do we need to do to get it in testing? 00:03:51 < stahnma> | jeff, what's the URL? 00:04:00 * | stahnma is too lazy to find his email 00:04:03 < Jeff_S_> | http://www.sheltren.com/epel/packages/ 00:04:05 < knurd> | Jeff_S_, will you maintain it for EPEL4? 00:04:25 < Jeff_S_> | knurd: yes, I can maintain yum + deps if nobody else is interested 00:04:42 < knurd> | seems you are the perfect one for the job atm 00:04:42 < Jeff_S_> | I'll run it by the fedora maintainers 00:04:47 < knurd> | Jeff_S_, k 00:04:54 * | f13 peeks in 00:05:07 --- | knurd has changed the topic to: EPEL Meeting|EPEL announcement happened -- are we satisfied with how everything worked out? 00:05:16 < knurd> | that's still on the topic list 00:05:21 <-- | jgu__ has left #fedora-meeting ( ) 00:05:25 < knurd> | do we want to discuss this further or simply move on? 00:05:38 < quaid> | think we discussed it, +1 to move on 00:05:40 < hpachas-PE> | install fedora 7 in SATA Model ST3250820AS, who? 00:05:49 * | Jeff_S_ fine to move on 00:06:05 < knurd> | k, I'll remove it from the schedule then 00:06:07 --- | knurd has changed the topic to: EPEL Meeting| RHX and EPEL -- quaid 00:06:07 --> | zoeloelip (Bart Vanbrabant) has joined #fedora-meeting 00:06:07 --> | zoeloelip (Bart Vanbrabant) has joined #fedora-meeting 00:06:10 < knurd> | quaid ? 00:06:25 < quaid> | nothing new 00:06:34 < knurd> | k :) 00:06:38 < quaid> | but I haven't asked in a while; forgot it could be on the agenda 00:06:48 < knurd> | but I leave it on the schedule? 00:06:56 < knurd> | s/the/our/ ? 00:06:59 < quaid> | well, that way we don't forget, ok 00:07:08 < knurd> | k 00:07:21 < knurd> | topic EPEL Meeting| for enterprise customers/ISVs/IHVs -- stahnma, quaid 00:07:24 --- | knurd has changed the topic to: EPEL Meeting| for enterprise customers/ISVs/IHVs -- stahnma, quaid 00:07:31 < knurd> | that also still on the schedule 00:07:35 < knurd> | is that still valid? 00:07:50 * | mmcgrath looks at communication plan 00:07:53 <-- | nphilipp has quit ("Leaving") 00:08:00 < quaid> | well, it's about as far as we can get it 00:08:08 < quaid> | but I haven't heard from the rest of the crew in a while 00:08:27 < stahnma> | are the RH SE's talking about EPEL at all? 00:08:39 < mmcgrath> | We should get something up there that speaks directly to ISV to tell them how to get involved and make it known to the rest of us that they are an ISV. 00:09:03 < knurd> | quaid, how about sending it to the list as RFC and ratify it next week? 00:09:04 < quaid> | stahnma: maybe 00:09:10 < quaid> | knurd: ok 00:09:27 < mmcgrath> | stahnma: we could always call RH, ask to talk to a sales guy and find out :) 00:09:50 * | knurd moves on 00:09:51 < stahnma> | hmm 00:09:52 < stahnma> | hahah 00:09:55 < knurd> | 7me waits 00:09:55 < stahnma> | sounds fun 00:10:13 --- | knurd has changed the topic to: EPEL Meeting| 00:10:22 < stahnma> | Jeff_S_: Yum works on RHEL 4 00:10:27 < knurd> | quaid, another old topic 00:10:28 --> | krh (Kristian H gsberg) has joined #fedora-meeting 00:10:30 < Jeff_S_> | stahnma: great, thanks for testing 00:10:30 < stahnma> | or doesn't work, however you want look at it 00:10:32 < knurd> | is that one still valid? 00:10:33 < Jeff_S_> | hah 00:10:44 < stahnma> | it builds, as do the deps 00:11:37 < knurd> | seems quaid vanished for the moment 00:11:47 --- | knurd has changed the topic to: EPEL Meeting|ExcludeArch TrackerBugs for EPEL -- notting/knurd 00:11:55 < knurd> | anyone interesed in solving this one 00:12:01 < knurd> | seems I don#t get down to it 00:12:01 --> | debarshi_ (Debarshi Ray) has joined #fedora-meeting 00:12:05 < quaid> | sorry, was working on that email 00:12:21 < quaid> | I'll send the generic job descriptiokn as an RFC as well 00:12:33 < knurd> | quaid, k, thx 00:12:58 < hpachas-PE> | sorry, SATA work with Fedora 7 ?? 00:12:58 * | knurd will wait 30 sekonds for volunteers for the "ExcludeArch TrackerBugs for EPEL" before moving on 00:13:17 < knurd> | hpachas-PE, you'll likely want to ask in #fedora 00:13:18 < Jeff_S_> | hpachas-PE: try #fedora please 00:13:28 * | Jeff_S_ too slow 00:13:29 < knurd> | hpachas-PE, we have a meeting specific to epel here currently 00:13:40 < hpachas-PE> | ok. sorry 00:13:41 < knurd> | Jeff_S_, just one second afaics ;-) 00:13:45 < knurd> | hpachas-PE, np 00:14:17 * | knurd EPEL -- FESCo mandate/how to move on with SIG and SteeringCommittee 00:14:21 --- | knurd has changed the topic to: EPEL -- FESCo mandate/how to move on with SIG and SteeringCommittee 00:14:24 < knurd> | that's better 00:14:34 < knurd> | I just remembered that we need to think about this soon 00:14:47 < knurd> | the mandate from FESCo is limited till 30th September iirc 00:14:53 < stahnma> | what is this topic saying? 00:15:03 < knurd> | do we want to move on with the current scheme 00:15:17 < knurd> | or do we want to elect a sterring committee? 00:15:27 < quaid> | *ick* :) 00:15:38 < quaid> | I'm like you, I've begun to wonder about all this election noise 00:15:40 < mmcgrath> | I guess the question is what are we trying to accomplish beyond what we are accomplishing now. 00:15:47 < quaid> | is it helpful? what do we do, poll people to find out? 00:16:07 < stahnma> | elections to me would be nice, but it seems interest is among only very few people, so elections probalby wouldn't do a whole lot 00:16:07 < quaid> | mmcgrath: maintenance and growth 00:16:22 < knurd> | mmcgrath, yeah, I'm don#t like the election idea myself, but well, if others want then I'm find with doing one 00:16:32 < knurd> | stahnma, +1 00:17:08 < knurd> | well, maybe we should all thing about this somehow 00:17:16 < quaid> | we could recommend an extension of the mandate for e.g. 6 months 00:17:18 < stahnma> | I think right now growth of the repo and user-base is where we should putting effort 00:17:23 < stahnma> | not into politics 00:17:32 < quaid> | +1 00:17:52 < quaid> | and we seem to have a manageable group without adding or subtracting 00:17:55 < knurd> | quaid, well, is there a reasons to time-limit it again? 00:18:01 < mmcgrath> | I guess a specific goal would be good. I mean the obvious goal is there but do we also want to aggressively add more packages? Add more packagers? Add more documentation? Marketing? 00:18:09 < quaid> | knurd: only if we think we need a forced decision at some point 00:18:21 < knurd> | yeah, you have a point 00:18:22 < quaid> | mmcgrath: yes :) 00:18:26 < stahnma> | I would like to get more involvement from EL customers, and hear what they think/want need 00:18:27 < nirik> | I don't know that we would have enough people to make an election worth it. 00:18:31 < knurd> | mmcgrath, "more packages" is still goal #1 I'd say 00:18:45 * | nirik agrees with knurd 00:19:40 < mmcgrath> | Well, how do we get more packages in? 00:19:47 < knurd> | good question 00:19:55 < mmcgrath> | AFAIK most people have just come upon us :) 00:19:58 < knurd> | lists of important pacakges that still miss in EPEL? 00:19:59 < stahnma> | allow for hostile takeover of maintainane :) 00:20:01 < knurd> | more maintainers? 00:20:27 * | mmcgrath thinks now would be a good time for "more packagers/maintainer" 00:20:38 < mmcgrath> | get the word out about how to get involved, maybe help with reviews, etc. 00:20:47 < stahnma> | +1 mmcgrath 00:20:54 < knurd> | maybe a sponser-way for EPEL-only contrinbutors 00:20:56 < stahnma> | most reviews are done already in the Fedora space 00:21:05 < knurd> | that want to maintain existing packages 00:21:25 <-- | debarshi has quit (Read error: 110 (Connection timed out)) 00:21:32 --- | debarshi_ is now known as debarshi 00:21:44 < knurd> | well, let's stop here and continue on the list and in the next meeting with this topic 00:21:48 < stahnma> | there are several packages in Fedora not in EPEL yet, should we do a mass emailing off all non-committed maintiners and try to solicit their wish for involvingment in EPEL? 00:22:03 * | stahnma can't type 00:22:13 < knurd> | stahnma, maybe yes 00:22:17 < stahnma> | baiscally, find out the status for everyone 00:22:26 < stahnma> | and then see what package will need new maintainers for EPEL 00:22:32 < stahnma> | and get those built if possible 00:22:33 < knurd> | stahnma, the package database might help 00:22:42 < knurd> | but abadger1999 is busy with lots of stuff already 00:22:42 * | stahnma was looking that last night 00:22:56 < knurd> | so EPEL specific things likely won#t he high on the todo list 00:23:10 < abadger1999> | What's the issue? 00:23:32 * | nirik has a number of packages he would like to branch for epel, but hasn't had time. 00:23:33 < knurd> | abadger1999, nothing specific (yet) 00:24:07 * | mmcgrath wonders if peoples packages aren't in epel because of -ENOTIME -EDOESNTCARE or -EMISSINGDEP 00:24:12 < knurd> | but maybe tracking the stuff from http://fedoraproject.org/wiki/EPEL/ContributorStatus in a DB might help to identify packages/packagers, that do not hit EPEL 00:24:22 < abadger1999> | knurd: k. Feel free to open a ticket in http://hosted.fedoraproject.org/projects/packagedb when you have something you need done. 00:24:50 < knurd> | mmcgrath, I suppose "can#t test easily" and "fear long maintanance time" 00:24:56 < stahnma> | mmcgrath: I think missingdep is #1 00:24:59 < knurd> | abadger1999, will do, thx for your help 00:25:10 < knurd> | stahnma, yeah, that also 00:25:32 < mmcgrath> | missingdeps is a chicken and egg thing, but it will take care of itself over time (even if it is painfully slow) 00:25:35 * | knurd votes for moving on now 00:25:41 < knurd> | mmcgrath, +1 00:25:48 --> | sgarrity (sgarrity) has joined #fedora-meeting 00:26:01 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:26:06 < knurd> | anything else to discuss? 00:26:21 < knurd> | my mail on "Meetings and mailiglists/decision finding process" maybe? 00:26:29 < knurd> | or shall we discuss it further on the list? 00:26:43 * | mmcgrath just wanted to say I think the EPEL community is pretty healthy right now, lots of people and packages being built and we're still very young. 00:27:04 < Jeff_S_> | I'm happy to try to do most communication on the list and then just finalize things in meetings -- that way we can speed through these faster :) 00:27:11 < knurd> | mmcgrath, kind of agreed, but there is still a lot to improve afaics 00:27:14 < Jeff_S_> | and we'll get more community input that way as well 00:27:16 < stahnma> | I liked the speed of today's meeting 00:27:20 < nirik> | yeah, I think we are in a period where there aren't too many decisions to be made... more maintainers needed more, etc. 00:27:32 < mmcgrath> | stahnma: and the number of people that showed up :) 00:27:38 < stahnma> | I suppose 00:27:42 < knurd> | stahnma, well, it does only work if stuff is discussed on the list first 00:27:47 < stahnma> | true 00:27:48 < knurd> | e.g. the details 00:27:50 < mmcgrath> | nirik: I guess thats a tribute to how good FESCo (and EPEL's general upstream) has been. 00:28:12 < nirik> | well, we don't have to worry about things like package guidelines, etc, they are all there upstream. ;) 00:28:38 < mmcgrath> | exactly 00:28:52 --> | _blah_ (purple) has joined #fedora-meeting 00:28:52 --> | _blah_ (purple) has joined #fedora-meeting 00:29:17 < knurd> | well, anything else? 00:29:24 * | mmcgrath has nothing 00:29:25 < knurd> | or shall we close the meeting for today? 00:29:26 --> | LetoTo (Paul Wouters) has joined #fedora-meeting 00:29:51 * | knurd will close the meeting in 60 00:29:52 < Jeff_S_> | nothing here 00:30:05 * | nirik has nothing either. 00:30:14 * | knurd will close the meeting in 30 00:30:34 * | knurd will close the meeting in 10 00:30:44 < knurd> | -- MARK -- Meeting end 00:30:44 --- | knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule 00:30:49 < knurd> | thx everyone From fedora at leemhuis.info Sun Aug 19 12:26:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Aug 2007 14:26:47 +0200 Subject: EPEL report week 33 2007 Message-ID: <46C83707.1080605@leemhuis.info> = Weekly EPEL Summary = Week 33/2007 == Most important happenings == * reminder: now that EPEL is officially announced all new and updates EPEL packages go straight to EPEL-testing and *not* to the stable repo. EPEL-testing packages will (if everything is sane) get moved to stable repo in parallel with a quarterly RHEL update. If you have a security update that needs to go to EPEL-stable build normally and contact ThorstenLeemhuis There are some discussion to adjust that scheme (sync more often, push new packages directly or after a small warning period to stable, ...); see the list for details at https://www.redhat.com/archives/epel-devel-list/2007-August/msg00083.html * some discussion on the list to do much more on the mailiglist instead of in the meetings -- see https://www.redhat.com/archives/epel-devel-list/2007-August/msg00071.html * two RFC's which might be approved soon got posted to the list -- * Job description: https://www.redhat.com/archives/epel-devel-list/2007-August/msg00082.html * communication plan: https://www.redhat.com/archives/epel-devel-list/2007-August/msg00081.html if you don't like something speak up now From: http://fedoraproject.org/wiki/EPEL/Reports/Week33 == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * quaid (KarstenWade) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * dgilmore (DennisGilmore) (missed it by a few minutes) === Summary === * new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore * finished ; thx for your work dgilmore * we need to do more stuff with the scripts to be able to push to stable easily; knurd will take a look * branch for EPEL if Fedora maintainer does not react * finished; dgilmore enhanced the text to fix something knurd complained about. The last sentence reads now: "If the Fedora maintainer later decides to participate in EPEL, then the Fedora maintainer will become co-maintainer for EPEL. (Of course co-maintainership can be extended to Fedora)" * yum for EPEL4 -- Jeff_S * "How to do it" also got finished :) -- we take the CentOS srpms as base, ship them with a lower release to do no harm to CentOS and remove the yum.conf, as yum without a RHEL4-repo can not be used to install stuff from EPEL, but is of value for stuff like yum-utils or mock * EPEL announcement happened -- are we satisfied with how everything worked out? * was discussed in the past meetings -- we'll remove it from the schedule, move on and discuss stuff as needed * RHX and EPEL -- quaid * quiad: "nothing new ; but I haven't asked in a while; forgot it could be on the agenda " * communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid * will get send to the list for final discussions * Generic Job Description -- quaid * will get send to the list for final discussions * ExcludeArch TrackerBugs for EPEL -- notting/knurd * knurd doesn't find the time for it atm; any volunteers? * FESCo mandate/how to move on with SIG and SteeringCommittee * current mandate for the EPEL SIG and its Steering Committee is limited until end of September; do we want to move on with the current scheme ? or do we want to elect a sterring committee? * some people wondered if elections really make sense * we could recommend to FESCo an extension of the mandate for e.g. 6 months * stahnma> "I think right now growth of the repo and user-base is where we should putting effort not into politics " * quaid> "we seem to have a manageable group without adding or subtracting " * mmcgrath> "I guess a specific goal would be good. I mean the obvious goal is there but do we also want to aggressively add more packages? Add more packagers? Add more documentation? Marketing? " * "more packages" is still a important goal * stahnma> "allow for hostile takeover of maintainane :) " * knurd> "maybe we need a sponsor-way for EPEL-only contributors that want to maintain existing packages " * we stopped there and will continue this topic on the list and in the next meeting * Free discussion around EPEL * mmcgrath> "just wanted to say I think the EPEL community is pretty healthy right now, lots of people and packages being built and we're still very young. " * Jeff_S_> "I'm happy to try to do most communication on the list and then just finalize things in meetings -- that way we can speed through these faster :) " * stahnma> "I liked the speed of today's meeting " === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00115.html == Stats == === General === Number of EPEL Contributors -- now that the pgkdb is in production it's for now not easily determinable (AFAIK) === EPEL 5 === Number of source packages: 590 Number of binary packages: 1146 There are 79 new Packages (might include some old packages that were moved to testing right before the EPEL announcement): * arj | Archiver for .arj files * audio-entropyd | Generate entropy from audio output * bcfg2 | Configuration management system * bugzilla | Bug tracking system * cabextract | Utility for extracting cabinet (.cab) archives * chmlib | Library for dealing with ITSS/CHM format files * evolution-bogofilter | A plugin for bogofilter support in evolution * freeze | freeze/melt/fcat compression utilities * gdal | GIS file format library * geos | GEOS is a C++ port of the Java Topology Suite * gnome-screensaver-frogs | GNOME Screensaver Slideshow of Frogs * google-perftools | Very fast malloc and performance analysis tools * guile-cairo | The Cairo graphics library for Guile Scheme * guile-lib | A repository of useful code written in Guile Scheme * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * lasi | C++ library for creating Postscript documents * libdap | The C++ DAP2 library from OPeNDAP * libgeotiff | GeoTIFF format library * limph | A PHP5-compatible network host/service poller with web interface * lzop | Real-time file compressor * mapserver | Environment for building spatially-enabled internet applications * mfstools | Utilities for TiVo drive upgrades * moodle | A Course Management System * netgo | Networking profile manager * nikto | Web server scanner * nomarch | GPLed Arc de-archiver * ogdi | Open Geographic Datastore Interface * oneko | Cat chases the cursor * pbzip2 | Parallel implementation of bzip2 * Perlbal | Reverse-proxy load balancer and webserver * perl-Convert-TNEF | Perl module to read TNEF files * perl-Convert-UUlib | Perl interface to the uulib library * perl-Danga-Socket | Event loop and event-driven async socket base class * perl-Device-SerialPort | Linux/POSIX emulation of Win32::SerialPort functions * perl-ExtUtils-F77 | Simple interface to F77 libs * perl-Gearman-Client-Async | Asynchronous Client for the Gearman distributed job system * perl-Gearman | Distributed job system * perl-Gearman-Server | Function call "router" and load balancer * perl-Image-ExifTool | Utility for reading and writing image meta info * perl-IO-AIO | Asynchronous Input/Output * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Mail-SPF-Query | Query Sender Policy Framework * perl-MogileFS-Utils | Utilities for MogileFS * perl-Net-CIDR-Lite | Net::CIDR::Lite Perl module * perl-Net-Pcap | Interface to pcap(3) LBL packet capture library * perl-Razor-Agent | Use a Razor catalogue server to filter spam messages * perl-Sys-Syscall | Access system calls that Perl doesn't normally provide access to * perl-Test-Base | Data Driven Testing Framework * perltidy | Tool for indenting and reformatting Perl scripts * php-pear-PHP-CodeSniffer | PHP coding standards enforcement tool * physfs | Library to provide abstract access to various archives * plplot | Library of functions for making scientific plots * postgresql-pgpool | Pgpool is a connection pooling/replication server for PostgreSQL * proftpd | Flexible, stable and highly-configurable FTP server * proj | Cartographic projection software (PROJ.4) * pv | A tool for monitoring the progress of data through a pipeline * pychart | Python library for generating chart images * python-Coherence | Python framework to participate in digital living networks * python-iniparse | Python Module for Accessing and Modifying Configuration Data in INI files * python-lxml | ElementTree-like Python bindings for libxml2 and libxslt * python-pygments | A syntax highlighting engine written in Python * pyxdg | Python library to access freedesktop.org standards * qhull | General dimension convex hull programs * qucs | Circuit simulator * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * ser2net | Proxy that allows tcp connections to serial ports * stripesnoop | Magnetic Stripe Reader * svgalib | Low-level fullscreen SVGA graphics library * svnmailer | Tool to post subversion repository commit information * tcpxtract | Tool for extracting files from network traffic * tidy | Utility to clean up and pretty print HTML/XHTML/XML * translate-toolkit | A collection of tools to assist software localization * udunits | A library for manipulating units of physical quantities * ustr | String library, very low memory overhead, simple to import * vpnc | IPSec VPN client compatible with Cisco equipment * xerces-c | Validating XML Parser * xkeycaps | Graphical front end to xmodmap * xsupplicant | Open Source Implementation of IEEE 802.1x * zabbix | Open-source monitoring solution for your IT infrastructure === EPEL 4 === Number of source packages: 377 Number of binary packages: 778 There are 62 new Packages (might include some old packages that were moved to testing right before the EPEL announcement): * arj | Archiver for .arj files * audio-entropyd | Generate entropy from audio output * bcfg2 | Configuration management system * bugzilla | Bug tracking system * chmlib | Library for dealing with ITSS/CHM format files * cobbler | Boot server configurator * freeze | freeze/melt/fcat compression utilities * geos | GEOS is a C++ port of the Java Topology Suite * gnome-screensaver-frogs | GNOME Screensaver Slideshow of Frogs * google-perftools | Very fast malloc and performance analysis tools * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * libdap | The C++ DAP2 library from OPeNDAP * libgeotiff | GeoTIFF format library * limph | A PHP5-compatible network host/service poller with web interface * lzop | Real-time file compressor * mfstools | Utilities for TiVo drive upgrades * mimedefang | E-Mail filtering framework using Sendmail's Milter interface * mock | Builds packages inside chroots * mod_security | Security module for the Apache HTTP Server * moodle | A Course Management System * netgo | Networking profile manager * nikto | Web server scanner * nomarch | GPLed Arc de-archiver * oneko | Cat chases the cursor * pbzip2 | Parallel implementation of bzip2 * perl-Convert-TNEF | Perl module to read TNEF files * perl-Convert-UUlib | Perl interface to the uulib library * perl-Danga-Socket | Event loop and event-driven async socket base class * perl-Device-SerialPort | Linux/POSIX emulation of Win32::SerialPort functions * perl-ExtUtils-F77 | Simple interface to F77 libs * perl-Image-ExifTool | Utility for reading and writing image meta info * perl-IO-AIO | Asynchronous Input/Output * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Mail-SPF-Query | Query Sender Policy Framework * perl-Net-CIDR-Lite | Net::CIDR::Lite Perl module * perl-Net-Server | Extensible, general Perl server engine * perl-Razor-Agent | Use a Razor catalogue server to filter spam messages * perl-SOAP-Lite | Client and server side SOAP implementation * perl-Sys-Syscall | Access system calls that Perl doesn't normally provide access to * physfs | Library to provide abstract access to various archives * postgresql-dbi-link | Partial implementation of the SQL/MED portion of the SQL:2003 specification * postgresql-pgpoolAdmin | PgpoolAdmin - web-based pgpool administration * postgresql-pgpool | Pgpool is a connection pooling/replication server for PostgreSQL * proj | Cartographic projection software (PROJ.4) * pychart | Python library for generating chart images * python-Coherence | Python framework to participate in digital living networks * python-lxml | ElementTree-like Python bindings for libxml2 and libxslt * pyxdg | Python library to access freedesktop.org standards * qucs | Circuit simulator * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * ser2net | Proxy that allows tcp connections to serial ports * specto | An desktop application that will watch configurable events * sqlgrey | Postfix grey-listing policy service * stripesnoop | Magnetic Stripe Reader * svgalib | Low-level fullscreen SVGA graphics library * trac | Enhanced wiki and issue tracking system * trac-webadmin | Web interface for administration of Trac * udunits | A library for manipulating units of physical quantities * xerces-c | Validating XML Parser * xkeycaps | Graphical front end to xmodmap * xsupplicant | Open Source Implementation of IEEE 802.1x * zabbix | Open-source monitoring solution for your IT infrastructure ---- ["CategoryEPELReports"] From mdehaan at redhat.com Mon Aug 20 12:33:24 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 20 Aug 2007 08:33:24 -0400 Subject: To update or not to update... In-Reply-To: <46C6DD4F.9030305@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <2999.65.192.24.164.1187376560.squirrel@mail.jcomserv.net> <46C6DD4F.9030305@leemhuis.info> Message-ID: <46C98A14.3010009@redhat.com> Thorsten Leemhuis wrote: > > >>> experimental -- I just updated this package, it may eat your brane >>> > > Fedora rawhide. > Rawhide packages installing on RHEL? Surely not. From fedora at leemhuis.info Mon Aug 20 12:47:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 20 Aug 2007 14:47:22 +0200 Subject: To update or not to update... In-Reply-To: <46C98A14.3010009@redhat.com> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <2999.65.192.24.164.1187376560.squirrel@mail.jcomserv.net> <46C6DD4F.9030305@leemhuis.info> <46C98A14.3010009@redhat.com> Message-ID: <46C98D5A.8020601@leemhuis.info> On 20.08.2007 14:33, Michael DeHaan wrote: > Thorsten Leemhuis wrote: >> >>>> experimental -- I just updated this package, it may eat your brane >> Fedora rawhide. > Rawhide packages installing on RHEL? Surely not. >From the part you stripped in your reply: "We IMHO have a multi-level-system as well if you look at the big picture." Big picture = "Fedora and RHEL as a whole" rawhide is indirectly the experimental for RHEL as well as for EPEL. CU knurd From mdehaan at redhat.com Mon Aug 20 12:57:41 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 20 Aug 2007 08:57:41 -0400 Subject: To update or not to update... In-Reply-To: <46C98D5A.8020601@leemhuis.info> References: <20070815173210.GA9700@bludgeon.org> <46C5F0E4.9040401@redhat.com> <2999.65.192.24.164.1187376560.squirrel@mail.jcomserv.net> <46C6DD4F.9030305@leemhuis.info> <46C98A14.3010009@redhat.com> <46C98D5A.8020601@leemhuis.info> Message-ID: <46C98FC5.9080402@redhat.com> Thorsten Leemhuis wrote: > > > Big picture = "Fedora and RHEL as a whole" > > rawhide is indirectly the experimental for RHEL as well as for EPEL. > > Obviously, I know this -- the point is we aren't trying to create a way to build a distribution here, and this is where I believe the mistake lies. EPEL is a gateway to provide additional packages to a distribution which is, of course, emergent from the aforementioned rawhide/Fedora/etc. What I want to see here is a way for SA's to find packages that help them get their job done, without going through lots of pain with rpmbuild and finding missing deps. This means making a certain quality of packages available, but it should not restrict SA's to old content. "Old" isn't the same as stable, we need other critera for that, or just to have the ability for someone to manually push to testing to stable -- and just put some basic recommendations around that. From kwade at redhat.com Mon Aug 20 19:27:02 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 20 Aug 2007 12:27:02 -0700 Subject: Meetings and mailiglists/decision finding process In-Reply-To: <7874d9dd0708182241o595af7ccg32daabea8fbce592@mail.gmail.com> References: <46C1E839.4050002@leemhuis.info> <1187200025.6168.41.camel@erato.phig.org> <7874d9dd0708170649x301ff2acj244f388bedf0add2@mail.gmail.com> <1187479535.5699.311.camel@erato.phig.org> <7874d9dd0708182241o595af7ccg32daabea8fbce592@mail.gmail.com> Message-ID: <1187638022.5699.431.camel@erato.phig.org> On Sun, 2007-08-19 at 00:41 -0500, Michael Stahnke wrote: > If a status report is given a minute before the meeting, then we have > to take a break during the meeting to read and discuss. Either that, > or we read it after the meeting and any discussion happens the next > meeting or on list. It just seems ineffective to have a deadline a > minute before we are in a forum to take action...unless everything > only applies to the next meeting. We may need a distinction between "statuses that require discussion before the meeting" and "statuses that do not require discussion." This is a gray area, no distinct line, so we need to leave room for the discretion of the individuals involved. I recommend we have a guideline such as, "Report early if you have an item worth discussing so there is sufficient time on list; otherwise get status reports in before the meeting starts.[1]" Anyone who fails to give a topic sufficient on-list time learns the consequences. This guideline would fall out from the guideline/directive that discussions happen on list, not saved for IRC, with the 48-hour minimum cooking time for new topics to stew on list. FWIW, that is probably a good practice across Fedora. :) - Karsten [1] I'm just being a realist based on my experience. If you say "one hour before the meeting", it is as likely to arrive before that as after that. If we set the deadline "24 hours before the meeting", it is as likely to arrive before that as after that, and once it hits after that time, it's as likely to arrive in the last five minutes as at any other five minute interval since the deadline passed. A similar situation occurs with other people reading the status. It's as likely someone reads the report when it arrives as during any five minute period from arrival to just before the meeting. This is why I like the five-minute-before-the-meeting rule. It acknowledges that a measurable portion of the people do not deliver or read reports until that last five minutes. It really only takes that long to read them, anyway. -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Aug 20 20:29:00 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 20 Aug 2007 23:29:00 +0300 Subject: Complete RHEL package lists? Message-ID: <200708202329.01131.ville.skytta@iki.fi> Hi, I'm about to submit tomcat-native (also known as libtcnative, tcnative) for review in Fedora, but my primary interest for it is EL-5, specifically CentOS 5. But before doing that, I'd like to verify that it is not already available in some RHEL 5 channels and that the package won't cause problems if it's shipped in EPEL 5, if I should adjust something etc. For CentOS 5 it's fine, but I don't have a RHEL 5 box at the moment that I could use to check for possible conflicts and the like. Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice. If not, could they be arranged somewhere? In the meantime, could someone verify if tomcat-native/libtcnative/tcnative is available in some RHEL 5 channel or not? From dag at wieers.com Tue Aug 21 10:54:54 2007 From: dag at wieers.com (Dag Wieers) Date: Tue, 21 Aug 2007 12:54:54 +0200 (CEST) Subject: Complete RHEL package lists? In-Reply-To: <200708202329.01131.ville.skytta@iki.fi> References: <200708202329.01131.ville.skytta@iki.fi> Message-ID: On Mon, 20 Aug 2007, Ville Skytt? wrote: > I'm about to submit tomcat-native (also known as libtcnative, tcnative) for > review in Fedora, but my primary interest for it is EL-5, specifically CentOS > 5. > > But before doing that, I'd like to verify that it is not already available in > some RHEL 5 channels and that the package won't cause problems if it's > shipped in EPEL 5, if I should adjust something etc. For CentOS 5 it's fine, > but I don't have a RHEL 5 box at the moment that I could use to check for > possible conflicts and the like. It won't be fine for CentOS 5 either if it is not fine for RHEL 5. CentOS also rebuilds the source packages from other RHN channels and even if they may not be available right now they may be in the future. So the same concerns hold true. > Is there a complete list of all binary packages included in all RHEL channels > that EPEL should be compatible with available somewhere? Complete public > binary repodatas (just the metadata, not packages) of binary packages > included in them would be nice. That would be interesting indeed. A complete list of binary packages, metadata and a list of all the SRPMs (just to verify if they all are on the mirrors and have not been mistakenly forgotten). -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ville.skytta at iki.fi Tue Aug 21 12:05:24 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 21 Aug 2007 15:05:24 +0300 Subject: Complete RHEL package lists? In-Reply-To: References: <200708202329.01131.ville.skytta@iki.fi> Message-ID: <200708211505.25125.ville.skytta@iki.fi> On Tuesday 21 August 2007, Dag Wieers wrote: > On Mon, 20 Aug 2007, Ville Skytt? wrote: > > I'm about to submit tomcat-native (also known as libtcnative, tcnative) > > for review in Fedora, but my primary interest for it is EL-5, > > specifically CentOS 5. > > > > But before doing that, I'd like to verify that it is not already > > available in some RHEL 5 channels and that the package won't cause > > problems if it's shipped in EPEL 5, if I should adjust something etc. > > For CentOS 5 it's fine, but I don't have a RHEL 5 box at the moment that > > I could use to check for possible conflicts and the like. > > It won't be fine for CentOS 5 either if it is not fine for RHEL 5. CentOS > also rebuilds the source packages from other RHN channels and even if they > may not be available right now they may be in the future. So the same > concerns hold true. Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority. > > Is there a complete list of all binary packages included in all RHEL > > channels that EPEL should be compatible with available somewhere? > > Complete public binary repodatas (just the metadata, not packages) of > > binary packages included in them would be nice. > > That would be interesting indeed. A complete list of binary packages, > metadata and a list of all the SRPMs (just to verify if they all are on > the mirrors and have not been mistakenly forgotten). From buildsys at fedoraproject.org Tue Aug 21 14:21:56 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 21 Aug 2007 10:21:56 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-08-21 Message-ID: <20070821142156.5A99A152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 16 NEW ccache-2.4-10.el5 : C/C++ compiler cache NEW cvsgraph-1.6.1-4.el5 : CVS/RCS repository grapher NEW libpqxx-2.6.8-7.el5 : C++ client API for PostgreSQL (!) nagios-2.9-1.el5 : INVALID rebuild, not published! NEW nginx-0.5.31-3.el5 : Robust, small and high performance http and reverse proxy server postgresql-pgpool-II-1.2-4.el5 postgresql-pgpoolAdmin-1.0.0-7.el5 python-kid-0.9.6-1.el5 (!) python-lxml-1.3.3-1.el5 : INVALID rebuild, not published! python-pygments-0.8.1-2.el5 NEW python-sqlalchemy-0.3.10-2.el5 : Modular and flexible ORM library for python NEW R-systemfit-0.8-6.el5 : Simultaneous Equation Estimation R Package NEW radiusclient-ng-0.5.6-2.el5 : RADIUS protocol client library wine-0.9.43-1.el5 wine-docs-0.9.43-1.el5 yumex-2.0-1.el5 Packages built and released for Fedora EPEL 4: 9 NEW cvsgraph-1.5.1-4.el4 : A CVS/RCS repository grapher NEW libpqxx-2.6.8-7.el4 : C++ client API for PostgreSQL NEW nginx-0.5.31-4.el4 : Robust, small and high performance http and reverse proxy server postgresql-pgpool-II-1.2-4.el4 postgresql-pgpoolAdmin-1.0.0-7.el4 NEW python-kid-0.9.6-1.el4 : Kid - A simple and pythonic XML template language (!) python-lxml-1.3.3-1.el4 : INVALID rebuild, not published! NEW sqlite-3.3.6-0.3.el4 : Library that implements an embeddable SQL database engine wine-0.9.43-1.el4 Changes in Fedora EPEL 5: ccache-2.4-10.el5 ----------------- * Sun Aug 19 2007 Ville Skytt? - 2.4-10 - License: GPLv2+ - Make compiler symlinks relative. - Make profile.d scripts noreplace. * Mon Jul 30 2007 Ville Skytt? - 2.4-9 - Use shared cache dir for users in the ccache group by default (#247760, based on Andy Shevchenko's work). - Fix outdated hardlink info in cache sharing docs. - Add auto-symlink support for avr-gcc(-c++) and arm-gp2x-linux-gcc(-c++). - Make triggers always exit with a zero exit status. cvsgraph-1.6.1-4.el5 -------------------- * Sat Aug 18 2007 Marek Mahut - 1.6.1.-4 - Rebuild for EPEL libpqxx-2.6.8-7.el5 ------------------- * Fri Aug 17 2007 Rex Dieter 2.6.8-7 - update Source URL's nagios-2.9-1.el5 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 nginx-0.5.31-3.el5 ------------------ * Sat Aug 18 2007 Jeremy Hinegardner - 0.5.31-3 - added --with-http_stub_status_module build option. - added --with-http_sub_module build option. - add in pcre-config --cflags * Sat Aug 18 2007 Jeremy Hinegardner - 0.5.31-2 - remove BuildRequires: perl-devel * Fri Aug 17 2007 Jeremy Hinegardner - 0.5.31-1 - Update to 0.5.31 - specify license is BSD * Sat Aug 11 2007 Jeremy Hinegardner - 0.5.30-2 - Add BuildRequires: perl-devel - fixing rawhide build * Mon Jul 30 2007 Jeremy Hinegardner - 0.5.30-1 - Update to 0.5.30 * Tue Jul 24 2007 Jeremy Hinegardner - 0.5.29-1 - Update to 0.5.29 postgresql-pgpool-II-1.2-4.el5 ------------------------------ * Thu Aug 16 2007 Devrim Gunduz 1.2-4 - Fixed the directory name where sample conf files and sql files are installed. * Sun Aug 05 2007 Devrim Gunduz 1.2-3 - Added a patch for sample conf file to use Fedora defaults * Sun Aug 05 2007 Devrim Gunduz 1.2-2 - Added an init script for pgpool - Added /etc/sysconfig/pgpool postgresql-pgpoolAdmin-1.0.0-7.el5 ---------------------------------- * Thu Aug 16 2007 Devrim Gunduz 1.0.0-7 - Fix httpd configuration file -- it was using wrong directory. python-kid-0.9.6-1.el5 ---------------------- * Fri Aug 17 2007 Konstantin Ryabitsev - 0.9.6-1 - Upstream 0.9.6 python-lxml-1.3.3-1.el5 ----------------------- * Mon Jul 30 2007 Jeffrey C. Ollie - 1.3.3-1 - Update to 1.3.3 python-pygments-0.8.1-2.el5 --------------------------- * Fri Aug 17 2007 Steve 'Ashcrow' Milner - 0.8.1-2 - Removed the dos2unix build dependency. python-sqlalchemy-0.3.10-2.el5 ------------------------------ * Tue Jul 24 2007 Toshio Kuratomi - 0.3.10-2 - Remove python-abi Requires. This is automatic since FC4+. * Tue Jul 24 2007 Toshio Kuratomi - 0.3.10-1 - Update to new upstream version 0.3.10 R-systemfit-0.8-6.el5 --------------------- * Wed Aug 15 2007 Orion Poplawski - 0.8-6 - Update to 0.8-3 radiusclient-ng-0.5.6-2.el5 --------------------------- * Wed Aug 15 2007 Jeffrey C. Ollie - 0.5.6-2 - Update to 0.5.6 wine-0.9.43-1.el5 ----------------- * Sat Aug 18 2007 Andreas Bierfert - 0.9.43-2 - fix license * Sat Aug 11 2007 Andreas Bierfert - 0.9.43-1 - version upgrade - fix init-script output (#252144) - add lsb stuff (#247096) wine-docs-0.9.43-1.el5 ---------------------- * Sat Aug 18 2007 Andreas Bierfert - 0.9.43-1 - version upgrade - fix license yumex-2.0-1.el5 --------------- * Thu Aug 16 2007 Tim Lauridsen - 2.0-1 - Release 2.0 GA - Updated license tag to apply to Fedora guidelines. Changes in Fedora EPEL 4: cvsgraph-1.5.1-4.el4 -------------------- * Sat Aug 18 2007 Marek Mahut 0:1.5.1-4 - Rebuild for EPEL libpqxx-2.6.8-7.el4 ------------------- * Fri Aug 17 2007 Rex Dieter 2.6.8-7 - update Source URL's nginx-0.5.31-4.el4 ------------------ * Sat Aug 18 2007 Jeremy Hinegardner - 0.5.31-4 - added --with-http_stub_status_module build option. - added --with-http_sub_module build option. * Sat Aug 18 2007 Jeremy Hinegardner - 0.5.31-3 - add in pcre-config --cflags * Sat Aug 18 2007 Jeremy Hinegardner - 0.5.31-2 - remove BuildRequires: perl-devel * Fri Aug 17 2007 Jeremy Hinegardner - 0.5.31-1 - Update to 0.5.31 - specify license is BSD * Sat Aug 11 2007 Jeremy Hinegardner - 0.5.30-2 - Add BuildRequires: perl-devel - fixing rawhide build * Mon Jul 30 2007 Jeremy Hinegardner - 0.5.30-1 - Update to 0.5.30 * Tue Jul 24 2007 Jeremy Hinegardner - 0.5.29-1 - Update to 0.5.29 postgresql-pgpool-II-1.2-4.el4 ------------------------------ * Thu Aug 16 2007 Devrim Gunduz 1.2-4 - Fixed the directory name where sample conf files and sql files are installed. * Sun Aug 05 2007 Devrim Gunduz 1.2-3 - Added a patch for sample conf file to use Fedora defaults * Sun Aug 05 2007 Devrim Gunduz 1.2-2 - Added an init script for pgpool - Added /etc/sysconfig/pgpool postgresql-pgpoolAdmin-1.0.0-7.el4 ---------------------------------- * Thu Aug 16 2007 Devrim Gunduz 1.0.0-7 - Fix httpd configuration file -- it was using wrong directory. python-kid-0.9.6-1.el4 ---------------------- * Fri Aug 17 2007 Konstantin Ryabitsev - 0.9.6-1 - Upstream 0.9.6 python-lxml-1.3.3-1.el4 ----------------------- * Mon Jul 30 2007 Jeffrey C. Ollie - 1.3.3-1 - Update to 1.3.3 sqlite-3.3.6-0.3.el4 -------------------- * Fri Aug 17 2007 Mike McGrath - 3.3.6-0.3 - Official EPEL build * Wed Jul 25 2007 Jeff Sheltren - 3.3.6-0.2 - Prepend 0 to release - Rebuild for EPEL wine-0.9.43-1.el4 ----------------- * Sat Aug 18 2007 Andreas Bierfert - 0.9.43-2 - fix license * Sat Aug 11 2007 Andreas Bierfert - 0.9.43-1 - version upgrade - fix init-script output (#252144) - add lsb stuff (#247096) For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From kwade at redhat.com Tue Aug 21 21:41:34 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 21 Aug 2007 14:41:34 -0700 Subject: Complete RHEL package lists? In-Reply-To: <200708211505.25125.ville.skytta@iki.fi> References: <200708202329.01131.ville.skytta@iki.fi> <200708211505.25125.ville.skytta@iki.fi> Message-ID: <1187732494.14030.111.camel@erato.phig.org> On Tue, 2007-08-21 at 15:05 +0300, Ville Skytt? wrote: > Ok, that just amplifies the point that the information requested below seems > to be critical prerequisite for inclusion of *any* package in EPEL. Steering > committee, please process this request with high priority. > > > > Is there a complete list of all binary packages included in all RHEL > > > channels that EPEL should be compatible with available somewhere? > > > Complete public binary repodatas (just the metadata, not packages) of > > > binary packages included in them would be nice. There are a lot of people here with knowledge of how Red Hat works. Is there an impediment to getting that list? -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mastahnke at gmail.com Tue Aug 21 23:20:47 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 21 Aug 2007 18:20:47 -0500 Subject: Complete RHEL package lists? In-Reply-To: <1187732494.14030.111.camel@erato.phig.org> References: <200708202329.01131.ville.skytta@iki.fi> <200708211505.25125.ville.skytta@iki.fi> <1187732494.14030.111.camel@erato.phig.org> Message-ID: <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> On 8/21/07, Karsten Wade wrote: > On Tue, 2007-08-21 at 15:05 +0300, Ville Skytt? wrote: > > > Ok, that just amplifies the point that the information requested below seems > > to be critical prerequisite for inclusion of *any* package in EPEL. Steering > > committee, please process this request with high priority. > > > > > > Is there a complete list of all binary packages included in all RHEL > > > > channels that EPEL should be compatible with available somewhere? > > > > Complete public binary repodatas (just the metadata, not packages) of > > > > binary packages included in them would be nice. > > There are a lot of people here with knowledge of how Red Hat works. > > Is there an impediment to getting that list? > > -- > Karsten Wade ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.fedorapeople.org | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out. stahnma From smooge at gmail.com Wed Aug 22 00:34:07 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 21 Aug 2007 18:34:07 -0600 Subject: Complete RHEL package lists? In-Reply-To: <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> References: <200708202329.01131.ville.skytta@iki.fi> <200708211505.25125.ville.skytta@iki.fi> <1187732494.14030.111.camel@erato.phig.org> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> Message-ID: <80d7e4090708211734r3c979196n7ee8d0046c2dffab@mail.gmail.com> On 8/21/07, Michael Stahnke wrote: > On 8/21/07, Karsten Wade wrote: > > On Tue, 2007-08-21 at 15:05 +0300, Ville Skytt? wrote: > > > > > Ok, that just amplifies the point that the information requested below seems > > > to be critical prerequisite for inclusion of *any* package in EPEL. Steering > > > committee, please process this request with high priority. > > > > > > > > Is there a complete list of all binary packages included in all RHEL > > > > > channels that EPEL should be compatible with available somewhere? > > > > > Complete public binary repodatas (just the metadata, not packages) of > > > > > binary packages included in them would be nice. > > > > There are a lot of people here with knowledge of how Red Hat works. > > > > Is there an impediment to getting that list? > > > > -- > > Karsten Wade ^ Fedora Documentation Project > > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > > quaid.fedorapeople.org | gpg key: AD0E0C41 > > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > > > _______________________________________________ > > epel-devel-list mailing list > > epel-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > > > > > Can someone detail out what information is being looked for? Also, > what channels in RHN would some of this stuff fall under. I think > that tomcat and lots o' other java stuff is in some developer > channels. We'll need to iron the whole thing out. > Well there is the "Extras" which contains non-FLOSS code and some kernel modules that arent in the main-line I think. The only other stuff that would be not on CentOS-4/5 that is on RHN would be the RHX channels. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dag at wieers.com Wed Aug 22 02:03:23 2007 From: dag at wieers.com (Dag Wieers) Date: Wed, 22 Aug 2007 04:03:23 +0200 (CEST) Subject: Complete RHEL package lists? In-Reply-To: <80d7e4090708211734r3c979196n7ee8d0046c2dffab@mail.gmail.com> References: <200708202329.01131.ville.skytta@iki.fi> <200708211505.25125.ville.skytta@iki.fi> <1187732494.14030.111.camel@erato.phig.org> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <80d7e4090708211734r3c979196n7ee8d0046c2dffab@mail.gmail.com> Message-ID: On Tue, 21 Aug 2007, Stephen John Smoogen wrote: > On 8/21/07, Michael Stahnke wrote: > > On 8/21/07, Karsten Wade wrote: > > > On Tue, 2007-08-21 at 15:05 +0300, Ville Skytt? wrote: > > > > > > > Ok, that just amplifies the point that the information requested below seems > > > > to be critical prerequisite for inclusion of *any* package in EPEL. Steering > > > > committee, please process this request with high priority. > > > > > > > > > > Is there a complete list of all binary packages included in all RHEL > > > > > > channels that EPEL should be compatible with available somewhere? > > > > > > Complete public binary repodatas (just the metadata, not packages) of > > > > > > binary packages included in them would be nice. > > > > > > There are a lot of people here with knowledge of how Red Hat works. > > > > > > Is there an impediment to getting that list? > > > > Can someone detail out what information is being looked for? Also, > > what channels in RHN would some of this stuff fall under. I think > > that tomcat and lots o' other java stuff is in some developer > > channels. We'll need to iron the whole thing out. > > Well there is the "Extras" which contains non-FLOSS code and some > kernel modules that arent in the main-line I think. The only other > stuff that would be not on CentOS-4/5 that is on RHN would be the RHX > channels. I think there's more than just RHX/Extras. Everything that is in RHN and that is not available from ftp.redhat.com in RPM or SRPM format. There are beta-channels that are not offered as SRPM afaik. But it's hard to list things that you don't know exist :) Someone with full RHN access could simply verify for himself. Also, it would be useful to have everything that cannot be distributed available in nosrc format as well. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From mastahnke at gmail.com Wed Aug 22 02:50:48 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 21 Aug 2007 21:50:48 -0500 Subject: Complete RHEL package lists? In-Reply-To: References: <200708202329.01131.ville.skytta@iki.fi> <200708211505.25125.ville.skytta@iki.fi> <1187732494.14030.111.camel@erato.phig.org> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <80d7e4090708211734r3c979196n7ee8d0046c2dffab@mail.gmail.com> Message-ID: <7874d9dd0708211950m5ed031dek70c58204ef5a3fe@mail.gmail.com> On 8/21/07, Dag Wieers wrote: > On Tue, 21 Aug 2007, Stephen John Smoogen wrote: > > > On 8/21/07, Michael Stahnke wrote: > > > On 8/21/07, Karsten Wade wrote: > > > > On Tue, 2007-08-21 at 15:05 +0300, Ville Skytt? wrote: > > > > > > > > > Ok, that just amplifies the point that the information requested below seems > > > > > to be critical prerequisite for inclusion of *any* package in EPEL. Steering > > > > > committee, please process this request with high priority. > > > > > > > > > > > > Is there a complete list of all binary packages included in all RHEL > > > > > > > channels that EPEL should be compatible with available somewhere? > > > > > > > Complete public binary repodatas (just the metadata, not packages) of > > > > > > > binary packages included in them would be nice. > > > > > > > > There are a lot of people here with knowledge of how Red Hat works. > > > > > > > > Is there an impediment to getting that list? > > > > > > Can someone detail out what information is being looked for? Also, > > > what channels in RHN would some of this stuff fall under. I think > > > that tomcat and lots o' other java stuff is in some developer > > > channels. We'll need to iron the whole thing out. > > > > Well there is the "Extras" which contains non-FLOSS code and some > > kernel modules that arent in the main-line I think. The only other > > stuff that would be not on CentOS-4/5 that is on RHN would be the RHX > > channels. > > I think there's more than just RHX/Extras. Everything that is in RHN and > that is not available from ftp.redhat.com in RPM or SRPM format. There are > beta-channels that are not offered as SRPM afaik. > > But it's hard to list things that you don't know exist :) Someone with > full RHN access could simply verify for himself. > > Also, it would be useful to have everything that cannot be distributed > available in nosrc format as well. > > Kind regards, > -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- > [Any errors in spelling, tact or fact are transmission errors] > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > I'll check my RHN account tomorrow. We have many channels, not sure if it's all of them or not. I will start making a list and post here. stahnma From jos at xos.nl Wed Aug 22 09:13:50 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 22 Aug 2007 11:13:50 +0200 Subject: Complete RHEL package lists? In-Reply-To: <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com>; from mastahnke@gmail.com on Tue, Aug 21, 2007 at 06:20:47PM -0500 References: <200708202329.01131.ville.skytta@iki.fi> <200708211505.25125.ville.skytta@iki.fi> <1187732494.14030.111.camel@erato.phig.org> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> Message-ID: <20070822111350.A16513@xos037.xos.nl> On Tue, Aug 21, 2007 at 06:20:47PM -0500, Michael Stahnke wrote: > Can someone detail out what information is being looked for? Also, > what channels in RHN would some of this stuff fall under. I think > that tomcat and lots o' other java stuff is in some developer > channels. We'll need to iron the whole thing out. Tomcat is a standard part of RHEL5 and thus in the regular channels, like much other Java stuff, that was formerly (pre-RHEL5) known as the "Red Hat Application Server". -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ville.skytta at iki.fi Wed Aug 22 14:43:33 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 22 Aug 2007 17:43:33 +0300 Subject: Complete RHEL package lists? In-Reply-To: <20070822111350.A16513@xos037.xos.nl> References: <200708202329.01131.ville.skytta@iki.fi> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <20070822111350.A16513@xos037.xos.nl> Message-ID: <200708221743.34571.ville.skytta@iki.fi> On Wednesday 22 August 2007, Jos Vos wrote: > On Tue, Aug 21, 2007 at 06:20:47PM -0500, Michael Stahnke wrote: > > Can someone detail out what information is being looked for? Also, > > what channels in RHN would some of this stuff fall under. I think > > that tomcat and lots o' other java stuff is in some developer > > channels. We'll need to iron the whole thing out. > > Tomcat is a standard part of RHEL5 and thus in the regular channels, > like much other Java stuff, that was formerly (pre-RHEL5) known as > the "Red Hat Application Server". tomcat is also in Fedora, but that's not what I'm talking about. What I'm ready to submit for review is the native APR-based connector, tomcat-native (also known as tcnative, maybe libtcnative). http://tomcat.apache.org/tomcat-6.0-doc/apr.html http://archive.apache.org/dist/tomcat/tomcat-connectors/native/ For this particular case, I guess it suffices to know whether there are any packages that contain a file named libtcnative-1.so in any RHEL 5 channels. From mastahnke at gmail.com Wed Aug 22 15:32:01 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 22 Aug 2007 10:32:01 -0500 Subject: Complete RHEL package lists? In-Reply-To: <200708221743.34571.ville.skytta@iki.fi> References: <200708202329.01131.ville.skytta@iki.fi> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <20070822111350.A16513@xos037.xos.nl> <200708221743.34571.ville.skytta@iki.fi> Message-ID: <7874d9dd0708220832p72a01f35ne7acb7de205ad339@mail.gmail.com> On 8/22/07, Ville Skytt? wrote: > On Wednesday 22 August 2007, Jos Vos wrote: > > On Tue, Aug 21, 2007 at 06:20:47PM -0500, Michael Stahnke wrote: > > > Can someone detail out what information is being looked for? Also, > > > what channels in RHN would some of this stuff fall under. I think > > > that tomcat and lots o' other java stuff is in some developer > > > channels. We'll need to iron the whole thing out. > > > > Tomcat is a standard part of RHEL5 and thus in the regular channels, > > like much other Java stuff, that was formerly (pre-RHEL5) known as > > the "Red Hat Application Server". > > tomcat is also in Fedora, but that's not what I'm talking about. What I'm > ready to submit for review is the native APR-based connector, tomcat-native > (also known as tcnative, maybe libtcnative). > > http://tomcat.apache.org/tomcat-6.0-doc/apr.html > http://archive.apache.org/dist/tomcat/tomcat-connectors/native/ > > For this particular case, I guess it suffices to know whether there are any > packages that contain a file named libtcnative-1.so in any RHEL 5 channels. > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > I've added this topic to today's EPEL SIG. stahnma From kwade at redhat.com Wed Aug 22 16:22:19 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 22 Aug 2007 09:22:19 -0700 Subject: updates, missing meeting Message-ID: <1187799739.14030.183.camel@erato.phig.org> I have a conflicting meeting, here are my not-much-updated updates: * EPEL and Red Hat Support -- no action, still need to contact someone * RHEL subscriptions -- looking for a budget sponsor, haven't found one yet * RHX/EPEL -- holding pattern -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed Aug 22 18:55:14 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 22 Aug 2007 12:55:14 -0600 Subject: updates, missing meeting In-Reply-To: <1187799739.14030.183.camel@erato.phig.org> References: <1187799739.14030.183.camel@erato.phig.org> Message-ID: <80d7e4090708221155r8dfcc77wf1929e84a651fe17@mail.gmail.com> On 8/22/07, Karsten Wade wrote: > I have a conflicting meeting, here are my not-much-updated updates: > > * EPEL and Red Hat Support -- no action, still need to contact someone > * RHEL subscriptions -- looking for a budget sponsor, haven't found one > yet Worse comes to worse, I am sure we could get Oracle to sponsor some subscriptions for us so we could look at the RHX+ channels :). > * RHX/EPEL -- holding pattern > > -- > Karsten Wade ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.fedorapeople.org | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From fedora at leemhuis.info Sun Aug 26 13:14:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Aug 2007 15:14:34 +0200 Subject: Log from this weeks (200700822) EPEL SIG Meeting Message-ID: <46D17CBA.8060202@leemhuis.info> Just a reminder: it's a SIG meeting, not a Steering Committee meeting. The EPEL Steering Committee would be glad if SIG members and other EPEL contributors would join us more often! 00:00:02 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:02 < knurd> | Hi everybody; who's around? 00:00:02 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:04 * | knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:00:22 * | nirik is here. 00:00:23 --> | che (Rudolf Kastl) has joined #fedora-meeting 00:00:30 * | mmcgrath here 00:00:44 < che> | heyyas 00:01:05 < mmcgrath> | I know dgilmore is traveling today 00:01:57 < knurd> | stahnma, was around two hours ago 00:02:22 --> | kital (Joerg Simon) has joined #fedora-meeting 00:02:40 --> | Jeff_S (Jeff) has joined #fedora-meeting 00:02:46 < knurd> | hi Jeff_S :) 00:02:56 < Jeff_S> | :) 00:03:10 < knurd> | that makes four people from the steering committee 00:03:16 < knurd> | well, let's start slowly 00:03:21 --- | knurd has changed the topic to: EPEL Meeting|push to stable easily -- knurd 00:03:33 < knurd> | I talked to mschwendt about it 00:03:39 < knurd> | but didn't find time for more yet 00:03:53 < knurd> | my plan is to create a second set of push scripts 00:04:02 * | nirik thinks that sounds reasonable. 00:04:08 < knurd> | and a small add-on script, that moves stuff from testing to stable 00:04:10 < mmcgrath> | that do what? 00:04:25 < knurd> | and then uses the normal scripts for the createrepo, repoview and sync stuff 00:05:02 < nirik> | we will need to make sure that testing is totally clear of problems before moving things to stable... 00:05:02 < knurd> | nirik, are you extras pushed? 00:05:14 < knurd> | nirik, or accidentally familar with the push scripts? 00:05:21 < knurd> | I likely could need some help 00:05:58 --> | stahnma_ (Unknown) has joined #fedora-meeting 00:06:00 < nirik> | I didn't do extras pushes, no... I'd be happy to help. 00:06:01 < knurd> | nirik, yeah, but we could do that similar to how we did it for the annoucement 00:06:10 < mmcgrath> | 00:06:11 * | stahnma_ is here...stupid network issues 00:06:12 < knurd> | nirik, do you know python well? 00:06:30 < mmcgrath> | it seems likely that without manual work the testing repo will probably always be broken 00:06:30 < knurd> | mmcgrath, could you sponser nirik as epel_pusher? 00:06:33 < nirik> | not super well. I'm more of a quick and dirty shell scripter from long ago. 00:06:37 <-- | ricky has quit (Read error: 104 (Connection reset by peer)) 00:06:41 < nirik> | but I can figure out python usually. 00:06:50 < knurd> | nirik, well, we'll find a way 00:07:00 < mmcgrath> | knurd: will he be working on the scripts or doing the pushing or both? 00:07:02 < knurd> | I think we move on now and discuss the details another time 00:07:17 < knurd> | mmcgrath, I'd say: all that is involved with pushing 00:07:20 < mmcgrath> | nirik: apply for the epel pushers group. 00:07:23 < nirik> | yeah, we will need to intervene on testing repo to make it clean I am sure. 00:07:24 < Jeff_S> | in general it sounds like a good idea to me 00:07:38 < nirik> | mmcgrath: ok. 00:07:48 --- | knurd has changed the topic to: EPEL Meeting|new meeting time? -- all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime 00:08:02 < knurd> | shall we remove this from the list and stick to this time? 00:08:22 < stahnma_> | would it be possible to do alternating meetings, like some other Fedora groups though? 00:08:27 * | mmcgrath doesn't have an opinion on this really. 00:08:27 < nirik> | I think this time is probibly the best we are going to do. 00:08:28 < Jeff_S> | well, I'll be at a new job starting in October and I'm not sure if this will work or not for me at that point 00:08:30 < stahnma_> | so sometimes it's not in the middle of my work day? 00:08:32 < mmcgrath> | stahnma_: +1 00:08:43 < Jeff_S> | but likely it'll still work 00:08:56 < knurd> | stahnma_, I'm fine with that 00:09:08 < Jeff_S> | +1 here too 00:09:11 < stahnma_> | ok, let's talk about it on list 00:09:15 < knurd> | but that likely means that I won#t be around if we don#t find a european-firendly timeslot 00:09:19 < knurd> | stahnma_, +1 00:09:36 <-- | ChitleshGoorah has quit (No route to host) 00:09:49 < stahnma_> | ok, well try and have a good for Europe timeslot one week and good for US next week or something 00:09:53 < stahnma_> | anyway, details on list 00:09:57 < Jeff_S> | ok 00:10:07 --- | knurd has changed the topic to: EPEL Meeting| MetaData for all Packages available to contributors. -- stahnma 00:10:15 < knurd> | stahnma_ ? 00:10:22 < stahnma_> | The thread that was brough up about this is very interesting 00:10:34 < stahnma_> | basically, the EPEL community has no exact list of packages in RHEL/RHN proper 00:10:45 < stahnma_> | and even if we get a list of packages, we still need metadata 00:10:53 < stahnma_> | to see if we're conflicting with RH packages 00:10:55 < nirik> | I was pondering on that... could we get a list from plagueserver? 00:11:04 < nirik> | ie, the buildsystem? 00:11:09 < stahnma_> | using hte RHN API I can get almost everything 00:11:13 < knurd> | nirik, has only RHEL, not the extras channels 00:11:13 < stahnma_> | I was working on this morning 00:11:18 < mmcgrath> | well the build system doesn't have extra channels. 00:11:24 < stahnma_> | the metadata is the hard part 00:11:28 < nirik> | ah, ok. 00:11:29 < mmcgrath> | unfortunately I think this may have to be a reactive thing. 00:11:34 < mmcgrath> | since its a moving target. 00:11:44 < stahnma_> | I mean, using hte API I can get files and all sort of stuff, basically, anything that RPM can give you 00:11:53 < nirik> | could we provide some lookup tool? 00:11:58 < stahnma_> | but, how to capture the data and incorporate into our processes, that's hard 00:12:02 < stahnma_> | nirik: +1 00:12:06 < mmcgrath> | nirik: and use what as the back end? 00:12:06 < stahnma_> | If we had a generic RHN account 00:12:20 < mmcgrath> | Fedora Infrastructure has RHN but not all of the channels 00:12:25 < stahnma_> | Just a python script that hits RHN? 00:12:25 < nirik> | not sure. ;( 00:12:42 < mmcgrath> | there is an API to RHN. 00:12:42 < knurd> | stahnma_, quaid said something about "RHEL subscriptions -- looking for a budget sponsor, haven't found one yet" 00:12:48 < nirik> | we do need something tho, so we block already existing packages. ;( 00:12:54 < stahnma_> | that's what I have been working with mmcgrath 00:13:17 < mmcgrath> | whats the end goal of knowing whats in RHEL? 00:13:28 < mmcgrath> | not duplicating? 00:13:33 < stahnma_> | I think it's making sure new package don't conflict with rhel or addon packages 00:13:38 < nirik> | right. 00:13:45 < stahnma_> | but I am unclear on our position for all channels 00:13:57 < mmcgrath> | stahnma_: but both epel and RHN are moving targets. 00:14:07 < stahnma_> | true, so I guess we need some ongoing process 00:14:09 < nirik> | also, are there going to be any more new packages added to 5.1 that were not in the 5.1beta? I guess we wait and see. 00:14:10 < mmcgrath> | so there's no real way to do what we're proposing. 00:14:28 < mmcgrath> | unless we do like a daily check of everything in RHN vs everything in epel. 00:14:57 < stahnma_> | yes, if we had a good outline of what exactly was required, I think we could conquer it 00:14:59 <-- | sankarshan has quit ("Are you sure you want to quit this channel (Cancel/Ok) ?") 00:15:07 < nirik> | do new packages get added to RHN at non quarterly updates? or only on quarterly? 00:15:18 < stahnma_> | supposedly only quarterly 00:15:23 < mmcgrath> | when it comes to additional channels, I don't think there's any rules. 00:15:23 < skvidal> | umm 00:15:23 < stahnma_> | but new channels can pop up any time 00:15:23 < skvidal> | no 00:15:30 < skvidal> | security updates get pushed async 00:15:31 < warren> | It isn't exactly quarterly 00:15:45 < stahnma_> | skvidal: right, updates for existing packages 00:16:00 < stahnma_> | but new packages, as in foo previously didn't exist in RHEL 5 channel 00:16:00 < warren> | and sometimes new packages are added "async", usually in the "Fastrack" channel 00:16:36 --> | ricky (Ricky) has joined #fedora-meeting 00:16:47 < knurd> | so, what to do? 00:16:53 < knurd> | continue the discussion on the list? 00:16:55 < nirik> | ideally, what we want is 2 items: when a new epel package is being added we want to make sure it's not already in RHN. Also, we want to know when new RHN packages are added so if they are in EPEL we can drop the epel one, right? 00:16:57 <-- | kital has quit (Remote closed the connection) 00:17:40 < knurd> | nirik, I think those are the main problems (at least afaics) 00:17:58 < stahnma_> | yeah, according to RHN there are 464 channels 00:18:01 < stahnma_> | currently 00:18:06 * | warren sends a note to management to be sure added packages are "newer" than EPEL packages. 00:18:14 < nirik> | FYI, 5.1 (beta at least) has 3 new packages that are in epel already 00:18:30 < nirik> | but all of them are newer in rhn... so no problem with upgrades. 00:18:34 < skvidal> | what about z-stream or whatever it is being called today builds? 00:18:54 < nirik> | stahnma_: 464! woah. What are all those? yikes. I thought there were only a handfull... 00:18:57 < stahnma_> | skvidal: is that the LAMP stack stuff that can roll? 00:19:13 < stahnma_> | nirik: well, that's each arch, and AS and ES separate 00:20:10 < knurd> | we get slow again -- continue on the list? 00:20:28 < mmcgrath> | +1 to the list. This is a compicated topic. 00:20:39 < mmcgrath> | seems straight forward, but it just isn't :) 00:20:39 < nirik> | sure... I think stahnma_ is the leader here since he has RHN access. ;) 00:20:56 < stahnma_> | Ok 00:21:07 < stahnma_> | I will get some data together and try to circle round on the list 00:21:08 * | knurd has access to some RHN boxes now as well -- finally :-) 00:21:15 < knurd> | stahnma_, k, thx 00:21:17 * | knurd moves on 00:21:25 --- | knurd has changed the topic to: EPEL Meeting| for enterprise customers/ISVs/IHVs -- stahnma, quaid 00:21:34 < knurd> | quaid's topics, who's not around 00:21:41 < stahnma_> | skip... 00:21:44 < knurd> | does anyone want to say something about that topic? 00:21:52 < knurd> | seesm not 00:21:53 --> | G_ (Nigel Jones) has joined #fedora-meeting 00:21:53 --- | knurd has changed the topic to: EPEL Meeting| 00:21:58 < stahnma_> | I need to reread the stuff Quaid sent out 00:22:00 < knurd> | same prceedure 00:22:08 < stahnma_> | again, on list... 00:22:09 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:22:22 < knurd> | anything else to discuss? 00:22:43 --- | chitlesh_ is now known as ChitleshGoorah 00:22:51 < Jeff_S> | not me 00:23:00 * | knurd will close the meeting in 60 00:23:12 < nirik> | oh, on the license stuff... EPEL branches should get updated as well, right? 00:23:26 < nirik> | since we follow fedora package guidelines? But not rebuilt? or ? 00:23:29 < stahnma_> | nirik: I would assume 00:23:29 < knurd> | same as FC-6 and F-7 afaics 00:23:38 < knurd> | e.g. update with next pacakge update 00:23:42 < nirik> | ok, we might drop a note to the epel list about that... 00:23:51 < stahnma_> | probably a good idea 00:23:54 < knurd> | +1 00:23:57 * | stahnma_ has several packages to update... 00:24:01 < Jeff_S> | +1 00:24:21 < knurd> | does anyone want to take care of that? 00:24:26 < knurd> | or shall I just mention it in the report? 00:24:36 < knurd> | btw, is anybody reading the reports? 00:24:40 < stahnma_> | I do 00:24:42 < knurd> | or am I just wasting my time? 00:24:42 < stahnma_> | every week 00:24:46 < Jeff_S> | I always read them 00:24:47 < nirik> | In the report is fine... I can do a seperate post if people want. 00:24:51 * | nirik reads them. 00:24:57 < knurd> | nirik, might be a good idea 00:25:05 < stahnma_> | +1 00:25:10 < knurd> | nirik, maybe quickly ask spot for his opinion on that topic 00:25:32 < nirik> | ok, will do one. I also did a mass check of sources, might be some epel packages affected by that (although I just checked devel/rawhide) 00:25:49 < nirik> | ok, can do. 00:25:58 < knurd> | k, anything else regarding EPEL? 00:26:11 * | mmcgrath has nothing 00:26:19 --> | _blah_ (purple) has joined #fedora-meeting 00:26:24 * | knurd will close the meeting in 30 00:26:42 * | knurd will close the meeting in 15 00:26:56 < knurd> | -- MARK -- Meeting end From fedora at leemhuis.info Sun Aug 26 13:22:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Aug 2007 15:22:13 +0200 Subject: EPEL report week 34 2007 Message-ID: <46D17E85.8010709@leemhuis.info> = Weekly EPEL Summary = Week 34/2007 == Most important happenings == * None == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * dgilmore (DennisGilmore) (missed it by a few minutes) * quaid (KarstenWade) === Summary === * EPEL Meeting|push to stable easily -- knurd * knurd talked to mschwendt about it but didn't find time for more yet; more work underway (which is in progress already when this report got written) * we'll make nirik a pusher as well to spread the burden of the work * new meeting time? -- all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) * stahnma suggested to do alternating meetings (and not in the middle of the work-day), like some other Fedora groups. Another old idea mentioned earlier was to do bi-weekly meetings (maybe a mix of both?). Discuss further on the list. * Metadata for all Packages available to contributors. -- stahnma * The thread that was brought up about this is very interesting; basically, the EPEL community has no exact list of packages in RHEL/RHN proper; and even if we get a list of packages, we still need metadata; to see if we're conflicting with RH packages * some discussion around this; see log for full details; But its a complicated topic, so continue on the list * the new License tags and EPEL * nirik will consult spot how to handle the tags for EPEL and post to the list about it * is anybody reading the weekly reports? * some people said they do. But its a boring job, so tell me if I'm wasing my time ;-) === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00135.html == Stats == === General === Number of EPEL Contributors: unknown -- now that the pgkdb is in production it's not easily determinable for now (AFAIK) === EPEL 5 === Number of source packages: 597 Number of binary packages: 1156 There are 6 new Packages: * ccache | C/C++ compiler cache * cvsgraph | CVS/RCS repository grapher * libpqxx | C++ client API for PostgreSQL * nginx | Robust, small and high performance http and reverse proxy server * python-sqlalchemy | Modular and flexible ORM library for python * radiusclient-ng | RADIUS protocol client library === EPEL 4 === Number of source packages: 382 Number of binary packages: 785 There are 5 new Packages: * cvsgraph | A CVS/RCS repository grapher * libpqxx | C++ client API for PostgreSQL * nginx | Robust, small and high performance http and reverse proxy server * python-kid | Kid - A simple and pythonic XML template language * sqlite | Library that implements an embeddable SQL database engine ---- ["CategoryEPELReports"] From fedora at leemhuis.info Sun Aug 26 13:48:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Aug 2007 15:48:00 +0200 Subject: EPEL Steering Committee's mandate is expiring -- how to move on? Message-ID: <46D18490.3050309@leemhuis.info> Hi all! > The EPEL Steering Committee's mandate for leading EPEL was time-limited > by FESCo until end of September this year. Well, we are getting closer > to that date now, so we IMHO should start to discuss how to move on. > [...] I just send a mail to fedora-devel-list with this para and some more details. As most EPEL contributors are likely on that list as well I avoided to cross-post the mail here and chose to send this "heads up" instead. If you are not on fedora-devel you can find that mail at: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01845.html Feel free to express you opinion here, but it IMHO would be best for everyone if we have the discussion just in one place (e.g. fedora-devel). CU knurd From mmcgrath at redhat.com Sun Aug 26 15:35:05 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 26 Aug 2007 10:35:05 -0500 Subject: Testing -> stable? Message-ID: <46D19DA9.40907@redhat.com> There's been a lot of conversations about the testing -> stable process on this list, on IRC and just in general chats. Can someone explain what the current consensus is? I have branding concerns. -Mike From mastahnke at gmail.com Sun Aug 26 17:52:16 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sun, 26 Aug 2007 12:52:16 -0500 Subject: Timeslot for EPEL Meeting Message-ID: <7874d9dd0708261052q741bc927m8c84af9212018f0c@mail.gmail.com> There has been some discussion about timeslots for the the EPEL SIG meeting. Last week, some discussion was brought up about rotating the time-slot to allow for more involvement from different parts of the world. In general, this would be an effort to gain more participation from the community and SIG as a whole and not just the steering committee. EPEL is new, and needs care and feeding, that means help from everyone willing to put in some time. I will go ahead and propose a meeting time on Wednesdays of 23:00 UTC and rotate that every other week with the current time of 17:00 UTC. If this is too much, or the wrong time, please speak up on this thread. We are looking for ways to encourage participation. I also realize that both of these timeslots may not be all that Asia friendly. If we have interest from Asia, we can continue to make adjustments. stahnma From mastahnke at gmail.com Sun Aug 26 17:56:24 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sun, 26 Aug 2007 12:56:24 -0500 Subject: Complete RHEL package lists? In-Reply-To: <7874d9dd0708220832p72a01f35ne7acb7de205ad339@mail.gmail.com> References: <200708202329.01131.ville.skytta@iki.fi> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <20070822111350.A16513@xos037.xos.nl> <200708221743.34571.ville.skytta@iki.fi> <7874d9dd0708220832p72a01f35ne7acb7de205ad339@mail.gmail.com> Message-ID: <7874d9dd0708261056y3309afd4na13e59a2262f20bf@mail.gmail.com> I haven't forgotten about this topic, but I am still at a loss for direction toward a solution. I can use the RHN API to pull in a lot of information about RHEL channels and such, but there are 400+ channels in RHN, and virtually no metadata. I suppose the metadata could somehow be derived, but that is a moving target. I want to understand the total process before we dive in and try to solve the problem. Right now the problem from what I understand is: Does an RHN channel already provide file : /usr/lib/foo ? Are there other problems to tackle here? What about obsoleting an EL/RHN package? Is that bad? stahnma From sheltren at cs.ucsb.edu Sun Aug 26 18:41:48 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 26 Aug 2007 11:41:48 -0700 Subject: Timeslot for EPEL Meeting In-Reply-To: <7874d9dd0708261052q741bc927m8c84af9212018f0c@mail.gmail.com> References: <7874d9dd0708261052q741bc927m8c84af9212018f0c@mail.gmail.com> Message-ID: On Aug 26, 2007, at 10:52 AM, Michael Stahnke wrote: > > I will go ahead and propose a meeting time on Wednesdays of 23:00 UTC > and rotate that every other week with the current time of 17:00 UTC. > If this is too much, or the wrong time, please speak up on this > thread. We are looking for ways to encourage participation. +1. I think this would work for me. I am interested to see if the time change would bring in more participation from people that are interested in EPEL but not necessarily on the steering committee. -Jeff From smooge at gmail.com Sun Aug 26 22:37:37 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 26 Aug 2007 16:37:37 -0600 Subject: Log from this weeks (200700822) EPEL SIG Meeting In-Reply-To: <46D17CBA.8060202@leemhuis.info> References: <46D17CBA.8060202@leemhuis.info> Message-ID: <80d7e4090708261537g10e8ff0djb36a39deefbf869b@mail.gmail.com> On 8/26/07, Thorsten Leemhuis wrote: > Just a reminder: it's a SIG meeting, not a Steering Committee meeting. The EPEL Steering Committee would be glad if SIG members and other EPEL contributors would join us more often! Currently the meetings are occuring during other workside stuff. I will see if I can join when at the new meeting time. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From fedora at leemhuis.info Mon Aug 27 04:57:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Aug 2007 06:57:03 +0200 Subject: Timeslot for EPEL Meeting In-Reply-To: References: <7874d9dd0708261052q741bc927m8c84af9212018f0c@mail.gmail.com> Message-ID: <46D2599F.2030409@leemhuis.info> On 26.08.2007 20:41, Jeff Sheltren wrote: > On Aug 26, 2007, at 10:52 AM, Michael Stahnke wrote: >> I will go ahead and propose a meeting time on Wednesdays of 23:00 UTC >> and rotate that every other week with the current time of 17:00 UTC. >> If this is too much, or the wrong time, please speak up on this >> thread. We are looking for ways to encourage participation. > > +1. I think this would work for me. > > I am interested to see if the time change would bring in more > participation from people that are interested in EPEL but not > necessarily on the steering committee. Fine with me -- but I likely never will be able to make the 23:00 UTC meetings as they are way to late for me (my alarm clock rings at 3:30 ATM...). So if you want to do those meetings make sure there is always one (preferred: most of the time the same person) that runs them (stahnma, would you be willing to do that?). That person should also write the summary for the report (I find it hard to write them if someone else ran the meeting). CU knurd From fedora at leemhuis.info Mon Aug 27 06:31:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Aug 2007 08:31:14 +0200 Subject: Testing -> stable? In-Reply-To: <46D19DA9.40907@redhat.com> References: <46D19DA9.40907@redhat.com> Message-ID: <46D26FB2.8030900@leemhuis.info> On 26.08.2007 17:35, Mike McGrath wrote: > There's been a lot of conversations about the testing -> stable process > on this list, on IRC and just in general chats. Can someone explain > what the current consensus is? I have branding concerns. Well, nothing new got decided yet. So the current plan is still the old: - all new and updated packages go to testing - security updates go straight to stable or to testing for 24h and then get moved to stable - when a RHEL quarterly update is due we do what we did when we announced EPEL; e.g. make sure all deps are fulfilled in the repo (testing in this case) and expect the packages are working and move the packages to a new dir (e.g. 5.1/) and create a symlink from 5 -> 5.1 (thus people staying on 5.0 can stick to EPEL 5.0 if they want); cycle starts anew here and testing will get build for 5.2 What is under discussion is afaics this ( points with * are my option on the issue): - move new packages to current stable more often * I'd say that should be fine if they were in testing for some time (four weeks maybe?). But who is willing to do that work? Someone would need to prepare a repo locally, move all packages that fall under this rule over and make sure all deps are still satisfied in the porper repo. Then hand the list of to-be-moved-to-stable packages to one of the signers and let him move it over (when we have the proper tools in place, which is in the works; thx to mschwendt). - move updated packages to stable more often * if there is a strong need to move a package it is allowed according to the policy. But for the other updates I think we manage EPEL similar to how RHEL does it: non-crucial updates go into a quarterly update and no major updates if there isn't a reasons for them. Just "latest and greatest" is IMHO not the reason - manage EPEL more like Fedora {,Extras} * afaics most people in the buildup phase wanted a stable EPEL and I really think that should continue to be our #1 goal. But I see a need and interest for a "more up2date packages" EPEL repo. That what I call EPEL-rolling; I'm fine with having it in parallel to the stable repo. But do we have the man-power to start this yet? CU thl From Christian.Iseli at licr.org Mon Aug 27 07:13:43 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 27 Aug 2007 09:13:43 +0200 Subject: EPEL report week 34 2007 In-Reply-To: <46D17E85.8010709@leemhuis.info> References: <46D17E85.8010709@leemhuis.info> Message-ID: <20070827091343.7d67b656@ludwig-alpha.unil.ch> On Sun, 26 Aug 2007 15:22:13 +0200, Thorsten Leemhuis wrote: > * is anybody reading the weekly reports? Yes I am. Helps me keep up to date with what is happening in EPEL. C From sundaram at fedoraproject.org Mon Aug 27 09:11:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 27 Aug 2007 14:41:39 +0530 Subject: EPEL report week 34 2007 In-Reply-To: <46D17E85.8010709@leemhuis.info> References: <46D17E85.8010709@leemhuis.info> Message-ID: <46D2954B.6000601@fedoraproject.org> Thorsten Leemhuis wrote: > * is anybody reading the weekly reports? > > * some people said they do. But its a boring job, so tell me if I'm > wasing my time ;-) You are not wasting your time. I don't find time to read the entire logs often and the meeting mins are absolutely essential to keep track things of changes within the project quickly. The number of contributors and packages are also a good metric. Rahul From kevin at tummy.com Mon Aug 27 16:16:04 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 27 Aug 2007 10:16:04 -0600 Subject: License tag updates reminder Message-ID: <20070827101604.08b55830@ghistelwchlohm.scrye.com> Just a reminder to everyone: While you are updating your License tags in your Fedora branches to meet the new guidelines (See: http://fedoraproject.org/wiki/Licensing ) Please do update your EPEL branches as well to conform to this guideline and check them into CVS. NOTE: please don't rebuild your package for just this change, we just want to make sure all packages have been updated to meet this guideline and the change would go out with your next real update to the package. Thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Mon Aug 27 16:24:41 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 27 Aug 2007 10:24:41 -0600 Subject: clamav Message-ID: <20070827102441.54f04c9a@ghistelwchlohm.scrye.com> Since Enrico never intended to maintain clamav in EPEL, he has formally orphaned clamav in EL-4 and EL-5. Is there anyone out there that would be willing to take it on? Preferably someone who likes/understands Enrico's package setup so you can stay in sync with Fedora versions? If no one steps up soon, I might be able to take it over, but I would be quite likely to radically change the packaging. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Mon Aug 27 16:29:38 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 27 Aug 2007 18:29:38 +0200 (CEST) Subject: clamav In-Reply-To: <20070827102441.54f04c9a@ghistelwchlohm.scrye.com> References: <20070827102441.54f04c9a@ghistelwchlohm.scrye.com> Message-ID: On Mon, 27 Aug 2007, Kevin Fenzi wrote: > Since Enrico never intended to maintain clamav in EPEL, he has formally > orphaned clamav in EL-4 and EL-5. > > Is there anyone out there that would be willing to take it on? > > Preferably someone who likes/understands Enrico's package setup so you > can stay in sync with Fedora versions? > > If no one steps up soon, I might be able to take it over, but I would > be quite likely to radically change the packaging. Before you do, let's discuss how we can make things compatible in order to help existing users :) -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From fedora at leemhuis.info Mon Aug 27 17:53:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Aug 2007 19:53:46 +0200 Subject: Complete RHEL package lists? In-Reply-To: <7874d9dd0708261056y3309afd4na13e59a2262f20bf@mail.gmail.com> References: <200708202329.01131.ville.skytta@iki.fi> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <20070822111350.A16513@xos037.xos.nl> <200708221743.34571.ville.skytta@iki.fi> <7874d9dd0708220832p72a01f35ne7acb7de205ad339@mail.gmail.com> <7874d9dd0708261056y3309afd4na13e59a2262f20bf@mail.gmail.com> Message-ID: <46D30FAA.7070300@leemhuis.info> On 26.08.2007 19:56, Michael Stahnke wrote: > I haven't forgotten about this topic, but I am still at a loss for > direction toward a solution. I can use the RHN API to pull in a lot > of information about RHEL channels and such, but there are 400+ > channels in RHN, and virtually no metadata. I suppose the metadata > could somehow be derived, but that is a moving target. I think the point got mentioned in a meeting a bit, but not further discussed: Why can't we simply run a small script on one or two (RHEL5Desktop and RHEL5Server) machines somewhere that just write the informations into some files and uploads those somewhere? That way we might not provide all the data people might be interested it, but a package-list (which would be a good start) and some other stuff afaics should be possible, which is better than nothing. CU knurd From kyle.gonzales at gmail.com Mon Aug 27 18:54:36 2007 From: kyle.gonzales at gmail.com (Kyle Gonzales) Date: Mon, 27 Aug 2007 14:54:36 -0400 Subject: Complete RHEL package lists? In-Reply-To: <46D30FAA.7070300@leemhuis.info> References: <200708202329.01131.ville.skytta@iki.fi> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <20070822111350.A16513@xos037.xos.nl> <200708221743.34571.ville.skytta@iki.fi> <7874d9dd0708220832p72a01f35ne7acb7de205ad339@mail.gmail.com> <7874d9dd0708261056y3309afd4na13e59a2262f20bf@mail.gmail.com> <46D30FAA.7070300@leemhuis.info> Message-ID: On 8/27/07, Thorsten Leemhuis wrote: > > > On 26.08.2007 19:56, Michael Stahnke wrote: > > I haven't forgotten about this topic, but I am still at a loss for > > direction toward a solution. I can use the RHN API to pull in a lot > > of information about RHEL channels and such, but there are 400+ > > channels in RHN, and virtually no metadata. I suppose the metadata > > could somehow be derived, but that is a moving target. > > I think the point got mentioned in a meeting a bit, but not further > discussed: > > Why can't we simply run a small script on one or two (RHEL5Desktop and > RHEL5Server) machines somewhere that just write the informations into > some files and uploads those somewhere? > > That way we might not provide all the data people might be interested > it, but a package-list (which would be a good start) and some other > stuff afaics should be possible, which is better than nothing. Do you need a listing for the layered products as well, or just the base/extra/supplementary RHEL channels? -- Kyle Gonzales kyle.gonzales at gmail.com GPG Pub Key: 9C3FBD51 From ville.skytta at iki.fi Mon Aug 27 19:14:27 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 27 Aug 2007 22:14:27 +0300 Subject: Complete RHEL package lists? In-Reply-To: References: <200708202329.01131.ville.skytta@iki.fi> <46D30FAA.7070300@leemhuis.info> Message-ID: <200708272214.28213.ville.skytta@iki.fi> On Monday 27 August 2007, Kyle Gonzales wrote: > On 8/27/07, Thorsten Leemhuis wrote: > > > > Why can't we simply run a small script on one or two (RHEL5Desktop and > > RHEL5Server) machines somewhere that just write the informations into > > some files and uploads those somewhere? > > > > That way we might not provide all the data people might be interested > > it, but a package-list (which would be a good start) and some other > > stuff afaics should be possible, which is better than nothing. > > Do you need a listing for the layered products as well, or just the > base/extra/supplementary RHEL channels? I think the EPEL project needs to decide, enumerate and document the exact channels, derived distributions etc it attempts to be compatible with first. The answer to the above question would then be those channels etc. From kyle.gonzales at gmail.com Mon Aug 27 19:16:55 2007 From: kyle.gonzales at gmail.com (Kyle Gonzales) Date: Mon, 27 Aug 2007 15:16:55 -0400 Subject: Complete RHEL package lists? In-Reply-To: <200708272214.28213.ville.skytta@iki.fi> References: <200708202329.01131.ville.skytta@iki.fi> <46D30FAA.7070300@leemhuis.info> <200708272214.28213.ville.skytta@iki.fi> Message-ID: On 8/27/07, Ville Skytt? wrote: > On Monday 27 August 2007, Kyle Gonzales wrote: > > On 8/27/07, Thorsten Leemhuis wrote: > > > > > > Why can't we simply run a small script on one or two (RHEL5Desktop and > > > RHEL5Server) machines somewhere that just write the informations into > > > some files and uploads those somewhere? > > > > > > That way we might not provide all the data people might be interested > > > it, but a package-list (which would be a good start) and some other > > > stuff afaics should be possible, which is better than nothing. > > > > Do you need a listing for the layered products as well, or just the > > base/extra/supplementary RHEL channels? > > I think the EPEL project needs to decide, enumerate and document the exact > channels, derived distributions etc it attempts to be compatible with first. > The answer to the above question would then be those channels etc. Then once the project gets this info, I should be able to help with this information. -- Kyle Gonzales kyle.gonzales at gmail.com GPG Pub Key: 9C3FBD51 From mmcgrath at redhat.com Mon Aug 27 19:20:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 27 Aug 2007 14:20:06 -0500 Subject: Complete RHEL package lists? In-Reply-To: <200708272214.28213.ville.skytta@iki.fi> References: <200708202329.01131.ville.skytta@iki.fi> <46D30FAA.7070300@leemhuis.info> <200708272214.28213.ville.skytta@iki.fi> Message-ID: <46D323E6.7090503@redhat.com> Ville Skytt? wrote: > On Monday 27 August 2007, Kyle Gonzales wrote: > >> On 8/27/07, Thorsten Leemhuis wrote: >> >>> Why can't we simply run a small script on one or two (RHEL5Desktop and >>> RHEL5Server) machines somewhere that just write the informations into >>> some files and uploads those somewhere? >>> >>> That way we might not provide all the data people might be interested >>> it, but a package-list (which would be a good start) and some other >>> stuff afaics should be possible, which is better than nothing. >>> >> Do you need a listing for the layered products as well, or just the >> base/extra/supplementary RHEL channels? >> > > I think the EPEL project needs to decide, enumerate and document the exact > channels, derived distributions etc it attempts to be compatible with first. > The answer to the above question would then be those channels etc. > Personally I think documenting these processes is a lot of work with questional benefit. It seems to me more logical to be reactive to this. When something comes up that is a conflict, remove / fix it in epel. Trying to write and maintain a script that monitors two moving targets is bound to be buggy / hard to verify. -Mike From ville.skytta at iki.fi Mon Aug 27 20:34:52 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 27 Aug 2007 23:34:52 +0300 Subject: Complete RHEL package lists? In-Reply-To: <46D323E6.7090503@redhat.com> References: <200708202329.01131.ville.skytta@iki.fi> <200708272214.28213.ville.skytta@iki.fi> <46D323E6.7090503@redhat.com> Message-ID: <200708272334.53349.ville.skytta@iki.fi> On Monday 27 August 2007, Mike McGrath wrote: > > Personally I think documenting these processes is a lot of work with > questional benefit. It seems to me more logical to be reactive to > this. I'm afraid I'll have to disagree here and would not be comfortable with using packages from or seriously contributing to such a project. Mileages vary, of course, but I'd be surprised if it were just me. One Scenario: work hard to produce a great package of something popular and complex, succeed, get it through the review process, ship it in EPEL. Months pass, users are happy, and build things on top of the EPEL package and its configuration. Then, someone finds out that there's a conflict/unwanted upgrade or something like that problem with the package and something in some channel or derivative distro. I can't come up with a good way to react to this kind of a situation without breaking something, and just throwing things out there to see if something breaks is not what I'd expect from a project like EPEL. The _best_ case is that people report the problem and the reactive fix will "only" result in wasted packager/maintainer/reviewer resources. > When something comes up that is a conflict, remove / fix it in epel. Conflicts are kind of easy as the probability of damage done to existing end user installations is pretty low because the package didn't actually get installed, but unwanted and incompatible upgrades which do get installed and start to cause problems afterwards are not. From mmcgrath at redhat.com Mon Aug 27 21:05:54 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 27 Aug 2007 16:05:54 -0500 Subject: Complete RHEL package lists? In-Reply-To: <200708272334.53349.ville.skytta@iki.fi> References: <200708202329.01131.ville.skytta@iki.fi> <200708272214.28213.ville.skytta@iki.fi> <46D323E6.7090503@redhat.com> <200708272334.53349.ville.skytta@iki.fi> Message-ID: <46D33CB2.1030709@redhat.com> Ville Skytt? wrote: > On Monday 27 August 2007, Mike McGrath wrote: > >> Personally I think documenting these processes is a lot of work with >> questional benefit. It seems to me more logical to be reactive to >> this. >> > > I'm afraid I'll have to disagree here and would not be comfortable with using > packages from or seriously contributing to such a project. Mileages vary, of > course, but I'd be surprised if it were just me. > > One Scenario: work hard to produce a great package of something popular and > complex, succeed, get it through the review process, ship it in EPEL. Months > pass, users are happy, and build things on top of the EPEL package and its > configuration. Then, someone finds out that there's a conflict/unwanted > upgrade or something like that problem with the package and something in some > channel or derivative distro. > > I can't come up with a good way to react to this kind of a situation without > breaking something, and just throwing things out there to see if something > breaks is not what I'd expect from a project like EPEL. The _best_ case is > that people report the problem and the reactive fix will "only" result in > wasted packager/maintainer/reviewer resources. > > Exact same thing happens if RH decides to include it in an update. >> When something comes up that is a conflict, remove / fix it in epel. >> > > Conflicts are kind of easy as the probability of damage done to existing end > user installations is pretty low because the package didn't actually get > installed, but unwanted and incompatible upgrades which do get installed and > start to cause problems afterwards are not. > I'm just saying that trying to put strict guidelines/lists around something that is very murky requires a lot of effort and the outcome is bound to be unreliable. The fact is what RH does or does not decide to ship is up to them and it is a completely unpredictable unordered process which we are trying to bring order to. That said, if someone wants to do the work and thinks they can make it reliable, have at it :) -Mike From kwade at redhat.com Tue Aug 28 03:19:38 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 27 Aug 2007 20:19:38 -0700 Subject: Complete RHEL package lists? In-Reply-To: References: <200708202329.01131.ville.skytta@iki.fi> <7874d9dd0708211620s5429b4c8y2cd65bdddb5f7603@mail.gmail.com> <20070822111350.A16513@xos037.xos.nl> <200708221743.34571.ville.skytta@iki.fi> <7874d9dd0708220832p72a01f35ne7acb7de205ad339@mail.gmail.com> <7874d9dd0708261056y3309afd4na13e59a2262f20bf@mail.gmail.com> <46D30FAA.7070300@leemhuis.info> Message-ID: <1188271178.8400.129.camel@erato.phig.org> On Mon, 2007-08-27 at 14:54 -0400, Kyle Gonzales wrote: > Do you need a listing for the layered products as well, or just the > base/extra/supplementary RHEL channels? We need layered products as well. - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From kwade at redhat.com Tue Aug 28 03:49:55 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 27 Aug 2007 20:49:55 -0700 Subject: Complete RHEL package lists? In-Reply-To: <46D33CB2.1030709@redhat.com> References: <200708202329.01131.ville.skytta@iki.fi> <200708272214.28213.ville.skytta@iki.fi> <46D323E6.7090503@redhat.com> <200708272334.53349.ville.skytta@iki.fi> <46D33CB2.1030709@redhat.com> Message-ID: <1188272995.8400.142.camel@erato.phig.org> On Mon, 2007-08-27 at 16:05 -0500, Mike McGrath wrote: > I'm just saying that trying to put strict guidelines/lists around > something that is very murky requires a lot of effort and the outcome is > bound to be unreliable. The fact is what RH does or does not decide to > ship is up to them and it is a completely unpredictable unordered > process which we are trying to bring order to. That said, if someone > wants to do the work and thinks they can make it reliable, have at it :) I haven't seen any indication from any product managers that they intend to ignore what is happening in EPEL when they decide what goes into the package sets. OTOH, we don't have enough people who are communicating between the groups. How changing of a creature is it really, when we're talking about the past? How many new-to-the-repo packages are added during a RHEL update? How about for a layered product? Isn't this just a few dozen or so lists that don't change once set? Anyone know someone in Product Management who wants to help the communication bridge? - Karsten -- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From lemenkov at gmail.com Tue Aug 28 15:55:21 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 28 Aug 2007 19:55:21 +0400 Subject: Fwd: Build Error (Job 35992): erlang-R11B-0_1_el4 on fedora-4-epel In-Reply-To: <20070828155256.9B064152131@buildsys.fedoraproject.org> References: <20070828155256.9B064152131@buildsys.fedoraproject.org> Message-ID: Hello All! ============================================================= ---------- Forwarded message ---------- From: buildsys at fedoraproject.org Date: 28.08.2007 19:52 Subject: Build Error (Job 35992): erlang-R11B-0_1_el4 on fedora-4-epel To: lemenkov at gmail.com Job failed on arch x86_64 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-4-epel/35992-erlang-R11B-0.1.el4/ ------------------------------------------------- creating ../lib/tools/c_src/x86_64-unknown-linux-gnu/Makefile creating ../lib/asn1/c_src/x86_64-unknown-linux-gnu/Makefile creating x86_64-unknown-linux-gnu/config.h creating include/internal/x86_64-unknown-linux-gnu/ethread_header_config.h creating include/x86_64-unknown-linux-gnu/erl_int_sizes_config.h + chmod -R u+w . + make cd erts/emulator && ERL_TOP=/builddir/build/BUILD/otp_src_R11B-0 make generate depend make[1]: Entering directory `/builddir/build/BUILD/otp_src_R11B-0/erts/emulator' make -f x86_64-unknown-linux-gnu/Makefile generate make[2]: Entering directory `/builddir/build/BUILD/otp_src_R11B-0/erts/emulator' LANG=C /usr/bin/perl utils/beam_makeops -outdir x86_64-unknown-linux-gnu/opt \ -emulator /builddir/build/BUILD/otp_src_R11B-0/lib/compiler/src/genop.tab beam/ops.tab beam/frag_ops.tab hipe/hipe_ops.tab LANG=C /usr/bin/perl utils/make_tables -src x86_64-unknown-linux-gnu -include x86_64-unknown-linux-gnu beam/atom.names beam/bif.tab hipe/hipe_bif0.tab hipe/hipe_bif1.tab hipe/hipe_bif2.tab hipe/hipe_amd64.tab LANG=C /usr/bin/perl utils/make_version -o x86_64-unknown-linux-gnu/erl_version.h R11B 5.5 x86_64-unknown-linux-gnu LANG=C /usr/bin/perl utils/make_driver_tab -o x86_64-unknown-linux-gnu/driver_tab.c /builddir/build/BUILD/otp_src_R11B-0/erts/obj.beam/x86_64-unknown-linux-gnu/efile_drv.o /builddir/build/BUILD/otp_src_R11B-0/erts/obj.beam/x86_64-unknown-linux-gnu/ddll_drv.o /builddir/build/BUILD/otp_src_R11B-0/erts/obj.beam/x86_64-unknown-linux-gnu/inet_drv.o /builddir/build/BUILD/otp_src_R11B-0/erts/obj.beam/x86_64-unknown-linux-gnu/zlib_drv.o /builddir/build/BUILD/otp_src_R11B-0/erts/obj.beam/x86_64-unknown-linux-gnu/ram_file_drv.o /builddir/build/BUILD/otp_src_R11B-0/erts/obj.beam/x86_64-unknown-linux-gnu/ttsl_drv.o LANG=C /usr/bin/perl utils/make_preload -old /builddir/build/BUILD/otp_src_R11B-0/lib/kernel/ebin/otp_ring0.beam /builddir/build/BUILD/otp_src_R11B-0/lib/kernel/ebin/init.beam /builddir/build/BUILD/otp_src_R11B-0/lib/kernel/ebin/prim_inet.beam /builddir/build/BUILD/otp_src_R11B-0/lib/kernel/ebin/prim_file.beam /builddir/build/BUILD/otp_src_R11B-0/lib/kernel/ebin/erl_prim_loader.beam /builddir/build/BUILD/otp_src_R11B-0/lib/kernel/ebin/erlang.beam > x86_64-unknown-linux-gnu/preload.c LANG=C /usr/bin/perl utils/make_alloc_types -src beam/erl_alloc.types -dst x86_64-unknown-linux-gnu/opt/erl_alloc_types.h threads hipe unix m4 -DTARGET=x86_64-unknown-linux-gnu -DOPSYS=linux -DARCH=amd64 hipe/hipe_x86_asm.m4 > x86_64-unknown-linux-gnu/opt/hipe_x86_asm.h /bin/sh: m4: command not found make[2]: *** [x86_64-unknown-linux-gnu/opt/hipe_x86_asm.h] Error 127 make[2]: Leaving directory `/builddir/build/BUILD/otp_src_R11B-0/erts/emulator' make[1]: *** [generate] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/otp_src_R11B-0/erts/emulator' make: *** [depend] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.91132 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.91132 (%build) ============================================================= EL-4 doesn't ship m4 along other build tools? BTW on EL-5 all builds fine. -- With best regards! From fedora at leemhuis.info Tue Aug 28 16:12:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 28 Aug 2007 18:12:53 +0200 Subject: Fwd: Build Error (Job 35992): erlang-R11B-0_1_el4 on fedora-4-epel In-Reply-To: References: <20070828155256.9B064152131@buildsys.fedoraproject.org> Message-ID: <46D44985.7060909@leemhuis.info> On 28.08.2007 17:55, Peter Lemenkov wrote: > > [...] > > EL-4 doesn't ship m4 along other build tools? > BTW on EL-5 all builds fine. m4 is not listed in this list: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions Thus you should list it as BR if you need it -- according to the guidlines also on RHEL5 or F7/rawhide, even if it's tracked in there by default by those packages in the list or another package with you BuildRequire. Why you ask? Well, maybe m4 won't get tracked in by default in Fedora#s future -- just recently for example gawk vanished from the buildroots. The discussion was on fedora-devel or fedora-maintainers just a few days ago. Cu knurd From mdehaan at redhat.com Tue Aug 28 18:32:42 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 28 Aug 2007 14:32:42 -0400 Subject: Testing -> stable? In-Reply-To: <46D26FB2.8030900@leemhuis.info> References: <46D19DA9.40907@redhat.com> <46D26FB2.8030900@leemhuis.info> Message-ID: <46D46A4A.5030609@redhat.com> Thorsten Leemhuis wrote: > On 26.08.2007 17:35, Mike McGrath wrote: > >> There's been a lot of conversations about the testing -> stable process >> on this list, on IRC and just in general chats. Can someone explain >> what the current consensus is? I have branding concerns. >> > > I'd really like to see something that is more updated than stable without being "testing". An additional level seems sufficient. > > * if there is a strong need to move a package it is allowed according > to the policy. But for the other updates I think we manage EPEL similar > to how RHEL does it: non-crucial updates go into a quarterly update and > no major updates if there isn't a reasons for them. Just "latest and > greatest" is IMHO not the reason > How do you determine which bugfixes are "serious enough"? ... it seems like the package maintainers usually would be the best qualified to make this decision if there is a bit of a guideline for it. > - manage EPEL more like Fedora {,Extras} > > * afaics most people in the buildup phase wanted a stable EPEL and I > really think that should continue to be our #1 goal. Are there threads that say this? The list membership isn't huge, and we probably have a lot of users that haven't joined ... I would think there is a sizeable community of users that just want a easy way to add useful and reasonably-working-well-together packages to their platform, so they can get their jobs done. What people want in leaf packages is probably not the same as what they want for core packages. Quarterly doesn't really mean "stable", it just means "quarterly". So having a rolling stable where a package must be in testing for X seems reasonable to me. If we need an additional quarterly level that's ok, but if folks have to adopt everything from testing to just get one package from testing that is essentially considered stable that's a problem. I'd like to at least see an option where updates can be moved at some X which is much less than 120 days -- 2 weeks seems fair to me as most packages should have some adopters out of each repo. > But I see a need > and interest for a "more up2date packages" EPEL repo. That what I call > EPEL-rolling; I'm fine with having it in parallel to the stable repo. > But do we have the man-power to start this yet? > Disregarding resources, what would we really like to do? I'd hate to shoot down an idea for how we are going to do things because there aren't resources. If it's a good enough idea, there might be resources crawling out of the woodwork ... you never know... > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Tue Aug 28 19:07:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 28 Aug 2007 21:07:55 +0200 Subject: Testing -> stable? In-Reply-To: <46D46A4A.5030609@redhat.com> References: <46D19DA9.40907@redhat.com> <46D26FB2.8030900@leemhuis.info> <46D46A4A.5030609@redhat.com> Message-ID: <46D4728B.5060205@leemhuis.info> On 28.08.2007 20:32, Michael DeHaan wrote: > Thorsten Leemhuis wrote: >> On 26.08.2007 17:35, Mike McGrath wrote: >> * if there is a strong need to move a package it is allowed according >> to the policy. But for the other updates I think we manage EPEL similar >> to how RHEL does it: non-crucial updates go into a quarterly update and >> no major updates if there isn't a reasons for them. Just "latest and >> greatest" is IMHO not the reason > How do you determine which bugfixes are "serious enough"? ... it seems > like the package maintainers > usually would be the best qualified to make this decision Of course they are. > if there is a > bit of a guideline for it. http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies Section "Some examples of what package updates that are fine or not" >> - manage EPEL more like Fedora {,Extras} >> * afaics most people in the buildup phase wanted a stable EPEL and I >> really think that should continue to be our #1 goal. > Are there threads that say this? Sorry, EPEL is being discussed for over a year now (first in private), and I can't point out a single thread -- but that my interpretation (it was in a * section, which were explicitly marked as my opinion) of lots of discussions that happend over the last year and lead to the guidelines as they were written. >[...] > Quarterly doesn't really mean "stable", it just means "quarterly". So > having a rolling stable where a package must be > in testing for X seems reasonable to me. Note that the idea was to freeze EPEL for some (two) weeks before pushing it to stable. We didn't do that, but I still think we should go for that in the long-term. >> But I see a need >> and interest for a "more up2date packages" EPEL repo. That what I call >> EPEL-rolling; I'm fine with having it in parallel to the stable repo. >> But do we have the man-power to start this yet? > Disregarding resources, what would we really like to do? I'd hate to > shoot down an idea for how we are going to do things > because there aren't resources. If it's a good enough idea, there might > be resources crawling out of the woodwork ... you never > know... On the other hand you can easily fail if you try to many things at once. And we have lots to improve in EPEL before doing the next big steps. Koji and Bodhi for EPEL. More packages. make sure we have a common look and feel (e.g. not "latest and greatest" in one area and "old and boring" in another one). CU knurd From mastahnke at gmail.com Wed Aug 29 04:18:32 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 28 Aug 2007 23:18:32 -0500 Subject: Testing -> stable? In-Reply-To: <46D4728B.5060205@leemhuis.info> References: <46D19DA9.40907@redhat.com> <46D26FB2.8030900@leemhuis.info> <46D46A4A.5030609@redhat.com> <46D4728B.5060205@leemhuis.info> Message-ID: <7874d9dd0708282118p316f9583x8470e1c6fd3b780a@mail.gmail.com> I'm still in favor of pushing more often during the initial build-up phase. I don't know exactly what that takes from the infrastructure team though. Right now, if a package is missing completely from EPEL, I would like it in stable (assuming it works and whatnot). We probably do need some form of test-bed. Automated tests would be awesome. Sadly, writing test suites for thousands of packages probably isn't going to happen anytime soon. The dependencies are a major concern. My hat is off to the guys thus far who have been rather successful with keeping EPEL working. Is it possible to push new packages into stable? Even if something is in testing, just because it sat there for X amount of time, does it mean it works properly? stahnma From buildsys at fedoraproject.org Wed Aug 29 09:00:41 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 29 Aug 2007 05:00:41 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-08-29 Message-ID: <20070829090041.719F5152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 48 NEW amtterm-0.5-1.el5 : Serial-over-lan (sol) client for Intel AMT bugzilla-3.0.1-0.el5 cgdb-0.6.4-2.el5 NEW dfu-programmer-0.4.3-2.el5 : A Device Firmware Update based USB programmer for Atmel chips digitemp-3.5.0-2.el5 eclipse-cdt-3.1.2-7.el5 eggdrop-1.6.18-10.el5 NEW erlang-R11B-2.3.el5 : General-purpose programming language and runtime environment gmrun-0.9.2-8.el5 NEW iftop-0.17-6.el5 : Command line tool that displays bandwidth usage on an interface NEW jhead-2.7-1.el5 : Tool for displaying EXIF data embedded in JPEG images libopm-0.1-5.20050731cvs.el5 librsync-0.9.7-11.el5 libsmbios-0.13.10-1.el5 mksh-30-2.el5 perl-AnyData-0.10-4.el5 NEW perl-CGI-Simple-0.077-7.el5 : Simple totally OO CGI interface that is CGI.pm compliant NEW perl-CGI-Untaint-1.26-3.el5 : Process CGI input parameters NEW perl-Class-Accessor-Chained-0.01-5.el5 : Make chained accessors perl-Class-Data-Inheritable-0.06-2.el5 NEW perl-Class-Trigger-0.12-1.el5 : Mixin to add / call inheritable triggers NEW perl-Class-Whitehole-0.04-4.el5 : Base class to treat unhandled method calls as errors NEW perl-Exporter-Lite-0.02-2.el5 : Lightweight exporting of variables perl-Net-LibIDN-0.09-4.el5 NEW perl-OLE-Storage_Lite-0.14-9.el5 : Simple Class for OLE document interface NEW perl-Perlbal-XS-HTTPHeaders-0.19-2.el5 : Perlbal extension for processing HTTP headers NEW perl-Spreadsheet-WriteExcel-2.18-1.el5 : Write formatted text and numbers to a cross-platform Excel binary file NEW perl-SQL-Abstract-1.22-2.el5 : Generate SQL from Perl data structures NEW perl-Tie-DBI-1.02-3.el5 : Tie hashes to DBI relational databases NEW perl-UNIVERSAL-exports-0.05-3.el5 : Lightweight, universal exporting of variables NEW perl-UNIVERSAL-moniker-0.08-5.el5 : Real world naming for classes php-pear-Console-Getargs-1.3.4-1.el5 puppet-0.23.2-1.el5 python-genshi-0.4.4-1.el5 python-lxml-1.3.3-2.el5 qfaxreader-0.3.1-8.el5.1 NEW rootsh-1.5.2-5.el5 : Shell wrapper for auditing NEW shapelib-1.2.10-14.20060304cvs : API in "C" for Shapefile handling smolt-0.9.8.4-4.el5 tcpick-0.2.1-13.el5 wine-0.9.44-1.el5 wine-docs-0.9.44-1.el5 NEW xbase-2.0.0-6.el5 : XBase compatible database library and tools NEW xbiso-0.6.1-1.el5 : ISO extraction utility for xdvdfs images NEW xbsql-0.11-9.el5 : A SQL wrapper for xbase NEW xclip-0.08-4.el5 : Command line clipboard grabber NEW yum-cron-0.3-3.el5 : Files needed to run yum updates as a cron job yumex-2.0.1-1.el5 Packages built and released for Fedora EPEL 4: 42 bugzilla-2.22.3-0.el4 NEW createrepo-0.4.4-0.3.el4 : Creates a common metadata repository digitemp-3.5.0-2.el4 eggdrop-1.6.18-10.el4 NEW gmrun-0.9.2-8.el4 : Lightweight "Run program" dialog box with search history and tab completion NEW iftop-0.17-6.el4 : Command line tool that displays bandwidth usage on an interface libopm-0.1-5.20050731cvs.el4 librsync-0.9.7-11.el4 libsmbios-0.13.10-1.el4 logserial-0.4.2-5.el4.1 mksh-30-2.el4 perl-AnyData-0.10-4.el4 NEW perl-CGI-Simple-0.077-7.el4 : Simple totally OO CGI interface that is CGI.pm compliant NEW perl-CGI-Untaint-1.26-3.el4 : Process CGI input parameters NEW perl-Class-Accessor-Chained-0.01-5.el4 : Make chained accessors perl-Class-Data-Inheritable-0.06-2.el4 NEW perl-Class-Trigger-0.12-1.el4 : Mixin to add / call inheritable triggers NEW perl-Class-Whitehole-0.04-4.el4 : Base class to treat unhandled method calls as errors NEW perl-Exporter-Lite-0.02-2.el4 : Lightweight exporting of variables perl-Net-LibIDN-0.09-4.el4 NEW perl-OLE-Storage_Lite-0.14-9.el4 : Simple Class for OLE document interface NEW perl-Spreadsheet-WriteExcel-2.18-1.el4 : Write formatted text and numbers to a cross-platform Excel binary file NEW perl-SQL-Abstract-1.22-2.el4 : Generate SQL from Perl data structures NEW perl-String-CRC32-1.4-1.el4 : Perl interface for cyclic redundancy check generation NEW perl-Tie-DBI-1.02-3.el4.1 : Tie hashes to DBI relational databases NEW perl-UNIVERSAL-exports-0.05-3.el4 : Lightweight, universal exporting of variables NEW perl-UNIVERSAL-moniker-0.08-5.el4 : Real world naming for classes puppet-0.23.2-1.el4 NEW python-elementtree-1.2.6-0.6.el4 : Fast XML parser and writer python-lxml-1.3.3-2.el4 NEW python-sqlite-1.1.7-0.1.2.2.el4 : Python bindings for sqlite. NEW python-urlgrabber-2.9.8-0.3.el4 : A high-level cross-protocol url-grabber qfaxreader-0.3.1-8.el4.1 NEW rootsh-1.5.2-5.el4 : Shell wrapper for auditing NEW shapelib-1.2.10-13 : API in "C" for Shapefile handling tcpick-0.2.1-13.el4 wine-0.9.44-1.el4 NEW xbase-2.0.0-4.el4 : XBase compatible database library and tools NEW xbiso-0.6.1-1.el4 : ISO extraction utility for xdvdfs images NEW xbsql-0.11-9.el4 : A SQL wrapper for xbase NEW xclip-0.08-4.el4.1 : Command line clipboard grabber NEW yum-2.4.3-0.5.el4 : RPM installer/updater Changes in Fedora EPEL 5: amtterm-0.5-1.el5 ----------------- * Tue Aug 21 2007 Gerd Hoffmann - 0.5-1 - update to version 0.5 * clarify license (GPLv2+). * keyboard tweaks. * cursor blink option. - fix specfile bugs pointed out by review. * Mon Aug 20 2007 Gerd Hoffmann - 0.4-1 - update to version 0.4 * minur gui tweaks. * started tool to control machines. * Thu Aug 16 2007 Gerd Hoffmann - 0.3-1 - update to version 0.3 * gui improvements. * Wed Aug 15 2007 Gerd Hoffmann - 0.2-1 - update to version 0.2 * added gui (gtk) version. * some protocol fixups. * Thu Aug 09 2007 Gerd Hoffmann - 0.1-1 - initial release bugzilla-3.0.1-0.el5 -------------------- * Mon Aug 27 2007 John Berninger - 3.0.1-0 - update to 3.0.1 - bz 256021 cgdb-0.6.4-2.el5 ---------------- * Sun Aug 26 2007 - 0.6.4-2 - Fixed license tag. * Wed May 16 2007 - 0.6.4-1 - 0.6.4 - Fix broken info installation. - Enable SMP build. - Preserve the source time-stamp. - Replace install with %{__install}. dfu-programmer-0.4.3-2.el5 -------------------------- * Wed Aug 15 2007 Weston Schmidt - 0.4.3-2 - updated the license tag * Sun Aug 12 2007 Weston Schmidt - 0.4.3-1 - see NEWS for details about this release digitemp-3.5.0-2.el5 -------------------- * Tue Aug 28 2007 Robert Scheck 3.5.0-2 - Updated the license tag according to the guidelines eclipse-cdt-3.1.2-7.el5 ----------------------- * Thu Aug 16 2007 Jeff Johnston 3.1.2-7 - Resolves #251412 - Rebase autotools to 0.1.1 - Add minimum java runtime requirement - Add direct Autotools wizards - Add autogen.sh options eggdrop-1.6.18-10.el5 --------------------- * Tue Aug 28 2007 Robert Scheck 1.6.18-10 - Updated the license tag according to the guidelines erlang-R11B-2.3.el5 ------------------- * Sun Dec 31 2006 Gerard Milmeister - R11B-2.3 - remove buildroot from installed files gmrun-0.9.2-8.el5 ----------------- * Sun Aug 26 2007 Gilboa Davara - 0.9.2-8 - Fixed license tag. - Fixed F8 BR - popt-devel. * Sat Feb 10 2007 Gilboa Davara - 0.9.2-7 - Preserve the source time-stamp. iftop-0.17-6.el5 ---------------- * Tue Aug 28 2007 Robert Scheck 0.17-6 - Buildrequire %{_includedir}/pcap.h instead of conditionals - Patch to display top scale in bytes when measuring in bytes * Sat Aug 25 2007 Aurelien Bompard 0.17-5 - fix license tag - rebuild for BuildID jhead-2.7-1.el5 --------------- * Sun Mar 18 2007 Adrian Reber - 2.7-1 - updated to 2.7 libopm-0.1-5.20050731cvs.el5 ---------------------------- * Tue Aug 28 2007 Robert Scheck 0.1-5.20050731cvs - Updated the license tag according to the guidelines - Generate API documentation, added buildrequirement to doxygen librsync-0.9.7-11.el5 --------------------- * Tue Aug 28 2007 Robert Scheck 0.9.7-11 - Updated the license tag according to the guidelines - Buildrequire %{_includedir}/popt.h for separate popt (#249352) libsmbios-0.13.10-1.el5 ----------------------- * Tue Aug 28 2007 Michael E Brown - 0.13.10-1 - Fix one instance where return code to fread was incorrectly checked. * Wed Aug 22 2007 Michael E Brown - 0.13.9 - Fix a couple of failure-to-check-return on fread. most were unit-test code only, but two or three were in regular code. - Add hinting to the memory class, so that it can intelligently close /dev/mem file handle when it is not needed (which is most of the time). it only leaves it open when it is scanning, so speed is not impacted. * Mon Aug 06 2007 Michael E Brown - 0.13.8 - new upstream mksh-30-2.el5 ------------- * Tue Aug 28 2007 Robert Scheck 30-2 - Updated the license tag according to the guidelines perl-AnyData-0.10-4.el5 ----------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.10-4 - license fix perl-CGI-Simple-0.077-7.el5 --------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.077-7 - license fix perl-CGI-Untaint-1.26-3.el5 --------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 1.26-3 - license fix perl-Class-Accessor-Chained-0.01-5.el5 -------------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.01-5 - license fix perl-Class-Data-Inheritable-0.06-2.el5 -------------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.06-2 - license fix perl-Class-Trigger-0.12-1.el5 ----------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.12-1 - bump to 0.12 - license fix perl-Class-Whitehole-0.04-4.el5 ------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.04-4 - license fix perl-Exporter-Lite-0.02-2.el5 ----------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.02-2 - license tag fix perl-Net-LibIDN-0.09-4.el5 -------------------------- * Wed Aug 29 2007 Robert Scheck 0.09-4 - Updated the license tag according to the guidelines perl-OLE-Storage_Lite-0.14-9.el5 -------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.14-9 - license tag fix perl-Perlbal-XS-HTTPHeaders-0.19-2.el5 -------------------------------------- * Fri Aug 17 2007 Ruben Kerkhof 0.19-2 - Correct license tag perl-Spreadsheet-WriteExcel-2.18-1.el5 -------------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 2.18-1 - 2.18 - license tag fix perl-SQL-Abstract-1.22-2.el5 ---------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 1.22-2 - license tag fix perl-Tie-DBI-1.02-3.el5 ----------------------- * Sun Aug 26 2007 Tom "spot" Callaway 1.02-3 - license tag fix perl-UNIVERSAL-exports-0.05-3.el5 --------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.05-3 - license tag fix perl-UNIVERSAL-moniker-0.08-5.el5 --------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.08-5 - license tag fix php-pear-Console-Getargs-1.3.4-1.el5 ------------------------------------ * Tue Aug 21 2007 Remi Collet 1.3.4-1 - update to 1.3.4 - fix license and Remove file puppet-0.23.2-1.el5 ------------------- * Wed Aug 22 2007 David Lutterkort - 0.23.2-1 - New version * Thu Jul 26 2007 David Lutterkort - 0.23.1-1 - Remove old config files python-genshi-0.4.4-1.el5 ------------------------- * Mon Aug 27 2007 Jeffrey C. Ollie - 0.4.4-1 - Update to 0.4.4 python-lxml-1.3.3-2.el5 ----------------------- * Wed Aug 22 2007 Jeffrey C. Ollie - 1.3.3-2 - Bump release and rebuild. qfaxreader-0.3.1-8.el5.1 ------------------------ * Wed Aug 22 2007 manuel wolfshant - 0.3.1-8.1 - Rebuilt * Tue Aug 14 2007 manuel wolfshant - 0.3.1-8 - License clarification rootsh-1.5.2-5.el5 ------------------ * Mon Aug 27 2007 Tom "spot" Callaway 1.5.2-5 - license tag fix - rebuild for BuildID shapelib-1.2.10-14.20060304cvs ------------------------------ * Tue Aug 21 2007 Shawn McCann - 1.2.10-14.20060304cvs - Rebuild for EPEL 5 smolt-0.9.8.4-4.el5 ------------------- * Mon Aug 13 2007 Mike McGrath 0.9.8.4-4 - Rebuild to clean up 'config.py' compilations * Mon Aug 13 2007 Mike McGrath 0.9.8.4-1 - Upstream released new version (major changes) - New config file - New Makefile - Added deps tcpick-0.2.1-13.el5 ------------------- * Tue Aug 28 2007 Robert Scheck 0.2.1-13 - Updated the license tag according to the guidelines - Buildrequire %{_includedir}/pcap.h instead of conditionals wine-0.9.44-1.el5 ----------------- * Sat Aug 25 2007 Andreas Bierfert - 0.9.44-1 - version upgrade wine-docs-0.9.44-1.el5 ---------------------- * Sat Aug 25 2007 Andreas Bierfert - 0.9.44-1 - version upgrade xbase-2.0.0-6.el5 ----------------- * Mon Sep 11 2006 Tom "spot" Callaway 2.0.0-6 - rebuild xbiso-0.6.1-1.el5 ----------------- * Mon Aug 27 2007 Tom "spot" Callaway - 0.6.1-2 - license tag fix - rebuild for BuildID xbsql-0.11-9.el5 ---------------- * Mon Aug 27 2007 Tom "spot" Callaway 0.11-9 - license fix - rebuild for BuildID xclip-0.08-4.el5 ---------------- * Mon Aug 27 2007 Tom "spot" Callaway 0.08-4 - license tag fix - rebuild for BuildID yum-cron-0.3-3.el5 ------------------ * Mon Aug 27 2007 Frank Wittig - 0.3-3 - Actual update action is now configurable. It does check-only now if configured. Default behaviour is to do updates. * Tue Aug 21 2007 Alec Habig - 0.3-2 - Changed over to dist tags, to play more nciely with the Fedora build system - License changed "GPL" to "GPLv2" since rpmlint now cares * Mon Aug 20 2007 Alec Habig - 0.3-1 - Bumped version for release to fedora-extras * Mon Jul 30 2007 Alec Habig - 0.2-5 - spec file updates in response to review. yumex-2.0.1-1.el5 ----------------- * Wed Aug 22 2007 Tim Lauridsen - 2.0.1-1 - Release 2.0.1 Changes in Fedora EPEL 4: bugzilla-2.22.3-0.el4 --------------------- * Mon Aug 27 2007 John Berninger - 2.22.3-0 - upate to 2.22.3 - bz 256021 createrepo-0.4.4-0.3.el4 ------------------------ * Tue Aug 28 2007 Jeff Sheltren - 0.4.4-0.3 - Official EPEL rebuild - Update License tag digitemp-3.5.0-2.el4 -------------------- * Tue Aug 28 2007 Robert Scheck 3.5.0-2 - Updated the license tag according to the guidelines eggdrop-1.6.18-10.el4 --------------------- * Tue Aug 28 2007 Robert Scheck 1.6.18-10 - Updated the license tag according to the guidelines gmrun-0.9.2-8.el4 ----------------- * Sun Aug 26 2007 Gilboa Davara - 0.9.2-8 - Fixed license tag. - Fixed F8 BR - popt-devel. iftop-0.17-6.el4 ---------------- * Tue Aug 28 2007 Robert Scheck 0.17-6 - Buildrequire %{_includedir}/pcap.h instead of conditionals - Patch to display top scale in bytes when measuring in bytes * Sat Aug 25 2007 Aurelien Bompard 0.17-5 - fix license tag - rebuild for BuildID libopm-0.1-5.20050731cvs.el4 ---------------------------- * Tue Aug 28 2007 Robert Scheck 0.1-5.20050731cvs - Updated the license tag according to the guidelines - Generate API documentation, added buildrequirement to doxygen librsync-0.9.7-11.el4 --------------------- * Tue Aug 28 2007 Robert Scheck 0.9.7-11 - Updated the license tag according to the guidelines - Buildrequire %{_includedir}/popt.h for separate popt (#249352) libsmbios-0.13.10-1.el4 ----------------------- * Tue Aug 28 2007 Michael E Brown - 0.13.10-1 - Fix one instance where return code to fread was incorrectly checked. * Wed Aug 22 2007 Michael E Brown - 0.13.9 - Fix a couple of failure-to-check-return on fread. most were unit-test code only, but two or three were in regular code. - Add hinting to the memory class, so that it can intelligently close /dev/mem file handle when it is not needed (which is most of the time). it only leaves it open when it is scanning, so speed is not impacted. * Mon Aug 06 2007 Michael E Brown - 0.13.8 - new upstream logserial-0.4.2-5.el4.1 ----------------------- * Wed Aug 22 2007 Manuel Wolfshant 0.4.2-5.1 - rebuilt * Mon Aug 06 2007 Manuel Wolfshant 0.4.2-5 - License clarification mksh-30-2.el4 ------------- * Tue Aug 28 2007 Robert Scheck 30-2 - Updated the license tag according to the guidelines perl-AnyData-0.10-4.el4 ----------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.10-4 - license fix * Thu Sep 14 2006 Tom "spot" Callaway 0.10-3 - bump for FC-6 perl-CGI-Simple-0.077-7.el4 --------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.077-7 - license fix perl-CGI-Untaint-1.26-3.el4 --------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 1.26-3 - license fix perl-Class-Accessor-Chained-0.01-5.el4 -------------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.01-5 - license fix perl-Class-Data-Inheritable-0.06-2.el4 -------------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.06-2 - license fix perl-Class-Trigger-0.12-1.el4 ----------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.12-1 - bump to 0.12 - license fix perl-Class-Whitehole-0.04-4.el4 ------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 0.04-4 - license fix perl-Exporter-Lite-0.02-2.el4 ----------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.02-2 - license tag fix perl-Net-LibIDN-0.09-4.el4 -------------------------- * Wed Aug 29 2007 Robert Scheck 0.09-4 - Updated the license tag according to the guidelines perl-OLE-Storage_Lite-0.14-9.el4 -------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.14-9 - license tag fix perl-Spreadsheet-WriteExcel-2.18-1.el4 -------------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 2.18-1 - 2.18 - license tag fix perl-SQL-Abstract-1.22-2.el4 ---------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 1.22-2 - license tag fix perl-String-CRC32-1.4-1.el4 --------------------------- * Thu Apr 20 2006 Paul Howarth 1.4-1 - Update to 1.4 perl-Tie-DBI-1.02-3.el4.1 ------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 1.02-3 - license tag fix perl-UNIVERSAL-exports-0.05-3.el4 --------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.05-3 - license tag fix perl-UNIVERSAL-moniker-0.08-5.el4 --------------------------------- * Sun Aug 26 2007 Tom "spot" Callaway 0.08-5 - license tag fix puppet-0.23.2-1.el4 ------------------- * Wed Aug 22 2007 David Lutterkort - 0.23.2-1 - New version * Thu Jul 26 2007 David Lutterkort - 0.23.1-1 - Remove old config files python-elementtree-1.2.6-0.6.el4 -------------------------------- * Tue Aug 28 2007 Jeff Sheltren 1.2.6-0.6 - Official EPEL rebuild python-lxml-1.3.3-2.el4 ----------------------- * Wed Aug 22 2007 Jeffrey C. Ollie - 1.3.3-2 - Bump release and rebuild. python-sqlite-1.1.7-0.1.2.2.el4 ------------------------------- * Tue Aug 28 2007 Jeff Sheltren - 1.1.7-0.1.2.2 - Official EPEL rebuild python-urlgrabber-2.9.8-0.3.el4 ------------------------------- * Tue Aug 28 2007 Jeff Sheltren - 2.9.8-0.3 - Official EPEL rebuild - Update License tag qfaxreader-0.3.1-8.el4.1 ------------------------ * Wed Aug 22 2007 manuel wolfshant - 0.3.1-8.1 - Rebuilt * Tue Aug 14 2007 manuel wolfshant - 0.3.1-8 - License clarification rootsh-1.5.2-5.el4 ------------------ * Mon Aug 27 2007 Tom "spot" Callaway 1.5.2-5 - license tag fix - rebuild for BuildID shapelib-1.2.10-13 ------------------ * Tue Aug 21 2007 Shawn McCann 0:1.2.10-13 - Rebuild for EPEL 4 tcpick-0.2.1-13.el4 ------------------- * Tue Aug 28 2007 Robert Scheck 0.2.1-13 - Updated the license tag according to the guidelines - Buildrequire %{_includedir}/pcap.h instead of conditionals wine-0.9.44-1.el4 ----------------- * Sat Aug 25 2007 Andreas Bierfert - 0.9.44-1 - version upgrade xbase-2.0.0-4.el4 ----------------- * Tue Feb 28 2006 Tom "spot" Callaway 2.0.0-4 - bump for FC-5 xbiso-0.6.1-1.el4 ----------------- * Mon Aug 27 2007 Tom "spot" Callaway - 0.6.1-2 - license tag fix - rebuild for BuildID xbsql-0.11-9.el4 ---------------- * Mon Aug 27 2007 Tom "spot" Callaway 0.11-9 - license fix - rebuild for BuildID xclip-0.08-4.el4.1 ------------------ * Mon Aug 27 2007 Tom "spot" Callaway 0.08-4 - license tag fix - rebuild for BuildID yum-2.4.3-0.5.el4 ----------------- * Tue Aug 28 2007 Jeff Sheltren 2.4.3-0.5 - Official EPEL rebuild - Update License tag * Wed Aug 15 2007 Jeff Sheltren 2.4.3-0.4 - Remove requires: yumconf - Don't package yum.conf file For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Aug 29 19:28:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 29 Aug 2007 15:28:50 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-08-29 Message-ID: <20070829192850.4E6A7152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 4 mimedefang-2.63-1.el5 NEW pexpect-2.1-5.el5 : Pure Python Expect-like module php-idn-1.2-3.el5 php-magickwand-0.1.8-4.el5 Packages built and released for Fedora EPEL 4: 2 NEW pexpect-2.1-5.el4 : Pure Python Expect-like module NEW php-idn-1.2-3.el4 : PHP API for GNU LibIDN Changes in Fedora EPEL 5: mimedefang-2.63-1.el5 --------------------- * Wed Aug 29 2007 Robert Scheck 2.63-1 - Upgrade to 2.63 - Updated the license tag according to the guidelines pexpect-2.1-5.el5 ----------------- * Wed Aug 29 2007 Robert Scheck 2.1-5 - Rebuilt (and some minor spec file tweaks) php-idn-1.2-3.el5 ----------------- * Wed Aug 29 2007 Robert Scheck 1.2-3 - Updated the license tag according to the guidelines php-magickwand-0.1.8-4.el5 -------------------------- * Wed Aug 29 2007 Robert Scheck 0.1.8-4 - Updated the license tag according to the guidelines Changes in Fedora EPEL 4: pexpect-2.1-5.el4 ----------------- * Wed Aug 29 2007 Robert Scheck 2.1-5 - Rebuilt (and some minor spec file tweaks) php-idn-1.2-3.el4 ----------------- * Wed Aug 29 2007 Robert Scheck 1.2-3 - Updated the license tag according to the guidelines For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tcallawa at redhat.com Wed Aug 29 20:29:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 29 Aug 2007 16:29:40 -0400 Subject: My packages for EPEL Message-ID: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> As one of the top 5 Fedora packagers (top 5? I used to be top 2, must be slipping), I've finally finished rebuilding as many of my packages for EL-4 and EL-5 as possible. Here's what I couldn't build: Quantlib (EL-4, boost too old) SimGear (missing deps for EL-4, EL-5) blacs (EL-4, deps are not new enough) gambas (EL-4, EL-5, needs sqlite2-devel) lincity-ng (EL-4, EL-5, needs SDL_mixer, SDL_gfx) ntfsprogs (fails on EL-4, gnutls is too old) perl-Apache-Session-Wrapper (EL-4, EL-5, needs Params::Validate) perl-CGI-Untaint-date (EL-4, EL-5, needs Date::Simple) perl-CGI-Untaint-email (EL-4, EL-5, needs Email::Valid) perl-Class-DBI (EL-4, EL-5, needs LOTS of missing perl bits) perl-Class-DBI-AbstractSearch perl-Class-DBI-AsForm perl-Class-DBI-FromCGI perl-Class-DBI-Loader perl-Class-DBI-Loader-Relationship perl-Class-DBI-Pager perl-Class-DBI-Pg perl-Class-DBI-Plugin perl-Class-DBI-Plugin-RetrieveAll perl-Class-DBI-Plugin-Type perl-Class-DBI-SQLite perl-Class-DBI-mysql ^^^ (not built for EL-4, EL-5, needs Class::DBI) perl-DBD-AnyData (EL-4, EL-5, needs SQL::Statement) perl-DBD-SQLite2 (EL-4, EL-5, needs sqlite2) perl-DBIx-ContextualFetch (EL-4, EL-5, needs Test::Pod) perl-Data-Page (EL-4, EL-5, needs Test::Pod, Test::Exception) perl-Email-Abstract (EL-4, EL-5, needs Test::Pod) perl-Email-Date (EL-4, EL-5, needs Email::Abstract, Time::Piece) perl-Email-MIME-Attachment-Stripper (EL-4, EL-5, Email::MIME, Email::MIME::ContentType, Email::MIME::Modifier) perl-Email-MIME-Creator (EL-4, EL-5, Test::Pod, Email::MIME, Email::Date, Email::MIME::Modifier, Email::Simple, Email::Simple::Creator) perl-Email-Reply (EL-4, EL-5, Test::Pod, Email::Abstract, Email::Address, Email::MIME, Email::MIME::Creator, Email::MIME::Modifier, Email::Simple, Email::Simple::Creator, Email::Date) perl-Email-Send (EL-4, EL-5, Email::Address, Email::Simple, Return::Value, Email::Abstract, Test::Pod) perl-Email-Simple-Creator (EL-4, EL-5, Email::Date, Email::Simple, Test::Pod) perl-Email-Valid (Test::Pod::Coverage on EL-4, Test::Pod on EL-5) perl-ExtUtils-XSBuilder (EL-4, EL-5, Tie::IxHash) perl-HTML-Tree (EL-4, EL-5, Test::Pod) perl-HTTP-Body (EL-4, EL-5, Test::Pod) perl-IO-CaptureOutput (EL-4, EL-5, Test::Pod::Coverage) perl-Mail-Box (EL-4, EL-5, Email::Abstract, Mail::Transport::Dbx, HTML::Tree, HTML::Format, File::Remove, MIME::Types) perl-Mail-Box-Parser-C (EL-4, EL-5, Mail::Box) perl-Mail-Transport-Dbx (EL-4, EL-5, Test::Pod) perl-Maypole (EL-4, EL-5, LOTS OF STUFF) perl-MIME-Types (EL-4, EL-5, Test::Pod) perl-Return-Value (EL-4, EL-5, Test::Pod::Coverage, Test::Perl::Critic) perl-SQL-Abstract-Limit (EL-4, EL-5, Class::DBI, DBD::AnyData) perl-Template-GD (EL-4, EL-5, GD::Graph3d) perl-Template-Plugin-Class (EL-4, EL-5, Template::Plugin, Module::Build) perl-Template-Toolkit (EL-4, EL-5, GD::Graph3d, Image::Info, Image::Size) perl-Test-MockModule (EL-4, EL-5, Test::Pod) perl-XML-RSS (EL-4, EL-5, Test::Pod, Test::Manifest, Test::Differences) pydot (EL-4, EL-5, needs pyparsing) rekall (EL-4, EL-5, needs scons) rocksndiamonds (EL-4, EL-5, needs SDL_mixer, at a minimum) winpdb (EL-4, EL-5, no wxPython) wlassistant (EL-4, EL-5, needs scons) xpdf (EL-5 needs t1lib-devel) So, in case you were curious, thats why those packages aren't in EPEL. :) ~spot From pertusus at free.fr Wed Aug 29 20:50:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 29 Aug 2007 22:50:37 +0200 Subject: My packages for EPEL In-Reply-To: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> References: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070829205037.GH4024@free.fr> On Wed, Aug 29, 2007 at 04:29:40PM -0400, Tom spot Callaway wrote: > As one of the top 5 Fedora packagers (top 5? I used to be top 2, must be > slipping), I've finally finished rebuilding as many of my packages for > EL-4 and EL-5 as possible. Here's what I couldn't build: > xpdf (EL-5 needs t1lib-devel) This should certainly be corrected, texlive will depend on t1lib, and grace also depends on t1lib... -- Pat From jamatos at fc.up.pt Wed Aug 29 21:09:00 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Wed, 29 Aug 2007 22:09:00 +0100 Subject: My packages for EPEL In-Reply-To: <20070829205037.GH4024@free.fr> References: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> <20070829205037.GH4024@free.fr> Message-ID: <200708292209.02875.jamatos@fc.up.pt> On Wednesday 29 August 2007 21:50:37 Patrice Dumas wrote: > This should certainly be corrected, texlive will depend on t1lib, and > grace also depends on t1lib... Spot already asked me to rebuild those to EPEL, I will take of that soon (this week). > -- > Pat -- Jos? Ab?lio From paul at city-fan.org Fri Aug 31 07:52:37 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 31 Aug 2007 08:52:37 +0100 Subject: My packages for EPEL In-Reply-To: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> References: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <46D7C8C5.6040509@city-fan.org> Tom "spot" Callaway wrote: > As one of the top 5 Fedora packagers (top 5? I used to be top 2, must be > slipping), I've finally finished rebuilding as many of my packages for > EL-4 and EL-5 as possible. Here's what I couldn't build: > > Quantlib (EL-4, boost too old) > SimGear (missing deps for EL-4, EL-5) > blacs (EL-4, deps are not new enough) > gambas (EL-4, EL-5, needs sqlite2-devel) > lincity-ng (EL-4, EL-5, needs SDL_mixer, SDL_gfx) > ntfsprogs (fails on EL-4, gnutls is too old) > perl-Apache-Session-Wrapper (EL-4, EL-5, needs Params::Validate) > perl-CGI-Untaint-date (EL-4, EL-5, needs Date::Simple) Date::Simple is now built for EL-4 and EL-5. Paul. From buildsys at fedoraproject.org Fri Aug 31 21:33:00 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 31 Aug 2007 17:33:00 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-08-31 Message-ID: <20070831213300.E4AAA152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 15 amtterm-1.0-1.el5 bitlbee-1.0.4-1.el5 cobbler-0.6.1-2.el5 NEW dstat-0.6.6-1.el5 : Versatile resource statistics tool geomview-1.9.4-2.el5 gnucash-2.2.1-2.el5 koan-0.6.1-2.el5 maxima-5.13.0-4.el5 NEW perl-Date-Simple-3.02-6.el5 : Simple date object for perl NEW php-extras-5.1.6-4.el5 : Additional PHP modules from the standard PHP distribution NEW php-pecl-memcache-2.1.2-1.el5 : Extension to work with the Memcached caching daemon (!) puppet-0.23.2-1.el5 : INVALID rebuild, not published! NEW python-boto-0.9b-1.el5 : A simple lightweight interface to Amazon Web Services sbcl-1.0.9-1.el5 tidy-0.99.0-11.20051025.el5 Packages built and released for Fedora EPEL 4: 11 bitlbee-1.0.4-1.el4 cobbler-0.6.1-2.el4 geomview-1.9.4-2.el4 koan-0.6.1-2.el4 maxima-5.13.0-4.el4 NEW pdns-2.9.21-1.el4 : A modern, advanced and high performance authoritative-only nameserver NEW perl-Date-Simple-3.02-6.el4 : Simple date object for perl (!) puppet-0.23.2-1.el4 : INVALID rebuild, not published! NEW python-boto-0.9b-1.el4 : A simple lightweight interface to Amazon Web Services sbcl-1.0.9-1.el4 NEW tidy-0.99.0-2.20041214 : Utility to clean up and pretty print HTML/XHTML/XML Changes in Fedora EPEL 5: amtterm-1.0-1.el5 ----------------- * Fri Aug 31 2007 Gerd Hoffmann - 1.0-1 - update to version 1.0 * more amttool improvements (network config). - don't strip binaries (bug #269241). * Fri Aug 24 2007 Gerd Hoffmann - 0.99-1 - update to version 0.99 * add manual pages. * add desktop file. * improve amttool alot. * misc bug fixes. - add amttool to the package description. bitlbee-1.0.4-1.el5 ------------------- * Wed Aug 29 2007 Robert Scheck 1.0.4-1 - Upgrade to 1.0.4 - Updated the license tag according to the guidelines cobbler-0.6.1-2.el5 ------------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) dstat-0.6.6-1.el5 ----------------- * Tue May 01 2007 Scott Baker - 0.6.6-1 - Bumped to latest release geomview-1.9.4-2.el5 -------------------- * Mon Aug 27 2007 Rex Dieter 1.9.4-2 - BR: gawk * Mon Aug 27 2007 Rex Dieter 1.9.4-1 - geomview-1.9.4 * Sat Aug 11 2007 Rex Dieter 1.9.3-3 - License: LGPLv2+ * Mon Jul 16 2007 Rex Dieter 1.9.3-2 - geomview.desktop: Categories=-Education (#241441) gnucash-2.2.1-2.el5 ------------------- * Wed Aug 29 2007 Bill Nottingham - 2.2.1-2 - fix build * Tue Aug 21 2007 Bill Nottingham - 2.2.1-1 - update to 2.2.1 * Fri Aug 03 2007 Bill Nottingham - tweak license tag * Mon Jul 23 2007 Bill Nottingham - 2.2.0-2 - fix icon (#248492) koan-0.6.1-2.el5 ---------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) maxima-5.13.0-4.el5 ------------------- * Thu Aug 30 2007 Rex Dieter 5.13.0-4 - (re)--enable-gcl, f8+ (#256281) - fix inadvertant Obsoletes: maxima-runtime-gcl (f7) * Mon Aug 27 2007 Rex Dieter 5.13.0-3 - until it is unborked, disable gcl support, f8+ (#256281) - --with-default-lisp=sbcl (was gcl) * Sun Aug 26 2007 Rex Dieter 5.13.0-2 - rebuild against sbcl-1.0.9 * Sat Aug 25 2007 Rex Dieter 5.13.0-1 - maxima-5.13.0 * Sun Aug 19 2007 Rex Dieter 5.12.99-0.5.rc2 - maxima-5.12.99rc2 * Thu Aug 09 2007 Rex Dieter 5.12.99-0.4.rc1 - maxima-5.12.99rc1 - enable langpacks: es, pt, pt_BR * Sat Jul 28 2007 Rex Dieter 5.12.0-6 - respin for sbcl-1.0.8 * Fri Jul 20 2007 Rex Dieter 5.12.0-5 - disable clisp/ppc, still awol (#166347) - respin for sbcl-1.0.7 * Thu Jul 12 2007 Rex Dieter 5.12.0-4 - enable clisp/ppc (#166347) - revert koji hack. perl-Date-Simple-3.02-6.el5 --------------------------- * Mon Aug 13 2007 Paul Howarth 3.02-6 - Clarify license as GPL v1 or later, or Artistic (same as perl) - Add buildreq perl(Test::More) php-extras-5.1.6-4.el5 ---------------------- * Wed Jun 20 2007 Dmitry Butskoy - 5.1.6-4 - add patch for mssql (#244736), a backport of some php-5.2 changes php-pecl-memcache-2.1.2-1.el5 ----------------------------- * Mon Aug 20 2007 Remi Collet 2.1.2-1 - initial RPM puppet-0.23.2-1.el5 ------------------- * Wed Aug 22 2007 David Lutterkort - 0.23.2-1 - New version python-boto-0.9b-1.el5 ---------------------- * Thu Aug 30 2007 Robert Scheck 0.9b-1 - Upgrade to 0.9b - Initial spec file for Fedora and Red Hat Enterprise Linux sbcl-1.0.9-1.el5 ---------------- * Sun Aug 26 2007 Rex Dieter 1.0.9-1 - sbcl-1.0.9 * Sat Aug 25 2007 Rex Dieter 1.0.8-3 - respin (ppc32) * Fri Aug 10 2007 Rex Dieter 1.0.8-2 - ExclusiveArch: i386 (#251689) - License: BSD * Sat Jul 28 2007 Rex Dieter 1.0.8-1 - sbcl-1.0.8 * Wed Jun 27 2007 Rex Dieter 1.0.7-1 - sbcl-1.0.7 * Wed Jun 06 2007 Rex Dieter 1.0.6-2 - respin tidy-0.99.0-11.20051025.el5 --------------------------- * Tue Aug 29 2006 Rex Dieter 0.99.0-11.20051025 - fc6 respin Changes in Fedora EPEL 4: bitlbee-1.0.4-1.el4 ------------------- * Wed Aug 29 2007 Robert Scheck 1.0.4-1 - Upgrade to 1.0.4 - Updated the license tag according to the guidelines cobbler-0.6.1-2.el4 ------------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) geomview-1.9.4-2.el4 -------------------- * Mon Aug 27 2007 Rex Dieter 1.9.4-2 - BR: gawk * Mon Aug 27 2007 Rex Dieter 1.9.4-1 - geomview-1.9.4 * Sat Aug 11 2007 Rex Dieter 1.9.3-3 - License: LGPLv2+ * Mon Jul 16 2007 Rex Dieter 1.9.3-2 - geomview.desktop: Categories=-Education (#241441) koan-0.6.1-2.el4 ---------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) maxima-5.13.0-4.el4 ------------------- * Thu Aug 30 2007 Rex Dieter 5.13.0-4 - (re)--enable-gcl, f8+ (#256281) - fix inadvertant Obsoletes: maxima-runtime-gcl (f7) * Mon Aug 27 2007 Rex Dieter 5.13.0-3 - until it is unborked, disable gcl support, f8+ (#256281) - --with-default-lisp=sbcl (was gcl) * Sun Aug 26 2007 Rex Dieter 5.13.0-2 - rebuild against sbcl-1.0.9 * Sat Aug 25 2007 Rex Dieter 5.13.0-1 - maxima-5.13.0 * Sun Aug 19 2007 Rex Dieter 5.12.99-0.5.rc2 - maxima-5.12.99rc2 * Thu Aug 09 2007 Rex Dieter 5.12.99-0.4.rc1 - maxima-5.12.99rc1 - enable langpacks: es, pt, pt_BR pdns-2.9.21-1.el4 ----------------- * Tue Apr 24 2007 Ruben Kerkhof 2.9.21-1 - Upstream released 2.9.21 - Enabled new SQLite backend perl-Date-Simple-3.02-6.el4 --------------------------- * Mon Aug 13 2007 Paul Howarth 3.02-6 - Clarify license as GPL v1 or later, or Artistic (same as perl) - Add buildreq perl(Test::More) puppet-0.23.2-1.el4 ------------------- * Wed Aug 22 2007 David Lutterkort - 0.23.2-1 - New version python-boto-0.9b-1.el4 ---------------------- * Thu Aug 30 2007 Robert Scheck 0.9b-1 - Upgrade to 0.9b - Initial spec file for Fedora and Red Hat Enterprise Linux sbcl-1.0.9-1.el4 ---------------- * Sun Aug 26 2007 Rex Dieter 1.0.9-1 - sbcl-1.0.9 * Sat Aug 25 2007 Rex Dieter 1.0.8-3 - respin (ppc32) * Fri Aug 10 2007 Rex Dieter 1.0.8-2 - ExclusiveArch: i386 (#251689) - License: BSD tidy-0.99.0-2.20041214 ---------------------- * Thu Dec 16 2004 Ville Skytt? - 0:0.99.0-2.20041214 - Update to 041214 and docs to 041206. - Build with dependency tracking disabled. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/