epel-devel September 2007

epel-devel@lists.fedoraproject.org

34 participants
40 discussions

Fedora EPEL Package Build Report 2007-09-06
by Fedora Koji Build System 05 Sep '07

05 Sep '07

Packages built and released for Fedora EPEL 5: 10 GeoIP-1.4.3-1.el5 NEW gkrellm-2.3.0-4.el5.1 : Multiple stacked system monitors in one process NEW gkrellm-volume-2.1.13-6.el5 : GKrellM volume plugin NEW hddtemp-0.3-0.14.beta15.el5 : Hard disk temperature tool NEW imlib-1.9.15-4.el5 : An image loading and rendering library for X11R6 NEW libcdio-0.78.2-2.el5 : CD-ROM input and control library NEW libmodplug-0.8.4-1.el5 : Modplug mod music file format library NEW libmpcdec-1.2.6-1.el5 : Musepack audio decoding library NEW perl-CGI-Untaint-date-1.00-3.el5 : Validate a date yum-cron-0.4-1.el5 Packages built and released for Fedora EPEL 4: 4 GeoIP-1.4.3-1.el4 libmpcdec-1.2.6-1.el4 NEW perl-CGI-Untaint-date-1.00-3.el4 : Validate a date NEW php-pecl-memcache-2.1.2-1.el4.1 : Extension to work with the Memcached caching daemon Changes in Fedora EPEL 5: GeoIP-1.4.3-1.el5 ----------------- * Wed Sep 05 2007 Michael Fleming <mfleming+rpm(a)enlartenment.com> 1.4.3-1 - New upstream release. - Fix GeoIPCity fetcher script - Update License tag gkrellm-2.3.0-4.el5.1 --------------------- * Wed Sep 05 2007 Ville Skyttä <ville.skytta at iki.fi> - 2.3.0-4.1 - Adapt to lm_sensors availability/setup in EL. * Wed Sep 05 2007 Ville Skyttä <ville.skytta at iki.fi> - 2.3.0-4 - Rewrite gkrellmd init script: better LSB compliance, hddtemp interoperability, avoidance of X error messages, general cleanup. * Tue Sep 04 2007 Ville Skyttä <ville.skytta at iki.fi> - 2.3.0-3 - Fix gnutls detection/build and use it instead of openssl. - Sync user and group creation with current Fedora guidelines. * Tue Aug 07 2007 Hans de Goede <j.w.r.degoede(a)hhs.nl> 2.3.0-2 - Update License tag for new Licensing Guidelines compliance gkrellm-volume-2.1.13-6.el5 --------------------------- * Tue Sep 04 2007 Ville Skyttä <ville.skytta at iki.fi> - 2.1.13-6 - Convert docs to UTF-8. * Thu Aug 16 2007 Ville Skyttä <ville.skytta at iki.fi> - 2.1.13-5 - License: GPLv2+ hddtemp-0.3-0.14.beta15.el5 --------------------------- * Wed Sep 05 2007 Ville Skyttä <ville.skytta at iki.fi> - 0.3-0.14.beta15 - Adjust server chkconfig start/stop priorities to start before gkrellmd, other cosmetic init script tweaks. - Mark hddtemp.db as %config(noreplace). imlib-1.9.15-4.el5 ------------------ * Thu Aug 09 2007 Paul Howarth <paul(a)city-fan.org> 1:1.9.15-4 - re-clarify license as GNU Lesser General Public License v2 or later (LGPLv2+) * Wed Aug 08 2007 Paul Howarth <paul(a)city-fan.org> 1:1.9.15-3 - redesign of enlightenment.org website removed imlib page, so URL changed to enlightenment.sourceforge.net where the original website lived (#251278) - clarify license as GNU Lesser General Public License v2 or later (LGPL+) libcdio-0.78.2-2.el5 -------------------- * Mon Jul 23 2007 Adrian Reber <adrian(a)lisas.de> - 0.78.2-2 - updated to 0.78.2 (#221359) (this time for real) libmodplug-0.8.4-1.el5 ---------------------- * Wed Apr 04 2007 Ville Skyttä <ville.skytta at iki.fi> - 1:0.8.4-1 - 0.8.4. libmpcdec-1.2.6-1.el5 --------------------- * Wed Jun 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.2.6-1 - libmpcdec-1.2.6 perl-CGI-Untaint-date-1.00-3.el5 -------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway <tcallawa(a)redhat.com> 1.00-3 - fix license tag yum-cron-0.4-1.el5 ------------------ * Mon Sep 03 2007 Alec Habig <ahabig(a)umn.edu> - 0.4-1 - Fix bug in cron.daily which was preventing updates from running - Integrate Frank's checkonly patches into the source Changes in Fedora EPEL 4: GeoIP-1.4.3-1.el4 ----------------- * Wed Sep 05 2007 Michael Fleming <mfleming+rpm(a)enlartenment.com> 1.4.3-1 - New upstream release. - Fix GeoIPCity fetcher script - Update License tag libmpcdec-1.2.6-1.el4 --------------------- * Wed Jun 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.2.6-1 - libmpcdec-1.2.6 perl-CGI-Untaint-date-1.00-3.el4 -------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway <tcallawa(a)redhat.com> 1.00-3 - fix license tag php-pecl-memcache-2.1.2-1.el4.1 ------------------------------- * Sat Sep 01 2007 Remi Collet <Fedora(a)FamilleCollet.com> 2.1.2-1.el4.1 - specific spec for EL4 - memcache-php439.patch, see http://pecl.php.net/bugs/bug.php?id=11953 * Mon Aug 20 2007 Remi Collet <Fedora(a)FamilleCollet.com> 2.1.2-1 - initial RPM For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/

1 0

EPEL SIG Log -- 05 Sept 2007
by Michael Stahnke 05 Sep '07

05 Sep '07

[18:01] *** You set the channel topic to "EPEL Sig meeting". [18:01] <nirik> afternoon stahnma (or evening or morning) [18:01] <stahnma> afternoon/evening [18:01] <stahnma> ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL [18:01] * nirik wonders if anyone else is around. ;) [18:02] <stahnma> me too [18:02] <stahnma> I thought the new time might work out better...we'll see [18:02] <rsc> RobertScheck [18:03] <stahnma> mmcgrath: ? , Jeff_S, quaid? [18:04] <stahnma> ok [18:04] <stahnma> we don't have quarum [18:04] <nirik> yeah, doesn't seem so. ;( [18:04] <stahnma> no voting tonight [18:04] <stahnma> not that anything was up on the table [18:04] *** You set the channel topic to "EPEL Meeting | push to stable easily -- knurd". [18:04] <stahnma> knurd is obviusly not here [18:04] <stahnma> but there has been discussion on list [18:05] <nirik> yeah, it's the middle of his night. ;) [18:05] <stahnma> yup [18:05] <stahnma> are we making progress here? [18:05] <stahnma> I haven't kept up with it 100% [18:05] <stahnma> rsc: feel free to participate as much as you want [18:05] <nirik> well, I think we decided to do monthly pushes of new packages only... [18:05] <stahnma> or anyone in the peanut gallery :) [18:05] <mmcgrath> pong [18:06] <jwb> er [18:06] <nirik> I have the info on how to do pushes now, but haven't had time to try one. [18:06] <stahnma> ok [18:06] <jwb> monthly pushes for new packages? [18:06] <nirik> yeah. [18:06] <jwb> why only monthly? [18:06] <stahnma> to maintain stability [18:06] * mmcgrath was fine with quartly or whenever RH did it honestly. [18:06] <rsc> stahnma: I am already EPEL maintainer, isn't that enough? [18:06] <stahnma> EL doesn't introduce new packages ad hoc [18:07] <mmcgrath> its not like we keep the testing repo private. [18:07] <stahnma> rsc sure is [18:07] <nirik> well, we could possibly do more often, the thought is that it might be pretty time consuming [18:07] <stahnma> I just saw you popped in at the start of the meeting, and thought you might something to add (no worries) [18:07] <rsc> stahnma: no problem. I'll shout, if there's something [18:08] <stahnma> right now while the repo is still growing pushing new packages into it seems to make sense [18:08] <stahnma> though using epel-testing also makes sense [18:08] <rsc> btw, is there a real chance for getting koji for EPEL? [18:08] <stahnma> either way, as long as progress is being made on list, I think we can move on [18:08] <stahnma> rsc: not near term [18:08] <stahnma> moving on? [18:09] *** You set the channel topic to "EPEL Meeting | do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all". [18:09] <stahnma> I think knurd snuck this one in here [18:09] <stahnma> It's a good reminder [18:09] <stahnma> lists don't have timezones to work around [18:09] <nirik> yeah. It's hard to remember to make sure and reply to all the list stuff, but I think it's a good thing to try for... [18:09] <stahnma> I don't think there's a lot of comments on this one.... [18:10] <nirik> we should also remember to send things to the list when they are talked about on irc or whatever. [18:10] *** You set the channel topic to "EPEL Meeting | MetaData for all Packages available to contributors. -- stahnma". [18:10] <stahnma> I had a little bit of time today to work on this [18:10] <stahnma> but didn't get very far [18:10] <stahnma> I will continue working on it tonight [18:10] <stahnma> one issue is that my enterprise account may not have access to all channels [18:11] <stahnma> it would be wonderful to get a real RHN account from RH for EPEL [18:11] <stahnma> or at least some representation with a direct link to RHEL/RHN [18:11] <mmcgrath> for what purpose? [18:11] <stahnma> to see what packages are stepping on items offered by RH [18:12] <stahnma> also, a new issue was brough up on list about pear/php stuff in EL4, since RH ships a moving AMP stack on RHEL [18:12] <stahnma> how does a maintainer build PHP packages in EL [18:13] <stahnma> the people I have spoken with in #rhel and #rhn about epel often sight concern over "stepping on RHN" [18:13] <nirik> they are just like any other package... but yeah, no idea if they are already in some channel from RHEL [18:13] <nirik> I'd be happy for us not to step on them, but it's not clear how we can find out if we are or not. [18:13] <stahnma> nirik: that's the issue. I will continue to look into it [18:14] <stahnma> I assume a solution is out there, and we may be making it more complicated than it really is [18:14] --> bpepple|lt has joined this channel (n=bpepple|(a)rrcs-70-61-160-147.central.biz.rr.com). [18:14] *** You set the channel topic to "EPEL Meeting | [:EPEL/CommunicationPlan:Communication plan] for enterprise customers/ISVs/IHVs -- stahnma, quaid". [18:14] <stahnma> sorry, I forgot to ask if we can move on [18:14] <nirik> well, I would expect redhat has a way of determining if something is already offered by them or not. [18:14] <stahnma> (I'm new here) [18:14] <stahnma> :) [18:15] <nirik> anyhow, yeah, move on [18:15] <stahnma> I have little updates on this. Again, figuring out the RHN conflicts will help the communcation/adoption of EPEL [18:15] <stahnma> my company is moving RHEL 5 builds to EPEL though :) [18:15] <nirik> cool. [18:16] <stahnma> quaid isn't present, so that's all I have [18:16] <stahnma> this is looking like it coudl be quite a short meeting [18:16] * nirik would be ok with that. [18:16] <stahnma> job decription is also quaid [18:16] *** You set the channel topic to "EPEL Meeting | General Discussion". [18:17] * mmcgrath has nothing [18:17] <nirik> I have a item or two real quickly... [18:17] <stahnma> dgilmore had mentioned he would like to step down from EPEL on the list [18:17] <stahnma> do we solicit for another spot to be filled? [18:18] <stahnma> I can bring it up on list [18:18] <stahnma> nirik: what do you have? [18:18] <nirik> I have added epel4 and epel5 audit files in the fedora-security setup. I generated them by looking at the fc7 lists and putting in only those packages that exist in epel4 or epel5. Now comes the fun part of auditing everything to see what security updates we need/are missing. [18:18] <nirik> I have slowly started on that. If anyone would like to help, let me know. [18:18] <stahnma> do you have any documentation describing the process? [18:18] <stahnma> I am not familiar with it [18:19] <nirik> yeah, there is a readme and such, I can dig it up. [18:19] <nirik> Basically we have a file that has each CVE listed and then if our package is vunerable or not. [18:19] <stahnma> I can try to help, but you can also solicit on list. [18:20] <nirik> so something like: [18:20] <nirik> CVE-2005-4803 version (graphviz, fixed 2.2.1) [18:20] <nirik> so the graphviz in epel5 is newer than the version it was fixed in (2.2.1) so it's ok. [18:20] <stahnma> can that process be automated? [18:21] <nirik> possibly, but it's pretty complex. [18:21] <stahnma> ok [18:21] <nirik> There is newer version, there is backported patch, not vunlerable because it's a windows thing, etc. [18:21] <stahnma> ah yes, backporting [18:21] <nirik> but we do need to track security well on EPEL. [18:21] <stahnma> that would make things hard [18:22] <stahnma> agreed [18:22] <nirik> I can solicit the list... although it's currently in an area that requires you to be in the security team to check in changes. [18:22] <stahnma> ah [18:22] * stahnma is not on the security team [18:22] <nirik> I can keep working on it too. [18:23] <stahnma> ok [18:23] <stahnma> any other business from anybody? [18:23] <nirik> Also, a somewhat related item: [18:23] <nirik> looking at security, I note there are a number of packages that have branches for epel, but don't seem to have been built. [18:23] <nirik> I guess I can generate a list and bug people on the list about it. [18:24] <stahnma> I would assume some people are still waiting on deps [18:24] <stahnma> but it might be time to ping them [18:24] <nirik> mediawiki has a el5 branch, but doesn't appear to be in the repo... for example. [18:24] <stahnma> yeah, and I would love it :) [18:24] <stahnma> bug reports are probably ok on that [18:24] <nirik> libmodplug was another. I think there were some more too. [18:25] <nirik> anyhow, just thought I would mention it. [18:25] * nirik has no more. [18:25] <stahnma> I will close meeting in 10 [18:25] <ivazquez> I have something I'd like to ask about. [18:25] <stahnma> ok [18:25] <stahnma> I won't close :) [18:25] <ivazquez> EPEL5 has lapack 3.1.1, but doesn't EL5 have lapack 3.0? [18:27] <stahnma> ok, I am not familiar with lapack [18:28] <nirik> yeah, seems to be the case. ;( [18:28] <ivazquez> AIUI, EPEL has not going to replace packages in the base EL set. [18:28] <ivazquez> *was [18:28] <nirik> this gets back to trying to make sure we don't step on RHEL [18:28] <stahnma> EL 5 has 3.0-37 [18:28] <stahnma> from what I can see in RHN [18:29] <stahnma> nirik, can shoudl this be filed as a bug with you? [18:29] <nirik> well, I guess we need to just remove it... ;( [18:29] <stahnma> or more on the infrastructure side? [18:29] <nirik> yeah, we should come up with a way to get repo requests done/tracked. [18:30] <stahnma> maybe we should also bring that up on list [18:30] <nirik> perhaps we could setup a epel traq instance? mmcgrath ? [18:30] <stahnma> or use the same trac? [18:30] <mmcgrath> buhhh [18:30] <nirik> yeah, or just use infrastructures... [18:30] <nirik> :) [18:31] <mmcgrath> for what? when files need to be removed? [18:31] <nirik> yeah, packages removed from the repo... [18:31] <stahnma> or general issues with epel infrastrcuture? [18:31] <mmcgrath> how is it done im fedora? [18:32] * stahnma isn't sure :) [18:32] <nirik> mail to releng? [18:32] <jwb> yes [18:33] <stahnma> are any epel-infrastructure people also in releng? [18:33] <nirik> so we could just also make a epeleng alias? [18:33] <jwb> who's the epel infrastructure people? [18:34] <mmcgrath> for epel we should probably email epel_signers-members(a)fp.o [18:34] <stahnma> jwb trumps me with his logic [18:34] <jwb> that was a real question. but i think the answer is no [18:34] <jwb> rel-eng is me, spot, rdieter, f13, jeremy, and warren [18:34] <stahnma> yeah, I don't know [18:35] <mmcgrath> there's no difference between the epel and normal fedora 'infrastructure' people. but epel doesn't have any release engineers. The closest thing is the signers. [18:35] <stahnma> ok [18:35] <stahnma> well, as long as a task gets handled in a timely maner, the process isn't all that important [18:35] <nirik> yeah, but it would be good to have a process we can point people at... [18:35] <stahnma> hopefully these needs will rarely arise [18:35] <stahnma> true [18:36] <nirik> so they don't just give up and it never gets done. [18:36] <stahnma> yes [18:36] <stahnma> should the official process just be to bring it up on epel-devel-list? [18:36] <stahnma> it seems easy enough, and probably effective [18:37] <stahnma> brb [18:37] <nirik> so, for now, how about email to epel_signers-members@ ? [18:37] <mmcgrath> WORKSFORME [18:37] <nirik> good catch on that ivazquez. [18:37] <-- kanarip has left this server (Remote closed the connection). [18:37] <nirik> sure, that would be fine too... [18:38] --> kanarip has joined this channel (n=kanarip@fedora/kanarip). [18:38] <stahnma> ok [18:38] <stahnma> any other items? [18:38] * stahnma will close the meeting in 10 [18:38] <stahnma> -- MARK -- Meeting end [18:38] <nirik> ivazquez: is there a bug filed on that lapack thing? If not we should so the maintainer knows whats going on. Todos: * Continue to investigate Metadata/package conflicts with RHN/EL and EPEL -- stahnma * Security setup for EPEL4-5, nirik will send out more information on list. -- nirik * How to notify the EPEL team if a package should be removed due to conflicting with EL. -- nirik * Evaluate meeting time again. Same people that are normally there, were there. Minus Knurd.

1 0

Pull perl-XML-DOM from EL-4 repo
by Orion Poplawski 05 Sep '07

05 Sep '07

Can we *please* get perl-XML-DOM pulled from the EL-4 repo? I've asked everywhere I can think of, but no response. https://bugzilla.redhat.com/show_bug.cgi?id=249901 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

EPEL report week 35 2007
by Thorsten Leemhuis 05 Sep '07

05 Sep '07

http://fedoraproject.org/wiki/EPEL/Reports/Week35 (sorry, a bit late this time; was busy on sunday, afk Monday after work and didn't get it completely finished yesterday evening) = Weekly EPEL Summary = Week 35/2007 == Most important happenings == * we will do alternate meeting times now; 23:00 one week, 17:00 UTC the other; next meeting at 20070905 at 23:00 UTC * FESCo [https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02213.html extended the mandate] for the EPEL Steering Committee * the plan is to push new packages (not updates ones) more often to stable in the future; likely every four weeks for now -- no exact timeframe can be given yet, as we need to see how complicate it is (the process needs to be prepared manually by someone in a local test-repo first, to check if all deps are still satisfied before packages can actually be moved) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * quaid (KarstenWade) === Summary === * easier pushing from testing to stable * nirik can push for EPEL as well (in addition to dgilmore, knurd and mmcgrath) * mschwendt did some improvements to the scripts (many thx mschwendt for your work!); they should make it easy to move something from testing to stable ; the final patch to the scripts-in-production was not applied yet ; knurd talked to dgilmore about it (he knows the scripts way better than I do) and wants to take a look (on his todo list after fixing plague ); if he doesn't find the time knurd will take the risk over the next few days as do it himself * we need to be careful that a update doesn't depend on something else in testing. * new meeting schedule/scheme * alternate meetings are the new black; find the details in https://www.redhat.com/archives/epel-devel-list/2007-September/msg00005.html and http://fedoraproject.org/wiki/EPEL/Meetings * MetaData for all Packages available to contributors. -- stahnma * I've been trying to get a better definition of the problem ; I understand the issue, but use-cases etc would be nice ; we need a clear stance on EPEL not stepping on RHN provided material and a way to hopefully enforce it * might be a good start to at least have a package list of RHEL4 and RHEL5 online somewhere * mandate for the Steering Committee * nirik will ask FESCo (which happened in between) * push quicker to stable * see section "most important happenings" * Free discussion around EPEL * Quotes: "I want a pony" and "the weather sucks " * stahnma> "I am trying to get some more #rhel and #rhn people involved here in EPEL "; are there any other channels/mailing lists where we should ask interested people to join us in the meetings? * stahnma> "can anyone write for RH magazine? " stahnma will evaluate and would happily write it; but maybe mether or someone else is preparing one already? * nirik is working on clamav; comments on his post appreciated; "and solving the problems with the packaging and compatibility with dag/rpmforge would be good"; on the other hand it's good if stuff is similar in Fedora and EPEL === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-September/msg00006.html == Stats == === General === Number of EPEL Contributors: unknown -- looks like we'll have it next again next week! === EPEL 5 === Number of source packages: 628 Number of binary packages: 1196 There are 29 new Packages: * amtterm | Serial-over-lan (sol) client for Intel AMT * dfu-programmer | A Device Firmware Update based USB programmer for Atmel chips * dstat | Versatile resource statistics tool * erlang | General-purpose programming language and runtime environment * iftop | Command line tool that displays bandwidth usage on an interface * jhead | Tool for displaying EXIF data embedded in JPEG images * perl-CGI-Simple | Simple totally OO CGI interface that is CGI.pm compliant * perl-CGI-Untaint | Process CGI input parameters * perl-Class-Trigger | Mixin to add / call inheritable triggers * perl-Class-Whitehole | Base class to treat unhandled method calls as errors * perl-Date-Simple | Simple date object for perl * perl-Exporter-Lite | Lightweight exporting of variables * perl-OLE-Storage_Lite | Simple Class for OLE document interface * perl-Spreadsheet-WriteExcel | Write formatted text and numbers to a cross-platform Excel binary file * perl-SQL-Abstract | Generate SQL from Perl data structures * perl-Tie-DBI | Tie hashes to DBI relational databases * perl-UNIVERSAL-exports | Lightweight, universal exporting of variables * perl-UNIVERSAL-moniker | Real world naming for classes * pexpect | Pure Python Expect-like module * php-extras | Additional PHP modules from the standard PHP distribution * php-pecl-memcache | Extension to work with the Memcached caching daemon * python-boto | A simple lightweight interface to Amazon Web Services * rootsh | Shell wrapper for auditing * shapelib | API in "C" for Shapefile handling * xbase | XBase compatible database library and tools * xbiso | ISO extraction utility for xdvdfs images * xbsql | A SQL wrapper for xbase * xclip | Command line clipboard grabber * yum-cron | Files needed to run yum updates as a cron job === EPEL 4 === Number of source packages: 413 Number of binary packages: 827 There are 30 new Packages: * createrepo | Creates a common metadata repository * gmrun | Lightweight "Run program" dialog box with search history and tab completion * iftop | Command line tool that displays bandwidth usage on an interface * pdns | A modern, advanced and high performance authoritative-only nameserver * perl-CGI-Simple | Simple totally OO CGI interface that is CGI.pm compliant * perl-CGI-Untaint | Process CGI input parameters * perl-Class-Trigger | Mixin to add / call inheritable triggers * perl-Class-Whitehole | Base class to treat unhandled method calls as errors * perl-Date-Simple | Simple date object for perl * perl-Exporter-Lite | Lightweight exporting of variables * perl-OLE-Storage_Lite | Simple Class for OLE document interface * perl-Spreadsheet-WriteExcel | Write formatted text and numbers to a cross-platform Excel binary file * perl-SQL-Abstract | Generate SQL from Perl data structures * perl-String-CRC32 | Perl interface for cyclic redundancy check generation * perl-Tie-DBI | Tie hashes to DBI relational databases * perl-UNIVERSAL-exports | Lightweight, universal exporting of variables * perl-UNIVERSAL-moniker | Real world naming for classes * pexpect | Pure Python Expect-like module * php-idn | PHP API for GNU LibIDN * python-boto | A simple lightweight interface to Amazon Web Services * python-elementtree | Fast XML parser and writer * python-urlgrabber | A high-level cross-protocol url-grabber * rootsh | Shell wrapper for auditing * shapelib | API in "C" for Shapefile handling * tidy | Utility to clean up and pretty print HTML/XHTML/XML * xbase | XBase compatible database library and tools * xbiso | ISO extraction utility for xdvdfs images * xbsql | A SQL wrapper for xbase * xclip | Command line clipboard grabber * yum | RPM installer/updater ---- ["CategoryEPELReports"]

1 0

EPEL Meeting This week [new time]
by Michael Stahnke 04 Sep '07

04 Sep '07

Reminder, EPEL is trying alternative meeting times to encourage more attendance from everyone ( not just steering coommittee memebers). If you have any interest in EPEL, please come join us! LOOK -----------> Meeting is at 23:00 UTC this week. /topic EPEL Meeting|push to stable easily -- all /topic EPEL Meeting| MetaData for all Packages available to contributors. -- stahnma /topic EPEL Meeting|[:EPEL/CommunicationPlan:Communication plan] for enterprise customers/ISVs/IHVs -- stahnma, quaid /topic EPEL Meeting|[:EPEL/PackageMaintainer/GenericJobDescription: Generic Job Description]||[:KarstenWade:quaid] /topic EPEL Meeting|new meeting time? -- all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) stahnma

1 0

Log from last weeks (200700829) EPEL SIG Meeting
by Thorsten Leemhuis 04 Sep '07

04 Sep '07

00:00:46 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:46 < knurd> | Hi everybody; who's around? 00:00:46 * | 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:46 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:50 < mmcgrath> | pong 00:00:57 < stahnma> | pong 00:01:20 * | nirik is here. 00:01:43 * | stahnma tried to solicit interest from #rhn 00:02:12 < knurd> | well, let's start 00:02:15 --- | knurd has changed the topic to: EPEL Meeting|push to stable easily -- knurd 00:02:25 < knurd> | mschwendt did some improvements to the scripts 00:02:42 < knurd> | they should make it easy to moev something from testing to stable 00:02:50 < knurd> | the final patch was not applied yet 00:03:11 < knurd> | I talked to dgilmore about it (he knows the scripts way better than I do) and wants to take a look 00:03:23 < knurd> | if he doesn#t find the time i'll take the risk over the next few days 00:03:33 < nirik> | we just need to be carefull that a update doesn't depend on something else in testing. 00:03:55 < knurd> | ohh, and I'd like to say "thx for your work mschwendt" 00:04:18 < stahnma> | as someone not too familiar with the infrastructure side of things, were are these scripts at? 00:04:21 < knurd> | nirik, well, with the current policy we only move updates for stable packages 00:04:24 < stahnma> | and can I review them? 00:04:52 * | dgilmore is here 00:04:57 < mmcgrath> | I actually don't know where the canonical spot for that stuff is 00:04:59 < knurd> | stahnma, somewhere in http://cvs.fedora.redhat.com/viewcvs/?root=fedora 00:05:15 < dgilmore> | extras-buildsys 00:05:20 < nirik> | knurd: are you talking about moving single packages from testing-> stable, or moving all packages in testing-> stable? 00:05:37 < knurd> | nirk, for now only single packages 00:05:37 < stahnma> | ok, I can take that offline, I just would like to be a bit more involved in some of the infrastructure for EPEL 00:05:45 < knurd> | e.g. in case of urgent bugixes 00:05:52 < nirik> | the first we need to make sure the package is not built against any of the other packages that are still sitting in testing... 00:06:30 < knurd> | dgilmore, I suppose you didn#t find time yet to look into the improvements from mschwendt? 00:06:46 --> | BobJensen (Robert 'Bob' Jensen) has joined #Fedora-Meeting 00:06:51 < knurd> | nirik, well, normally there should be any new stuff where in testing which could lead to problems 00:06:53 < dgilmore> | knurd: not yet. its on my todo list after fixing plague 00:07:02 < knurd> | nirik, but yeah, we shound not forget about it 00:07:06 < nirik> | yeah, we also need that for security updates. I should perhaps see if we can add a audit file for epel and discuss on the list security. 00:07:06 < knurd> | dgilmore, k, thx 00:07:10 < stahnma> | dgilmore: are the EL-5 builders still amuck? 00:07:17 < stahnma> | (I have no idea if I spelled that right) 00:07:52 < dgilmore> | stahnma: all plague builds 00:08:20 < rsc> | dgilmore: just to comment. I was one of the guys having such problems. I fired lots of builds the last days, no problems for me. But I can't speak for all. 00:08:36 < dgilmore> | rsc: there has still been reports 00:09:33 < knurd> | well, anything else for now? 00:09:42 * | knurd will move on soon 00:09:59 --- | knurd has changed the topic to: EPEL Meeting|new meeting schedule/scheme 00:10:13 < stahnma> | I sent out some feelers on list 00:10:18 < knurd> | stahnma, would you be willing to run the meetings every second week at 23:00 UTC? 00:10:20 < stahnma> | didn't get much back other than the SIG 00:10:28 < nirik> | I'm happy to try an alternate meeting time... we can always try and if no more people show we can stop doing it. ;) 00:10:29 < stahnma> | knurd: I think so 00:10:29 < knurd> | then I'd say we just try it 00:10:45 < knurd> | (even if I never will be able to make those meetings) 00:10:59 < knurd> | is the timeslot fee in this channel? 00:11:03 < stahnma> | hmm 00:11:08 < stahnma> | probably something I should ahve looked at 00:11:18 < stahnma> | yeag 00:11:46 * | stahnma will add to the #fedora-meeting schedule 00:11:53 < knurd> | k 00:12:33 < knurd> | so agreed we agree on: one week at 17:00 UTC, the other week on 23:00 UTC, this channel and Wednesday 00:12:38 < knurd> | is that correct? 00:12:45 < knurd> | and fine for everybody? 00:12:57 < mmcgrath> | we're still meeting weekly, just different times each week? 00:13:07 < knurd> | mmcgrath, seems so 00:13:12 < nirik> | so next week starts the other meeting time? 00:13:15 < nirik> | or today? 00:13:19 < knurd> | nirik, next week 00:13:29 < stahnma> | next week 00:13:34 < knurd> | nirik, or do you want to have two meetings on one day? ;-) 00:13:48 < nirik> | ok, but we should note that it's a trial, and if there isn't much response we will not be doing it further. 00:13:52 --> | mpdehaan (Michael DeHaan) has joined #fedora-meeting 00:13:54 < nirik> | ha. No thanks. ;) 00:14:07 < knurd> | nirik, "trial" > sounds like a good plan 00:14:28 < knurd> | settled then? yell now or I'll consider it accepted 00:14:29 < stahnma> | ok 00:14:39 < knurd> | stahnma, will you write the meeting summaries for the reports as well? 00:14:45 < stahnma> | sure 00:14:49 < knurd> | great :) 00:15:22 * | knurd considers it as accepted and moves on 00:15:25 < knurd> | ohh, wait, stop 00:15:35 < knurd> | I think we nevertheless should try to do more on the list 00:15:39 < stahnma> | +1 00:15:41 < knurd> | or what do other think? 00:15:44 < knurd> | others 00:15:52 < nirik> | sure, I agree. 00:16:06 < knurd> | k 00:16:13 < knurd> | I hope to write something up about it 00:16:15 < knurd> | soon 00:16:19 * | knurd moves on 00:16:21 --- | knurd has changed the topic to: EPEL Meeting| MetaData for all Packages available to contributors. -- stahnma 00:16:24 < knurd> | stahnma ? 00:16:43 < stahnma> | I've been trying to get a better definition of the problem 00:16:53 < stahnma> | I understand the issue, but use-cases etc would be nice 00:17:09 < stahnma> | we need a clear stance on EPEL not stepping on RHN provided material 00:17:17 < stahnma> | and a way to hopefully enforce it 00:17:18 < knurd> | stahnma, maybe it would be a good start to at lest have a package list online somewhere 00:17:21 < stahnma> | but how, I haven't got there yet 00:17:25 < stahnma> | ok 00:17:25 < knurd> | for 5Desktop and 5Server 00:17:28 < stahnma> | I can probably do that 00:17:33 < stahnma> | if it's not already done 00:17:38 < nirik> | I'm still unsure whats in all those hundreds of channels. 00:17:39 < knurd> | not that I know of 00:17:52 <-- | TowerBE has left #fedora-meeting ( "I'm outta here") 00:17:55 * | knurd doesn't know that either 00:17:56 < nirik> | is that other packages or just a different set (like a fedora spin?) 00:17:57 < stahnma> | nirik: packages :) Many of them are old RH channels 00:18:00 < stahnma> | like 7.2 00:18:01 < stahnma> | and 7.3 00:18:03 < stahnma> | and such 00:18:13 < nirik> | ah ha. 00:18:15 --> | Jeff_S (Jeff) has joined #fedora-meeting 00:18:19 < nirik> | well, most of those can be ignored I bet. 00:18:21 < stahnma> | and separate channels for each arch and each flavor (AS, ES, AP) 00:18:22 < stahnma> | right 00:18:30 < stahnma> | it's mostly a matter of sorting through them 00:18:32 * | Jeff_S on phone, sorry :( 00:18:40 < nirik> | stahnma: perhaps a list of channels would be good to post? or is that info something redhat wouldn't want released? 00:18:49 < stahnma> | I think I have it on fedorapeople 00:18:51 < stahnma> | let me check 00:19:00 < stahnma> | http://stahnma.fedorapeople.org/rhn_channels.txt 00:19:09 < stahnma> | this is a week or two old 00:19:39 < nirik> | ok, so what info can you get from each channel? packages names? 00:19:44 < stahnma> | yes 00:19:49 < stahnma> | and EVRs 00:19:50 < nirik> | how about files? 00:19:51 < stahnma> | if we want them 00:19:55 < stahnma> | I *think* so 00:19:59 < stahnma> | I have to check on that one 00:20:06 < nirik> | or provides? 00:20:34 < stahnma> | yup, I can get a list of files for each package 00:20:56 < nirik> | basically what I think we want is a tool or something where we can do a lookup by name/provides/files so we can tell if a package someone wants to move into epel conflicts with that. 00:21:24 < stahnma> | I can get provides 00:21:31 < stahnma> | the RHN API is pretty cool 00:21:37 < nirik> | ie, search on 'openmotif' and or 'Provides: libm.so.4' or whatever. 00:21:51 * | nirik guesses thats a bad example, but that kind of thing. 00:22:02 < stahnma> | I'll see what I can come up with 00:22:08 < knurd> | I'd say we should not overengeneer the problem 00:22:18 < stahnma> | knurd: ++ 00:22:20 < nirik> | perhaps just name is good enough. 00:22:26 < stahnma> | I'll start there :) 00:22:26 < knurd> | nirik, for the start 00:22:31 < knurd> | then we can see what people need 00:22:35 <-- | mbacovsk has quit (Read error: 110 (Connection timed out)) 00:22:41 < knurd> | and provide more informations if really needed 00:23:26 < nirik> | sounds good to me. 00:23:28 < knurd> | stahnma, will you take care of it ? 00:23:48 < stahnma> | yeah 00:23:59 < stahnma> | give me a week or two 00:24:03 < knurd> | k 00:24:07 < knurd> | then let's move on now 00:24:25 --- | knurd has changed the topic to: EPEL Meeting| mandate for the Steering Committee 00:24:35 < knurd> | I kicked the discussion of on fedora-devel 00:24:46 < knurd> | I liked quaid's mail 00:25:13 < knurd> | we just actually need to adjut some details to lower the influence of the Steering Committee 00:25:24 < knurd> | to make "more power to the people" possible 00:25:34 < knurd> | anything else regarding the topic? 00:25:48 < nirik> | I liked that too... 00:26:03 * | knurd really should start sending out topic lists ahead of th meeting again 00:26:11 < nirik> | so do we need to get any kind of ack from fesco? or we just switch to a SIG and move ahead as we like? 00:26:28 < knurd> | nirik, well, I think we need a ack 00:26:48 < knurd> | some kind of "we extend the mandate for the EPEL Steering Committe by 6 months / a year" 00:27:22 < knurd> | nirik, can you make sure it gets discussed over the next two weeks maybe? 00:27:30 < nirik> | yep. 00:27:38 < knurd> | nirik, thx 00:28:05 --- | knurd has changed the topic to: EPEL Meeting | push quicker to stable 00:28:18 < knurd> | seems this topic is getting discussed a bit more again 00:28:32 < nirik> | I'm not opposed to faster pushes from testing... but we need to be carefull... 00:28:35 < knurd> | my 2 cent: I'm fine with moving new packages over after four weeks or so 00:28:38 < mmcgrath> | the current method has worked well for me both as a contributor and as a consumer. 00:28:52 < knurd> | but updates to existing packages only should get over if there is a need to (and not automatically) 00:29:02 < nirik> | are the redhat 'quarterly' updates really quarterly? 00:29:08 < stahnma> | nirik: no 00:29:19 < stahnma> | nirik: they are every-so-often 00:29:24 < nirik> | yeah, thats what I thought. 00:29:31 < knurd> | nirik, yeah, if they are not then we really should do them more often for new packages 00:29:32 < stahnma> | 4-5 months lately, it seems like 00:29:46 < mmcgrath> | But if we are trying to match RHEL as a great complimentary repo to RHEL, we just have to take their lead. 00:29:54 < knurd> | with four people beeing alte to push we might have the manpower to do it soon 00:30:20 * | nirik is happy to do pushes after he gets trained on how to. ;) 00:30:21 < knurd> | but we'd need to prepare that one machine, check the deps, and after that do it in the repo 00:30:29 < knurd> | to make sure all the deps are fulfilt 00:30:41 < knurd> | mmcgrath, +1 00:30:45 < nirik> | yeah. 00:30:48 < knurd> | mmcgrath, but we are still in the early stages 00:31:01 < knurd> | so pushing new packages (not updated ones) more often might be a good idea 00:31:22 < knurd> | nirik, I'll tell you soon how to push 00:31:27 < mmcgrath> | <nod> 00:31:47 < stahnma> | ok 00:31:47 * | knurd has a headache today and will leave the keyboard right after the meeting 00:32:02 < nirik> | yeah, how about weekly we push any new package that has been in testing for 4 weeks (provided it has no broken deps or anything) 00:32:21 < Jeff_S> | I agree -- for the time being, it would be really nice to push 'new' packages to stable more often 00:32:30 < nirik> | 5-6 months does seem a while to wait for your new package if it's all stable. 00:32:30 < knurd> | nirik, well, I think that's do much work with the current tools 00:32:46 < knurd> | nirik, I'd say one a months should be often enough 00:33:17 < nirik> | yeah, I don't know how hard it would be... I am pretty good about doing scheduled tasks like that tho... so whatever works. 00:33:35 < mpdehaan> | more often would be goodness 00:33:37 < knurd> | nirik, I#d just say we try it once and see how much work it is 00:33:49 < nirik> | yeah. 00:33:52 < knurd> | and decide then if we do it each week, every two, or evrey four 00:34:01 < nirik> | mpdehaan: yeah, would that meet your needs somewhat? you wanted faster pushes... 00:34:23 < Jeff_S> | mpdehaan: btw, yum, createrepo, etc. are now in EPEL-4 testing if you hadn't noticed 00:34:24 < mpdehaan> | haven't been following this chat too closely -- how often is how often? 00:34:42 < mpdehaan> | anyhow, the problem is that testing can be any varying degree of unstable, while stable is very old 00:34:48 < mpdehaan> | just some middle ground would would be great 00:35:01 < mpdehaan> | Jeff_S, awesome 00:35:02 < nirik> | it's not been decided yet. ;) We were thinking if a new package has been in testing a month it gets moved to stable. 00:35:02 <-- | LetoTo has quit (Read error: 110 (Connection timed out)) 00:35:04 < Jeff_S> | I think once a month or so is a good starting spot and we can see how that goes 00:35:04 < knurd> | mmcgrath, I'd say "every four week" if likely for now 00:35:11 < mpdehaan> | nirik, 1 month sounds great 00:35:12 < knurd> | weeks 00:35:32 < nirik> | bugfixes, updates, stay in testing until the next rhel quarterly unless they are security or major. 00:35:44 < knurd> | well, anything else regarding this topic? 00:35:44 < mmcgrath> | now are we saying the rpms have to be in testing for 4 weeks? or if someone happens to build the night before a push, it goes? 00:35:51 < mpdehaan> | umh, don't know about the quarterly business 00:35:53 * | knurd waits 00:36:01 < mpdehaan> | just 4 weeks sounds great 00:36:10 < knurd> | mmcgrath, we'd evaluate when we do it for the first time 00:36:23 < knurd> | mmcgrath, we can check the buildtime of the packages 00:36:29 < Jeff_S> | mmcgrath: I think they'd need to be in testing for some amount of time (which we can discuss) 00:36:34 < nirik> | mmcgrath: I would say we try and look at whats in testing and only move things that are: a) new package and b) been there 4 weeks or longer 00:36:54 < knurd> | should not be to hard, as we need to prepare it in a local test repo in any case, to make sure all deps are available 00:37:15 < mmcgrath> | just a matter of the scripts. It would be nice to keep this stuff as simple as possible though. 00:37:24 < knurd> | mmcgrath, +1 00:37:41 < mmcgrath> | thats one reason I like the current way, everyone knows what happens when and its easy to explain (even though we haven't actually done it yet really :) 00:37:42 < knurd> | especailly as we might need new scripts once we switch to bodhi 00:37:56 < mpdehaan> | X weeks is easy enough to explain :) 00:38:04 --- | stickster is now known as stickster_afk 00:38:42 < knurd> | well, I'd say we move on now, and finetune the details somewhen else 00:38:50 < nirik> | well, but it's not just X weeks everything pushes... so it's harder to explain. ;) 00:39:00 < mmcgrath> | except that if we only do a push every 4 weeks, some people will have RPMs in there for 7.9 weeks. 00:39:29 < nirik> | right. thats why I was thinking weekly, but not sure how much hassle it is. 00:39:29 < mmcgrath> | s/there/testing/ 00:40:00 < Jeff_S> | nirik: or bi-weekly 00:40:15 < knurd> | Jeff_S, let's seee how much work it is, and decide then 00:40:16 < nirik> | I can post to the list and see what people suggest? or we just figure out whats feasable on the current scripts? 00:40:26 < Jeff_S> | knurd: agreed 00:40:34 < Jeff_S> | but it really depends on the people doing the pushing IMO 00:40:42 < knurd> | nirik, let's try it once, and then decide or ask the list 00:40:46 < nirik> | ok. 00:41:09 * | knurd moves on now if nobody yells 00:41:23 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:41:28 < knurd> | anything else to discuss? 00:41:49 < mpdehaan> | I want a pony? 00:42:16 < knurd> | the weather sucks 00:42:17 < nirik> | I'm going to try and add security setup for epel... security team people are probibly greatfully accepted. ;) 00:42:50 < stahnma> | I am trying to get some more #rhel and #rhn people involved here in EPEL 00:43:05 < stahnma> | I just started today, so we'll see how it goes 00:43:22 < knurd> | nirik, "security setup" as in: people that check security lists and makre sure all issues releavant to EPEL get solved? 00:43:24 < nirik> | could we possibly get someone to write a redhat magazine article on epel? that might get to a lot more rhel folks... 00:43:40 < stahnma> | can anyone write for RH magazine? 00:43:44 < knurd> | nirik, mether indicated to write one weeks ago 00:43:46 < stahnma> | if so, I would happily write it 00:43:49 < knurd> | not sure if he ever did it 00:44:02 < mmcgrath> | stahnma: I think so, I've written for it twice. Send an email to gdk and ask for sure. 00:44:09 < stahnma> | ok 00:44:15 < nirik> | knurd: yeah, hopefully we can add it into the existing fedora setup. Make a audit/epel4 audit/epel5 files and track CVE's against epel packages... file bugs against them, make sure pushes happen for security, etc; 00:44:26 < knurd> | stahnma, and ask mether if he prepared something already 00:44:31 < stahnma> | ok 00:44:38 < nirik> | oh, another thing... did folks see my clamav post? 00:44:38 < knurd> | nirik, sounds great :) 00:45:24 < knurd> | nirik, saw it, but I have a mental filter for anything with clamav in the topic ;-) 00:45:33 < knurd> | well, no, I actually read it 00:45:57 < nirik> | yeah, I can take it over if no one else wants to... (I'd prefer not to), but if I do, I would want to diverge a lot from the current package... 00:46:04 < knurd> | and solving the problems with the packaging and compatapility with dag7rpmforge would be good 00:46:35 < knurd> | nirik, well, I'd prefer if stuff is similar in Fedora and EPEL 00:46:40 < nirik> | frankly, I would love to just use the dag version... perhaps even try and talk him into maintaining or something. 00:46:49 < nirik> | yeah, thats the issue... :( 00:46:50 < knurd> | but well, that won't work always, and this is such a case afaics 00:47:25 < knurd> | nirik, I think going to use dag's version is fine 00:47:27 < nirik> | clamav is also a security nightmare. ;( 00:47:44 < knurd> | (but I never looked to close at it in any case, so my opinion is not much worth) 00:48:05 < nirik> | well, I didn't get much reply on the mailing list. I guess I will wait a while and then move forward. 00:48:23 < knurd> | nirik, sounds good 00:48:25 --> | LetoTo (Paul Wouters) has joined #fedora-meeting 00:48:42 < knurd> | anything else? 00:49:03 * | nirik has nothing. 00:49:11 < Jeff_S> | nope 00:49:22 * | knurd will close the meeting in n 00:49:23 < mmcgrath> | nothing here 00:49:25 * | knurd will close the meeting in 30 00:49:27 <-- | LetoTo has left #fedora-meeting ( ) 00:49:41 * | knurd will close the meeting in 15 00:49:42 < stahnma> | thanks 00:49:46 <-- | stahnma has left #fedora-meeting ( "Time for something else....") 00:49:56 < knurd> | -- MARK -- Meeting end 00:49:56 --- | 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:50:00 < knurd> | thx everyone 00:50:02 < mmcgrath> | thanks knurd 00:50:13 < nirik> | thanks knurd

1 0

EPEL SIG Meetings now alternating between 17:00 and 23:00 UTC on Wednesdays
by Thorsten Leemhuis 04 Sep '07

04 Sep '07

Hi all! Just FYI, in the EPEL SIG meeting last week it was decided to have alternating meeting times for our weekly meetings on Wednesdays. In weeks with an even number (like this one, as it's the 36th week currently; the gnome panel date applet will tell you the current week number) we'll have the meetings at 23:00 UTC. In the weeks with and odd number we'll continue to have them at 17:00 UTC. Time are daylight saving times. During the winters we'll adjust them by one hour, to make sure the effective meeting time stays the same. So join us in the next meeting, which is scheduled for tomorrow at 23:00**UTC in #fedora-meeting. CU knurd P.S.: Note that this new meeting scheme doesn't revert the plan to try to get more stuff done on the list and less in the meetings. That still the plan, but we need to experiment a bit how to actually have a good workflow on the list (and quick meetings that still will be needed).

1 0

Meeting Tomorrow
by Jeff Sheltren 04 Sep '07

04 Sep '07

I'll be traveling tomorrow so I won't be able to make the meeting. Have fun without me! :) -Jeff

1 0

PHP extension in EL4
by Remi Collet 03 Sep '07

03 Sep '07

I've a look to PHP and extensions in EL4. We have a lot "PEAR" and PECL extensions in EPEL for EL5 which cannot go to EPEL for EL4 because of very old PHP and PEAR version. RHEL 4 users can use packages from RHWAS (Web Application Stack 1.0) ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHWAS/SRPMS ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4ES/en/RHWAS/SRPMS We found there - php-5.1.6 (as for RHEL5) - pear-1.4.11 CentOS 4 users can use packages from centosplus repository We found there all RHWAS RPM and a lot of RPM from Fedora/EPEL (i've read some changelog to verify) http://isoredirect.centos.org/centos/4/centosplus/SRPMS/ I think the packages from EPEL-5 could easily be maintain for an EPEL-4+ repository (using RHEL + RHWAS as references). I also think it's quite strange than CentOS repository is more complete than EPEL using only RHEL + Fedora community work... What must we do in EPEL-4 ? Regards

2 2

My packages for EPEL
by Tom Callaway 01 Sep '07

01 Sep '07

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

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

epel-devel September 2007