From buildsys at fedoraproject.org Sun Feb 1 11:48:07 2009 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 01 Feb 2009 11:48:07 -0000 Subject: Broken dependencies in EPEL - 2009-02-01 Message-ID: <20090201114807.464.59547@releng2.fedora.phx.redhat.com> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): UNKNOWN OWNER fail2ban - 0.6.2-3.el4.noarch hellanzb - 0.13-5.el5.noarch devrim AT fedoraproject.org postgresql-dbi-link - 2.0.0-3.el4.noarch postgresql-pgpoolAdmin - 1.0.0-7.el4.noarch python-psycopg2-zope - 2.0.8-1.el4.i386 python-psycopg2-zope - 2.0.8-1.el4.ppc python-psycopg2-zope - 2.0.8-1.el4.x86_64 gilboa AT fedoraproject.org cgdb - 0.6.4-2.el5.ppc ianweller AT fedoraproject.org mediawiki-ParserFunctions - 1.1.1-1.20080520svn35130.el4.noarch icon AT fedoraproject.org python-kiwi-gazpacho - 1.9.23-2.el5.noarch jgu AT fedoraproject.org shorewall-common - 4.0.15-1.el4.noarch shorewall-lite - 4.0.15-1.el4.noarch jjohnstn AT fedoraproject.org eclipse-cdt - 1:3.1.2-8.el5.ppc jkeating AT fedoraproject.org mock - 0.9.11-1.el4.noarch jwb AT fedoraproject.org bugzilla - 2.22.3-0.el4.noarch laxathom AT fedoraproject.org specto - 0.2.0-4.el4.noarch lkundrak AT fedoraproject.org NetworkManager-pptp - 0.6.4-2.el5.i386 NetworkManager-pptp - 0.6.4-2.el5.ppc NetworkManager-pptp - 0.6.4-2.el5.x86_64 thunderbird-lightning - 0.8-3.el5.2.ppc llaumgui AT fedoraproject.org backup-manager - 0.7.7-7.el5.noarch mdomsch AT fedoraproject.org dkms - 2.0.19.1-1.el5.noarch mmahut AT fedoraproject.org grc - 0.70-3.el5.noarch mtruch AT fedoraproject.org kst - 1.3.1-6.el5.i386 pertusus AT fedoraproject.org ooo2txt - 0.0.6-3.el5.noarch pwouters AT fedoraproject.org dnssec-conf - 1.13-2.el5.noarch ruben AT fedoraproject.org poweradmin - 2.1.2-2.el4.noarch spot AT fedoraproject.org tcl-tcludp - 1.0.8-1.el4.i386 tcl-tcludp - 1.0.8-1.el4.ppc tcl-tcludp - 1.0.8-1.el4.x86_64 tcl-tcludp - 1.0.8-1.el5.i386 tcl-tcludp - 1.0.8-1.el5.ppc tcl-tcludp - 1.0.8-1.el5.x86_64 tcl-tclvfs - 20080503-1.el4.i386 tcl-tclvfs - 20080503-1.el4.ppc tcl-tclvfs - 20080503-1.el4.x86_64 tcl-tclvfs - 20080503-1.el5.i386 tcl-tclvfs - 20080503-1.el5.ppc tcl-tclvfs - 20080503-1.el5.x86_64 tcl-tktreectrl - 2.2.8-1.el4.1.i386 tcl-tktreectrl - 2.2.8-1.el4.1.ppc tcl-tktreectrl - 2.2.8-1.el4.1.x86_64 tcl-tktreectrl - 2.2.8-1.el5.1.i386 tcl-tktreectrl - 2.2.8-1.el5.1.ppc tcl-tktreectrl - 2.2.8-1.el5.1.x86_64 srini AT fedoraproject.org ruby-openwsman - 2.1.0-1.el4.i386 ruby-openwsman - 2.1.0-1.el4.ppc ruby-openwsman - 2.1.0-1.el4.x86_64 steve AT fedoraproject.org amavisd-new - 2.4.5-1.el5.noarch cpanspec - 1.77-1.el5.noarch thias AT fedoraproject.org gnome-applet-sshmenu - 3.15-5.el5.noarch python-Coherence - 0.2.1-3.el4.noarch sshmenu - 3.15-5.el5.noarch tmraz AT fedoraproject.org vpnc - 0.4.0-2.el5.ppc trasher AT fedoraproject.org BackupPC - 3.1.0-2.el5.noarch ====================================================================== Broken packages in fedora-epel-4-ppc: shorewall-common-4.0.15-1.el4.noarch requires iptables shorewall-lite-4.0.15-1.el4.noarch requires iptables ====================================================================== Broken packages in fedora-epel-5-i386: NetworkManager-pptp-0.6.4-2.el5.i386 requires NetworkManager = 1:0.6.4 ====================================================================== Broken packages in fedora-epel-5-ppc: BackupPC-3.1.0-2.el5.noarch requires perl(Archive::Zip) NetworkManager-pptp-0.6.4-2.el5.ppc requires NetworkManager = 1:0.6.4 amavisd-new-2.4.5-1.el5.noarch requires perl(Archive::Zip) cgdb-0.6.4-2.el5.ppc requires gdb cpanspec-1.77-1.el5.noarch requires perl(Archive::Zip) dkms-2.0.19.1-1.el5.noarch requires kernel-devel eclipse-cdt-1:3.1.2-8.el5.ppc requires gdb ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip) thunderbird-lightning-0.8-3.el5.2.ppc requires thunderbird vpnc-0.4.0-2.el5.ppc requires kernel >= 0:2.4 ====================================================================== Broken packages in fedora-epel-5-x86_64: NetworkManager-pptp-0.6.4-2.el5.x86_64 requires NetworkManager = 1:0.6.4 ====================================================================== Broken packages in fedora-epel-testing-4-i386: bugzilla-2.22.3-0.el4.noarch requires perl(Template::Stash) mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.el4.noarch requires mediawiki >= 0:1.10 mock-0.9.11-1.el4.noarch requires python >= 0:2.4 mock-0.9.11-1.el4.noarch requires python-ctypes postgresql-dbi-link-2.0.0-3.el4.noarch requires perl-DBI >= 0:1.52 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php-pgsql >= 0:4.4.2 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php >= 0:4.4.2 poweradmin-2.1.2-2.el4.noarch requires php-pear(MDB2_Driver_pgsql) poweradmin-2.1.2-2.el4.noarch requires php-pear(MDB2_Driver_mysql) python-Coherence-0.2.1-3.el4.noarch requires python-twisted-core python-Coherence-0.2.1-3.el4.noarch requires python-nevow python-Coherence-0.2.1-3.el4.noarch requires python-twisted-web python-Coherence-0.2.1-3.el4.noarch requires SOAPpy python-psycopg2-zope-2.0.8-1.el4.i386 requires zope ruby-openwsman-2.1.0-1.el4.i386 requires ruby(abi) = 0:1.8 specto-0.2.0-4.el4.noarch requires notify-python tcl-tcludp-1.0.8-1.el4.i386 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el4.i386 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el4.1.i386 requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-4-ppc: bugzilla-2.22.3-0.el4.noarch requires perl(Template::Stash) fail2ban-0.6.2-3.el4.noarch requires iptables mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.el4.noarch requires mediawiki >= 0:1.10 mock-0.9.11-1.el4.noarch requires python >= 0:2.4 mock-0.9.11-1.el4.noarch requires python-ctypes postgresql-dbi-link-2.0.0-3.el4.noarch requires perl-DBI >= 0:1.52 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php-pgsql >= 0:4.4.2 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php >= 0:4.4.2 poweradmin-2.1.2-2.el4.noarch requires php-pear(MDB2_Driver_pgsql) poweradmin-2.1.2-2.el4.noarch requires php-pear(MDB2_Driver_mysql) python-Coherence-0.2.1-3.el4.noarch requires python-twisted-core python-Coherence-0.2.1-3.el4.noarch requires python-nevow python-Coherence-0.2.1-3.el4.noarch requires python-twisted-web python-Coherence-0.2.1-3.el4.noarch requires SOAPpy python-psycopg2-zope-2.0.8-1.el4.ppc requires zope ruby-openwsman-2.1.0-1.el4.ppc requires ruby(abi) = 0:1.8 specto-0.2.0-4.el4.noarch requires notify-python tcl-tcludp-1.0.8-1.el4.ppc requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el4.ppc requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el4.1.ppc requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-4-x86_64: bugzilla-2.22.3-0.el4.noarch requires perl(Template::Stash) mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.el4.noarch requires mediawiki >= 0:1.10 mock-0.9.11-1.el4.noarch requires python >= 0:2.4 mock-0.9.11-1.el4.noarch requires python-ctypes postgresql-dbi-link-2.0.0-3.el4.noarch requires perl-DBI >= 0:1.52 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php-pgsql >= 0:4.4.2 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php >= 0:4.4.2 poweradmin-2.1.2-2.el4.noarch requires php-pear(MDB2_Driver_pgsql) poweradmin-2.1.2-2.el4.noarch requires php-pear(MDB2_Driver_mysql) python-Coherence-0.2.1-3.el4.noarch requires python-twisted-core python-Coherence-0.2.1-3.el4.noarch requires python-nevow python-Coherence-0.2.1-3.el4.noarch requires python-twisted-web python-Coherence-0.2.1-3.el4.noarch requires SOAPpy python-psycopg2-zope-2.0.8-1.el4.x86_64 requires zope ruby-openwsman-2.1.0-1.el4.x86_64 requires ruby(abi) = 0:1.8 specto-0.2.0-4.el4.noarch requires notify-python tcl-tcludp-1.0.8-1.el4.x86_64 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el4.x86_64 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el4.1.x86_64 requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-5-i386: backup-manager-0.7.7-7.el5.noarch requires genisoimage dnssec-conf-1.13-2.el5.noarch requires unbound >= 0:1.1.1-7 gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2) gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2) grc-0.70-3.el5.noarch requires gnuradio hellanzb-0.13-5.el5.noarch requires python-twisted hellanzb-0.13-5.el5.noarch requires par2cmdline python-kiwi-gazpacho-1.9.23-2.el5.noarch requires gazpacho >= 0:0.6.6 sshmenu-3.15-5.el5.noarch requires ruby(gtk2) tcl-tcludp-1.0.8-1.el5.i386 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el5.i386 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el5.1.i386 requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-5-ppc: backup-manager-0.7.7-7.el5.noarch requires genisoimage dnssec-conf-1.13-2.el5.noarch requires unbound >= 0:1.1.1-7 gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2) gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2) grc-0.70-3.el5.noarch requires gnuradio hellanzb-0.13-5.el5.noarch requires python-twisted hellanzb-0.13-5.el5.noarch requires par2cmdline python-kiwi-gazpacho-1.9.23-2.el5.noarch requires gazpacho >= 0:0.6.6 sshmenu-3.15-5.el5.noarch requires ruby(gtk2) tcl-tcludp-1.0.8-1.el5.ppc requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el5.ppc requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el5.1.ppc requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-5-x86_64: backup-manager-0.7.7-7.el5.noarch requires genisoimage dnssec-conf-1.13-2.el5.noarch requires unbound >= 0:1.1.1-7 gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2) gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2) grc-0.70-3.el5.noarch requires gnuradio hellanzb-0.13-5.el5.noarch requires python-twisted hellanzb-0.13-5.el5.noarch requires par2cmdline kst-1.3.1-6.el5.i386 requires libkjsembed.so.1 python-kiwi-gazpacho-1.9.23-2.el5.noarch requires gazpacho >= 0:0.6.6 sshmenu-3.15-5.el5.noarch requires ruby(gtk2) tcl-tcludp-1.0.8-1.el5.x86_64 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el5.x86_64 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires tcl(abi) = 0:8.4 From wart at kobold.org Mon Feb 2 22:27:30 2009 From: wart at kobold.org (Michael Thomas) Date: Mon, 02 Feb 2009 14:27:30 -0800 Subject: Broken dependencies in EPEL - 2009-02-01 In-Reply-To: <20090201114807.464.59547@releng2.fedora.phx.redhat.com> References: <20090201114807.464.59547@releng2.fedora.phx.redhat.com> Message-ID: <49877352.6050609@kobold.org> Fedora Extras repoclosure wrote: > ====================================================================== > The results in this summary consider Test Updates! > ====================================================================== > [...] > tcl-tcludp-1.0.8-1.el5.i386 requires tcl = 0:8.4 > tcl-tclvfs-20080503-1.el5.i386 requires tcl = 0:8.4 > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires tcl(abi) = 0:8.4 In RHEL4/5, Tcl does not Provides: tcl(abi) = 8.4. That particular Provides statement is only in Fedora. These EPEL packages should drop the abi and simply: Requires: tcl --Wart From buildsys at fedoraproject.org Tue Feb 3 04:08:59 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 3 Feb 2009 04:08:59 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-03 Message-ID: <20090203040859.973BD1880F8@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 6 NEW mingw32-cairo-1.8.0-6.el5 : MinGW Windows Cairo library nrpe-2.12-6.el5 perl-Devel-StackTrace-1.20-1.el5 perl-Parse-RecDescent-1.96-1.el5 superiotool-0-0.15.20090202svn3827.el5 NEW udns-0.0.9-3.el5 : DNS resolver library for both synchronous and asynchronous DNS queries Packages built and released for Fedora EPEL testing/4: 3 nrpe-2.12-6.el4 poweradmin-2.1.2-2.el4.1 superiotool-0-0.15.20090202svn3827.el4 Changes in Fedora EPEL testing/5: mingw32-cairo-1.8.0-6.el5 ------------------------- * Mon Jan 26 2009 Richard W.M. Jones - 1.8.0-6 - Requires pkgconfig (Erik van Pienbroek). * Mon Jan 26 2009 Richard W.M. Jones - 1.8.0-5 - Don't need to remove extra pkgconfig file in install section. * Mon Jan 26 2009 Richard W.M. Jones - 1.8.0-4 - Disable freetype in configure so it doesn't break if freetype or fontconfig are actually installed. (Erik van Pienbroek). * Mon Jan 19 2009 Richard W.M. Jones - 1.8.0-3 - Include license file in documentation section. - Disable building static library to save time. - Remove BRs on mingw32-fontconfig and mingw32-freetype which are not needed on Win32. - Use _smp_mflags. - Added BRs mingw32-dlfcn, mingw32-iconv, mingw32-zlib. nrpe-2.12-6.el5 --------------- * Mon Feb 02 2009 Peter Lemenkov - 2.12-6 - Fixed BZ# 449174 - Clean up (in order to disable rpmlint warnings) * Sat Jan 17 2009 Tomas Mraz - 2.12-5 - rebuild with new openssl * Sun Dec 21 2008 Mike McGrath - 2.12-4 - Added some doc lines for ticket 477527 perl-Devel-StackTrace-1.20-1.el5 -------------------------------- * Sun Feb 01 2009 Xavier Lamien - 1.20-1 - Update release. perl-Parse-RecDescent-1.96-1.el5 -------------------------------- * Mon Feb 02 2009 Stepan Kasal - 1.96-1 - new upstream version * Wed Feb 27 2008 Tom "spot" Callaway - 1.95.1-5 - Rebuild for perl 5.10 (again) * Sun Jan 20 2008 Tom "spot" Callaway - 1.95.1-4 - rebuild for new perl * Wed Nov 14 2007 Robin Norwood - 1.95.1-3 - Apply fixes from package review: - Remove BR: perl - Use iconv to convert file to utf-8 - Include BR: perl(Test::Pod) - Fix old changelog entry - Resolves: bz#226274 * Tue Oct 16 2007 Tom "spot" Callaway - 1.95.1-2 - add BR: perl(version), perl(Test::More) * Tue Oct 16 2007 Tom "spot" Callaway - 1.95.1-1 - bump to 1.95.1 - correct license tag (now under perl license) - add BR: perl(ExtUtils::MakeMaker) * Fri Jul 20 2007 Robin Norwood - 1.94-6.fc8 - Bring fixes from EPEL build into F8 - Fix minor specfile issues - Package the docs as well superiotool-0-0.15.20090202svn3827.el5 -------------------------------------- * Mon Feb 02 2009 Peter Lemenkov 0-0.15.20090202svn3827 - Added register map based on NSC PC87392 datasheet. - Add detection support for ITE IT8228E, IT8711F, IT8722F, IT8761E, IT8780F, and Fintek F71863FG. udns-0.0.9-3.el5 ---------------- * Sun Sep 14 2008 Adrian Reber - 0.0.9-3 - removed rblcheck binary to resolve conflict with package rblcheck Changes in Fedora EPEL testing/4: nrpe-2.12-6.el4 --------------- * Mon Feb 02 2009 Peter Lemenkov - 2.12-6 - Fixed BZ# 449174 - Clean up (in order to disable rpmlint warnings) * Sat Jan 17 2009 Tomas Mraz - 2.12-5 - rebuild with new openssl * Sun Dec 21 2008 Mike McGrath - 2.12-4 - Added some doc lines for ticket 477527 poweradmin-2.1.2-2.el4.1 ------------------------ * Mon Feb 02 2009 Ruben Kerkhof - 2.1.2-2.el4.1 - mdb2 drivers for mysql and postgresql are not available on el4 superiotool-0-0.15.20090202svn3827.el4 -------------------------------------- * Mon Feb 02 2009 Peter Lemenkov 0-0.15.20090202svn3827 - Added register map based on NSC PC87392 datasheet. - Add detection support for ITE IT8228E, IT8711F, IT8722F, IT8761E, IT8780F, and Fintek F71863FG. From wolfy at nobugconsulting.ro Tue Feb 3 12:27:18 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 03 Feb 2009 14:27:18 +0200 Subject: to bump or not to bump Message-ID: <49883826.70204@nobugconsulting.ro> Hello I would like to hear some more opinions on the subject described in the thread started by https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is expressed in comment #9 and I am quite sure that any future update of the rawhide version might introduce the exact same problem again. I could, of course, keep using always the same release tag as in the corresponding rawhide version, but it looks a bit odd to me. Are there any guidelines on the subject of the correspondence of release numbers between epel and rawhide ? -- Manuel From pertusus at free.fr Tue Feb 3 13:33:48 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Feb 2009 14:33:48 +0100 Subject: to bump or not to bump In-Reply-To: <49883826.70204@nobugconsulting.ro> References: <49883826.70204@nobugconsulting.ro> Message-ID: <20090203133348.GD2539@free.fr> On Tue, Feb 03, 2009 at 02:27:18PM +0200, Manuel Wolfshant wrote: > Hello > > > I would like to hear some more opinions on the subject described in > the thread started by > https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is > expressed in comment #9 and I am quite sure that any future update of > the rawhide version might introduce the exact same problem again. I > could, of course, keep using always the same release tag as in the > corresponding rawhide version, but it looks a bit odd to me. Are there > any guidelines on the subject of the correspondence of release numbers > between epel and rawhide ? First, I think that the exact same guidelines should apply to fedora rawhide versus fedora releases. Then I think that it is better to sync releases when this really corresponds with the same package (same version, same functionality), and helps versionned requires. However, I don't think that bumps and builds should be done only for that. In the case at hand, the build should still be in epel testing, so a bump and a rebuild would do no harm and help requires, so I think it is fine to do it -- at least when there is a known case where it helps requires. In the end I don't think that this should be a guideline, more something that is left to the packager. So if you think that it is pointless to try to sync with the rawhide releases, you shouldn't do the bump and rebuild. -- Pat From fedora at leemhuis.info Tue Feb 3 13:41:28 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Feb 2009 14:41:28 +0100 Subject: to bump or not to bump In-Reply-To: <49883826.70204@nobugconsulting.ro> References: <49883826.70204@nobugconsulting.ro> Message-ID: <49884988.5030701@leemhuis.info> On 03.02.2009 13:27, Manuel Wolfshant wrote: > I would like to hear some more opinions on the subject described in > the thread started by > https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is > expressed in comment #9 and I am quite sure that any future update of > the rawhide version might introduce the exact same problem again. I'd tend to agree with some of what the reported outlines, but I'd say it's not important enough to justify a rebuild. > I > could, of course, keep using always the same release tag as in the > corresponding rawhide version, but it looks a bit odd to me. For me it's not odd; I'd even say it's the natural thing to do. Rawhide is the main "devel branch" for the spec file itself -- the version-release of the spec file for me is like a verison number of a regular software. Version numbers don't go backwards; thus if I'd (kind of) fork a spec file by picking it from rawhide and using it for another branch (EPEL in this case) then I'd normally leave the version-release as it is as long as %dist gets used in %release. But if maintainers in Rawhide and EPEL are different then I'd want to be on the safe site and would add a ".1" to %release and "rebuild for EPEL" to the changelog -- then it's obvious where this spec file exactly comes from and how they relate to each other -- that might be important to know for users and packagers. CU knurd From wolfy at nobugconsulting.ro Tue Feb 3 14:09:26 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 03 Feb 2009 16:09:26 +0200 Subject: to bump or not to bump In-Reply-To: <49884988.5030701@leemhuis.info> References: <49883826.70204@nobugconsulting.ro> <49884988.5030701@leemhuis.info> Message-ID: <49885016.1070205@nobugconsulting.ro> Thorsten Leemhuis wrote: > On 03.02.2009 13:27, Manuel Wolfshant wrote: >> I would like to hear some more opinions on the subject described >> in the thread started by >> https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is >> expressed in comment #9 and I am quite sure that any future update of >> the rawhide version might introduce the exact same problem again. > > I'd tend to agree with some of what the reported outlines, but I'd say > it's not important enough to justify a rebuild. > >> I could, of course, keep using always the same release tag as in the >> corresponding rawhide version, but it looks a bit odd to me. > > For me it's not odd; I'd even say it's the natural thing to do. > > Rawhide is the main "devel branch" for the spec file itself -- the > version-release of the spec file for me is like a verison number of a > regular software. Version numbers don't go backwards; thus if I'd > (kind of) fork a spec file by picking it from rawhide and using it for > another branch (EPEL in this case) then I'd normally leave the > version-release as it is as long as %dist gets used in %release. > > But if maintainers in Rawhide and EPEL are different then I'd want to > be on the safe site and would add a ".1" to %release and "rebuild for > EPEL" to the changelog -- then it's obvious where this spec file > exactly comes from and how they relate to each other -- that might be > important to know for users and packagers. > Maintainers are different in EPEL and rawhide. I try to sync with Ville before rebuilding in EPEL, but I am not going to keep his pace. My intention is to do as few rebuilds as sensible, integrating the differences accumulated over time. Current bump to 0.85 was mainly triggered by the release of RHEL 5.3 and integrated a few changes which were commited by Ville to CVS, were not yet included in any version built in koji but about which he told me in a private mail that might be good to include. Changes which were properly documented by me in the changelog. From fedora at leemhuis.info Tue Feb 3 14:31:33 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Feb 2009 15:31:33 +0100 Subject: to bump or not to bump In-Reply-To: <49885016.1070205@nobugconsulting.ro> References: <49883826.70204@nobugconsulting.ro> <49884988.5030701@leemhuis.info> <49885016.1070205@nobugconsulting.ro> Message-ID: <49885545.7010300@leemhuis.info> On 03.02.2009 15:09, Manuel Wolfshant wrote: > Thorsten Leemhuis wrote: >> On 03.02.2009 13:27, Manuel Wolfshant wrote: > > Maintainers are different in EPEL and rawhide. I try to sync with Ville > before rebuilding in EPEL, but I am not going to keep his pace. Wasn't likely obvious from my mail, as I didn't go much into that part of the discussion. But I agree with this -- the EPEL branch should just sync now and then. But nevertheless I'd say the version-release should indicate where from which rawhide spec file the spec in EPEL comes from. CU knurd From ville.skytta at iki.fi Wed Feb 4 20:17:53 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 4 Feb 2009 22:17:53 +0200 Subject: to bump or not to bump In-Reply-To: <49885016.1070205@nobugconsulting.ro> References: <49883826.70204@nobugconsulting.ro> <49884988.5030701@leemhuis.info> <49885016.1070205@nobugconsulting.ro> Message-ID: <200902042217.53560.ville.skytta@iki.fi> On Tuesday 03 February 2009, Manuel Wolfshant wrote: > Current bump to 0.85 was mainly > triggered by the release of RHEL 5.3 and integrated a few changes which > were commited by Ville to CVS, were not yet included in any version > built in koji but about which he told me in a private mail that might be > good to include. No strong opinions here, but in this particular case I would have personally put it to EPEL as 0.85-3%{?dist}.1. "3" for the reasons outlined by others, and .1 appended because it's actually a bit ahead of Fedora's 3%{?dist}. From smooge at gmail.com Wed Feb 4 22:42:30 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 4 Feb 2009 15:42:30 -0700 Subject: Alpine-2.0 for RHEL-4 Message-ID: <80d7e4090902041442j583844aar5e6a45a7dc26d198@mail.gmail.com> I saw that alpine-2.0 is in for RHEL-5 but not for EL-4. Is there a reason as it not working? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From wolfy at nobugconsulting.ro Thu Feb 5 11:32:03 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 05 Feb 2009 13:32:03 +0200 Subject: to bump or not to bump In-Reply-To: <200902042217.53560.ville.skytta@iki.fi> References: <49883826.70204@nobugconsulting.ro> <49884988.5030701@leemhuis.info> <49885016.1070205@nobugconsulting.ro> <200902042217.53560.ville.skytta@iki.fi> Message-ID: <498ACE33.9030703@nobugconsulting.ro> Ville Skytt? wrote: > On Tuesday 03 February 2009, Manuel Wolfshant wrote: > > >> Current bump to 0.85 was mainly >> triggered by the release of RHEL 5.3 and integrated a few changes which >> were commited by Ville to CVS, were not yet included in any version >> built in koji but about which he told me in a private mail that might be >> good to include. >> > > No strong opinions here, but in this particular case I would have personally > put it to EPEL as 0.85-3%{?dist}.1. "3" for the reasons outlined by others, > and .1 appended because it's actually a bit ahead of Fedora's 3%{?dist}. > Thank you all for your advices. I have followed Knurd's/Ville's suggestions and bumped released to 3.1 manuel From rdieter at math.unl.edu Thu Feb 5 15:40:38 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Feb 2009 09:40:38 -0600 Subject: Alpine-2.0 for RHEL-4 References: <80d7e4090902041442j583844aar5e6a45a7dc26d198@mail.gmail.com> Message-ID: Stephen John Smoogen wrote: > I saw that alpine-2.0 is in for RHEL-5 but not for EL-4. Is there a > reason as it not working? Shouldn't be. I just haven't any EL-4 boxen to test, but if someone else would be willing to do that, I'd be happy to build it. -- Rex From rdieter at math.unl.edu Thu Feb 5 15:53:12 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Feb 2009 09:53:12 -0600 Subject: Alpine-2.0 for RHEL-4 References: <80d7e4090902041442j583844aar5e6a45a7dc26d198@mail.gmail.com> Message-ID: Rex Dieter wrote: > Stephen John Smoogen wrote: > >> I saw that alpine-2.0 is in for RHEL-5 but not for EL-4. Is there a >> reason as it not working? > > Shouldn't be. I just haven't any EL-4 boxen to test, but if someone else > would be willing to do that, I'd be happy to build it. fwiw, building now, http://buildsys.fedoraproject.org/build-status/job.psp?uid=1374 (totally forgot that we had an older alpine-1.10 build there). -- Rex From wolfy at nobugconsulting.ro Thu Feb 5 16:56:17 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 05 Feb 2009 18:56:17 +0200 Subject: Alpine-2.0 for RHEL-4 In-Reply-To: References: <80d7e4090902041442j583844aar5e6a45a7dc26d198@mail.gmail.com> Message-ID: <498B1A31.4010206@nobugconsulting.ro> On 02/05/2009 05:53 PM, Rex Dieter wrote: > Rex Dieter wrote: > > >> Stephen John Smoogen wrote: >> >> >>> I saw that alpine-2.0 is in for RHEL-5 but not for EL-4. Is there a >>> reason as it not working? >>> >> Shouldn't be. I just haven't any EL-4 boxen to test, but if someone else >> would be willing to do that, I'd be happy to build it. >> > > fwiw, building now, > http://buildsys.fedoraproject.org/build-status/job.psp?uid=1374 > > (totally forgot that we had an older alpine-1.10 build there). > i've just done a minimal test (setup preferences + sending a mail) and it worked OK From smooge at gmail.com Thu Feb 5 17:02:01 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 5 Feb 2009 10:02:01 -0700 Subject: Alpine-2.0 for RHEL-4 In-Reply-To: References: <80d7e4090902041442j583844aar5e6a45a7dc26d198@mail.gmail.com> Message-ID: <80d7e4090902050902w766160ban87aae6a3d1a3cca3@mail.gmail.com> On Thu, Feb 5, 2009 at 8:40 AM, Rex Dieter wrote: > Stephen John Smoogen wrote: > >> I saw that alpine-2.0 is in for RHEL-5 but not for EL-4. Is there a >> reason as it not working? > > Shouldn't be. I just haven't any EL-4 boxen to test, but if someone else > would be willing to do that, I'd be happy to build it. > I built it out of CVS via mockbuild last night and tested it on our boxes. Worked for me. Need an 'official' one to say it really works. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tdiehl at rogueind.com Thu Feb 5 22:10:13 2009 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 5 Feb 2009 17:10:13 -0500 (EST) Subject: Alpine-2.0 for RHEL-4 In-Reply-To: <80d7e4090902050902w766160ban87aae6a3d1a3cca3@mail.gmail.com> References: <80d7e4090902041442j583844aar5e6a45a7dc26d198@mail.gmail.com> <80d7e4090902050902w766160ban87aae6a3d1a3cca3@mail.gmail.com> Message-ID: On Thu, 5 Feb 2009, Stephen John Smoogen wrote: > On Thu, Feb 5, 2009 at 8:40 AM, Rex Dieter wrote: >> Stephen John Smoogen wrote: >> >>> I saw that alpine-2.0 is in for RHEL-5 but not for EL-4. Is there a >>> reason as it not working? >> >> Shouldn't be. I just haven't any EL-4 boxen to test, but if someone else >> would be willing to do that, I'd be happy to build it. >> > > I built it out of CVS via mockbuild last night and tested it on our > boxes. Worked for me. Need an 'official' one to say it really works. Just curious, if you select, for instance a pdf attachment to view in alpine does it display or do you get a file not found error? When I do that the pdf viewer opens but I get a file not found error. If this works for you, does anyone know how to troubleshoot this? Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From buildsys at fedoraproject.org Fri Feb 6 17:34:32 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Feb 2009 17:34:32 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-06 Message-ID: <20090206173432.652CA1880BF@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 14 NEW celt-0.5.1-2.el5 : An audio codec for use in low-delay speech and audio communication NEW cgit-0.8.2-1.el5 : A fast webinterface for git dbmail-2.2.11-1.el5 NEW dissy-8-2.el5 : Graphical frontend to the objdump disassembler NEW hatools-2.00-1.el5 : Improved shell scripting in High Availability environment htop-0.8.1-3.el5 NEW jabberd-2.2.5-1.el5 : OpenSource server implementation of the Jabber protocols NEW mcabber-0.9.9-1.el5 : Console Jabber instant messaging client mock-0.9.14-1.el5 nettee-0.1.9.1-1.el5 NEW perl-Net-Stomp-0.34-2.el5 : Stomp client module for Perl NEW php-pecl-imagick-2.2.1-3.el5 : Provides a wrapper to the ImageMagick library rpmlint-0.85-3.el5.1 trac-0.10.5-2.el5 Packages built and released for Fedora EPEL testing/4: 6 alpine-2.00-1.el4 duplicity-0.5.06-1.el4 NEW fvwm-2.5.26-2.el4.2 : Highly configurable multiple virtual desktop window manager NEW hatools-2.00-1.el4 : Improved shell scripting in High Availability environment htop-0.8.1-3.el4 mock-0.9.14-1.el4 Changes in Fedora EPEL testing/5: celt-0.5.1-2.el5 ---------------- * Mon Feb 02 2009 Peter Robinson 0.5.1-2 - Updates for package review cgit-0.8.2-1.el5 ---------------- * Thu Feb 05 2009 Todd Zullinger - 0.8.2-1 - Update to 0.8.2 - Drop upstreamed Makefile patch - Build for EL-5 * Mon Jan 12 2009 Todd Zullinger - 0.8.1-1 - Initial package dbmail-2.2.11-1.el5 ------------------- * Tue Feb 03 2009 Bernard Johnson - 2.2.11-1 - v 2.2.11 - updated summaries - fix bug in dbmail-pop3d init script * Mon Jul 07 2008 Tom "spot" Callaway - 2.2.9-2 - fix conditional comparison dissy-8-2.el5 ------------- * Wed Feb 06 2008 Lubomir Rintel - 8-2 - Fix about dialog close hatools-2.00-1.el5 ------------------ * Thu Jan 29 2009 Oliver Falk - 2.00-1 - Initial specfile htop-0.8.1-3.el5 ---------------- * Thu Feb 05 2009 Adam Miller - 0.8.1-3 - "Tree view doesn't work with threads hidden" fixed (#481072) - Rafal issued the fix, this is just the update and build for EPEL jabberd-2.2.5-1.el5 ------------------- * Tue Feb 03 2009 Adrian Reber - 2.2.5-1 - updated to 2.2.5 * Fri Jan 23 2009 Bernie Innocenti - 2.2.4-2 - Replace /etc/sysconfig/jabberd on upgrade to drop obsolete daemons - Rebuilt for new libmysqlclient mcabber-0.9.9-1.el5 ------------------- * Sun Oct 12 2008 Michael Fleming - 0.9.9-1 - Upgrade to 0.9.9 - Revert to using OpenSSL (#bz 389481) mock-0.9.14-1.el5 ----------------- * Mon Feb 02 2009 Clark Williams - 0.9.14-1 - logging cleanup (mikem) - add new exception for resultdir not available (mebrown) - moved mock cache dir to /var/cache/mock (williams) - added version variable and version banner to logs (williams) - removed import of popen2 to whack deprecated message (williams) - prevent disabling ccache on epel-5 (tmz) - added configs for sparc and s390 (dgilmore) - fixed git log command used in build (tmz) - added copy of spec/sources for building srpms (mebrown) - changed unlink to rmdir (mebrown) - set HOME directory globally (mikeb) - commented out privlege drop in --copyin (williams) * Thu Nov 06 2008 Jesse Keating - 0.9.13-1 - Add configs for F10 (jkeating) * Tue Oct 14 2008 Clark Williams - 0.9.12-1 - internal setarch support for s390/s390x (mikem) - Refer to the .newkey location of current Fedora 8/9 updates. (jkeating) - [bz458234] Picked up corrected patch (pmatilai) nettee-0.1.9.1-1.el5 -------------------- * Wed Feb 04 2009 Fabian Affolter - 0.1.9.1-1 - Updated to upstream version 0.1.9.1 perl-Net-Stomp-0.34-2.el5 ------------------------- * Tue Feb 03 2009 Lubomir Rintel (Good Data) 0.34-2 - Fix description wording (thanks to Manuel Wolfshant) * Fri Jan 30 2009 Lubomir Rintel (Good Data) 0.34-1 - Specfile autogenerated by cpanspec 1.77. - Fixed BuildRequires php-pecl-imagick-2.2.1-3.el5 ---------------------------- * Sun Jan 11 2009 Pavel Alexeev - 2.2.1-3 - All modifications in this release inspired by Fedora review by Remi Collet. - Add versions to BR for php-devel and ImageMagick-devel - Remove -n option from %setup which was excessive with -c - Module install/uninstall actions surround with %if 0 ... %endif - Add Provides: php-pecl(imagick) = 2.2.1 rpmlint-0.85-3.el5.1 -------------------- * Thu Feb 05 2009 Manuel Wolfshant - 0.85-3.1 - Bump release to express relationship with the rawhide version. No other changes. trac-0.10.5-2.el5 ----------------- * Thu Feb 05 2009 Jesse Keating - 0.10.5-2 - Add a patch to deal with GeneratorExit, which is a python-2.5ism (#458236) Changes in Fedora EPEL testing/4: alpine-2.00-1.el4 ----------------- * Wed Aug 27 2008 Rex Dieter 2.00-1 - alpine-2.00 (#460332) duplicity-0.5.06-1.el4 ---------------------- * Sun Jan 25 2009 Robert Scheck 0.5.06-1 - Upgrade to 0.5.06 (#481489) fvwm-2.5.26-2.el4.2 ------------------- * Thu Feb 05 2009 Adam Goode - 2.5.26-2.2 - Change Requires for EL-4 * Thu Feb 05 2009 Adam Goode - 2.5.26-2.1 - Change BuildRequires for EL-4 hatools-2.00-1.el4 ------------------ * Thu Jan 29 2009 Oliver Falk - 2.00-1 - Initial specfile htop-0.8.1-3.el4 ---------------- * Thu Feb 05 2009 Adam Miller - 0.8.1-3 - "Tree view doesn't work with threads hidden" fixed (#481072) - Rafal issued the fix, this is just the update and build for EPEL mock-0.9.14-1.el4 ----------------- * Mon Feb 02 2009 Clark Williams - 0.9.14-1 - logging cleanup (mikem) - add new exception for resultdir not available (mebrown) - moved mock cache dir to /var/cache/mock (williams) - added version variable and version banner to logs (williams) - removed import of popen2 to whack deprecated message (williams) - prevent disabling ccache on epel-5 (tmz) - added configs for sparc and s390 (dgilmore) - fixed git log command used in build (tmz) - added copy of spec/sources for building srpms (mebrown) - changed unlink to rmdir (mebrown) - set HOME directory globally (mikeb) - commented out privlege drop in --copyin (williams) * Thu Nov 06 2008 Jesse Keating - 0.9.13-1 - Add configs for F10 (jkeating) * Tue Oct 14 2008 Clark Williams - 0.9.12-1 - internal setarch support for s390/s390x (mikem) - Refer to the .newkey location of current Fedora 8/9 updates. (jkeating) - [bz458234] Picked up corrected patch (pmatilai) From buildsys at fedoraproject.org Sun Feb 8 11:49:20 2009 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 08 Feb 2009 11:49:20 -0000 Subject: Broken dependencies in EPEL - 2009-02-08 Message-ID: <20090208114920.25456.4367@releng2.fedora.phx.redhat.com> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): UNKNOWN OWNER bugzilla - 2.22.3-0.el4.noarch fail2ban - 0.6.2-3.el4.noarch hellanzb - 0.13-5.el5.noarch devrim AT fedoraproject.org postgresql-dbi-link - 2.0.0-3.el4.noarch postgresql-pgpoolAdmin - 1.0.0-7.el4.noarch python-psycopg2-zope - 2.0.8-1.el4.i386 python-psycopg2-zope - 2.0.8-1.el4.ppc python-psycopg2-zope - 2.0.8-1.el4.x86_64 gilboa AT fedoraproject.org cgdb - 0.6.4-2.el5.ppc ianweller AT fedoraproject.org mediawiki-ParserFunctions - 1.1.1-1.20080520svn35130.el4.noarch icon AT fedoraproject.org python-kiwi-gazpacho - 1.9.23-2.el5.noarch jgu AT fedoraproject.org shorewall-common - 4.0.15-1.el4.noarch shorewall-lite - 4.0.15-1.el4.noarch jjohnstn AT fedoraproject.org eclipse-cdt - 1:3.1.2-8.el5.ppc jkeating AT fedoraproject.org mock - 0.9.14-1.el4.noarch laxathom AT fedoraproject.org specto - 0.2.0-4.el4.noarch lkundrak AT fedoraproject.org NetworkManager-pptp - 0.6.4-2.el5.i386 NetworkManager-pptp - 0.6.4-2.el5.ppc NetworkManager-pptp - 0.6.4-2.el5.x86_64 thunderbird-lightning - 0.8-3.el5.2.ppc llaumgui AT fedoraproject.org backup-manager - 0.7.7-7.el5.noarch mdomsch AT fedoraproject.org dkms - 2.0.19.1-1.el5.noarch mmahut AT fedoraproject.org grc - 0.70-3.el5.noarch mtruch AT fedoraproject.org kst - 1.3.1-6.el5.i386 pertusus AT fedoraproject.org ooo2txt - 0.0.6-3.el5.noarch pwouters AT fedoraproject.org dnssec-conf - 1.13-2.el5.noarch spot AT fedoraproject.org tcl-tcludp - 1.0.8-1.el4.i386 tcl-tcludp - 1.0.8-1.el4.ppc tcl-tcludp - 1.0.8-1.el4.x86_64 tcl-tcludp - 1.0.8-1.el5.i386 tcl-tcludp - 1.0.8-1.el5.ppc tcl-tcludp - 1.0.8-1.el5.x86_64 tcl-tclvfs - 20080503-1.el4.i386 tcl-tclvfs - 20080503-1.el4.ppc tcl-tclvfs - 20080503-1.el4.x86_64 tcl-tclvfs - 20080503-1.el5.i386 tcl-tclvfs - 20080503-1.el5.ppc tcl-tclvfs - 20080503-1.el5.x86_64 tcl-tktreectrl - 2.2.8-1.el4.1.i386 tcl-tktreectrl - 2.2.8-1.el4.1.ppc tcl-tktreectrl - 2.2.8-1.el4.1.x86_64 tcl-tktreectrl - 2.2.8-1.el5.1.i386 tcl-tktreectrl - 2.2.8-1.el5.1.ppc tcl-tktreectrl - 2.2.8-1.el5.1.x86_64 srini AT fedoraproject.org ruby-openwsman - 2.1.0-1.el4.i386 ruby-openwsman - 2.1.0-1.el4.ppc ruby-openwsman - 2.1.0-1.el4.x86_64 steve AT fedoraproject.org amavisd-new - 2.4.5-1.el5.noarch cpanspec - 1.77-1.el5.noarch thias AT fedoraproject.org gnome-applet-sshmenu - 3.15-5.el5.noarch python-Coherence - 0.2.1-3.el4.noarch sshmenu - 3.15-5.el5.noarch tmraz AT fedoraproject.org vpnc - 0.4.0-2.el5.ppc trasher AT fedoraproject.org BackupPC - 3.1.0-2.el5.noarch ====================================================================== Broken packages in fedora-epel-4-ppc: shorewall-common-4.0.15-1.el4.noarch requires iptables shorewall-lite-4.0.15-1.el4.noarch requires iptables ====================================================================== Broken packages in fedora-epel-5-i386: NetworkManager-pptp-0.6.4-2.el5.i386 requires NetworkManager = 1:0.6.4 ====================================================================== Broken packages in fedora-epel-5-ppc: BackupPC-3.1.0-2.el5.noarch requires perl(Archive::Zip) NetworkManager-pptp-0.6.4-2.el5.ppc requires NetworkManager = 1:0.6.4 amavisd-new-2.4.5-1.el5.noarch requires perl(Archive::Zip) cgdb-0.6.4-2.el5.ppc requires gdb cpanspec-1.77-1.el5.noarch requires perl(Archive::Zip) dkms-2.0.19.1-1.el5.noarch requires kernel-devel eclipse-cdt-1:3.1.2-8.el5.ppc requires gdb ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip) thunderbird-lightning-0.8-3.el5.2.ppc requires thunderbird vpnc-0.4.0-2.el5.ppc requires kernel >= 0:2.4 ====================================================================== Broken packages in fedora-epel-5-x86_64: NetworkManager-pptp-0.6.4-2.el5.x86_64 requires NetworkManager = 1:0.6.4 ====================================================================== Broken packages in fedora-epel-testing-4-i386: bugzilla-2.22.3-0.el4.noarch requires perl(Template::Stash) mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.el4.noarch requires mediawiki >= 0:1.10 mock-0.9.14-1.el4.noarch requires python >= 0:2.4 mock-0.9.14-1.el4.noarch requires python-ctypes postgresql-dbi-link-2.0.0-3.el4.noarch requires perl-DBI >= 0:1.52 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php-pgsql >= 0:4.4.2 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php >= 0:4.4.2 python-Coherence-0.2.1-3.el4.noarch requires python-twisted-core python-Coherence-0.2.1-3.el4.noarch requires python-nevow python-Coherence-0.2.1-3.el4.noarch requires python-twisted-web python-Coherence-0.2.1-3.el4.noarch requires SOAPpy python-psycopg2-zope-2.0.8-1.el4.i386 requires zope ruby-openwsman-2.1.0-1.el4.i386 requires ruby(abi) = 0:1.8 specto-0.2.0-4.el4.noarch requires notify-python tcl-tcludp-1.0.8-1.el4.i386 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el4.i386 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el4.1.i386 requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-4-ppc: bugzilla-2.22.3-0.el4.noarch requires perl(Template::Stash) fail2ban-0.6.2-3.el4.noarch requires iptables mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.el4.noarch requires mediawiki >= 0:1.10 mock-0.9.14-1.el4.noarch requires python >= 0:2.4 mock-0.9.14-1.el4.noarch requires python-ctypes postgresql-dbi-link-2.0.0-3.el4.noarch requires perl-DBI >= 0:1.52 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php-pgsql >= 0:4.4.2 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php >= 0:4.4.2 python-Coherence-0.2.1-3.el4.noarch requires python-twisted-core python-Coherence-0.2.1-3.el4.noarch requires python-nevow python-Coherence-0.2.1-3.el4.noarch requires python-twisted-web python-Coherence-0.2.1-3.el4.noarch requires SOAPpy python-psycopg2-zope-2.0.8-1.el4.ppc requires zope ruby-openwsman-2.1.0-1.el4.ppc requires ruby(abi) = 0:1.8 specto-0.2.0-4.el4.noarch requires notify-python tcl-tcludp-1.0.8-1.el4.ppc requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el4.ppc requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el4.1.ppc requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-4-x86_64: bugzilla-2.22.3-0.el4.noarch requires perl(Template::Stash) mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.el4.noarch requires mediawiki >= 0:1.10 mock-0.9.14-1.el4.noarch requires python >= 0:2.4 mock-0.9.14-1.el4.noarch requires python-ctypes postgresql-dbi-link-2.0.0-3.el4.noarch requires perl-DBI >= 0:1.52 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php-pgsql >= 0:4.4.2 postgresql-pgpoolAdmin-1.0.0-7.el4.noarch requires php >= 0:4.4.2 python-Coherence-0.2.1-3.el4.noarch requires python-twisted-core python-Coherence-0.2.1-3.el4.noarch requires python-nevow python-Coherence-0.2.1-3.el4.noarch requires python-twisted-web python-Coherence-0.2.1-3.el4.noarch requires SOAPpy python-psycopg2-zope-2.0.8-1.el4.x86_64 requires zope ruby-openwsman-2.1.0-1.el4.x86_64 requires ruby(abi) = 0:1.8 specto-0.2.0-4.el4.noarch requires notify-python tcl-tcludp-1.0.8-1.el4.x86_64 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el4.x86_64 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el4.1.x86_64 requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-5-i386: backup-manager-0.7.7-7.el5.noarch requires genisoimage dnssec-conf-1.13-2.el5.noarch requires unbound >= 0:1.1.1-7 gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2) gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2) grc-0.70-3.el5.noarch requires gnuradio hellanzb-0.13-5.el5.noarch requires python-twisted hellanzb-0.13-5.el5.noarch requires par2cmdline python-kiwi-gazpacho-1.9.23-2.el5.noarch requires gazpacho >= 0:0.6.6 sshmenu-3.15-5.el5.noarch requires ruby(gtk2) tcl-tcludp-1.0.8-1.el5.i386 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el5.i386 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el5.1.i386 requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-5-ppc: backup-manager-0.7.7-7.el5.noarch requires genisoimage dnssec-conf-1.13-2.el5.noarch requires unbound >= 0:1.1.1-7 gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2) gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2) grc-0.70-3.el5.noarch requires gnuradio hellanzb-0.13-5.el5.noarch requires python-twisted hellanzb-0.13-5.el5.noarch requires par2cmdline python-kiwi-gazpacho-1.9.23-2.el5.noarch requires gazpacho >= 0:0.6.6 sshmenu-3.15-5.el5.noarch requires ruby(gtk2) tcl-tcludp-1.0.8-1.el5.ppc requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el5.ppc requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el5.1.ppc requires tcl(abi) = 0:8.4 ====================================================================== Broken packages in fedora-epel-testing-5-x86_64: backup-manager-0.7.7-7.el5.noarch requires genisoimage dnssec-conf-1.13-2.el5.noarch requires unbound >= 0:1.1.1-7 gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2) gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2) grc-0.70-3.el5.noarch requires gnuradio hellanzb-0.13-5.el5.noarch requires python-twisted hellanzb-0.13-5.el5.noarch requires par2cmdline kst-1.3.1-6.el5.i386 requires libkjsembed.so.1 python-kiwi-gazpacho-1.9.23-2.el5.noarch requires gazpacho >= 0:0.6.6 sshmenu-3.15-5.el5.noarch requires ruby(gtk2) tcl-tcludp-1.0.8-1.el5.x86_64 requires tcl = 0:8.4 tcl-tclvfs-20080503-1.el5.x86_64 requires tcl = 0:8.4 tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires tcl(abi) = 0:8.4 From fedora at leemhuis.info Sun Feb 8 12:46:14 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Feb 2009 13:46:14 +0100 Subject: Broken deps report incomplete? (was: Re: Broken dependencies in EPEL - 2009-02-08) In-Reply-To: <20090208114920.25456.4367@releng2.fedora.phx.redhat.com> References: <20090208114920.25456.4367@releng2.fedora.phx.redhat.com> Message-ID: <498ED416.9010503@leemhuis.info> Hi! On 08.02.2009 12:49, Fedora Extras repoclosure wrote: > ====================================================================== > The results in this summary consider Test Updates! > > ====================================================================== > Broken packages in fedora-epel-5-i386: > > NetworkManager-pptp-0.6.4-2.el5.i386 requires NetworkManager = 1:0.6.4 I just prepared a testing -> stable move and noticed a few broken deps in epel5 that are not in this list. --- $ setarch i686 repoclosure -n -r centos${EPELVER} -r epel${EPELVER} | grep -A 2 'from epel5' package: gyachi-plugin-photo_album-1.1.46-4.el5.i386 from epel5 unresolved deps: gyachi = 0:1.1.46-4.el5 -- package: php-pear-Image-Graph-roman-0.7.2-2.el5.noarch from epel5 unresolved deps: php-pear-Image-Graph = 0:0.7.2-2.el5 package: php-pear-Image-Graph-words-0.7.2-2.el5.noarch from epel5 unresolved deps: php-pear-Image-Graph = 0:0.7.2-2.el5 package: python-fedora-infrastructure-0.2.90.22-1.el5.noarch from epel5 unresolved deps: python-fedora = 0:0.2.90.22-1.el5 package: revisor-delta-2.0.5.1-4.el5.noarch from epel5 unresolved deps: revisor = 0:2.0.5.1-4.el5 package: revisor-jigdo-2.0.5.1-4.el5.noarch from epel5 unresolved deps: revisor = 0:2.0.5.1-4.el5 package: revisor-rebrand-2.0.5.1-4.el5.noarch from epel5 unresolved deps: revisor = 0:2.0.5.1-4.el5 package: revisor-virt-2.0.5.1-4.el5.noarch from epel5 unresolved deps: revisor = 0:2.0.5.1-4.el5 package: vala-docs-0.1.5-5.el5.i386 from epel5 unresolved deps: vala = 0:0.1.5-5.el5 --- Took a closer look and found that for example the revisor version that is missing for revisor-* above is actually in the repo: http://ftp-stud.fht-esslingen.de/pub/Mirrors/epel/5/i386/revisor-2.0.5.1-4.el5.noarch.rpm But there is also a newer one which thus breaks the deps: http://ftp-stud.fht-esslingen.de/pub/Mirrors/epel/5/i386/revisor-2.0.5.2-1.el5.noarch.rpm Anyone any idea why the script doesn't detect this? Or am I missing something? CU knurd From fedora at leemhuis.info Sun Feb 8 12:51:18 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Feb 2009 13:51:18 +0100 Subject: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside Message-ID: <498ED546.3060806@leemhuis.info> Hi all! I prepared the next testing -> stable move for EPEL4 and EPEL5. I plan to actually do the move on 20090212 at around 06:00 UTC. If one of your packages is in the attached "tobemoved-(s,)rpms-{4,5}" list and you don't want it moved please tell me soon or it'll be to late soon. = Packages that'll be moved == Here is the list of packages that will be moved: == EPEL4 == alpine augeas beesu cas cobbler collectl ctapi-cyberjack digitemp duplicity erlang fail2ban freehoo fvwm ganglia gromacs hatools htop jasper koan libmp4v2 libsieve libsigsegv munin net6 nikto nopaste nrpe obby ocsinventory pbzip2 perl-Convert-UUlib perl-Crypt-OpenSSL-Bignum perl-Crypt-OpenSSL-Random perl-Crypt-OpenSSL-RSA perl-Filesys-Df perl-libwhisker2 perl-Math-FFT perl-MD5 perl-Net-LibIDN perl-String-CRC32 perl-Test-Pod-Coverage perl-XML-Filter-BufferText poweradmin python-boto python-dateutil python-ldaphelper R-car superiotool supybot tbcload tclchecker tclcompiler tcldebugger tclparser tclpro txt2tags wine == EPEL5 == amarok augeas autotrust beesu bind-to-tinydns bodhi botan cas cobbler collectl crm114 dbmail digitemp dirac docbook2X dtc duplicity ejabberd fail2ban freehoo ganglia gnumeric grace gromacs gsh htop ikarus iok iperf jasper jrosetta js koan kst libedit libgsasl libntlm libsieve mediatomb mingw32-binutils mingw32-cairo mingw32-dlfcn mingw32-filesystem mingw32-freetype mingw32-gdbm mingw32-gettext mingw32-glib2 mingw32-libgpg-error mingw32-libjpeg mingw32-libpng mingw32-libxml2 mingw32-pdcurses mingw32-pixman mingw32-pthreads mingw32-readline mingw32-SDL mingw32-sqlite mingw32-w32api mock munin net6 nettee ngspice nikto nopaste nrpe ocsinventory pax-utils pbzip2 pdns perl-Algorithm-Annotate perl-B-Utils perl-Class-Inspector perl-Convert-UUlib perl-CSS-Squish perl-Data-Dump-Streamer perl-DDL-Oracle perl-Devel-StackTrace perl-Heap perl-HTML-TokeParser-Simple perl-libwhisker2 perl-Math-FFT perl-MD5 perl-mogilefs-server perl-Net-LibIDN perl-Network-IPv4Addr perl-Parse-RecDescent perl-Sub-Override perl-Test-Perl-Critic perl-Test-Signature perl-XML-Filter-BufferText php-pear-Cache-Lite podcatcher poweradmin python-BeautifulSoup python-configobj python-dns python-ldaphelper python-libgmail python-libgmail-docs python-progressbar python-ruledispatch python-turboflot pywebdav qmmp R-car ris-linux rpmlint rt3 rtpproxy rubygem-restr sbackup superiotool supybot-fedora tbcload tclchecker tclcompiler tcldebugger tclparser tclpro trac txt2tags udns unbound uriparser wine xine-lib CU knurd P.S.: EPEL-signers, if possible please don't push any new packages to the testing repos until the package move happens, as that might introduce new broken deps and thus trouble/a lot of work; tia! P.P.S.: I excluded a few brand new packages from the move that hit the testing repo yesterday -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tobemoved-rpms-4 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tobemoved-rpms-5 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tobemoved-srpms-4 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tobemoved-srpms-5 URL: From adam at spicenitz.org Sun Feb 8 17:30:18 2009 From: adam at spicenitz.org (Adam Goode) Date: Sun, 08 Feb 2009 12:30:18 -0500 Subject: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside In-Reply-To: <498ED546.3060806@leemhuis.info> References: <498ED546.3060806@leemhuis.info> Message-ID: <498F16AA.7040306@spicenitz.org> Thorsten Leemhuis wrote: > Hi all! > > I prepared the next testing -> stable move for EPEL4 and EPEL5. I plan > to actually do the move on 20090212 at around 06:00 UTC. > > If one of your packages is in the attached "tobemoved-(s,)rpms-{4,5}" > list and you don't want it moved please tell me soon or it'll be to late > soon. > Hi, Maybe hold out fwwm? It is a brand new EPEL package so probably should be in testing a little while first. Also, I only see it for EL-4, we should probably wait for the version in EL-5 so they can go in together. Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From kevin at tummy.com Mon Feb 9 17:34:15 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 9 Feb 2009 10:34:15 -0700 Subject: meetings and some issues Message-ID: <20090209103415.4e0fe999@ohm.scrye.com> Greetings. Since we haven't had an epel meeting in quite a while, I would like to revisit the idea of a new meeting time. Perhaps we could setup a table in the wiki for people to fill in and choose the best time that way? Or perhaps someone would like to suggest a time? Some issues that are pending that we can just discuss here: - Did we ever decide to make a epel-announce list? I think this might be good still to send important announcements about packages or other changes that end epel users should be notified of. I am not sure, but we could also send the package update announcements there (might be too much traffic tho, perhaps just the stable ones?) - Orphans. We have the following orphan packages. Some of them are more 'retired', but we should look at trying to find owners for the ones that can still be maintained. abcde aget cd-discid csync2 cvs2cl cvsps freetennis gkrellm gkrellm-volume gtkhtml38 libid3tag libmodplug mach otrs pytz redet redet-doc svn2cl - Bugs. We are now just over 100 epel bugs. This is no good, IMHO. Would it be possible to get some interested folks to dig through these and see about fixing easy ones/poking maintainers/doing something to move them along. Especially in the case where it's a missing dep. https://bugzilla.redhat.com/buglist.cgi?product=Fedora EPEL&bug_status=NEW&bug_status=MODIFIED&bug_status=ASSIGNED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=RELEASE_PENDING&bug_status=POST&bug_status=FAILS_QA - Do we need to do anything to prep for RHEL6? Do we just branch the things that are already in EPEL5? Or can we look at more than that? - How can we get better communication between EPEL and RHEL? ie, the recent packages they put in 5.3 without notifying or even providing a higher evr. ;( - How can we get more packages branched for EPEL? Perhaps we could approach some of the sigs, like the perl-sig and ask them to consider their packages that work/make sense on EPEL (I have seen a bunch of new perl packages in fedora that were not branched for EPEL). I'm sure there are other things, but those are the ones I can think of off the top of my head. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rayvd at bludgeon.org Mon Feb 9 17:43:55 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 9 Feb 2009 09:43:55 -0800 Subject: meetings and some issues In-Reply-To: <20090209103415.4e0fe999@ohm.scrye.com> References: <20090209103415.4e0fe999@ohm.scrye.com> Message-ID: <20090209174355.GA6480@bludgeon.org> On Mon, Feb 09, 2009 at 10:34:15AM -0700, Kevin Fenzi wrote: > - How can we get better communication between EPEL and RHEL? ie, the > recent packages they put in 5.3 without notifying or even providing a > higher evr. ;( Also have some questions on this one. I just submitted an EPEL only package (no Fedora branches and devel is dead.package'd). This package is included in Python 2.5 and newer already so it was suggested that I file bugs to have Obsoletes added to the python package in Fedora and RHEL6. I assume there is a RHEL6 target in bz for internal folks, but I don't have access to it. How should situations like this be handled? I filed it against RHEL 5.5 and just mentioned what I wanted done. We'll see what happens. :) I'll keep my eyes open for a meeting date... Ray From jdf.lists at gmail.com Mon Feb 9 17:52:04 2009 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Mon, 9 Feb 2009 09:52:04 -0800 Subject: meetings and some issues In-Reply-To: <20090209174355.GA6480@bludgeon.org> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090209174355.GA6480@bludgeon.org> Message-ID: <67437bc40902090952q44bb6ae5j35013708d425cafd@mail.gmail.com> On Mon, Feb 9, 2009 at 9:43 AM, Ray Van Dolson wrote: > On Mon, Feb 09, 2009 at 10:34:15AM -0700, Kevin Fenzi wrote: >> - How can we get better communication between EPEL and RHEL? ie, the >> recent packages they put in 5.3 without notifying or even providing a >> higher evr. ;( > > I assume there is a RHEL6 target in bz for internal folks, but I don't > have access to it. How should situations like this be handled? I > filed it against RHEL 5.5 and just mentioned what I wanted done. We'll > see what happens. :) On RHEL mailing lists it has been suggested that the only way to close the loop for organizational support is a Technical Account Manager (TAM). Perhaps if Red Hat wanted to show support for the EPEL effort they could assign a TAM to at least read the mailing list. This would be a person at Red Hat who has full access to inside information and so could at least say "hey, I'd hold off on that since it will be in 5.5" or maybe answer direct questions off-list. From rayvd at bludgeon.org Mon Feb 9 17:59:30 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 9 Feb 2009 09:59:30 -0800 Subject: meetings and some issues In-Reply-To: <67437bc40902090952q44bb6ae5j35013708d425cafd@mail.gmail.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090209174355.GA6480@bludgeon.org> <67437bc40902090952q44bb6ae5j35013708d425cafd@mail.gmail.com> Message-ID: <20090209175930.GA6672@bludgeon.org> On Mon, Feb 09, 2009 at 09:52:04AM -0800, Joshua Daniel Franklin wrote: > On Mon, Feb 9, 2009 at 9:43 AM, Ray Van Dolson wrote: > > On Mon, Feb 09, 2009 at 10:34:15AM -0700, Kevin Fenzi wrote: > >> - How can we get better communication between EPEL and RHEL? ie, the > >> recent packages they put in 5.3 without notifying or even providing a > >> higher evr. ;( > > > > I assume there is a RHEL6 target in bz for internal folks, but I don't > > have access to it. How should situations like this be handled? I > > filed it against RHEL 5.5 and just mentioned what I wanted done. We'll > > see what happens. :) > > On RHEL mailing lists it has been suggested that the only way to > close the loop for organizational support is a Technical Account Manager > (TAM). Perhaps if Red Hat wanted to show support for the EPEL effort > they could assign a TAM to at least read the mailing list. This would be > a person at Red Hat who has full access to inside information and so > could at least say "hey, I'd hold off on that since it will be in 5.5" or maybe > answer direct questions off-list. Hmm, I like that idea. Also, many of the companies we work for at $DAYJOB are RH customers. We could always start filing SR's for things that need done. :-) Ray From smooge at gmail.com Mon Feb 9 21:14:09 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 9 Feb 2009 14:14:09 -0700 Subject: Change Request: Updating Mediawiki to new branch Message-ID: <80d7e4090902091314j2a322aearfe10248a5780476b@mail.gmail.com> Mediawiki has upgraded itself quite a bit, and there are a bunch of security fixes. However, it is a major change and should get some look-see. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Mon Feb 9 23:49:20 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 9 Feb 2009 16:49:20 -0700 Subject: meetings and some issues In-Reply-To: <20090209103415.4e0fe999@ohm.scrye.com> References: <20090209103415.4e0fe999@ohm.scrye.com> Message-ID: <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> 2009/2/9 Kevin Fenzi : > Greetings. > > Since we haven't had an epel meeting in quite a while, I would like to > revisit the idea of a new meeting time. Perhaps we could setup a table > in the wiki for people to fill in and choose the best time that way? > Or perhaps someone would like to suggest a time? Thanks Kevin. > Some issues that are pending that we can just discuss here: > > - Did we ever decide to make a epel-announce list? I think this might > be good still to send important announcements about packages or other > changes that end epel users should be notified of. I am not sure, but > we could also send the package update announcements there (might be > too much traffic tho, perhaps just the stable ones?) It was tabled to be discussed on list. I am for it. > - Orphans. We have the following orphan packages. Some of them are more > 'retired', but we should look at trying to find owners for the ones > that can still be maintained. > > abcde > aget > cd-discid > csync2 > cvs2cl > cvsps > freetennis > gkrellm > gkrellm-volume > gtkhtml38 > libid3tag > libmodplug > mach > otrs > pytz > redet > redet-doc > svn2cl Hmmm I though otrs just got put in. > - Bugs. We are now just over 100 epel bugs. This is no good, IMHO. > Would it be possible to get some interested folks to dig through these > and see about fixing easy ones/poking maintainers/doing something to > move them along. Especially in the case where it's a missing dep. > https://bugzilla.redhat.com/buglist.cgi?product=Fedora > EPEL&bug_status=NEW&bug_status=MODIFIED&bug_status=ASSIGNED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=RELEASE_PENDING&bug_status=POST&bug_status=FAILS_QA Ok that sounds like something I can start on. > - Do we need to do anything to prep for RHEL6? Do we just branch the > things that are already in EPEL5? Or can we look at more than that? Yes. 1) We need to get the build system to koji. David Gilmore says thats real soon now (like this month). 2) We need to have a branch where we will build 'everything' against the BETA when it comes out. That way we can keep track of where things break and see if we can get some loving to EL-6 sooner versus later. 3) We need a TAM at Red Hat to keep us in contact with what is going on with EL{4,5,6} so that we have better communication about changes. > - How can we get better communication between EPEL and RHEL? ie, the > recent packages they put in 5.3 without notifying or even providing a > higher evr. ;( Same old, same old. I think the issue is that inter departmental communication has never been a good strength at Red Hat. [As was once noted if it didn't happen on tech-list, it wasn't a technical decision.] > - How can we get more packages branched for EPEL? Perhaps we could > approach some of the sigs, like the perl-sig and ask them to consider > their packages that work/make sense on EPEL (I have seen a bunch of > new perl packages in fedora that were not branched for EPEL). > > I'm sure there are other things, but those are the ones I can think of > off the top of my head. ;) > > kevin Thanks again kevin. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mastahnke at gmail.com Tue Feb 10 01:42:15 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 9 Feb 2009 19:42:15 -0600 Subject: Change Request: Updating Mediawiki to new branch In-Reply-To: <80d7e4090902091314j2a322aearfe10248a5780476b@mail.gmail.com> References: <80d7e4090902091314j2a322aearfe10248a5780476b@mail.gmail.com> Message-ID: <7874d9dd0902091742m46d89e83o53e4340b6985a16b@mail.gmail.com> On Mon, Feb 9, 2009 at 3:14 PM, Stephen John Smoogen wrote: > Mediawiki has upgraded itself quite a bit, and there are a bunch of > security fixes. However, it is a major change and should get some > look-see. > > -- > Stephen J Smoogen. -- BSD/GNU/Linux > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > Smooge, Just today I grabbed Nigel's package from the Infrastructure repo and it worked like a champ. It's all updated to 1.13 and is shiney. You might grab that and see what you can do with it, (or just build it). stahnma From mastahnke at gmail.com Tue Feb 10 01:50:36 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 9 Feb 2009 19:50:36 -0600 Subject: meetings and some issues In-Reply-To: <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> Message-ID: <7874d9dd0902091750o504bc908h701438e8190616af@mail.gmail.com> >> Since we haven't had an epel meeting in quite a while, I would like to >> revisit the idea of a new meeting time. Perhaps we could setup a table >> in the wiki for people to fill in and choose the best time that way? >> Or perhaps someone would like to suggest a time? The best time for me is late afternoon in the US. I know that's a pain to our European friends. In the morning I commonly am dealing with issues from work. >> - Did we ever decide to make a epel-announce list? I think this might >> be good still to send important announcements about packages or other >> changes that end epel users should be notified of. I am not sure, but >> we could also send the package update announcements there (might be >> too much traffic tho, perhaps just the stable ones?) +1 for the list. It's a good idea, but I hate to be on more lists. However, epel users would probably like it. >> - Orphans. We have the following orphan packages. Some of them are more >> 'retired', but we should look at trying to find owners for the ones >> that can still be maintained. >> >> cvs2cl >> cvsps >> svn2cl As much as we (maintainers) probably don't like CVS anymore, it's still used all over the place in companies. We should probably try to find somebody to keep those alive. I'd be happy to be a co-maintainer on the cvs packages, but I'd like help. >> - Bugs. We are now just over 100 epel bugs. This is no good, IMHO. >> Would it be possible to get some interested folks to dig through these >> and see about fixing easy ones/poking maintainers/doing something to >> move them along. Especially in the case where it's a missing dep. > Ouch. And I haven't filed any (that I remember). > 1) We need to get the build system to koji. David Gilmore says thats > real soon now (like this month). Maybe Dennis Gilmore? David Gilmore is of Pink Floyd fame. I mean, if he is working on Koji, more power to him, but if not, I'll let him keep playing guitar. > 2) We need to have a branch where we will build 'everything' against > the BETA when it comes out. That way we can keep track of where things > break and see if we can get some loving to EL-6 sooner versus later. I agree. My biggest issues with EPEL are normally a package I *need* is missing. > 3) We need a TAM at Red Hat to keep us in contact with what is going > on with EL{4,5,6} so that we have better communication about changes. ++ a lot. I really like this idea. Karsten, any thoughts on your end? This would be most excellent. I'll see about bringing it up to my sales rep, to see if maybe we can get traction on two fronts. I am sure my sales reps will somehow see $$$ from $DAYJOB, but whatever, I'll deal with it. >> - How can we get more packages branched for EPEL? Perhaps we could >> approach some of the sigs, like the perl-sig and ask them to consider >> their packages that work/make sense on EPEL (I have seen a bunch of >> new perl packages in fedora that were not branched for EPEL). The ruby-sig (like all 5 of us) are working pretty hard to get a lot of the packages into EL5. EL4 is pretty much a lost cause since rubygems can't really be installed. At $DAYJOB I have ripped out the entire ruby stack on RHEL4 and replaced it with a newer one. That's probably not recommended. I was working with the perl sig a while back on at least generating a report of what perl modules where in EPEL and what was missing. I forgot who I was working with, but it's in the archives and I'll look again when I get back to it. Anybody is welcome to help there. I can tell you that about 60% of the 'missing' packages in EPEL from my server team's perspective is perl modules. Thanks, stahnma From mastahnke at gmail.com Tue Feb 10 01:52:51 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 9 Feb 2009 19:52:51 -0600 Subject: Broken deps report incomplete? (was: Re: Broken dependencies in EPEL - 2009-02-08) In-Reply-To: <498ED416.9010503@leemhuis.info> References: <20090208114920.25456.4367@releng2.fedora.phx.redhat.com> <498ED416.9010503@leemhuis.info> Message-ID: <7874d9dd0902091752q75e903a4vc487d5a2fe4fc634@mail.gmail.com> I am apparently the worst deps maintainer in history. If anybody would like to work on it, please please do. I took it like a year ago to make some minor changes, and things went badly from there on out. git://git.fedorahosted.org/fedora-infrastructure.git Under /fedora-infrastructure/scripts/epel-repoclosure If anybody wants to fix it up, please do. I know ppc is still not quite right. stahnma From paul at city-fan.org Tue Feb 10 08:58:01 2009 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 Feb 2009 08:58:01 +0000 Subject: meetings and some issues In-Reply-To: <7874d9dd0902091750o504bc908h701438e8190616af@mail.gmail.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> <7874d9dd0902091750o504bc908h701438e8190616af@mail.gmail.com> Message-ID: <49914199.4010008@city-fan.org> Michael Stahnke wrote: > I was working with the perl sig a while back on at least generating a > report of what perl modules where in EPEL and what was missing. I > forgot who I was working with, but it's in the archives and I'll look > again when I get back to it. Anybody is welcome to help there. I can > tell you that about 60% of the 'missing' packages in EPEL from my > server team's perspective is perl modules. Perhaps you're thinking of this (from Chris Weyl): http://perl.biggerontheinside.net/packages/ Paul. From notting at redhat.com Tue Feb 10 14:23:02 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Feb 2009 09:23:02 -0500 Subject: meetings and some issues In-Reply-To: <20090209174355.GA6480@bludgeon.org> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090209174355.GA6480@bludgeon.org> Message-ID: <20090210142302.GB23288@nostromo.devel.redhat.com> Ray Van Dolson (rayvd at bludgeon.org) said: > On Mon, Feb 09, 2009 at 10:34:15AM -0700, Kevin Fenzi wrote: > > - How can we get better communication between EPEL and RHEL? ie, the > > recent packages they put in 5.3 without notifying or even providing a > > higher evr. ;( > > Also have some questions on this one. I just submitted an EPEL only > package (no Fedora branches and devel is dead.package'd). This package > is included in Python 2.5 and newer already so it was suggested that I > file bugs to have Obsoletes added to the python package in Fedora and > RHEL6. Why not file a bug against F11/rawhide to get it fixed there? Bill From notting at redhat.com Tue Feb 10 14:22:22 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Feb 2009 09:22:22 -0500 Subject: meetings and some issues In-Reply-To: <20090209103415.4e0fe999@ohm.scrye.com> References: <20090209103415.4e0fe999@ohm.scrye.com> Message-ID: <20090210142222.GA23288@nostromo.devel.redhat.com> Kevin Fenzi (kevin at tummy.com) said: > - Do we need to do anything to prep for RHEL6? Do we just branch the > things that are already in EPEL5? Or can we look at more than that? While I'd echo what was said earlier about communication, I would say it's definitely too early for you to be doing mass branching for RHEL 6. Do you feel you need to have packages ready *by* beta, or are you OK with determining the package set at that time? Bill From rayvd at bludgeon.org Tue Feb 10 14:45:50 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 10 Feb 2009 06:45:50 -0800 Subject: meetings and some issues In-Reply-To: <20090210142302.GB23288@nostromo.devel.redhat.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090209174355.GA6480@bludgeon.org> <20090210142302.GB23288@nostromo.devel.redhat.com> Message-ID: <20090210144549.GA22279@bludgeon.org> On Tue, Feb 10, 2009 at 09:23:02AM -0500, Bill Nottingham wrote: > Ray Van Dolson (rayvd at bludgeon.org) said: > > On Mon, Feb 09, 2009 at 10:34:15AM -0700, Kevin Fenzi wrote: > > > - How can we get better communication between EPEL and RHEL? ie, the > > > recent packages they put in 5.3 without notifying or even providing a > > > higher evr. ;( > > > > Also have some questions on this one. I just submitted an EPEL only > > package (no Fedora branches and devel is dead.package'd). This package > > is included in Python 2.5 and newer already so it was suggested that I > > file bugs to have Obsoletes added to the python package in Fedora and > > RHEL6. > > Why not file a bug against F11/rawhide to get it fixed there? > > Bill Did that also.... :) Ray From smooge at gmail.com Tue Feb 10 15:41:19 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 10 Feb 2009 08:41:19 -0700 Subject: meetings and some issues In-Reply-To: <7874d9dd0902091750o504bc908h701438e8190616af@mail.gmail.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> <7874d9dd0902091750o504bc908h701438e8190616af@mail.gmail.com> Message-ID: <80d7e4090902100741p5fbb5f93r9c55de1241a3e9fa@mail.gmail.com> On Mon, Feb 9, 2009 at 6:50 PM, Michael Stahnke wrote: >>> Since we haven't had an epel meeting in quite a while, I would like to >>> revisit the idea of a new meeting time. Perhaps we could setup a table >>> in the wiki for people to fill in and choose the best time that way? >>> Or perhaps someone would like to suggest a time? > The best time for me is late afternoon in the US. I know that's a > pain to our European friends. In the morning I commonly am dealing > with issues from work. I think for a global group we have to do as much on the list and then have a meeting as a catchup but in truth.. if its not on the list, it didn't happen/doesn't matter. >>> - Did we ever decide to make a epel-announce list? I think this might >>> be good still to send important announcements about packages or other >>> changes that end epel users should be notified of. I am not sure, but >>> we could also send the package update announcements there (might be >>> too much traffic tho, perhaps just the stable ones?) > +1 for the list. It's a good idea, but I hate to be on more lists. > However, epel users would probably like it. I agree. >>> - Orphans. We have the following orphan packages. Some of them are more >>> 'retired', but we should look at trying to find owners for the ones >>> that can still be maintained. >>> > >>> cvs2cl >>> cvsps >>> svn2cl > > As much as we (maintainers) probably don't like CVS anymore, it's > still used all over the place in companies. We should probably try to > find somebody to keep those alive. I'd be happy to be a co-maintainer > on the cvs packages, but I'd like help. I know that I am using it here.. but I haven't used any of them to see what it would mean. >>> - Bugs. We are now just over 100 epel bugs. This is no good, IMHO. >>> Would it be possible to get some interested folks to dig through these >>> and see about fixing easy ones/poking maintainers/doing something to >>> move them along. Especially in the case where it's a missing dep. >> > Ouch. And I haven't filed any (that I remember). Hmmm I wonder if we could have an email sent to the list for each one opened. It would help me know when new ones are open. >> 1) We need to get the build system to koji. David Gilmore says thats >> real soon now (like this month). > Maybe Dennis Gilmore? David Gilmore is of Pink Floyd fame. I mean, > if he is working on Koji, more power to him, but if not, I'll let him > keep playing guitar. That is what I get for listening to Echoes and typing at the same time. >> 2) We need to have a branch where we will build 'everything' against >> the BETA when it comes out. That way we can keep track of where things >> break and see if we can get some loving to EL-6 sooner versus later. > > I agree. My biggest issues with EPEL are normally a package I *need* > is missing. Agreed. Most of the time.. I need something like a rawhide for EPEL.. I am not expecting it to be stable for anyone just to see if it will work.. Then there are the packages I need to be very stable and those I try to help maintain. >> 3) We need a TAM at Red Hat to keep us in contact with what is going >> on with EL{4,5,6} so that we have better communication about changes. > > ++ a lot. I really like this idea. Karsten, any thoughts on your > end? This would be most excellent. I'll see about bringing it up to > my sales rep, to see if maybe we can get traction on two fronts. I am > sure my sales reps will somehow see $$$ from $DAYJOB, but whatever, > I'll deal with it. > >>> - How can we get more packages branched for EPEL? Perhaps we could >>> approach some of the sigs, like the perl-sig and ask them to consider >>> their packages that work/make sense on EPEL (I have seen a bunch of >>> new perl packages in fedora that were not branched for EPEL). > The ruby-sig (like all 5 of us) are working pretty hard to get a lot > of the packages into EL5. EL4 is pretty much a lost cause since > rubygems can't really be installed. At $DAYJOB I have ripped out the > entire ruby stack on RHEL4 and replaced it with a newer one. That's > probably not recommended. In some ways, it is pretty much what people have to do. I am having to find how to get Python-2.5 to work with RHEL-3 because project requires both. Its one of those things that I know a number of people do... but we just don't like to talk about it. > I was working with the perl sig a while back on at least generating a > report of what perl modules where in EPEL and what was missing. I > forgot who I was working with, but it's in the archives and I'll look > again when I get back to it. Anybody is welcome to help there. I can > tell you that about 60% of the 'missing' packages in EPEL from my > server team's perspective is perl modules. > > Thanks, > stahnma > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Wed Feb 11 16:38:40 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 11 Feb 2009 10:38:40 -0600 (CST) Subject: Change Request: Updating Mediawiki to new branch In-Reply-To: <7874d9dd0902091742m46d89e83o53e4340b6985a16b@mail.gmail.com> References: <80d7e4090902091314j2a322aearfe10248a5780476b@mail.gmail.com> <7874d9dd0902091742m46d89e83o53e4340b6985a16b@mail.gmail.com> Message-ID: On Mon, 9 Feb 2009, Michael Stahnke wrote: > On Mon, Feb 9, 2009 at 3:14 PM, Stephen John Smoogen wrote: > > Mediawiki has upgraded itself quite a bit, and there are a bunch of > > security fixes. However, it is a major change and should get some > > look-see. > > > > -- > > Stephen J Smoogen. -- BSD/GNU/Linux > > How far that little candle throws his beams! So shines a good deed > > in a naughty world. = Shakespeare. "The Merchant of Venice" > > > > _______________________________________________ > > epel-devel-list mailing list > > epel-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > > Smooge, > Just today I grabbed Nigel's package from the Infrastructure repo and > it worked like a champ. It's all updated to 1.13 and is shiney. You > might grab that and see what you can do with it, (or just build it). > Smooge and I talked on IRC but I thought I'd mention it here, we've been using it in Fedora for a while for the fedora project wiki also without issue. -Mike From mastahnke at gmail.com Wed Feb 11 22:18:42 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 11 Feb 2009 16:18:42 -0600 Subject: Change Request: Updating Mediawiki to new branch In-Reply-To: References: <80d7e4090902091314j2a322aearfe10248a5780476b@mail.gmail.com> <7874d9dd0902091742m46d89e83o53e4340b6985a16b@mail.gmail.com> Message-ID: <7874d9dd0902111418s670b79f3u65308ebd04831e47@mail.gmail.com> I've also started packaging several more extensions for mediawiki. Many of them have licensing issues that need to be cleared up, but some will be submitted for Fedora review soon. stahnma From mastahnke at gmail.com Wed Feb 11 22:24:10 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 11 Feb 2009 16:24:10 -0600 Subject: Mirror Manager and the way you get EPEL Message-ID: <7874d9dd0902111424y51bd0a80ob44419156404e76d@mail.gmail.com> This might be odd, but to me, I get frustrated every time I type download.fedoraproject.org into my browser and get taken to a mirror that doesn't have EPEL. I realize not every mirror can carry EPEL, but if I want to get EPEL packages (specifically epel-release) I have to log into a server that already has it, and cat /etc/yum.repos.d/epel.repo and see where I can find the information. The only other way is to browse to the fedoraproject wiki, and search on EPEL (because it's not listed on the front pages). I will talk to the web team and see if I can get this rectified. I guess I would like something like download.fedoraproject.org/epel and it would take to me random epel mirror. Is that possible? Am I the only one who ever thinks this? You can tell me if I am nuts. stahnma From giallu at gmail.com Wed Feb 11 23:39:35 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 12 Feb 2009 00:39:35 +0100 Subject: Mirror Manager and the way you get EPEL In-Reply-To: <7874d9dd0902111424y51bd0a80ob44419156404e76d@mail.gmail.com> References: <7874d9dd0902111424y51bd0a80ob44419156404e76d@mail.gmail.com> Message-ID: On Wed, Feb 11, 2009 at 11:24 PM, Michael Stahnke wrote: > This might be odd, but to me, I get frustrated every time I type > download.fedoraproject.org into my browser and get taken to a mirror > that doesn't have EPEL. I think you want his instead: http://mirrors.fedoraproject.org/publiclist/EPEL/5/ -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From joshua at eeinternet.com Thu Feb 12 01:46:49 2009 From: joshua at eeinternet.com (Joshua J. Kugler) Date: Wed, 11 Feb 2009 16:46:49 -0900 Subject: Status of python-twisted-mail, and others Message-ID: <200902111646.49377.joshua@eeinternet.com> Hi! First off, thank you much for the EPEL. It has made maintaining my boxes much easier! Second: does anyone know the status of the various python-twisted-* packages? I notice some, like python-twisted-mail are missing. Thanks! j -- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ?ID 0xDB26D7CE From mastahnke at gmail.com Thu Feb 12 02:21:23 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 11 Feb 2009 20:21:23 -0600 Subject: Mirror Manager and the way you get EPEL In-Reply-To: References: <7874d9dd0902111424y51bd0a80ob44419156404e76d@mail.gmail.com> Message-ID: <7874d9dd0902111821p491ee7c5m48639ddc0222a8a8@mail.gmail.com> On Wed, Feb 11, 2009 at 5:39 PM, Gianluca Sforna wrote: > On Wed, Feb 11, 2009 at 11:24 PM, Michael Stahnke wrote: >> This might be odd, but to me, I get frustrated every time I type >> download.fedoraproject.org into my browser and get taken to a mirror >> that doesn't have EPEL. > > I think you want his instead: > http://mirrors.fedoraproject.org/publiclist/EPEL/5/ I still think that is more complicated than download.fedoraproject.org, but thank you for your help. From mastahnke at gmail.com Thu Feb 12 03:04:10 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 11 Feb 2009 21:04:10 -0600 Subject: Status of python-twisted-mail, and others In-Reply-To: <200902111646.49377.joshua@eeinternet.com> References: <200902111646.49377.joshua@eeinternet.com> Message-ID: <7874d9dd0902111904q35395955n177a3b49b36fc57d@mail.gmail.com> On Wed, Feb 11, 2009 at 7:46 PM, Joshua J. Kugler wrote: > Hi! First off, thank you much for the EPEL. It has made maintaining my > boxes much easier! > > Second: does anyone know the status of the various python-twisted-* > packages? I notice some, like python-twisted-mail are missing. > > Thanks! It looks like python-twisted is a meta-package for the entire twisted framework. Some portions are in, and some are out. %{python}-twisted-core >= %{version} -- Available in EPEL %{python}-twisted-conch -- Built in mock from F-9 without issue (should file bug) %{python}-twisted-lore -- Built in mock from F-9 without issue %{python}-twisted-mail -- Built in mock from F-9 without issue %{python}-twisted-names -- Available in EPEL %{python}-twisted-news -- Built in mock from F-9 without issue %{python}-twisted-runner -- Built in mock from F-9 without issue %{python}-twisted-web -- Available in EPEL %{python}-twisted-words -- Available in EPEL It looks like there is a bug 439977, that is already open requesting twisted in EPEL. I updated the bug to emphasize the request. stahnma From joshua at eeinternet.com Thu Feb 12 03:40:27 2009 From: joshua at eeinternet.com (Joshua J. Kugler) Date: Wed, 11 Feb 2009 18:40:27 -0900 Subject: Status of python-twisted-mail, and others In-Reply-To: <7874d9dd0902111904q35395955n177a3b49b36fc57d@mail.gmail.com> References: <200902111646.49377.joshua@eeinternet.com> <7874d9dd0902111904q35395955n177a3b49b36fc57d@mail.gmail.com> Message-ID: <200902111840.27315.joshua@eeinternet.com> On Wednesday 11 February 2009, Michael Stahnke said something like: > On Wed, Feb 11, 2009 at 7:46 PM, Joshua J. Kugler wrote: > > Hi! First off, thank you much for the EPEL. It has made maintaining > > my boxes much easier! > > > > Second: does anyone know the status of the various python-twisted-* > > packages? I notice some, like python-twisted-mail are missing. > > > > Thanks! > > It looks like python-twisted is a meta-package for the entire twisted > framework. Some portions are in, and some are out. > > %{python}-twisted-core >= %{version} -- Available in EPEL > %{python}-twisted-conch -- Built in mock from F-9 without issue > (should file bug) > %{python}-twisted-lore -- Built in mock from F-9 without issue > %{python}-twisted-mail -- Built in mock from F-9 without issue > %{python}-twisted-names -- Available in EPEL > %{python}-twisted-news -- Built in mock from F-9 without issue > %{python}-twisted-runner -- Built in mock from F-9 without issue > %{python}-twisted-web -- Available in EPEL > %{python}-twisted-words -- Available in EPEL > > > It looks like there is a bug 439977, that is already open requesting > twisted in EPEL. I updated the bug to emphasize the request. Thank you! Much appreciated! -- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ?ID 0xDB26D7CE From buildsys at fedoraproject.org Thu Feb 12 07:02:06 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 12 Feb 2009 07:02:06 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-12 Message-ID: <20090212070206.ED90F188109@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 146 amarok-1.4.10-2.el5 augeas-0.3.6-2.el5 NEW autotrust-0.2.1-0.2.rc1.el5 : DNSKEY trust anchor update utility that uses RFC-5011 NEW beesu-2.1-1.el5 : Bee's installer script for beesu NEW bind-to-tinydns-0.4.3-4.el5 : Convert DNS zone files in BIND format to tinydns format bodhi-0.5.16-1.el5 NEW botan-1.8.1-1.el5 : Crypto library written in C++ NEW cas-0.13-119.el5 : Tool to analyze and configure core file environment cobbler-1.4.1-1.el5 collectl-3.1.3-1.el5 NEW crm114-0-0.4.20080703.el5 : CRM114 content classifier dbmail-2.2.11-1.el5 digitemp-3.6.0-1.el5 NEW dirac-1.0.0-2.el5 : Dirac is an open source video codec docbook2X-0.8.8-1.el5 docbook2X-0.8.8-1.el5 dtc-1.1.0-1.el5 dtc-1.1.0-1.el5 duplicity-0.5.06-1.el5 ejabberd-2.0.3-1.el5 NEW fail2ban-0.6.2-3.el5 : Ban IPs that make too many password failures freehoo-3.5.3-1.el5 ganglia-3.0.7-1.el5 gnumeric-1.6.3-15.el5.2 grace-5.1.22-2.el5 gromacs-4.0.3-4.el5 NEW gsh-0.3-5.el5 : Group Shell - aggregate several remote shells into one htop-0.8.1-3.el5 ikarus-0.0.3-2.el5 iok-1.2.0-1.el5 iperf-2.0.4-1.el5 jasper-1.900.1-9.el5 NEW jrosetta-1.0.2-1.el5 : A common base to build a graphical console NEW js-1.70-3.el5 : JavaScript interpreter and libraries koan-1.4.1-1.el5 kst-1.3.1-6.el5 libedit-2.11-2.20080712cvs.el5 NEW libgsasl-0.2.29-1.el5 : GNU SASL library NEW libntlm-1.0-1.el5 : NTLM authentication library libsieve-2.2.7-1.el5 NEW mediatomb-0.11.0-2.el5.1 : MediaTomb - UPnP AV Mediaserver for Linux mingw32-binutils-2.19-3.el5 NEW mingw32-cairo-1.8.0-6.el5 : MinGW Windows Cairo library NEW mingw32-dlfcn-0-0.3.r11.el5 : Implements a wrapper for dlfcn (dlopen dlclose dlsym dlerror) mingw32-filesystem-40-3.el5 NEW mingw32-freetype-2.3.8-1.el5 : Free and portable font rendering engine NEW mingw32-gdbm-1.8.0-1.el5 : MinGW port of GNU database routines NEW mingw32-gettext-0.17-7.el5 : GNU libraries and utilities for producing multi-lingual messages NEW mingw32-glib2-2.19.5-2.1.el5 : MinGW Windows GLib2 library NEW mingw32-libgpg-error-1.6-9.el5 : MinGW Windows GnuPGP error library NEW mingw32-libjpeg-6b-8.el5 : MinGW Windows Libjpeg library NEW mingw32-libpng-1.2.34-2.el5 : MinGW Windows Libpng library NEW mingw32-libxml2-2.7.2-6.el5 : MinGW Windows libxml2 XML processing library NEW mingw32-pdcurses-3.4-3.el5 : Curses library for MinGW NEW mingw32-pixman-0.13.2-2.el5 : MinGW Windows Pixman library NEW mingw32-pthreads-2.8.0-4.el5 : MinGW pthread library NEW mingw32-readline-5.2-4.el5 : MinGW port of readline for editing typed command lines NEW mingw32-SDL-1.2.13-4.el5 : MinGW Windows port of SDL cross-platform multimedia library NEW mingw32-sqlite-3.6.6.2-1.el5 : MinGW Windows port of sqlite embeddable SQL database engine mingw32-w32api-3.12-8.el5 mingw32-w32api-3.12-8.el5 mock-0.9.14-1.el5 munin-1.2.6-3.el5 net6-1.3.5-1.el5 net6-1.3.5-1.el5 nettee-0.1.9.1-1.el5 ngspice-18-1.el5 NEW nikto-1.36-3.el5 : Web server scanner NEW nopaste-2835-2.el5 : Command-line interface to rafb.net/paste nrpe-2.12-6.el5 NEW ocsinventory-1.02-0.10.rc3.el5 : Open Computer and Software Inventory Next Generation NEW pax-utils-0.1.17-1.el5 : PaX aware and related utilities for ELF binaries pbzip2-1.0.5-1.el5 pdns-2.9.22-3.el5 perl-Algorithm-Annotate-0.10-6.el5 perl-Algorithm-Annotate-0.10-6.el5 NEW perl-B-Utils-0.07-2.el5 : Helper functions for op tree manipulation perl-Class-Inspector-1.17-1.el5 perl-Class-Inspector-1.17-1.el5 perl-Convert-UUlib-1.11-1.el5 NEW perl-CSS-Squish-0.07-2.el5 : Compact many CSS files into one big file NEW perl-Data-Dump-Streamer-2.08-1.el5 : Accurately serialize a data structure as Perl code NEW perl-DDL-Oracle-1.11-1.el5 : DDL generator for Oracle databases perl-Devel-StackTrace-1.20-1.el5 perl-Heap-0.80-1.el5 perl-Heap-0.80-1.el5 NEW perl-HTML-TokeParser-Simple-3.15-1.el5 : Easy to use HTML::TokeParser interface NEW perl-libwhisker2-2.4-3.el5 : Perl module geared specificly for HTTP testing perl-Math-FFT-1.28-1.el5 perl-Math-FFT-1.28-1.el5 NEW perl-MD5-2.03-1.el5 : Perl interface to the MD5 Message-Digest Algorithm perl-mogilefs-server-2.30-1.el5 perl-Net-LibIDN-0.11-1.el5 NEW perl-Network-IPv4Addr-0.05-13.el5 : Network-IPv4Addr Perl module perl-Parse-RecDescent-1.96-1.el5 NEW perl-Sub-Override-0.08-2.el5 : Perl extension for easily overriding subroutines perl-Test-Perl-Critic-1.01-1.el5 perl-Test-Perl-Critic-1.01-1.el5 NEW perl-Test-Signature-1.10-2.el5 : Automated SIGNATURE testing perl-XML-Filter-BufferText-1.01-2.el5 perl-XML-Filter-BufferText-1.01-2.el5 php-pear-Cache-Lite-1.7.5-1.el5 NEW podcatcher-3.1.4-3.el5 : Armangil's podcatcher NEW poweradmin-2.1.2-2.el5 : A friendly web-based DNS administration tool for Bert Hubert's PowerDNS server NEW python-BeautifulSoup-3.0.7a-3.el5 : HTML/XML parser for quick-turnaround applications like screen-scraping python-configobj-4.4.0-2.el5 python-configobj-4.4.0-2.el5 python-dns-1.6.0-2.el5 python-dns-1.6.0-2.el5 python-fedora-0.3.9.1-2.el5 NEW python-ldaphelper-1.0.1-1.el5 : A python wrapper for LDAP search results python-libgmail-0.1.8-2.el5 python-libgmail-0.1.8-2.el5 python-libgmail-docs-0.3-6.el5 python-libgmail-docs-0.3-6.el5 NEW python-progressbar-2.2-5.el5 : Text progressbar library for python python-ruledispatch-0.5a0-0.8.svnr2306.el5 python-ruledispatch-0.5a0-0.8.svnr2306.el5 python-turboflot-0.1.0-1.el5 python-turboflot-0.1.0-1.el5 NEW pywebdav-0.8-2.el5 : WebDAV library NEW qmmp-0.2.3-2.el5 : Qt-based multimedia player R-car-1.2-2.el5 R-car-1.2-2.el5 NEW ris-linux-0.4-4.el5 : RIS for Linux - Boot winpe from the net / Ris Windows Installation rpmlint-0.85-3.el5.1 rt3-3.6.7-1.el5 rtpproxy-1.2-0.3.beta.200901120.el5 NEW rubygem-restr-0.4.0-1.el5 : Simple client for RESTful web services NEW sbackup-0.10.5-5.el5 : Simple Backup Suite for desktop use superiotool-0-0.15.20090202svn3827.el5 supybot-fedora-0.2.3-1.el5 NEW tbcload-1.4-6.20061030cvs.el5 : Tcl bytecode loader NEW tclchecker-1.4-4.20061030cvs.el5 : Tcl syntax checker NEW tclcompiler-1.5-4.20061030cvs.el5 : Tcl bytecode compiler NEW tcldebugger-1.4-6.20061030cvs.el5 : Tcl debugging library NEW tclparser-1.4-3.20061030cvs.el5 : Tcl syntax parser NEW tclpro-1.5.0-11.20061030cvs.el5 : Development and debugging tools for Tcl applications trac-0.10.5-2.el5 NEW txt2tags-2.5-5.el5 : Summary: Converts text files to HTML, XHTML, LaTeX, and other formats NEW udns-0.0.9-3.el5 : DNS resolver library for both synchronous and asynchronous DNS queries unbound-1.0.2-5.el5 unbound-1.0.2-5.el5 NEW uriparser-0.7.1-6.el5 : URI parsing library - RFC 3986 wine-1.0.1-1.el5 xine-lib-1.1.16.1-1.el5 Packages built and released for Fedora EPEL testing/5: 25 augeas-0.4.0-1.el5 backup-manager-0.7.8-1.el5 dnssec-conf-1.15-1.el5 NEW fetchlog-1.2-1.el5 : Utility to display new messages of a logfile since last run NEW fvwm-2.5.26-2.el5.2 : Highly configurable multiple virtual desktop window manager garmindev-0-0.3.20090208svn1152.el5 NEW mingw32-atk-1.25.2-5.el5 : MinGW Windows Atk library NEW mingw32-libgcrypt-1.4.4-1.el5 : MinGW Windows gcrypt encryption library NEW mingw32-openssl-0.9.8j-2.el5 : MinGW port of the OpenSSL toolkit NetworkManager-openvpn-0.7.0-18.svn11.el5.1 NetworkManager-pptp-0.7.0-2.svn16.el5 NEW perl-Class-Can-0.01-1.el5 : Inspect a class/method and say what it can do (and why) NEW perl-Class-Exporter-0.03-2.el5 : Export class methods as regular subroutines NEW perl-HTML-DOMbo-3.10-1.el5 : Convert between XML::DOM and {XML/HTML}::Element trees NEW perl-Lingua-Stem-Snowball-0.952-1.el5 : Perl interface to Snowball stemmers NEW perl-Lingua-StopWords-0.09-2.el5 : Stop words for several languages NEW perl-NOCpulse-SetID-1.6.9-1.el5 : Provides api for correctly changing user identity NEW perl-XML-Generator-1.01-3.el5 : XML-Generator Perl module python-louie-1.1-4.el5 NEW python-pygooglechart-0.2.1-3.el5 : A complete Python wrapper for the Google Chart API NEW python-uuid-1.30-3.el5 : Python interface to RFC 4122 compliant UUID objects NEW pyvnc2swf-0.9.5-1.el5 : Vnc screen recorder trickle-1.07-6.el5 unbound-1.2.0-4.el5 xine-lib-1.1.16.2-1.el5 Packages built and released for Fedora EPEL 4: 75 alpine-2.00-1.el4 augeas-0.3.6-2.el4 NEW beesu-2.1-1.el4 : Bee's installer script for beesu NEW cas-0.13-119.el4 : Tool to analyze and configure core file environment cobbler-1.4.1-1.el4 collectl-3.1.3-1.el4 ctapi-cyberjack-3.3.0-4.el4 digitemp-3.6.0-1.el4 duplicity-0.5.06-1.el4 erlang-R11B-2.3.el4 erlang-R11B-2.3.el4 erlang-R11B-2.3.el4 NEW fail2ban-0.6.2-3.el4 : Ban IPs that make too many password failures freehoo-3.5.3-1.el4 NEW fvwm-2.5.26-2.el4.2 : Highly configurable multiple virtual desktop window manager ganglia-3.0.7-1.el4 gromacs-4.0.3-4.el4 NEW hatools-2.00-1.el4 : Improved shell scripting in High Availability environment htop-0.8.1-3.el4 jasper-1.900.1-9.el4 koan-1.4.1-1.el4 libmp4v2-1.5.0.1-6.el4 libmp4v2-1.5.0.1-6.el4 libmp4v2-1.5.0.1-6.el4 libsieve-2.2.7-1.el4 NEW libsigsegv-2.4-6.el4 : Library for handling page faults in user mode munin-1.2.6-3.el4 net6-1.3.5-1.el4 net6-1.3.5-1.el4 net6-1.3.5-1.el4 NEW nikto-1.36-3.el4 : Web server scanner NEW nopaste-2835-2.el4 : Command-line interface to rafb.net/paste nrpe-2.12-6.el4 obby-0.4.4-2.el4 obby-0.4.4-2.el4 obby-0.4.4-2.el4 NEW ocsinventory-1.02-0.10.rc3.el4.1 : Open Computer and Software Inventory Next Generation pbzip2-1.0.5-1.el4 perl-Convert-UUlib-1.11-1.el4 NEW perl-Crypt-OpenSSL-Bignum-0.04-4.el4 : Perl interface to OpenSSL for Bignum NEW perl-Crypt-OpenSSL-Random-0.04-6.el4 : Perl interface to OpenSSL for Random NEW perl-Crypt-OpenSSL-RSA-0.25-7.el4 : Perl interface to OpenSSL for RSA perl-Filesys-Df-0.92-3.el4 perl-Filesys-Df-0.92-3.el4 perl-Filesys-Df-0.92-3.el4 NEW perl-libwhisker2-2.4-3.el4 : Perl module geared specificly for HTTP testing perl-Math-FFT-1.28-1.el4 perl-Math-FFT-1.28-1.el4 perl-Math-FFT-1.28-1.el4 NEW perl-MD5-2.03-2.el4 : Perl interface to the MD5 Message-Digest Algorithm perl-Net-LibIDN-0.11-1.el4 perl-String-CRC32-1.4-1.el4 perl-String-CRC32-1.4-1.el4 perl-String-CRC32-1.4-1.el4 perl-Test-Pod-Coverage-1.08-1.el4 perl-Test-Pod-Coverage-1.08-1.el4 perl-Test-Pod-Coverage-1.08-1.el4 perl-XML-Filter-BufferText-1.01-4.el4 perl-XML-Filter-BufferText-1.01-4.el4 perl-XML-Filter-BufferText-1.01-4.el4 NEW poweradmin-2.1.2-2.el4.1 : A friendly web-based DNS administration tool for Bert Hubert's PowerDNS server python-boto-1.0a-1.el4.1 NEW python-dateutil-1.1-6.el4 : Powerful extensions to the standard datetime module NEW python-ldaphelper-1.0.1-1.el4 : A python wrapper for LDAP search results R-car-1.2-2.el4 superiotool-0-0.15.20090202svn3827.el4 NEW supybot-0.83.3-8.el4 : Cross-platform IRC bot written in Python NEW tbcload-1.4-6.20061030cvs.el4 : Tcl bytecode loader NEW tclchecker-1.4-4.20061030cvs.el4 : Tcl syntax checker NEW tclcompiler-1.5-4.20061030cvs.el4 : Tcl bytecode compiler NEW tcldebugger-1.4-6.20061030cvs.el4 : Tcl debugging library NEW tclparser-1.4-3.20061030cvs.el4 : Tcl syntax parser NEW tclpro-1.5.0-11.20061030cvs.el4 : Development and debugging tools for Tcl applications NEW txt2tags-2.5-5.el4 : Summary: Converts text files to HTML, XHTML, LaTeX, and other formats wine-1.0.1-1.el4 Packages built and released for Fedora EPEL testing/4: 6 augeas-0.4.0-1.el4 NEW perl-NOCpulse-SetID-1.6.9-1.el4 : Provides api for correctly changing user identity NEW python-dns-1.6.0-3.el4 : DNS toolkit for Python python-louie-1.1-4.el4 NEW python-uuid-1.30-3.el4 : Python interface to RFC 4122 compliant UUID objects trickle-1.07-6.el4 Changes in Fedora EPEL 5: amarok-1.4.10-2.el5 ------------------- * Mon Jan 12 2009 Rex Dieter - 1.4.10-2 - backport security patch augeas-0.3.6-2.el5 ------------------ * Mon Jan 26 2009 David Lutterkort - 0.3.6-1 - New version autotrust-0.2.1-0.2.rc1.el5 --------------------------- * Wed Jan 21 2009 Paul Wouters - 0.2.1-0.2.rc1 - Drop sysconfig argument for configure - Merged changelog entry to avoid rpm warning * Wed Jan 21 2009 Paul Wouters - 0.2.1-0.1.rc1 - Drop regeneration of configure - does not work on rawhide - Fix version/release tag - Removed merged in patch. updated to upstream which fixes the reported autoconf issues. beesu-2.1-1.el5 --------------- * Thu Jan 29 2009 Tom "spot" Callaway 2.1-1 - slight package cleanup from Bee bind-to-tinydns-0.4.3-4.el5 --------------------------- * Tue Jan 27 2009 Tim Jackson 0.4.3-4 - Compile stage now uses standard compiler flags * Tue Jan 27 2009 Tim Jackson 0.4.3-3 - Correct License tag to GPL+ * Tue Jan 27 2009 Tim Jackson 0.4.3-2 - Add missing source URL bodhi-0.5.16-1.el5 ------------------ * Mon Jan 05 2009 Luke Macken - 0.5.16-1 - Latest upstream bugfix release. * Mon Dec 22 2008 Luke Macken - 0.5.15-1 - Latest release, with more masher improvements. * Fri Dec 19 2008 Luke Macken - 0.5.14-1 - Latest upstream release, containing some masher improvements. * Wed Dec 10 2008 Luke Macken - 0.5.13-1 - Latest upstream release to fix various metrics/rss issues * Mon Nov 24 2008 Luke Macken - 0.5.12-1 - Latest upstream release, to fix the 10k bug * Fri Nov 21 2008 Luke Macken - 0.5.11-1 - Various F10 release tweaks * Fri Oct 24 2008 Luke Macken - 0.5.10-3 - Latest upstream release * Wed Oct 15 2008 Luke Macken - 0.5.9-2 - Fix a trivial module import issue * Tue Oct 14 2008 Luke Macken - 0.5.9-1 - Fix a variety of bugs, including a race-condition when editing. * Mon Oct 13 2008 Steve 'Ashcrow' Milner - 0.5.8-2 - Added default attributes to client files. * Sun Oct 12 2008 Luke Macken - 0.5.8-1 - Minor release to fix some new update creation bugs * Thu Oct 09 2008 Luke Macken - 0.5.7-1 - Latest release, containing some API improvements * Tue Oct 07 2008 Luke Macken - 0.5.6-1 - Latest upstream release. * Mon Oct 06 2008 Luke Macken - 0.5.5-1 - Latest upstream release. * Sat Oct 04 2008 Luke Macken - 0.5.4-2 - Make our masher extension point less obtrusive. * Tue Sep 16 2008 Luke Macken - 0.5.4-1 - Latest upstream release, containing various bugfixes - Make our python-fedora requirement explicit (#461518) * Wed Sep 10 2008 Luke Macken - 0.5.3-1 - Latest upstream release * Wed Sep 03 2008 Luke Macken - 0.5.2-2 - Add the masher deps to BuildRequires, since it now resides on the turbogears.extensions entry point and will be imported by pkg_resources at build time. * Wed Sep 03 2008 Luke Macken - 0.5.2-1 - Latest upstream bugfix release * Fri Aug 29 2008 Luke Macken - 0.5.1-3 - Fix some setuptools issues with our client subpackage * Mon Aug 25 2008 Luke Macken - 0.5.1-2 - Include the egg-info in the client subpackage. * Fri Aug 22 2008 Luke Macken - 0.5.1-1 - Latest upstream release * Sun Jul 06 2008 Luke Macken - 0.5.0-1 - Latest upstream release * Thu Jun 12 2008 Todd Zullinger - 0.4.10-5 - update URL to point to fedorahosted.org * Fri Apr 04 2008 Luke Macken - 0.4.10-4 - Add python-tgcaptcha to our server requirements * Tue Feb 26 2008 Luke Macken - 0.4.10-3 - Add python-bugzilla to our server requirements botan-1.8.1-1.el5 ----------------- * Wed Jan 21 2009 Thomas Moschny - 1.8.1-1 - Update to 1.8.1. This is a bugfix release, see http://botan.randombit.net/news/releases/1_8_1.html for changes. - No need to explicitly enable modules that will be enabled by configure.pl anyway. * Mon Jan 19 2009 Thomas Moschny - 1.8.0-2 - Move api* and tutorial* doc files to -devel package. * Sat Jan 17 2009 Thomas Moschny - 1.8.0-1 - New package. cas-0.13-119.el5 ---------------- * Wed Jan 21 2009 Adam Stokes - 0.13-119 - ExcludeArch ppc since crash is not available in this scenario cobbler-1.4.1-1.el5 ------------------- * Fri Jan 09 2009 Michael DeHaan - 1.4.1-1 - Upstream changes (see CHANGELOG) * Fri Dec 19 2008 Michael DeHaan - 1.4.0-4 - Fix for rawhide python requirement. collectl-3.1.3-1.el5 -------------------- * Sat Jan 24 2009 Dan Horak 3.1.3-1 - upgrade to upstream version 3.1.3 * Tue Jan 20 2009 Dan Horak 3.1.2-1 - upgrade to upstream version 3.1.2 crm114-0-0.4.20080703.el5 ------------------------- * Thu Jan 29 2009 Dominik Mierzejewski 0-0.4.20080703 - updated to 20080703 "BlameVT" - dropped obsolete patch - fixed license tag - corrected Summary: dbmail-2.2.11-1.el5 ------------------- * Tue Feb 03 2009 Bernard Johnson - 2.2.11-1 - v 2.2.11 - updated summaries - fix bug in dbmail-pop3d init script * Mon Jul 07 2008 Tom "spot" Callaway - 2.2.9-2 - fix conditional comparison digitemp-3.6.0-1.el5 -------------------- * Sun Jan 25 2009 Robert Scheck 3.6.0-1 - Upgrade to 3.6.0 * Sun Feb 10 2008 Robert Scheck 3.5.0-3 - Rebuilt against gcc 4.3 dirac-1.0.0-2.el5 ----------------- * Wed Jan 30 2008 kwizart < kwizart at gmail.com > - 1.0.0-2 - Adapt for EPEL-5 - Update to 1.0.0 docbook2X-0.8.8-1.el5 --------------------- * Wed Aug 08 2007 Patrice Dumas 0.8.8-1 - update to 0.8.8 dtc-1.1.0-1.el5 --------------- * Thu Jan 24 2008 Josh Boyer - Update to 1.1.0 duplicity-0.5.06-1.el5 ---------------------- * Sun Jan 25 2009 Robert Scheck 0.5.06-1 - Upgrade to 0.5.06 (#481489) ejabberd-2.0.3-1.el5 -------------------- * Mon Jan 26 2009 Peter Lemenkov 2.0.3-1 - Ver. 2.0.3 - Merged some stuff from git://dev.laptop.org/users/martin/ejabberd-xs.git * Fri Jan 16 2009 Tomas Mraz 2.0.2-4 - rebuild with new openssl fail2ban-0.6.2-3.el5 -------------------- * Sat Dec 30 2006 Axel Thimm - 0.6.2-3 - Remove forgotten condrestart. freehoo-3.5.3-1.el5 ------------------- * Wed Jan 21 2009 Ray Van Dolson - 3.5.3-1 - Upstream released 3.5.3 ganglia-3.0.7-1.el5 ------------------- * Tue Jan 20 2009 Kostas Georgiou - 3.0.7-1 - New upstream release - [480236] fix for a buffer overflow and an off-by-one bug in gmetad * Mon Dec 17 2007 Jarod Wilson 3.0.6-1 - New upstream release (security fix for web frontend cross-scripting vulnerability) * Wed Oct 24 2007 Jarod Wilson 3.0.5-2 - Reorg packages to fix multilib conflicts (#341201) * Wed Oct 03 2007 Jarod Wilson 3.0.5-1 - New upstream release * Fri May 18 2007 Jarod Wilson 3.0.4-3 - Add missing Req: php-gd so people will see nifty pie charts gnumeric-1.6.3-15.el5.2 ----------------------- * Sat Jan 10 2009 Lubomir Rintel 1:1.6.3-15.2 - Fix CVE-2009-0318 untrusted search path vulnerability grace-5.1.22-2.el5 ------------------ * Sun Jan 25 2009 Jos? Matos - 5.1.22-2 - Fix patch level used. * Fri Jan 23 2009 Jos? Matos - 5.1.22-1 - Upstream release (bug fixes). gromacs-4.0.3-4.el5 ------------------- * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-4 - Retry fixing gmxdemo. * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-3 - Fixed gmxdemo. * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-2 - Fix EPEL 4 build. * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-1 - Update to 4.0.3. * Wed Jan 14 2009 Jussi Lehtola - 4.0.2-7 - Update manual to latest version. - Removed Requires: blas and lapack. * Mon Nov 10 2008 Jussi Lehtola - 4.0.2-6 - Update to 4.0.2. gsh-0.3-5.el5 ------------- * Thu Jan 29 2009 Adam Miller - 0.3-5 - Added a patch to remove the shebang from pity.py that rpmlint didn't like * Thu Jan 29 2009 Adam Miller - 0.3-4 - removed unneeded second -n listing in setup macro listing * Thu Jan 29 2009 Jochen Schmitt - 0.3-3 - Several fixes to get package ready to fit with python packaging guideline * Wed Jan 28 2009 Adam Miller - 0.3-2 - Fixed rpmlint complaint, removed egg in setup, redownloaded source * Wed Jan 28 2009 Adam Miller - 0.3-1 - First build of gsh for fedora htop-0.8.1-3.el5 ---------------- * Thu Feb 05 2009 Adam Miller - 0.8.1-3 - "Tree view doesn't work with threads hidden" fixed (#481072) - Rafal issued the fix, this is just the update and build for EPEL ikarus-0.0.3-2.el5 ------------------ * Mon Sep 01 2008 Michel Salim - 0.0.3-2 - Own documentation directory iok-1.2.0-1.el5 --------------- * Mon Jan 19 2009 Parag Nemade - 1.2.0-1 - Update to Next release 1.2.0 * Tue Jan 13 2009 Parag Nemade - 1.1.0-1 - Update to Next release 1.1.0 * Wed Dec 17 2008 Parag Nemade - 1.0.9-1 - Update to Next release 1.0.9 iperf-2.0.4-1.el5 ----------------- * Wed Jan 21 2009 Gabriel Somlo 2.0.4-1 - update to 2.0.4 - patch to avoid tcp/dualtest server from quitting (bugzilla #449796), also submitted to iperf sourceforge ticket tracker (#1983829) jasper-1.900.1-9.el5 -------------------- * Sun Jan 25 2009 Rex Dieter 1.900.1-9 - patch for "jpc_dec_tiledecode: Assertion `dec->numcomps == 3' failed) (#481284, #481291) * Fri Feb 08 2008 Rex Dieter 1.900.1-8 - respin (gcc43) * Mon Oct 15 2007 Rex Dieter 1.900.1-7 - -libs: %post/%postun -p /sbin/ldconfig * Mon Sep 17 2007 Rex Dieter 1.900.1-6 - -libs: -Requires: %name - -devel: +Provides: libjasper-devel - drop (unused) geojasper bits * Wed Aug 22 2007 Rex Dieter 1.900.1-4 - -libs subpkg to be multilib friendlier - -utils subpkg for non-essential binaries jiv, tmrdemo (#244153) * Fri Aug 17 2007 Rex Dieter 1.900.1-3 - License: JasPer jrosetta-1.0.2-1.el5 -------------------- * Fri Jan 16 2009 kwizart < kwizart at gmail.com > - 1.0.2-1 - Fix License (GPLv2 only) - Fix Summary - Update to 1.0.2 - previous patch merged upstream js-1.70-3.el5 ------------- * Wed Jun 04 2008 Jon McCann - 1.70-3 - Add two missing files (#449715) koan-1.4.1-1.el5 ---------------- * Fri Jan 09 2009 Michael DeHaan - 1.4.1-1 - Upstream changes (see CHANGELOG) * Mon Dec 22 2008 Michael DeHaan - 1.4.0-4 - Fix python(abi) requirement some more * Mon Dec 22 2008 Michael DeHaan - 1.4.0-3 - Fix python(abi) requirement kst-1.3.1-6.el5 --------------- * Sun Jan 25 2009 Matthew Truch - 1.3.1-5 - Bump to pick up proper kjsembed.so. libedit-2.11-2.20080712cvs.el5 ------------------------------ * Thu Jan 22 2009 Jeffrey C. Ollie - 2.11-2.20080712cvs - Add ncurses-devel requires to -devel subpackage (BZ#481252) libgsasl-0.2.29-1.el5 --------------------- * Thu Jan 22 2009 Nikolay Vladimirov - 0.2.29-1 - Initial EPEL-5 build libntlm-1.0-1.el5 ----------------- * Tue Jan 20 2009 Nikolay Vladimirov - 1.0-1 - initial EL-5 build libsieve-2.2.7-1.el5 -------------------- * Wed Jan 28 2009 Bernard Johnson - 2.2.7-1 - v 2.2.7 - package pkgconfig file * Mon Feb 18 2008 Fedora Release Engineering - 2.2.6-3 - Autorebuild for GCC 4.3 mediatomb-0.11.0-2.el5.1 ------------------------ * Sun Sep 21 2008 Ian Burrell - 0.11.0-2.1 - Change BuildRequires and configure for EL-5 mingw32-binutils-2.19-3.el5 --------------------------- * Mon Jan 19 2009 Richard W.M. Jones - 2.19-3 - Rebuild with the correctly attributed changelog. * Tue Dec 16 2008 Levente Farkas - 2.19-2 - New upstream version 2.19. mingw32-cairo-1.8.0-6.el5 ------------------------- * Mon Jan 26 2009 Richard W.M. Jones - 1.8.0-6 - Requires pkgconfig (Erik van Pienbroek). * Mon Jan 26 2009 Richard W.M. Jones - 1.8.0-5 - Don't need to remove extra pkgconfig file in install section. * Mon Jan 26 2009 Richard W.M. Jones - 1.8.0-4 - Disable freetype in configure so it doesn't break if freetype or fontconfig are actually installed. (Erik van Pienbroek). * Mon Jan 19 2009 Richard W.M. Jones - 1.8.0-3 - Include license file in documentation section. - Disable building static library to save time. - Remove BRs on mingw32-fontconfig and mingw32-freetype which are not needed on Win32. - Use _smp_mflags. - Added BRs mingw32-dlfcn, mingw32-iconv, mingw32-zlib. mingw32-dlfcn-0-0.3.r11.el5 --------------------------- * Wed Jan 14 2009 Richard W.M. Jones - 0-0.3.r11 - Use Version 0 (https://www.redhat.com/archives/fedora-packaging/2009-January/msg00064.html) - Revert use of dos2unix for now (https://www.redhat.com/archives/fedora-packaging/2009-January/msg00066.html) - Use _smp_mflags. * Tue Jan 13 2009 Richard W.M. Jones - 0.1-0.2.r11 - Import into fedora-mingw temporary repository because there are packages which will depend on this. - Fix the version/release according to packaging guidelines. - Tidy up the spec file. - Use dos2unix and keep the timestamps. mingw32-filesystem-40-3.el5 --------------------------- * Wed Jan 14 2009 Richard W.M. Jones - 40-3 - Add pseudo-provides secur32.dll mingw32-freetype-2.3.8-1.el5 ---------------------------- * Fri Jan 16 2009 Richard W.M. Jones - 2.3.8-1 - New upstream version 2.3.8. - Use the patches from the Fedora native package. - Disable patented code. - Don't build the static library. - Use _smp_mflags. - BR mingw32-dlfcn (not required, but uses it if installed). - Add license file to doc section. * Tue Jan 13 2009 Richard W.M. Jones - 2.3.7-6 - Requires pkgconfig. mingw32-gdbm-1.8.0-1.el5 ------------------------ * Fri Oct 03 2008 Richard W.M. Jones - 1.8.0-1 - Initial RPM release. mingw32-gettext-0.17-7.el5 -------------------------- * Fri Jan 16 2009 Richard W.M. Jones - 0.17-7 - Remove the manpages - already available in base Fedora gettext-devel. - Use _smp_mflags for build. - Added list of potential BRs. - Added license file to doc section. mingw32-glib2-2.19.5-2.1.el5 ---------------------------- * Wed Jan 28 2009 Richard W.M. Jones - 2.19.5-2.1 - Doesn't really depend on mingw32-filesystem >= 43 (the one with the C++ compiler detection fix), since this bug didn't affect Fedora 10. * Fri Jan 23 2009 Richard W.M. Jones - 2.19.5-2 - Rebase to native Fedora version 2.19.5. - Use _smp_mflags. - Use find_lang. - Don't build static libraries. - +BR dlfcn. mingw32-libgpg-error-1.6-9.el5 ------------------------------ * Thu Jan 22 2009 Richard W.M. Jones - 1.6-9 - Verify that we are still matching current native package. - Use auto-buildrequires to identify more accurate list of BRs: + BR gettext (for /usr/bin/msgfmt etc) + BR mingw32-dlfcn + BR mingw32-iconv - Use _smp_mflags. - Use find_lang. mingw32-libjpeg-6b-8.el5 ------------------------ * Wed Jan 28 2009 Richard W.M. Jones - 6b-8 - Exclude the binaries. - Rename the binaries to *.exe (Levente Farkas). * Fri Jan 23 2009 Richard W.M. Jones - 6b-7 - Disable static libraries. - Use _smp_mflags. - Update for new libtool 2. - +BR mingw32-dlfcn. - Added documentation (README includes the license). mingw32-libpng-1.2.34-2.el5 --------------------------- * Tue Jan 13 2009 Richard W.M. Jones - 1.2.34-2 - Depend on mingw32-filesystem >= 40 so we can still build in F-10. * Tue Jan 13 2009 Richard W.M. Jones - 1.2.34-1 - Rebase to 1.2.34 and patches from Fedora. - Requires pkgconfig. - Add documentation. mingw32-libxml2-2.7.2-6.el5 --------------------------- * Mon Jan 26 2009 Richard W.M. Jones - 2.7.2-6 - Rerun autoreconf after patching configure.in (Erik van Pienbroek). - Rebuild libtool for Rawhide / libtool 2. - Add BRs dlfcn and iconv. * Fri Jan 23 2009 Richard W.M. Jones - 2.7.2-5 - Use _smp_mflags. - Disable static libraries. * Tue Jan 13 2009 Richard W.M. Jones - 2.7.2-4 - Requires pkgconfig. mingw32-pdcurses-3.4-3.el5 -------------------------- * Fri Jan 16 2009 Richard Jones - 3.4-3 - Remove +x permissions on the header files. mingw32-pixman-0.13.2-2.el5 --------------------------- * Thu Jan 15 2009 Richard W.M. Jones - 0.13.2-2 - Include LICENSE file (freedesktop bug 19582). * Tue Jan 13 2009 Richard W.M. Jones - 0.13.2-1 - Resynch with Fedora package (0.13.2). - Disable static library for speed. - Use _smp_mflags. - Requires pkgconfig. - Depends on dlfcn. mingw32-pthreads-2.8.0-4.el5 ---------------------------- * Tue Jan 13 2009 Richard W.M. Jones - 2.8.0-4 - Cleanup to the spec file, no functional changes. mingw32-readline-5.2-4.el5 -------------------------- * Sat Nov 22 2008 Richard W.M. Jones - 5.2-4 - Rename *.dll.a to lib*.dll.a so that libtool can use these libraries. mingw32-SDL-1.2.13-4.el5 ------------------------ * Tue Jan 13 2009 Richard W.M. Jones - 1.2.13-4 - Verify we are still up to date with Fedora release. - Include COPYING in documentation. - Build with dlfcn. - List all BRs. - No need to package the man pages, don't duplicate what's in the base Fedora package already. - Requires pkgconfig. mingw32-sqlite-3.6.6.2-1.el5 ---------------------------- * Tue Dec 16 2008 Richard Jones - 3.6.6.2-1 - New upstream release (to match Fedora native), 3.6.6.2. - Replace patches with ones from native. - Rebase -no-undefined patch. - Remove spurious +x permissions on libsqlite3.dll.a. - Requires pkgconfig. mingw32-w32api-3.12-8.el5 ------------------------- * Wed Nov 26 2008 Richard W.M. Jones - 3.12-8 - Force rebuild to get rid of the binary bootstrap package and replace with package built from source. mock-0.9.14-1.el5 ----------------- * Mon Feb 02 2009 Clark Williams - 0.9.14-1 - logging cleanup (mikem) - add new exception for resultdir not available (mebrown) - moved mock cache dir to /var/cache/mock (williams) - added version variable and version banner to logs (williams) - removed import of popen2 to whack deprecated message (williams) - prevent disabling ccache on epel-5 (tmz) - added configs for sparc and s390 (dgilmore) - fixed git log command used in build (tmz) - added copy of spec/sources for building srpms (mebrown) - changed unlink to rmdir (mebrown) - set HOME directory globally (mikeb) - commented out privlege drop in --copyin (williams) * Thu Nov 06 2008 Jesse Keating - 0.9.13-1 - Add configs for F10 (jkeating) * Tue Oct 14 2008 Clark Williams - 0.9.12-1 - internal setarch support for s390/s390x (mikem) - Refer to the .newkey location of current Fedora 8/9 updates. (jkeating) - [bz458234] Picked up corrected patch (pmatilai) munin-1.2.6-3.el5 ----------------- * Mon Aug 11 2008 Kevin Fenzi - 1.2.6-3 - Move Munin/Plugin.pm to the node subpackage (fixes #457403) * Sat Jul 12 2008 Kevin Fenzi - 1.2.6-2 - Apply postfix patch (fixes #454159) - Add perl version dep and remove unneeded perl-HTML-Template (fixes #453923) * Fri Jun 20 2008 Kevin Fenzi - 1.2.6-1 - Upgrade to 1.2.6 * Tue May 20 2008 Kevin Fenzi - 1.2.5-5 - Rebuild for new perl net6-1.3.5-1.el5 ---------------- * Sat Jun 16 2007 Luke Macken - 1.3.5-1 - 1.3.5 nettee-0.1.9.1-1.el5 -------------------- * Wed Feb 04 2009 Fabian Affolter - 0.1.9.1-1 - Updated to upstream version 0.1.9.1 ngspice-18-1.el5 ---------------- * Sat Jan 10 2009 Chitlesh Goorah 18-1 - new upstream release * Sun Jun 15 2008 Chitlesh Goorah 17-16 - Bugfix: #449409: FTBFS ngspice-17-14.fc9 * Fri Apr 18 2008 Chitlesh Goorah 17-15 - rebuild * Fri Aug 24 2007 Chitlesh Goorah 17-13 - mass rebuild for fedora 8 - BuildID * Sun Jul 08 2007 Chitlesh Goorah 17-12 - fixed ScriptletSnippets for Texinfo #246780 - moved documentations to -doc package nikto-1.36-3.el5 ---------------- * Wed May 30 2007 Sindre Pedersen Bj?rdal - 1.36-3 - Add sed magic to really replace nikto-1.36-config.patch nopaste-2835-2.el5 ------------------ * Sat Jan 10 2009 Simon Wesp - 2835-2 - Correct License to GPLv2 - Remove doc in files-section nrpe-2.12-6.el5 --------------- * Mon Feb 02 2009 Peter Lemenkov - 2.12-6 - Fixed BZ# 449174 - Clean up (in order to disable rpmlint warnings) * Sat Jan 17 2009 Tomas Mraz - 2.12-5 - rebuild with new openssl * Sun Dec 21 2008 Mike McGrath - 2.12-4 - Added some doc lines for ticket 477527 ocsinventory-1.02-0.10.rc3.el5 ------------------------------ * Sun Jan 11 2009 Remi Collet 1.02-0.10.rc3 - add r1447 and r1462 patch - change log selinux context (httpd_log_t) pax-utils-0.1.17-1.el5 ---------------------- * Thu Oct 30 2008 Dominik Mierzejewski 0.1.17-1 - initial build pbzip2-1.0.5-1.el5 ------------------ * Thu Jan 08 2009 Jeff Gilchrist - 1.0.5-1 - Release 1.0.5 * Sun Dec 21 2008 Jeff Gilchrist - 1.0.4-1 - Release 1.0.4 * Fri Oct 31 2008 Jeff Gilchrist - 1.0.3-1 - Release 1.0.3 - Added support for SUSE RPM build - Added symlink for pbzcat pdns-2.9.22-3.el5 ----------------- * Mon Jan 26 2009 Ruben Kerkhof 2.9.22-3 - Upstream released new version * Mon Nov 17 2008 Ruben Kerkhof 2.9.21.2-1 - Upstream released new version perl-Algorithm-Annotate-0.10-6.el5 ---------------------------------- * Thu Mar 06 2008 Tom "spot" Callaway - 0.10-6 - rebuild for new perl perl-B-Utils-0.07-2.el5 ----------------------- * Mon Dec 08 2008 Iain Arnell 0.07-2 - BR Test::Signature perl-Class-Inspector-1.17-1.el5 ------------------------------- * Fri Aug 17 2007 Ralf Cors?pius - 1.17-1 - Upstream update. perl-Convert-UUlib-1.11-1.el5 ----------------------------- * Fri Jul 11 2008 - 1:1.11-1 ? Fedora 10 alpha general package cleanup * Sat May 31 2008 Robert Scheck - 1:1.09-5 - Fixed %check section in order to get the package built perl-CSS-Squish-0.07-2.el5 -------------------------- * Wed Mar 05 2008 Tom "spot" Callaway 0.07-2 - rebuild for new perl perl-Data-Dump-Streamer-2.08-1.el5 ---------------------------------- * Fri Dec 05 2008 Iain Arnell 2.08-1 - Specfile autogenerated by cpanspec 1.77. - strip private provides/requires perl-DDL-Oracle-1.11-1.el5 -------------------------- * Tue Jan 13 2009 Milan Zazrivec 1.11-1 - initial packaging perl-Devel-StackTrace-1.20-1.el5 -------------------------------- * Sun Feb 01 2009 Xavier Lamien - 1.20-1 - Update release. perl-Heap-0.80-1.el5 -------------------- * Wed Aug 08 2007 Patrice Dumas 0.80-1 - update to 0.80 perl-HTML-TokeParser-Simple-3.15-1.el5 -------------------------------------- * Tue Nov 18 2008 Iain Arnell 3.15-1 - Specfile autogenerated by cpanspec 1.77. perl-libwhisker2-2.4-3.el5 -------------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 2.4-3 - Fix patch to really include lw1 bridge perl-Math-FFT-1.28-1.el5 ------------------------ * Wed Jun 25 2008 Miroslav Suchy 1.28-1 - Specfile autogenerated by cpanspec 1.77. perl-MD5-2.03-1.el5 ------------------- * Wed Oct 25 2006 Andreas Thienemann 2.03-1 - Specfile autogenerated by cpanspec 1.69. perl-mogilefs-server-2.30-1.el5 ------------------------------- * Mon Jan 19 2009 Ruben Kerkhof 2.30-1 - Upstream released new version perl-Net-LibIDN-0.11-1.el5 -------------------------- * Sun Jan 25 2009 Robert Scheck 0.11-1 - Upgrade to 0.11 * Thu Mar 06 2008 Tom "spot" Callaway 0.10-2 - Rebuild for new perl perl-Network-IPv4Addr-0.05-13.el5 --------------------------------- * Thu Jan 29 2009 Dennis Gilmore - 0.05-13 - remove OPTIMIZE for cleanliness sake - fix up source0 url * Wed Jan 28 2009 Dennis Gilmore - 0.05-12 - clean up spec file perl-Parse-RecDescent-1.96-1.el5 -------------------------------- * Mon Feb 02 2009 Stepan Kasal - 1.96-1 - new upstream version * Wed Feb 27 2008 Tom "spot" Callaway - 1.95.1-5 - Rebuild for perl 5.10 (again) * Sun Jan 20 2008 Tom "spot" Callaway - 1.95.1-4 - rebuild for new perl * Wed Nov 14 2007 Robin Norwood - 1.95.1-3 - Apply fixes from package review: - Remove BR: perl - Use iconv to convert file to utf-8 - Include BR: perl(Test::Pod) - Fix old changelog entry - Resolves: bz#226274 * Tue Oct 16 2007 Tom "spot" Callaway - 1.95.1-2 - add BR: perl(version), perl(Test::More) * Tue Oct 16 2007 Tom "spot" Callaway - 1.95.1-1 - bump to 1.95.1 - correct license tag (now under perl license) - add BR: perl(ExtUtils::MakeMaker) * Fri Jul 20 2007 Robin Norwood - 1.94-6.fc8 - Bring fixes from EPEL build into F8 - Fix minor specfile issues - Package the docs as well perl-Sub-Override-0.08-2.el5 ---------------------------- * Wed Nov 19 2008 Iain Arnell 0.08-2 - BR Test::Pod and Test::Pod::Coverage perl-Test-Perl-Critic-1.01-1.el5 -------------------------------- * Sat Jan 27 2007 Jose Pedro Oliveira - 1.01-1 - Update to 1.01. perl-Test-Signature-1.10-2.el5 ------------------------------ * Sun Dec 07 2008 Iain Arnell 1.10-2 - remove explicit requires perl-XML-Filter-BufferText-1.01-2.el5 ------------------------------------- * Sat Mar 17 2007 Andreas Thienemann 1.01-2 - Fixed dependencies php-pear-Cache-Lite-1.7.5-1.el5 ------------------------------- * Fri Jan 09 2009 Remi Collet 1.7.5-1 - update to 1.7.5 podcatcher-3.1.4-3.el5 ---------------------- * Mon Jan 05 2009 Christof Damian 3.1.4-3 - add repoid for download link and use name macro too - removed unused macros poweradmin-2.1.2-2.el5 ---------------------- * Mon Jan 19 2009 Ruben Kerkhof - 2.1.2-2 - Review fixes (#480552) * Sun Jan 18 2009 Ruben Kerkhof - 2.1.2-1 - Initial import python-BeautifulSoup-3.0.7a-3.el5 --------------------------------- * Mon Jan 12 2009 kwizart < kwizart at gmail.com > - 3.0.7a-3 - ReTag python-configobj-4.4.0-2.el5 ---------------------------- * Tue Feb 19 2008 Luke Macken - 4.4.0-2 - Bump and rebuild to fix a broken upgrade path python-dns-1.6.0-2.el5 ---------------------- * Fri Aug 29 2008 Tom "spot" Callaway - 1.6.0-2 - fix license tag python-fedora-0.3.9.1-2.el5 --------------------------- * Tue Feb 10 2009 Toshio Kuratomi - 0.3.9.1-2 - Another python-2.4 compatibility fix. * Mon Feb 09 2009 Toshio Kuratomi - 0.3.9.1-1 - Fix for python-2.4 compatibility * Sun Feb 08 2009 Toshio Kuratomi - 0.3.9-1 - New upstream with important bugfixes. * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 0.3.8-2 - Rebuild for Python 2.6 * Thu Nov 20 2008 Toshio Kuratomi - 0.3.8-1 - New upstream with pycurl client backend, more fas methods, and bodhi bugfix. python-ldaphelper-1.0.1-1.el5 ----------------------------- * Sat Jan 03 2009 Jon Stanley - 1.0.1-1 - update to 1.0.1 and new upstream python-libgmail-0.1.8-2.el5 --------------------------- * Tue Dec 11 2007 Michael Stahnke - 0.1.8-2 - Updated to proper license tag python-libgmail-docs-0.3-6.el5 ------------------------------ * Sun Jan 27 2008 Michael Stahnke - 0.3-6 - Excluded *.pyc *.pyo in %doc python-progressbar-2.2-5.el5 ---------------------------- * Thu Jan 08 2009 Christof Damian 2.2-5 - don't include sitelib in files python-ruledispatch-0.5a0-0.8.svnr2306.el5 ------------------------------------------ * Sat Dec 08 2007 Luke Macken 0.5a0-0.5.svn2305 - 0.5a0.dev-r2306 python-turboflot-0.1.0-1.el5 ---------------------------- * Sat Mar 08 2008 Luke Macken - 0.1.0-1 - Update to jQuery 1.2.3 and flot 0.4 pywebdav-0.8-2.el5 ------------------ * Tue Jan 20 2009 Dan Hor?k 0.8-2 - add PyDAVServer as an example into docs qmmp-0.2.3-2.el5 ---------------- * Thu Jan 15 2009 Karel Volny 0.2.3-2 - version for EPEL - adjusted BuildRequires to match EPEL - disabled FLAC, the older version is not compatible - patched for using qt4-4.2 (thanks to Ilya Kotov) R-car-1.2-2.el5 --------------- * Wed Feb 13 2008 Orion Poplawski 1.2-2 - Fix file permissions, line endings and encoding ris-linux-0.4-4.el5 ------------------- * Wed Jan 14 2009 Jeroen van Meeuwen - 0.4-4 - Rebuild for review (#469052) rpmlint-0.85-3.el5.1 -------------------- * Thu Feb 05 2009 Manuel Wolfshant - 0.85-3.1 - Bump release to express relationship with the rawhide version. No other changes. * Sat Jan 24 2009 Manuel Wolfshant - 0.85-1 - Sync with Fedora rawhide version 0.85-3, including: -- Update to upstream version 0.85 -- Apply upstream patch to load all *config from /etc/rpmlint. - Sync Fedora license list as Wiki revision 1.34 - Filter out "filename-too-long-for-joliet" and "symlink-should-be-*" warnings in default config. rt3-3.6.7-1.el5 --------------- * Sat Jan 10 2009 Xavier Bachelot - 3.6.7-1 - Update to 3.6.7 (BZ 481163 - CVE-2008-3502). - R: perl(CSS::Squish). - Add %defattr() to rt3-mailgate. rtpproxy-1.2-0.3.beta.200901120.el5 ----------------------------------- * Tue Jan 27 2009 Peter Lemenkov - 1.2-0.3.beta.200901120 - Snapshot 1.2.beta.200901120 - Added sysconfig file * Mon Oct 06 2008 Peter Lemenkov - 1.2-0.2.alpha.200807211 - Added missing BuildRequires - Added init-script * Wed Aug 13 2008 Peter Lemenkov - 1.2-0.1.alpha.200807211 - Snapshot 1.2.alpha.200807211 rubygem-restr-0.4.0-1.el5 ------------------------- * Tue Dec 16 2008 Jeroen van Meeuwen - 0.4.0-1 - Package for review sbackup-0.10.5-5.el5 -------------------- * Fri Jan 16 2009 Simon Wesp - 0.10.5-5 - Add ownage for cron-files - Correct patch0 - Add patch1 - Correct desktopfiles superiotool-0-0.15.20090202svn3827.el5 -------------------------------------- * Mon Feb 02 2009 Peter Lemenkov 0-0.15.20090202svn3827 - Added register map based on NSC PC87392 datasheet. - Add detection support for ITE IT8228E, IT8711F, IT8722F, IT8761E, IT8780F, and Fintek F71863FG. supybot-fedora-0.2.3-1.el5 -------------------------- * Sun Jan 25 2009 Jon Stanley - 0.2.3-1 - New upstream 0.2.3 * Sun Jan 11 2009 Jon Stanley - 0.2.2-1 - New upstream 0.2.2 tbcload-1.4-6.20061030cvs.el5 ----------------------------- * Wed Jan 28 2009 Wart 1.4-6.20061030cvs - Move out of tcl-specific directory due to multi-arch problems - Rebuild for EPEL-4 tclchecker-1.4-4.20061030cvs.el5 -------------------------------- * Wed Jan 28 2009 Wart 1.4-4.20061030cvs - Rebuild for EPEL4 tclcompiler-1.5-4.20061030cvs.el5 --------------------------------- * Wed Jan 28 2009 Wart 1.5-4.20061030cvs - Rebuild for EPEL4 tcldebugger-1.4-6.20061030cvs.el5 --------------------------------- * Wed Jan 28 2009 Wart 1.4-6.20061030cvs - Rebuild for EPEL4 tclparser-1.4-3.20061030cvs.el5 ------------------------------- * Wed Jan 28 2009 Wart 1.4-3.20061030cvs - Rebuild for EPEL4 tclpro-1.5.0-11.20061030cvs.el5 ------------------------------- * Wed Jan 28 2009 Wart 1.5.0-11.20061030cvs - Rebuild for EPEL4 trac-0.10.5-2.el5 ----------------- * Thu Feb 05 2009 Jesse Keating - 0.10.5-2 - Add a patch to deal with GeneratorExit, which is a python-2.5ism (#458236) txt2tags-2.5-5.el5 ------------------ * Thu Dec 04 2008 Ignacio Vazquez-Abrams - 2.5-5 - Rebuild for Python 2.6 udns-0.0.9-3.el5 ---------------- * Sun Sep 14 2008 Adrian Reber - 0.0.9-3 - removed rblcheck binary to resolve conflict with package rblcheck unbound-1.0.2-5.el5 ------------------- * Wed Oct 22 2008 Paul Wouters - 1.0.2-5 - Only call ldconfig in -libs package - Move configure into build section - devel subpackage should only depend on libs subpackage uriparser-0.7.1-6.el5 --------------------- * Sat Sep 06 2008 Rakesh Pandit 0.7.1-6 - changed document file handling in spec, used better method - %doc wine-1.0.1-1.el5 ---------------- * Thu Oct 23 2008 Andreas Bierfert - 1.0.1-1 - version upgrade xine-lib-1.1.16.1-1.el5 ----------------------- * Fri Jan 23 2009 Rex Dieter - 1.1.16.1-1 - xine-lib-1.1.16.1 - include avsync patch (#470568) * Sun Jan 18 2009 Rex Dieter - 1.1.16-2 - drop deepbind patch (#480504) - caca support (EPEL) * Wed Jan 07 2009 Kevin Kofler - 1.1.16-1.1 - patch for old libcaca in F9- Changes in Fedora EPEL testing/5: augeas-0.4.0-1.el5 ------------------ * Fri Feb 06 2009 David Lutterkort - 0.4.0-1 - New version backup-manager-0.7.8-1.el5 -------------------------- * Sat Feb 07 2009 Guillaume Kulakowski - 0.7.8-1 - Update to 0.7.8 - Remove genisoimage requirement dnssec-conf-1.15-1.el5 ---------------------- * Mon Feb 09 2009 Paul Wouters - 1.15-1 - Upgraded to new upstream. Added INSTALL to doc section fetchlog-1.2-1.el5 ------------------ * Wed Feb 11 2009 Paul Wouters - 1.2-1 - Updated to new upstream fvwm-2.5.26-2.el5.2 ------------------- * Fri Feb 06 2009 Adam Goode - 2.5.26-2.2 - ExcludeArch ppc, there is no Client RHEL for PPC * Fri Feb 06 2009 Adam Goode - 2.5.26-2.1 - Change Requires for EL-5 garmindev-0-0.3.20090208svn1152.el5 ----------------------------------- * Sun Feb 08 2009 Dan Hor?k 0-0.3.20090208svn1152 - update to revision 1152 - adds support for eTrex LegendHCx, eTrexH, eTrex Legend * Wed Nov 19 2008 Dan Hor?k 0-0.2.20081117svn928 - provide garmindev(interface) = 1.15 for correct interraction with QLandkarteGT mingw32-atk-1.25.2-5.el5 ------------------------ * Fri Feb 06 2009 Richard W.M. Jones - 1.25.2-5 - Include license file. * Fri Jan 30 2009 Richard W.M. Jones - 1.25.2-4 - Remove gtk-doc. - Fix defattr line. - Requires pkgconfig. - Remove the atk*.def file. * Fri Jan 23 2009 Richard W.M. Jones - 1.25.2-1 - Rebase to latest Fedora native version 1.25.2. - Use find_lang macro. - Use smp_mflags. - Fix URL. - Fix Source URL. mingw32-libgcrypt-1.4.4-1.el5 ----------------------------- * Fri Feb 06 2009 Richard W.M. Jones - 1.4.4-1 - Update to Fedora native version 1.4.4: . Remove potentially patented ECC support. . Do not abort when the fips mode kernel flag is inaccessible due to permissions (#470219). - For review (Michel Alexandre Salim): . Remove *.def file. . Make description clearer. . Distribute the license files. - The license for binaries is GPLv2+, so update the license field. - Add check section (disabled by default). - Why did we set PATH before configure? Removed. - Added BR mingw32-dlfcn suggested by auto-buildrequires. * Fri Jan 23 2009 Richard W.M. Jones - 1.4.3-3 - Use _smp_mflags. - Disable static libraries. mingw32-openssl-0.9.8j-2.el5 ---------------------------- * Mon Feb 02 2009 Levente Farkas - 0.9.8j-2 - Various build fixes. * Wed Jan 28 2009 Levente Farkas - 0.9.8j-1 - update to new upstream version. NetworkManager-openvpn-0.7.0-18.svn11.el5.1 ------------------------------------------- * Sat Feb 07 2009 Lubomir Rintel 1:0.7.0-18.svn11.1 - Adjust for RHEL 5.3, older and less capable keyring manager * Sat Jan 03 2009 Dan Williams 1:0.7.0-18.svn11 - Rebuild for updated NetworkManager - Fix some specfile issues (rh #477149) * Sat Dec 20 2008 Christoph H?ger 0.7.0-17.svn4326 - removed libpng-devel from BuildRequires, added /usr/share/gnome-vpn-properties/openvpn/ (rh #477149) * Fri Nov 21 2008 Dan Williams 1:0.7.0-16.svn4326 - Rebuild for updated NetworkManager * Mon Oct 27 2008 Dan Williams 1:0.7.0-16.svn4229 - Rebuild for updated NetworkManager NetworkManager-pptp-0.7.0-2.svn16.el5 ------------------------------------- * Sat Feb 07 2009 Lubomir Rintel 1:0.7.0-2.svn16 - Adjust for RHEL 5.3 * Sat Jan 03 2009 Dan Williams 1:0.7.0-1.svn16 - Rebuild for updated NetworkManager - Fix some specfile issues (rh #477153) - Allow the EAP authentication method * Fri Nov 21 2008 Dan Williams 1:0.7.0-12.svn4326 - Rebuild for updated NetworkManager * Wed Oct 29 2008 Dan Williams 1:0.7.0-12.svn4229 - Fix hang in auth dialog (rh #467007) * Mon Oct 27 2008 Dan Williams 1:0.7.0-11.svn4229 - Rebuild for updated NetworkManager - Ensure that certain PPP options are always overriden * Sun Oct 12 2008 Dan Williams 1:0.7.0-11.svn4178 - Rebuild for updated NetworkManager - Allow changing passwords from the connection editor * Sun Oct 05 2008 Lubomir Rintel 1:0.7.0-11.svn4027 - Add pptp dependency (#465644) * Fri Aug 29 2008 Dan Williams 1:0.7.0-10.svn4027 - Resurrect from the dead perl-Class-Can-0.01-1.el5 ------------------------- * Thu Feb 05 2009 Ian Burrell 0.01-1 - Specfile autogenerated by cpanspec 1.77. perl-Class-Exporter-0.03-2.el5 ------------------------------ * Fri Feb 06 2009 Ian Burrell - 0.03-2 - Fix spurious execute permissions * Thu Feb 05 2009 Ian Burrell 0.03-1 - Specfile autogenerated by cpanspec 1.77. perl-HTML-DOMbo-3.10-1.el5 -------------------------- * Thu Feb 05 2009 Ian M. Burrell - 3.10-1 - BuildRequire HTML::Tree - Specfile autogenerated by cpanspec 1.77. perl-Lingua-Stem-Snowball-0.952-1.el5 ------------------------------------- * Thu Feb 05 2009 Ian Burrell 0.952-1 - Specfile autogenerated by cpanspec 1.77. perl-Lingua-StopWords-0.09-2.el5 -------------------------------- * Fri Feb 06 2009 Ian Burrell - 0.09-2 - BuildRequires Test::More * Thu Feb 05 2009 Ian Burrell 0.09-1 - Specfile autogenerated by cpanspec 1.77. perl-NOCpulse-SetID-1.6.9-1.el5 ------------------------------- * Mon Feb 09 2009 Miroslav Such? 1.6.9-1 - 466906 - apply comments from package review perl-XML-Generator-1.01-3.el5 ----------------------------- * Wed Jan 28 2009 Dennis Gilmore - 1.01-3 - BR perl(XML::DOM) - remove OPTIMIZE option from %build * Wed Jan 28 2009 Dennis Gilmore - 1.01-2 - add back XML::Generator::DOM * Wed Jan 28 2009 Dennis Gilmore - 1.01-1 - spec file cleanups - update to 1.01 python-louie-1.1-4.el5 ---------------------- * Sun Feb 08 2009 Matthias Saou 1.1-4 - Add python-nose >= 0.8.3 requirement taken from the egg file. * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 1.1-3 - Rebuild for Python 2.6 * Tue Aug 28 2007 Matthias Saou 1.1-2 - Update python-setuptools build requirement to new python-setuptools-devel. python-pygooglechart-0.2.1-3.el5 -------------------------------- * Tue Jan 27 2009 Michael Stahnke - 0.2.1-3 - Removing check stanza, as it requires internet connectivity * Fri Jan 23 2009 Michael Stahnke - 0.2.1-2 - Updates per review. Adding COPYING to doc and adding check section. * Fri Jan 23 2009 Michael Stahnke - 0.2.1-1 - Initial Package python-uuid-1.30-3.el5 ---------------------- * Sat Feb 07 2009 Ray Van Dolson - 1.30-3 - Removed explicit python requires * Wed Jan 21 2009 Ray Van Dolson - 1.30-2 - Changed to noarch pyvnc2swf-0.9.5-1.el5 --------------------- * Tue Feb 10 2009 David Timms 0.9.5-1 - update to new upstream release - drop vnc2swf-edit usage exit patch, no longer needed trickle-1.07-6.el5 ------------------ * Fri Feb 06 2009 Nicoleau Fabien 1.07-6 - Add a fix for bug #484065 (CVE-2009-0415) * Thu Aug 28 2008 Manuel Wolfshant 1.07-5 - modify trickle-1.07-include_netdb.patch to adjust for building with fuzz=0 * Sun Jun 29 2008 Nicoleau Fabien 1.07-4 - rebuild for new libevent unbound-1.2.0-4.el5 ------------------- * Sun Feb 08 2009 Paul Wouters - 1.1.16.2-1 - xine-lib-1.1.16.2 * Mon Feb 09 2009 Rex Dieter - 1.1.16.1-4 - gapless-race-fix patch (kdebug#180339) * Sat Feb 07 2009 Rex Dieter - 1.1.16.1-3 - safe-audio-pause patch (kdebug#180339) * Mon Jan 26 2009 Rex Dieter - 1.1.16.1-2 - Provides: xine-lib(plugin-abi)%{?_isa} = %{abiver} - touchup Summary/Description Changes in Fedora EPEL 4: alpine-2.00-1.el4 ----------------- * Wed Aug 27 2008 Rex Dieter 2.00-1 - alpine-2.00 (#460332) augeas-0.3.6-2.el4 ------------------ * Mon Jan 26 2009 David Lutterkort - 0.3.6-1 - New version beesu-2.1-1.el4 --------------- * Thu Jan 29 2009 Tom "spot" Callaway 2.1-1 - slight package cleanup from Bee cas-0.13-119.el4 ---------------- * Wed Jan 21 2009 Adam Stokes - 0.13-119 - ExcludeArch ppc since crash is not available in this scenario cobbler-1.4.1-1.el4 ------------------- * Fri Jan 09 2009 Michael DeHaan - 1.4.1-1 - Upstream changes (see CHANGELOG) * Fri Dec 19 2008 Michael DeHaan - 1.4.0-4 - Fix for rawhide python requirement. collectl-3.1.3-1.el4 -------------------- * Sat Jan 24 2009 Dan Horak 3.1.3-1 - upgrade to upstream version 3.1.3 * Tue Jan 20 2009 Dan Horak 3.1.2-1 - upgrade to upstream version 3.1.2 ctapi-cyberjack-3.3.0-4.el4 --------------------------- * Sun Jan 04 2009 Frank B?ttner - 3.3.0-4 - fix missing dependency (libsysfs-devel) for EPEL4 * Sun Jan 04 2009 Frank B?ttner - 3.3.0-3 - fix missing dependency (libsysfs-devel) * Mon Dec 29 2008 Frank B?ttner - 3.3.0-2 - no changes * Mon Dec 29 2008 Frank B?ttner - 3.3.0-1 - update to 3.3.0 digitemp-3.6.0-1.el4 -------------------- * Sun Jan 25 2009 Robert Scheck 3.6.0-1 - Upgrade to 3.6.0 * Sun Feb 10 2008 Robert Scheck 3.5.0-3 - Rebuilt against gcc 4.3 duplicity-0.5.06-1.el4 ---------------------- * Sun Jan 25 2009 Robert Scheck 0.5.06-1 - Upgrade to 0.5.06 (#481489) erlang-R11B-2.3.el4 ------------------- * Sun Dec 31 2006 Gerard Milmeister - R11B-2.3 - remove buildroot from installed files fail2ban-0.6.2-3.el4 -------------------- * Thu Jan 29 2009 Adam Miller - 0.6.2-3 - Rebuild for EPEL - EL4 freehoo-3.5.3-1.el4 ------------------- * Wed Jan 21 2009 Ray Van Dolson - 3.5.3-1 - Upstream released 3.5.3 fvwm-2.5.26-2.el4.2 ------------------- * Thu Feb 05 2009 Adam Goode - 2.5.26-2.2 - Change Requires for EL-4 * Thu Feb 05 2009 Adam Goode - 2.5.26-2.1 - Change BuildRequires for EL-4 ganglia-3.0.7-1.el4 ------------------- * Tue Jan 20 2009 Kostas Georgiou - 3.0.7-1 - New upstream release - [480236] fix for a buffer overflow and an off-by-one bug in gmetad gromacs-4.0.3-4.el4 ------------------- * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-4 - Retry fixing gmxdemo. * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-3 - Fixed gmxdemo. * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-2 - Fix EPEL 4 build. * Mon Jan 19 2009 Jussi Lehtola - 4.0.3-1 - Update to 4.0.3. * Wed Jan 14 2009 Jussi Lehtola - 4.0.2-7 - Update manual to latest version. - Removed Requires: blas and lapack. * Mon Nov 10 2008 Jussi Lehtola - 4.0.2-6 - Update to 4.0.2. hatools-2.00-1.el4 ------------------ * Thu Jan 29 2009 Oliver Falk - 2.00-1 - Initial specfile htop-0.8.1-3.el4 ---------------- * Thu Feb 05 2009 Adam Miller - 0.8.1-3 - "Tree view doesn't work with threads hidden" fixed (#481072) - Rafal issued the fix, this is just the update and build for EPEL jasper-1.900.1-9.el4 -------------------- * Sun Jan 25 2009 Rex Dieter 1.900.1-9 - patch for "jpc_dec_tiledecode: Assertion `dec->numcomps == 3' failed) (#481284, #481291) * Fri Feb 08 2008 Rex Dieter 1.900.1-8 - respin (gcc43) * Mon Oct 15 2007 Rex Dieter 1.900.1-7 - -libs: %post/%postun -p /sbin/ldconfig * Mon Sep 17 2007 Rex Dieter 1.900.1-6 - -libs: -Requires: %name - -devel: +Provides: libjasper-devel - drop (unused) geojasper bits * Wed Aug 22 2007 Rex Dieter 1.900.1-4 - -libs subpkg to be multilib friendlier - -utils subpkg for non-essential binaries jiv, tmrdemo (#244153) * Fri Aug 17 2007 Rex Dieter 1.900.1-3 - License: JasPer koan-1.4.1-1.el4 ---------------- * Fri Jan 09 2009 Michael DeHaan - 1.4.1-1 - Upstream changes (see CHANGELOG) * Mon Dec 22 2008 Michael DeHaan - 1.4.0-4 - Fix python(abi) requirement some more * Mon Dec 22 2008 Michael DeHaan - 1.4.0-3 - Fix python(abi) requirement libmp4v2-1.5.0.1-6.el4 ---------------------- * Tue Feb 19 2008 Fedora Release Engineering - 1.5.0.1-6 - Autorebuild for GCC 4.3 libsieve-2.2.7-1.el4 -------------------- * Wed Jan 28 2009 Bernard Johnson - 2.2.7-1 - v 2.2.7 - package pkgconfig file * Mon Feb 18 2008 Fedora Release Engineering - 2.2.6-3 - Autorebuild for GCC 4.3 libsigsegv-2.4-6.el4 -------------------- * Fri Feb 22 2008 Rex Dieter 2.4-6 - multiarch conflicts (#342391) - -static subpkg munin-1.2.6-3.el4 ----------------- * Mon Aug 11 2008 Kevin Fenzi - 1.2.6-3 - Move Munin/Plugin.pm to the node subpackage (fixes #457403) * Sat Jul 12 2008 Kevin Fenzi - 1.2.6-2 - Apply postfix patch (fixes #454159) - Add perl version dep and remove unneeded perl-HTML-Template (fixes #453923) * Fri Jun 20 2008 Kevin Fenzi - 1.2.6-1 - Upgrade to 1.2.6 * Tue May 20 2008 Kevin Fenzi - 1.2.5-5 - Rebuild for new perl net6-1.3.5-1.el4 ---------------- * Sat Jun 16 2007 Luke Macken - 1.3.5-1 - 1.3.5 nikto-1.36-3.el4 ---------------- * Wed May 30 2007 Sindre Pedersen Bj?rdal - 1.36-3 - Add sed magic to really replace nikto-1.36-config.patch nopaste-2835-2.el4 ------------------ * Sat Jan 10 2009 Simon Wesp - 2835-2 - Correct License to GPLv2 - Remove doc in files-section nrpe-2.12-6.el4 --------------- * Mon Feb 02 2009 Peter Lemenkov - 2.12-6 - Fixed BZ# 449174 - Clean up (in order to disable rpmlint warnings) * Sat Jan 17 2009 Tomas Mraz - 2.12-5 - rebuild with new openssl * Sun Dec 21 2008 Mike McGrath - 2.12-4 - Added some doc lines for ticket 477527 obby-0.4.4-2.el4 ---------------- * Wed Dec 12 2007 Luke Macken - 0.4.4-2 - Remove avahi-devel requirement and disable zeroconf ocsinventory-1.02-0.10.rc3.el4.1 -------------------------------- * Sun Jan 18 2009 Remi Collet 1.02-0.10.rc3.el4.1 - fix php-xml > php-domxml in EL-4 pbzip2-1.0.5-1.el4 ------------------ * Thu Jan 08 2009 Jeff Gilchrist - 1.0.5-1 - Release 1.0.5 * Sun Dec 21 2008 Jeff Gilchrist - 1.0.4-1 - Release 1.0.4 * Fri Oct 31 2008 Jeff Gilchrist - 1.0.3-1 - Release 1.0.3 - Added support for SUSE RPM build - Added symlink for pbzcat perl-Convert-UUlib-1.11-1.el4 ----------------------------- * Fri Jul 11 2008 - 1:1.11-1 ? Fedora 10 alpha general package cleanup * Sat May 31 2008 Robert Scheck - 1:1.09-5 - Fixed %check section in order to get the package built perl-Crypt-OpenSSL-Bignum-0.04-4.el4 ------------------------------------ * Wed Mar 05 2008 Tom "spot" Callaway 0.04-4 - rebuild for new perl perl-Crypt-OpenSSL-Random-0.04-6.el4 ------------------------------------ * Tue Jun 17 2008 Wes Hardaker - 0.04-6 - exclude x86_64 because openssl on that arch has broken deps perl-Crypt-OpenSSL-RSA-0.25-7.el4 --------------------------------- * Thu Jun 19 2008 Wes Hardaker - 0.25-7 - Exclude x86_64 till it's fixed perl-Filesys-Df-0.92-3.el4 -------------------------- * Wed Jul 30 2008 Miroslav Suchy 0.92-3 - Add build dependency on MakeMaker perl-libwhisker2-2.4-3.el4 -------------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 2.4-3 - Fix patch to really include lw1 bridge perl-Math-FFT-1.28-1.el4 ------------------------ * Wed Jun 25 2008 Miroslav Suchy 1.28-1 - Specfile autogenerated by cpanspec 1.77. perl-MD5-2.03-2.el4 ------------------- * Thu Mar 06 2008 Tom "spot" Callaway - 2.03-2.1 Rebuild for new perl perl-Net-LibIDN-0.11-1.el4 -------------------------- * Sun Jan 25 2009 Robert Scheck 0.11-1 - Upgrade to 0.11 * Thu Mar 06 2008 Tom "spot" Callaway 0.10-2 - Rebuild for new perl perl-String-CRC32-1.4-1.el4 --------------------------- * Thu Apr 20 2006 Paul Howarth 1.4-1 - Update to 1.4 perl-Test-Pod-Coverage-1.08-1.el4 --------------------------------- * Thu Jan 26 2006 Jose Pedro Oliveira - 1.08-1 - Update to 1.08. perl-XML-Filter-BufferText-1.01-4.el4 ------------------------------------- * Tue Jan 29 2008 Tom "spot" Callaway 1.01-4 - BR perl(Test::More) poweradmin-2.1.2-2.el4.1 ------------------------ * Mon Feb 02 2009 Ruben Kerkhof - 2.1.2-2.el4.1 - mdb2 drivers for mysql and postgresql are not available on el4 * Mon Jan 19 2009 Ruben Kerkhof - 2.1.2-2 - Review fixes (#480552) * Sun Jan 18 2009 Ruben Kerkhof - 2.1.2-1 - Initial import python-boto-1.0a-1.el4.1 ------------------------ * Wed Jan 21 2009 Robert Scheck 1.0a-1.1 - Added patch from Matthew Farrellee to get S3 and EC2 working python-dateutil-1.1-6.el4 ------------------------- * Tue Jan 13 2009 Michal Nowak 1.1-6 - fixed the license field and patch0 line python-ldaphelper-1.0.1-1.el4 ----------------------------- * Sat Jan 03 2009 Jon Stanley - 1.0.1-1 - update to 1.0.1 and new upstream R-car-1.2-2.el4 --------------- * Wed Feb 13 2008 Orion Poplawski 1.2-2 - Fix file permissions, line endings and encoding superiotool-0-0.15.20090202svn3827.el4 -------------------------------------- * Mon Feb 02 2009 Peter Lemenkov 0-0.15.20090202svn3827 - Added register map based on NSC PC87392 datasheet. - Add detection support for ITE IT8228E, IT8711F, IT8722F, IT8761E, IT8780F, and Fintek F71863FG. supybot-0.83.3-8.el4 -------------------- * Sun Jan 18 2009 Ricky Zhou - 0.83.3-8 - Remove python-twisted-core and python-twisted-names in EL-4. tbcload-1.4-6.20061030cvs.el4 ----------------------------- * Wed Jan 28 2009 Wart 1.4-6.20061030cvs - Move out of tcl-specific directory due to multi-arch problems - Rebuild for EPEL-4 tclchecker-1.4-4.20061030cvs.el4 -------------------------------- * Wed Jan 28 2009 Wart 1.4-4.20061030cvs - Rebuild for EPEL4 tclcompiler-1.5-4.20061030cvs.el4 --------------------------------- * Wed Jan 28 2009 Wart 1.5-4.20061030cvs - Rebuild for EPEL4 tcldebugger-1.4-6.20061030cvs.el4 --------------------------------- * Wed Jan 28 2009 Wart 1.4-6.20061030cvs - Rebuild for EPEL4 tclparser-1.4-3.20061030cvs.el4 ------------------------------- * Wed Jan 28 2009 Wart 1.4-3.20061030cvs - Rebuild for EPEL4 tclpro-1.5.0-11.20061030cvs.el4 ------------------------------- * Wed Jan 28 2009 Wart 1.5.0-11.20061030cvs - Rebuild for EPEL4 txt2tags-2.5-5.el4 ------------------ * Thu Dec 04 2008 Ignacio Vazquez-Abrams - 2.5-5 - Rebuild for Python 2.6 wine-1.0.1-1.el4 ---------------- * Sat Jan 17 2009 Andreas Bierfert - 1.0.1-1 - version upgrade Changes in Fedora EPEL testing/4: augeas-0.4.0-1.el4 ------------------ * Fri Feb 06 2009 David Lutterkort - 0.4.0-1 - New version perl-NOCpulse-SetID-1.6.9-1.el4 ------------------------------- * Mon Feb 09 2009 Miroslav Such? 1.6.9-1 - 466906 - apply comments from package review python-dns-1.6.0-3.el4 ---------------------- * Sat Nov 29 2008 Jeffrey C. Ollie - 1.6.0-3 - Rebuild for Python 2.6 python-louie-1.1-4.el4 ---------------------- * Sun Feb 08 2009 Matthias Saou 1.1-4 - Add python-nose >= 0.8.3 requirement taken from the egg file. * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 1.1-3 - Rebuild for Python 2.6 * Tue Aug 28 2007 Matthias Saou 1.1-2 - Update python-setuptools build requirement to new python-setuptools-devel. python-uuid-1.30-3.el4 ---------------------- * Sat Feb 07 2009 Ray Van Dolson - 1.30-3 - Removed explicit python requires * Wed Jan 21 2009 Ray Van Dolson - 1.30-2 - Changed to noarch trickle-1.07-6.el4 ------------------ * Fri Feb 06 2009 Nicoleau Fabien 1.07-6 - Add a fix for bug #484065 (CVE-2009-0415) * Thu Aug 28 2008 Manuel Wolfshant 1.07-5 - modify trickle-1.07-include_netdb.patch to adjust for building with fuzz=0 * Sun Jun 29 2008 Nicoleau Fabien 1.07-4 - rebuild for new libevent From fedora at leemhuis.info Thu Feb 12 18:39:50 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Feb 2009 19:39:50 +0100 Subject: Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside) In-Reply-To: <498ED546.3060806@leemhuis.info> References: <498ED546.3060806@leemhuis.info> Message-ID: <49946CF6.9000604@leemhuis.info> On 08.02.2009 13:51, Thorsten Leemhuis wrote: > I prepared the next testing -> stable move for EPEL4 and EPEL5. I plan > to actually do the move on 20090212 at around 06:00 UTC. Did the move earlier today. There were a lot of warnings like: ---- > python-ruledispatch > python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm -> ppc > WARNING: /srv/rpmbuild/epel/tree/epel/5/ppc/python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm already exists, ignoring new one ---- Here is the full list: epel4: obby-0.4.4-2.el4.src.rpm epel4: net6-1.3.5-1.el4.src.rpm epel4: perl-Filesys-Df-0.92-3.el4.src.rpm epel4: libmp4v2-1.5.0.1-6.el4.src.rpm epel4: perl-Test-Pod-Coverage-1.08-1.el4.src.rpm epel4: erlang-R11B-2.3.el4.src.rpm epel4: perl-String-CRC32-1.4-1.el4.src.rpm epel4: perl-Math-FFT-1.28-1.el4.src.rpm epel4: perl-XML-Filter-BufferText-1.01-4.el4.src.rpm epel5: python-ruledispatch-0.5a0-0.8.svnr2306.el5.src.rpm epel5: perl-Heap-0.80-1.el5.src.rpm epel5: perl-XML-Filter-BufferText-1.01-2.el5.src.rpm epel5: mingw32-w32api-3.12-8.el5.src.rpm epel5: python-dns-1.6.0-2.el5.src.rpm epel5: perl-Class-Inspector-1.17-1.el5.src.rpm epel5: python-configobj-4.4.0-2.el5.src.rpm epel5: perl-Test-Perl-Critic-1.01-1.el5.src.rpm epel5: python-libgmail-docs-0.3-6.el5.src.rpm epel5: dtc-1.1.0-1.el5.src.rpm epel5: net6-1.3.5-1.el5.src.rpm epel5: R-car-1.2-2.el5.src.rpm epel5: perl-Math-FFT-1.28-1.el5.src.rpm epel5: docbook2X-0.8.8-1.el5.src.rpm epel5: python-libgmail-0.1.8-2.el5.src.rpm epel5: perl-Algorithm-Annotate-0.10-6.el5.src.rpm epel5: python-turboflot-0.1.0-1.el5.src.rpm epel5: unbound-1.0.2-5.el5.src.rpm Does anybody mind if I delete those from testing? Or do we want to force rebuild on those to make sure we know which packages users have installed? And does anyone volunteer to tell packagers why doing something that leads to above problems is bad? CU knurd From paul at city-fan.org Thu Feb 12 20:22:53 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 12 Feb 2009 20:22:53 +0000 Subject: Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside) In-Reply-To: <49946CF6.9000604@leemhuis.info> References: <498ED546.3060806@leemhuis.info> <49946CF6.9000604@leemhuis.info> Message-ID: <20090212202253.144c9801@metropolis.intra.city-fan.org> On Thu, 12 Feb 2009 19:39:50 +0100 Thorsten Leemhuis wrote: > On 08.02.2009 13:51, Thorsten Leemhuis wrote: > > I prepared the next testing -> stable move for EPEL4 and EPEL5. I > > plan to actually do the move on 20090212 at around 06:00 UTC. > > Did the move earlier today. There were a lot of warnings like: > > ---- > > python-ruledispatch > > python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm -> ppc > > WARNING: /srv/rpmbuild/epel/tree/epel/5/ppc/python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm > > already exists, ignoring new one > ---- > > Here is the full list: > > epel4: obby-0.4.4-2.el4.src.rpm > epel4: net6-1.3.5-1.el4.src.rpm > epel4: perl-Filesys-Df-0.92-3.el4.src.rpm > epel4: libmp4v2-1.5.0.1-6.el4.src.rpm > epel4: perl-Test-Pod-Coverage-1.08-1.el4.src.rpm > epel4: erlang-R11B-2.3.el4.src.rpm > epel4: perl-String-CRC32-1.4-1.el4.src.rpm > epel4: perl-Math-FFT-1.28-1.el4.src.rpm > epel4: perl-XML-Filter-BufferText-1.01-4.el4.src.rpm > epel5: python-ruledispatch-0.5a0-0.8.svnr2306.el5.src.rpm > epel5: perl-Heap-0.80-1.el5.src.rpm > epel5: perl-XML-Filter-BufferText-1.01-2.el5.src.rpm > epel5: mingw32-w32api-3.12-8.el5.src.rpm > epel5: python-dns-1.6.0-2.el5.src.rpm > epel5: perl-Class-Inspector-1.17-1.el5.src.rpm > epel5: python-configobj-4.4.0-2.el5.src.rpm > epel5: perl-Test-Perl-Critic-1.01-1.el5.src.rpm > epel5: python-libgmail-docs-0.3-6.el5.src.rpm > epel5: dtc-1.1.0-1.el5.src.rpm > epel5: net6-1.3.5-1.el5.src.rpm > epel5: R-car-1.2-2.el5.src.rpm > epel5: perl-Math-FFT-1.28-1.el5.src.rpm > epel5: docbook2X-0.8.8-1.el5.src.rpm > epel5: python-libgmail-0.1.8-2.el5.src.rpm > epel5: perl-Algorithm-Annotate-0.10-6.el5.src.rpm > epel5: python-turboflot-0.1.0-1.el5.src.rpm > epel5: unbound-1.0.2-5.el5.src.rpm > > Does anybody mind if I delete those from testing? Or do we want to > force rebuild on those to make sure we know which packages users have > installed? And does anyone volunteer to tell packagers why doing > something that leads to above problems is bad? I think the cause of this may be that packages are not being removed from -testing after being pushed to stable, not because packagers are rebuilding without bumping release. My perl-String-CRC32 package seems to have been listed in just about every testing to stable move list since the end of 2007 and that's not because I keep rebuilding it - I don't! Paul. From mastahnke at gmail.com Thu Feb 12 20:36:05 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 12 Feb 2009 14:36:05 -0600 Subject: Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside) In-Reply-To: <20090212202253.144c9801@metropolis.intra.city-fan.org> References: <498ED546.3060806@leemhuis.info> <49946CF6.9000604@leemhuis.info> <20090212202253.144c9801@metropolis.intra.city-fan.org> Message-ID: <7874d9dd0902121236q73fc9daxf5d31f2921d4aa39@mail.gmail.com> > I think the cause of this may be that packages are not being removed > from -testing after being pushed to stable, not because packagers are > rebuilding without bumping release. Agreed, I think that is what has happened. Please remove. Thanks stahnma From fedora at leemhuis.info Fri Feb 13 05:47:58 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Feb 2009 06:47:58 +0100 Subject: Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside) In-Reply-To: <7874d9dd0902121236q73fc9daxf5d31f2921d4aa39@mail.gmail.com> References: <498ED546.3060806@leemhuis.info> <49946CF6.9000604@leemhuis.info> <20090212202253.144c9801@metropolis.intra.city-fan.org> <7874d9dd0902121236q73fc9daxf5d31f2921d4aa39@mail.gmail.com> Message-ID: <4995098E.5020103@leemhuis.info> On 12.02.2009 21:36, Michael Stahnke wrote: >> I think the cause of this may be that packages are not being removed >> from -testing after being pushed to stable, not because packagers are >> rebuilding without bumping release. > Agreed, I think that is what has happened. Clicking 10 or 20 seconds in the browser would have told you two it's not the case for at least some of the packages (I guess the majority, but I didn't check). Just picked the first one in the list: http://download.fedora.redhat.com/pub/epel/4/SRPMS/obby-0.4.4-2.el4.src.rpm 12-Dec-2007 14:55 http://download.fedora.redhat.com/pub/epel/testing/4/SRPMS/obby-0.4.4-2.el4.src.rpm 14-May-2008 11:18 And it are definitely different builds: [thl at thl ~]$ repoquery --repoid epel4 --qf '%{buildtime}' obby.x86_64 1197477479 [thl at thl ~]$ repoquery --repoid epel4-testing --qf '%{buildtime}' obby.x86_64 1210359424 [thl at thl ~]$ Spec files are identical, nevertheless that's not what we want. CU knurd From wolfy at nobugconsulting.ro Fri Feb 13 06:48:46 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 13 Feb 2009 08:48:46 +0200 Subject: Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside) In-Reply-To: <4995098E.5020103@leemhuis.info> References: <498ED546.3060806@leemhuis.info> <49946CF6.9000604@leemhuis.info> <20090212202253.144c9801@metropolis.intra.city-fan.org> <7874d9dd0902121236q73fc9daxf5d31f2921d4aa39@mail.gmail.com> <4995098E.5020103@leemhuis.info> Message-ID: <499517CE.50506@nobugconsulting.ro> Thorsten Leemhuis wrote: > > > On 12.02.2009 21:36, Michael Stahnke wrote: >>> I think the cause of this may be that packages are not being removed >>> from -testing after being pushed to stable, not because packagers are >>> rebuilding without bumping release. >> Agreed, I think that is what has happened. > > Clicking 10 or 20 seconds in the browser would have told you two it's > not the case for at least some of the packages (I guess the majority, > but I didn't check). Just picked the first one in the list: > > http://download.fedora.redhat.com/pub/epel/4/SRPMS/obby-0.4.4-2.el4.src.rpm > > 12-Dec-2007 14:55 > > http://download.fedora.redhat.com/pub/epel/testing/4/SRPMS/obby-0.4.4-2.el4.src.rpm > > 14-May-2008 11:18 > > And it are definitely different builds: > > [thl at thl ~]$ repoquery --repoid epel4 --qf '%{buildtime}' obby.x86_64 > 1197477479 > [thl at thl ~]$ repoquery --repoid epel4-testing --qf '%{buildtime}' > obby.x86_64 > 1210359424 > [thl at thl ~]$ > > Spec files are identical, nevertheless that's not what we want. /me does not get it. Does it mean that those packages passed twice the "make build" step ? And if the answer is "yes", why would that happen ? From fedora at leemhuis.info Fri Feb 13 07:13:14 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Feb 2009 08:13:14 +0100 Subject: Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside) In-Reply-To: <499517CE.50506@nobugconsulting.ro> References: <498ED546.3060806@leemhuis.info> <49946CF6.9000604@leemhuis.info> <20090212202253.144c9801@metropolis.intra.city-fan.org> <7874d9dd0902121236q73fc9daxf5d31f2921d4aa39@mail.gmail.com> <4995098E.5020103@leemhuis.info> <499517CE.50506@nobugconsulting.ro> Message-ID: <49951D8A.5060000@leemhuis.info> On 13.02.2009 07:48, Manuel Wolfshant wrote: > Thorsten Leemhuis wrote: >> On 12.02.2009 21:36, Michael Stahnke wrote: >>>> I think the cause of this may be that packages are not being removed >>>> from -testing after being pushed to stable, not because packagers are >>>> rebuilding without bumping release. >>> Agreed, I think that is what has happened. >> Clicking 10 or 20 seconds in the browser would have told you two it's >> not the case for at least some of the packages (I guess the majority, >> but I didn't check). Just picked the first one in the list: >> >> http://download.fedora.redhat.com/pub/epel/4/SRPMS/obby-0.4.4-2.el4.src.rpm >> >> 12-Dec-2007 14:55 >> >> http://download.fedora.redhat.com/pub/epel/testing/4/SRPMS/obby-0.4.4-2.el4.src.rpm >> >> 14-May-2008 11:18 >> >> And it are definitely different builds: >> >> [thl at thl ~]$ repoquery --repoid epel4 --qf '%{buildtime}' obby.x86_64 >> 1197477479 >> [thl at thl ~]$ repoquery --repoid epel4-testing --qf '%{buildtime}' >> obby.x86_64 >> 1210359424 >> [thl at thl ~]$ >> >> Spec files are identical, nevertheless that's not what we want. > > /me does not get it. Does it mean that those packages passed twice the > "make build" step ? Looks a lot like it. > And if the answer is "yes", why would that happen ? In above case: I guess someone just did something stupid. CU knurd From robert at fedoraproject.org Fri Feb 13 07:23:47 2009 From: robert at fedoraproject.org (Robert Scheck) Date: Fri, 13 Feb 2009 08:23:47 +0100 Subject: Mirror Manager and the way you get EPEL In-Reply-To: <7874d9dd0902111424y51bd0a80ob44419156404e76d@mail.gmail.com> References: <7874d9dd0902111424y51bd0a80ob44419156404e76d@mail.gmail.com> Message-ID: <20090213072347.GA25585@hurricane.linuxnetz.de> On Wed, 11 Feb 2009, Michael Stahnke wrote: > I guess I would like something like download.fedoraproject.org/epel > and it would take to me random epel mirror. What at http://download.fedoraproject.org/pub/epel/ is not working for you? Just type a few characters more to get /pub/epel/ into the URL and - voila, it works :) Greetings, Robert From buildsys at fedoraproject.org Fri Feb 13 17:54:51 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 13 Feb 2009 17:54:51 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-13 Message-ID: <20090213175451.66134188106@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 2 moodle-1.8.8-1.el5 python-crypto-2.0.1-4.el5.1 Packages built and released for Fedora EPEL testing/5: 7 cobbler-1.4.2-1.el5 koan-1.4.2-1.el5 NEW mingw32-crossreport-6-1.el5 : Analysis tool to help cross-compilation to Windows NEW perl-NOCpulse-Debug-1.23.15-1.el5 : Perl debug output package NEW python-shove-0.1.3-2.el5 : Common object storage frontend trickle-1.07-7.el5 varnish-2.0.3-1.el5 Packages built and released for Fedora EPEL 4: 2 moodle-1.8.8-1.el4 python-crypto-2.0.1-1.el4.1 Packages built and released for Fedora EPEL testing/4: 6 cobbler-1.4.2-1.el4 koan-1.4.2-1.el4 NEW perl-NOCpulse-Debug-1.23.15-1.el4 : Perl debug output package NEW python-shove-0.1.3-2.el4 : Common object storage frontend trickle-1.07-7.el4 varnish-2.0.3-1.el4 Changes in Fedora EPEL 5: moodle-1.8.8-1.el5 ------------------ * Tue Feb 10 2009 Jon Ciesla - 1.8.8-1 - Update to 1.8.8. to fix CVE-2009-0499,0500,0501,0502. - Backported some fonts fixes. python-crypto-2.0.1-4.el5.1 --------------------------- * Fri Feb 13 2009 Thorsten Leemhuis - 2.0.1-4.1 - some improvements from fedora branch -- add patch to fix #485298 / CVE-2009-0544 -- provide pycrypto -- drop patch0 and fix libdir handling so it works on more arches than x86_64 Changes in Fedora EPEL testing/5: cobbler-1.4.2-1.el5 ------------------- * Thu Feb 12 2009 Michael DeHaan - 1.4.2-1 - Upstream changes (see CHANGELOG) koan-1.4.2-1.el5 ---------------- * Thu Feb 12 2009 Michael DeHaan - 1.4.2-1 - Upstream changes (see CHANGELOG) mingw32-crossreport-6-1.el5 --------------------------- * Fri Feb 13 2009 Richard W.M. Jones - 6-1 - Change to use Berkeley DB for storage. * Fri Feb 13 2009 Richard W.M. Jones - 5-1 - Requires binutils, for nm and c++filt (thanks Richard Hughes). * Fri Feb 13 2009 Richard W.M. Jones - 4-1 - Include the update script. * Wed Feb 11 2009 Richard W.M. Jones - 3-1 - Initial RPM release. perl-NOCpulse-Debug-1.23.15-1.el5 --------------------------------- * Wed Feb 04 2009 Miroslav Suchy 1.23.15-1 - remove ownership of /etc/nocpulse - add LICENSE * Tue Feb 03 2009 Miroslav Suchy 1.23.14-1 - 455934 - write timestamps to logs by default * Thu Jan 29 2009 Miroslav Suchy 1.23.13-1 - own %{perl_vendorlib}/NOCpulse - silent rpmlint by $RPM_BUILD_ROOT prefix to %install - move logging.ini from Makefile.PL to spec * Wed Jan 28 2009 Dennis Gilmore 1.23.10-1 - fix up spec so we can build * Tue Jan 27 2009 Dennis Gilmore 1.23.9-1 - BR perl(ExtUtils::MakeMaker) python-shove-0.1.3-2.el5 ------------------------ * Tue Jan 06 2009 Luke Macken 0.1.3-2 - Use consistent macros - Add comment about patch - Make rpmlint happy trickle-1.07-7.el5 ------------------ * Thu Feb 12 2009 Nicoleau Fabien 1.07-7 - Replace sed with a patch for #484065 (CVE-2009-0415) varnish-2.0.3-1.el5 ------------------- * Wed Feb 11 2009 Ingvar Hagelund - 2.0.3-1 New upstream release 2.0.3. A bugfix and feature enhancement release Changes in Fedora EPEL 4: moodle-1.8.8-1.el4 ------------------ * Tue Feb 10 2009 Jon Ciesla - 1.8.8-1 - Update to 1.8.8. to fix CVE-2009-0499,0500,0501,0502. - Backported some fonts fixes. python-crypto-2.0.1-1.el4.1 --------------------------- * Fri Feb 13 2009 Thorsten Leemhuis - 2.0.1-1.1 - some improvements from fedora branch -- add patch to fix #485298 / CVE-2009-0544 -- provide pycrypto -- drop patch0 and fix libdir handling so it works on more arches than x86_64 Changes in Fedora EPEL testing/4: cobbler-1.4.2-1.el4 ------------------- * Thu Feb 12 2009 Michael DeHaan - 1.4.2-1 - Upstream changes (see CHANGELOG) koan-1.4.2-1.el4 ---------------- * Thu Feb 12 2009 Michael DeHaan - 1.4.2-1 - Upstream changes (see CHANGELOG) perl-NOCpulse-Debug-1.23.15-1.el4 --------------------------------- * Wed Feb 04 2009 Miroslav Suchy 1.23.15-1 - remove ownership of /etc/nocpulse - add LICENSE * Tue Feb 03 2009 Miroslav Suchy 1.23.14-1 - 455934 - write timestamps to logs by default * Thu Jan 29 2009 Miroslav Suchy 1.23.13-1 - own %{perl_vendorlib}/NOCpulse - silent rpmlint by $RPM_BUILD_ROOT prefix to %install - move logging.ini from Makefile.PL to spec * Wed Jan 28 2009 Dennis Gilmore 1.23.10-1 - fix up spec so we can build * Tue Jan 27 2009 Dennis Gilmore 1.23.9-1 - BR perl(ExtUtils::MakeMaker) python-shove-0.1.3-2.el4 ------------------------ * Tue Jan 06 2009 Luke Macken 0.1.3-2 - Use consistent macros - Add comment about patch - Make rpmlint happy trickle-1.07-7.el4 ------------------ * Thu Feb 12 2009 Nicoleau Fabien 1.07-7 - Replace sed with a patch for #484065 (CVE-2009-0415) varnish-2.0.3-1.el4 ------------------- * Wed Feb 11 2009 Ingvar Hagelund - 2.0.3-1 New upstream release 2.0.3. A bugfix and feature enhancement release From kevin at tummy.com Mon Feb 16 20:26:51 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 16 Feb 2009 13:26:51 -0700 Subject: meetings and some issues In-Reply-To: <20090210142222.GA23288@nostromo.devel.redhat.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090210142222.GA23288@nostromo.devel.redhat.com> Message-ID: <20090216132651.7c2090fb@ohm.scrye.com> On Tue, 10 Feb 2009 09:22:22 -0500 Bill Nottingham wrote: > Kevin Fenzi (kevin at tummy.com) said: > > - Do we need to do anything to prep for RHEL6? Do we just branch the > > things that are already in EPEL5? Or can we look at more than > > that? > > While I'd echo what was said earlier about communication, I would say > it's definitely too early for you to be doing mass branching for RHEL > 6. Totally agreed. I was just wanting to bring up the subject of how we want to do it down the road. I guess the easy way is to mass branch EL-5, but there will be some things there that don't build/work. Also, there will be a bunch more things that now DO work that didn't with EL-5. > Do you feel you need to have packages ready *by* beta, or are you OK > with determining the package set at that time? Thats fine, I just want to get folks thinking about it... > Bill kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lfarkas at lfarkas.org Mon Feb 16 20:30:01 2009 From: lfarkas at lfarkas.org (Farkas Levente) Date: Mon, 16 Feb 2009 21:30:01 +0100 Subject: meetings and some issues In-Reply-To: <20090216132651.7c2090fb@ohm.scrye.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090210142222.GA23288@nostromo.devel.redhat.com> <20090216132651.7c2090fb@ohm.scrye.com> Message-ID: <4999CCC9.5060601@lfarkas.org> Kevin Fenzi wrote: > On Tue, 10 Feb 2009 09:22:22 -0500 > Bill Nottingham wrote: > >> Kevin Fenzi (kevin at tummy.com) said: >>> - Do we need to do anything to prep for RHEL6? Do we just branch the >>> things that are already in EPEL5? Or can we look at more than >>> that? >> While I'd echo what was said earlier about communication, I would say >> it's definitely too early for you to be doing mass branching for RHEL >> 6. > > Totally agreed. I was just wanting to bring up the subject of how we > want to do it down the road. I guess the easy way is to mass branch > EL-5, but there will be some things there that don't build/work. Also, > there will be a bunch more things that now DO work that didn't with > EL-5. any chance that for that time also epel can use koji? -- Levente "Si vis pacem para bellum!" From kevin at tummy.com Mon Feb 16 20:33:20 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 16 Feb 2009 13:33:20 -0700 Subject: meetings and some issues In-Reply-To: <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <80d7e4090902091549l999bf8bwa4866036f12816d6@mail.gmail.com> Message-ID: <20090216133320.77523b2a@ohm.scrye.com> On Mon, 9 Feb 2009 16:49:20 -0700 Stephen John Smoogen wrote: > 2009/2/9 Kevin Fenzi : > > Greetings. > > > > Since we haven't had an epel meeting in quite a while, I would like > > to revisit the idea of a new meeting time. Perhaps we could setup a > > table in the wiki for people to fill in and choose the best time > > that way? Or perhaps someone would like to suggest a time? > > Thanks Kevin. No problem. I think meetings are good if only for bringing issues up... > > Some issues that are pending that we can just discuss here: > > > > - Did we ever decide to make a epel-announce list? I think this > > might be good still to send important announcements about packages > > or other changes that end epel users should be notified of. I am > > not sure, but we could also send the package update announcements > > there (might be too much traffic tho, perhaps just the stable ones?) > > It was tabled to be discussed on list. I am for it. Yeah, I think I am too. Perhaps I should just go request one. > > - Orphans. We have the following orphan packages. Some of them are > > more 'retired', but we should look at trying to find owners for the > > ones that can still be maintained. > > > > abcde > > aget > > cd-discid > > csync2 > > cvs2cl > > cvsps > > freetennis > > gkrellm > > gkrellm-volume > > gtkhtml38 > > libid3tag > > libmodplug > > mach > > otrs > > pytz > > redet > > redet-doc > > svn2cl > > Hmmm I though otrs just got put in. I think it was orphaned, someone else picked it up, but then I don't know if they have done much with it. Perhaps they only picked up the non EPEL branches. > > - Bugs. We are now just over 100 epel bugs. This is no good, IMHO. > > Would it be possible to get some interested folks to dig through > > these and see about fixing easy ones/poking maintainers/doing > > something to move them along. Especially in the case where it's a > > missing dep. > > > https://bugzilla.redhat.com/buglist.cgi?product=Fedora > > EPEL&bug_status=NEW&bug_status=MODIFIED&bug_status=ASSIGNED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=RELEASE_PENDING&bug_status=POST&bug_status=FAILS_QA > > Ok that sounds like something I can start on. That would be excellent. > > - Do we need to do anything to prep for RHEL6? Do we just branch the > > things that are already in EPEL5? Or can we look at more than that? > > Yes. > > 1) We need to get the build system to koji. David Gilmore says thats > real soon now (like this month). > 2) We need to have a branch where we will build 'everything' against > the BETA when it comes out. That way we can keep track of where things > break and see if we can get some loving to EL-6 sooner versus later. > 3) We need a TAM at Red Hat to keep us in contact with what is going > on with EL{4,5,6} so that we have better communication about changes. Yeah, all those would be nice. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeff at ocjtech.us Mon Feb 16 21:31:50 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 16 Feb 2009 15:31:50 -0600 Subject: meetings and some issues In-Reply-To: <4999CCC9.5060601@lfarkas.org> References: <20090209103415.4e0fe999@ohm.scrye.com> <20090210142222.GA23288@nostromo.devel.redhat.com> <20090216132651.7c2090fb@ohm.scrye.com> <4999CCC9.5060601@lfarkas.org> Message-ID: <935ead450902161331yce94b02g10e2140623a1960d@mail.gmail.com> On Mon, Feb 16, 2009 at 2:30 PM, Farkas Levente wrote: > > any chance that for that time also epel can use koji? Changes to Koji are being put into place this weekend that will allow EPEL builds to happen in Koji. How soon the switchover happens is anyone's guess. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From mastahnke at gmail.com Tue Feb 17 15:47:01 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 17 Feb 2009 09:47:01 -0600 Subject: Websites and things Message-ID: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> A while back I mentioned that EPEL should be listed on the front page of the Fedoraproject wiki. I filed a ticket with the web infrastructure folks (#1139) to make that happen. Also, when clicking around on the wiki, EPEL is not listed as a SIG, nor a Sub-project. Which are we? I get confused about these terms. Either way, we should be listed on at least one of those. I am requesting input and discussion. Thanks stahnma From smooge at gmail.com Tue Feb 17 16:29:02 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 17 Feb 2009 09:29:02 -0700 Subject: Websites and things In-Reply-To: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> References: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> Message-ID: <80d7e4090902170829l6219106dsccdac3eb2552a3f8@mail.gmail.com> On Tue, Feb 17, 2009 at 8:47 AM, Michael Stahnke wrote: > A while back I mentioned that EPEL should be listed on the front page > of the Fedoraproject wiki. I filed a ticket with the web > infrastructure folks (#1139) to make that happen. > > Also, when clicking around on the wiki, EPEL is not listed as a SIG, > nor a Sub-project. Which are we? I get confused about these terms. > Either way, we should be listed on at least one of those. At one point I believed we were both. I am not sure either. I think we started as a Sub-Project and became a SIG.. or maybe it was vice versa. Sorry for not clarifying. > I am requesting input and discussion. > Thanks > stahnma > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux 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 Tue Feb 17 17:30:50 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 17 Feb 2009 18:30:50 +0100 Subject: Websites and things In-Reply-To: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> References: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> Message-ID: <20090217173050.GE2950@free.fr> On Tue, Feb 17, 2009 at 09:47:01AM -0600, Michael Stahnke wrote: > A while back I mentioned that EPEL should be listed on the front page > of the Fedoraproject wiki. I filed a ticket with the web > infrastructure folks (#1139) to make that happen. > > Also, when clicking around on the wiki, EPEL is not listed as a SIG, > nor a Sub-project. Which are we? I get confused about these terms. > Either way, we should be listed on at least one of those. It is explained on http://fedoraproject.org/wiki/Defining_projects that a project is defined by the Fedora Project Board (or by the project board for a sub-project). I don't recall the board nor FESCo telling that EPEL is a project, so I guess it is a SIG, but FESCo people would certainly remember better than me. However, it may also be that these things are not that clear, since the Packaging project is not listed on: http://fedoraproject.org/wiki/Projects though it doesn't seems to be the same than the Distribution project, and it is listed in http://fedoraproject.org/wiki/Defining_projects as being a main project. EPEL is something like cross-cutting in Packaging, Infrastructure. Maybe EPEL could be seen as a SIG under both Packaging and Infrastructure. Still it is a special SIG, since it is broader than usual SIGs, and is focused on a derivative distro of Fedora, but not based on current Fedora. It is similar with OLPC, in my opinion, but OLPC doesn't appear anywhere. Also I may be the only one, but I am not a member of Fedora anymore (at least not a member of the Fedora Packaging Group), but I am still in EPEL, this is not clear that it would be possible in a normal SIG. There is a page for EPEL as a SIG: http://fedoraproject.org/wiki/EPEL/SIG but it is a page that I haven't updated much when I updated the wiki, and it shows obsolete information. I am not sure about the list of the SIG members, for example. -- Pat From fedora at leemhuis.info Tue Feb 17 17:44:33 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Feb 2009 18:44:33 +0100 Subject: Websites and things In-Reply-To: <20090217173050.GE2950@free.fr> References: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> <20090217173050.GE2950@free.fr> Message-ID: <499AF781.3020107@leemhuis.info> On 17.02.2009 18:30, Patrice Dumas wrote: > On Tue, Feb 17, 2009 at 09:47:01AM -0600, Michael Stahnke wrote: >> A while back I mentioned that EPEL should be listed on the front page >> of the Fedoraproject wiki. I filed a ticket with the web >> infrastructure folks (#1139) to make that happen. >> Also, when clicking around on the wiki, EPEL is not listed as a SIG, >> nor a Sub-project. Which are we? I get confused about these terms. >> Either way, we should be listed on at least one of those. > It is explained on > http://fedoraproject.org/wiki/Defining_projects > that a project is defined by the Fedora Project Board (or by the project > board for a sub-project). I don't recall the board nor FESCo telling that > EPEL is a project, so I guess it is a SIG, That's correct; it's a SIG and FESCo is above it in the Fedora hierarchy. CU knurd From pertusus at free.fr Tue Feb 17 18:12:10 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 17 Feb 2009 19:12:10 +0100 Subject: Websites and things In-Reply-To: <499AF781.3020107@leemhuis.info> References: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> <20090217173050.GE2950@free.fr> <499AF781.3020107@leemhuis.info> Message-ID: <20090217181210.GA5303@free.fr> On Tue, Feb 17, 2009 at 06:44:33PM +0100, Thorsten Leemhuis wrote: > > That's correct; it's a SIG and FESCo is above it in the Fedora hierarchy. It is still very unclear to me who the SIG members are. Both a project and a SIG should know who their members are, but in the case of EPEL it is far from being clear. Indeed, for the Packaging project, members are more or less all the packagers, while it is not clear if the EPEL SIG members are all the EPEL maintainers + people interested in EPEL infrastructure + EPEL steering commitee, or if it is something else (like, for example, the list on http://fedoraproject.org/wiki/EPEL/SIG). -- Pat From buildsys at fedoraproject.org Tue Feb 17 18:21:15 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 17 Feb 2009 18:21:15 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-17 Message-ID: <20090217182115.DBA871880F4@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 8 NEW htmldoc-1.8.27-7.el5 : Convert HTML source files into HTML, PostScript, or PDF ldns-1.5.1-1.el5 NEW MochiKit-1.3.1-1.el5 : A lightweight JavaScript library NEW mod_auth_pam-1.1.1-6.el5 : PAM authentication module for Apache NEW perl-NOCpulse-Utils-1.14.11-1.el5 : NOCpulse utility packages php-pecl-json-1.2.1-3.el5 python-paramiko-1.7.4-4.el5 NEW rubygem-simple-rss-1.1-4.el5 : A simple, flexible, extensible, and liberal RSS and Atom reader for Ruby Packages built and released for Fedora EPEL testing/4: 3 NEW htmldoc-1.8.27-7.el4.1 : Convert HTML source files into HTML, PostScript, or PDF NEW MochiKit-1.4.2-2.el4 : A lightweight JavaScript library NEW perl-NOCpulse-Utils-1.14.11-1.el4 : NOCpulse utility packages Changes in Fedora EPEL testing/5: htmldoc-1.8.27-7.el5 -------------------- * Sat Aug 30 2008 Adam Goode - 1.8.27-7 - RPM 4.6 fix for patch tag ldns-1.5.1-1.el5 ---------------- * Fri Feb 13 2009 Paul Wouters - 1.5.1-1 - Upgrade to 1.5.1 (1.5.0 was a dud release) MochiKit-1.3.1-1.el5 -------------------- * Sun May 21 2006 Ignacio Vazquez-Abrams 1.3.1-1 - Upstream update mod_auth_pam-1.1.1-6.el5 ------------------------ * Mon Aug 11 2008 Tom "spot" Callaway - 1.1.1-6 - fix license tag perl-NOCpulse-Utils-1.14.11-1.el5 --------------------------------- * Wed Jan 07 2009 Milan Zazrivec 1.14.11-1 - include documentation fixes php-pecl-json-1.2.1-3.el5 ------------------------- * Fri Feb 13 2009 Remi Collet 1.2.1-3 - add configuration file python-paramiko-1.7.4-4.el5 --------------------------- * Mon Feb 16 2009 Jeffrey C. Ollie - 1.7.4-4 - Add demos as documentation. BZ#485742 * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 1.7.4-3 - Rebuild for Python 2.6 * Wed Sep 03 2008 Tom "spot" Callaway - 1.7.4-2 - fix license tag rubygem-simple-rss-1.1-4.el5 ---------------------------- * Mon Feb 09 2009 Michael Stahnke - 1.1-4 - More fixes from review * Sun Jan 25 2009 Michael Stahnke - 1.1-3 - One more doc update for review Changes in Fedora EPEL testing/4: htmldoc-1.8.27-7.el4.1 ---------------------- * Fri Feb 13 2009 Adam Goode - 1.8.27-7.1 - Update BuildRequires for EL-4 MochiKit-1.4.2-2.el4 -------------------- * Wed Feb 11 2009 Adam Miller 1.4.2-2 - Fix for bug 440052 - fixes path of MochiKit libs in source - Thanks to ivasquez for the awesome regex * Wed Feb 11 2009 Adam Miller 1.4.2-1 - new release of MochiKit perl-NOCpulse-Utils-1.14.11-1.el4 --------------------------------- * Wed Jan 07 2009 Milan Zazrivec 1.14.11-1 - include documentation fixes From fedora at leemhuis.info Tue Feb 17 19:41:01 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Feb 2009 20:41:01 +0100 Subject: Websites and things In-Reply-To: <20090217181210.GA5303@free.fr> References: <7874d9dd0902170747q4194b9d9r53c2dcae5d3ada0d@mail.gmail.com> <20090217173050.GE2950@free.fr> <499AF781.3020107@leemhuis.info> <20090217181210.GA5303@free.fr> Message-ID: <499B12CD.2050000@leemhuis.info> On 17.02.2009 19:12, Patrice Dumas wrote: > On Tue, Feb 17, 2009 at 06:44:33PM +0100, Thorsten Leemhuis wrote: >> That's correct; it's a SIG and FESCo is above it in the Fedora hierarchy. Maybe I should have added here: It's a SIG that is governed by the EPEL Steering Committee. > It is still very unclear to me who the SIG members are. I'd say it's round about: If you want to become a member of a SIG then you add your name to the page in the wiki; if you want to get out you remove your name. That afaics how it works/worked in many Fedora SIGs and I see no reason why EPEL should be different. > Both a project > and a SIG should know who their members are, but in the case of EPEL it > is far from being clear. Indeed, for the Packaging project, members are > more or less all the packagers, while it is not clear if the EPEL SIG > members are all the EPEL maintainers + people interested in EPEL > infrastructure + EPEL steering commitee, or if it is something else > (like, for example, the list on http://fedoraproject.org/wiki/EPEL/SIG). I'd say it are people that have a eneral interest in EPEL and want to keep it running and help to improve it. CU knurd From buildsys at fedoraproject.org Fri Feb 20 20:06:18 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 20 Feb 2009 20:06:18 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-20 Message-ID: <20090220200620.EF30218810A@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 21 NEW asterisk-sounds-core-1.4.14-1.el5 : Core sounds for Asterisk beanstalkd-1.2-1.el5 NEW cdk-5.0.20081105-1.el5 : Curses Development Kit NEW django-authopenid-0.9.6-2.el5 : Django application to integrate Django authentication system with OpenID gc-7.1-5.el5 gnupg2-2.0.9-1.el5 gromacs-4.0.4-1.el5 hercules-3.06-1.el5 NEW hosts3d-0.97-4.el5 : 3D real-time network visualiser iok-1.2.1-1.el5 libassuan-1.0.4-3.el5 libksba-1.0.5-1.el5 MochiKit-1.4.2-2.el5 NEW mon-1.2.0-3.el5 : General-purpose resource monitoring system munin-1.2.6-4.el5 nginx-0.6.35-2.el5 NEW perl-Mon-0.11-1.el5 : Mon Perl module NEW perl-NOCpulse-Object-1.26.10-1.el5 : NOCpulse Object abstraction for Perl NEW pygrace-0.3-5.el5 : Python bindings for grace NEW python-createrepo-0.9.6-1.el5 : Python module to create common metadata repositorys xine-lib-1.1.16.2-3.el5 Packages built and released for Fedora EPEL testing/4: 5 NEW django-authopenid-0.9.6-2.el4 : Django application to integrate Django authentication system with OpenID gromacs-4.0.4-1.el4 (!) MochiKit-1.4.2-2.el4 : INVALID rebuild, not published! munin-1.2.6-4.el4 NEW perl-NOCpulse-Object-1.26.10-1.el4 : NOCpulse Object abstraction for Perl Changes in Fedora EPEL testing/5: asterisk-sounds-core-1.4.14-1.el5 --------------------------------- * Thu Feb 19 2009 Jeffrey C. Ollie - 1.4.14-1 - Add dist tag back in. * Fri Jan 30 2009 Jeffrey C. Ollie - 1.4.14-1 - First version for Fedora beanstalkd-1.2-1.el5 -------------------- * Tue Feb 17 2009 Jeremy Hinegardner - 1.2-1 - update to upstream 1.2 - remove man page source as it was incorporated upstream cdk-5.0.20081105-1.el5 ---------------------- * Sun Jan 04 2009 Marek Mahut - 5.0.20081105-1 - Initial build django-authopenid-0.9.6-2.el5 ----------------------------- * Wed Feb 18 2009 Ian Weller 0.9.6-2 - Add patch from I. Vazquez (django-authopenid-0.9.6-keyword.patch) * Sun Feb 15 2009 Ian Weller 0.9.6-1 - Initial package build gc-7.1-5.el5 ------------ * Wed Oct 15 2008 Rex Dieter 7.1-5 - forward-port patches (gcinit, sparc) * Fri Oct 03 2008 Rex Dieter 7.1-4 - BR: libatomic_ops-devel * Mon Sep 08 2008 Rex Dieter 7.1-3 - upstream DONT_ADD_BYTE_AT_END patch - spec cosmetics * Sat Jul 12 2008 Rex Dieter 7.1-2 - --enable-large-config (#453972) * Sun May 04 2008 Rex Dieter 7.1-1 - gc-7.1 - purge rpaths * Fri Feb 08 2008 Rex Dieter 7.0-7 - respin (gcc43) * Wed Aug 29 2007 Rex Dieter 7.0-6 - BR: gawk - fixup compat_header patch to avoid needing auto* tools * Wed Aug 29 2007 Rex Dieter 7.0-5 - compat_header patch (supercedes previous pkgconfig patch) * Tue Aug 21 2007 Rex Dieter 7.0-4 - pkgconfig patch (cflags += -I%_includedir/gc) * Tue Aug 21 2007 Rex Dieter 7.0-3 - respin (ppc32) * Tue Jul 24 2007 Rex Dieter 7.0-2 - gcinit patch, ABI compatibility (#248700) * Mon Jul 09 2007 Rex Dieter 7.0-1 - gc-7.0 gnupg2-2.0.9-1.el5 ------------------ * Tue Feb 17 2009 Rex Dieter 2.0.9-1 - gnupg2-2.0.9 (#479032) gromacs-4.0.4-1.el5 ------------------- * Tue Feb 17 2009 Jussi Lehtola - 4.0.4-1 - Update to 4.0.4. hercules-3.06-1.el5 ------------------- * Wed Feb 18 2009 Dan Horak 3.06-1 - update to upstream version 3.06 - use system ltdl library hosts3d-0.97-4.el5 ------------------ * Tue Feb 17 2009 Simon Wesp - 0.97-4 - This Version will be only available for epel5 to avoid buildsys errors - Next version (0.98) will be with the same specfile for fedora & epel * Sun Feb 15 2009 Simon Wesp - 0.97-3 - Use autoconf instead of autoreconf in the BUILD section to avoid koji errors * Sun Feb 15 2009 Simon Wesp - 0.97-2 - Correct Provides/Obsolates - Correct make install - Honour RPM_OPT_FLAGS with PATCH0 by Jochen Schmitt - Add autoreconf to generate a new configure.in on the base of the patched configure.ac * Tue Feb 10 2009 Simon Wesp - 0.97-1 - Update to 0.97 - Homestead renamed to Hosts3D iok-1.2.1-1.el5 --------------- * Thu Feb 19 2009 Parag Nemade - 1.2.1-1 - Update to Next release 1.2.1 * Tue Jan 20 2009 Parag Nemade - 1.2.0-2 - Resolves: rh#480289 libassuan-1.0.4-3.el5 --------------------- * Thu Apr 03 2008 Rex Dieter 1.0.4-3 - multiarch conflicts (#341911) * Fri Feb 08 2008 Rex Dieter 1.0.4-2 - respin (gcc43) libksba-1.0.5-1.el5 ------------------- * Fri Jan 09 2009 Rex Dieter 1.0.5-1 - libksba-1.0.5 * Tue Sep 23 2008 Rex Dieter 1.0.4-1 - libksba-1.0.4 * Thu Apr 03 2008 Rex Dieter 1.0.3-2 - multiarch conflicts (#342201) * Tue Feb 12 2008 Rex Dieter 1.0.3-1 - libksba-1.0.3 * Fri Feb 08 2008 Rex Dieter 1.0.2-4 - respin (gcc43) MochiKit-1.4.2-2.el5 -------------------- * Wed Feb 11 2009 Adam Miller 1.4.2-2 - Fix for bug 440052 - fixes path of MochiKit libs in source - Thanks to ivasquez for the awesome regex * Wed Feb 11 2009 Adam Miller 1.4.2-1 - new release of MochiKit * Mon Jul 14 2008 Tom "spot" Callaway 1.3.1-2 - fix license tag mon-1.2.0-3.el5 --------------- * Fri Feb 20 2009 Lubomir Rintel (Good Data) - 1.2.0-3 - Remove AOL::TOC - Add most of shipped monitors (GDC #581) munin-1.2.6-4.el5 ----------------- * Wed Feb 18 2009 Andreas Thienemann - 1.2.6-4 - Updated dependencies to better reflect plugin requirements - Added hddtemp_smartctl patch to only scan for standby state on /dev/[sh]d? devices. nginx-0.6.35-2.el5 ------------------ * Thu Feb 19 2009 Jeremy Hinegardner - 0.6.35-2 - rebuild * Thu Feb 19 2009 Jeremy Hinegardner - 0.6.35-1 - update to 0.6.35 perl-Mon-0.11-1.el5 ------------------- * Sun Jul 13 2008 Lubomir Rintel (Good Data) 0.11-1 - Specfile autogenerated by cpanspec 1.75. - Fixed License tag perl-NOCpulse-Object-1.26.10-1.el5 ---------------------------------- * Wed Feb 18 2009 Miroslav Such? 1.26.10-1 - 485893 - add GPL headers to modules * Tue Feb 17 2009 Miroslav Such? 1.26.9-1 - add LICENSE - own NOCpulse dir - remove optimize flags * Wed Jan 28 2009 Dennis Gilmore 1.26.8-1 - BR perl(ExtUtils::MakeMaker) pygrace-0.3-5.el5 ----------------- * Thu Feb 19 2009 Jussi Lehtola - 0.3-5 - Retry fixing EPEL build. * Thu Feb 19 2009 Jussi Lehtola - 0.3-4 - Fix EPEL build. * Wed Feb 18 2009 Jussi Lehtola - 0.3-3 - Added examples to %doc. * Tue Feb 17 2009 Jussi Lehtola - 0.3-2 - Fixed license. * Sun Feb 15 2009 Jussi Lehtola - 0.3-1 - First release. python-createrepo-0.9.6-1.el5 ----------------------------- * Fri Feb 13 2009 Dennis Gilmore - 0.9.6-1 - rename to python-createrepo and package as a python module only. - for koji to run on EL-5 * Tue Feb 10 2009 Seth Vidal - 0.9.6-11 - change the order of deltarpms * Wed Feb 04 2009 Seth Vidal - 0.9.6-10 - working mergerepo again * Tue Feb 03 2009 Seth Vidal - 0.9.6-9 - fix normal createrepo'ing w/o the presto patches :( * Mon Feb 02 2009 Seth Vidal - 0.9.6-7 - add deltarpm requirement for making presto metadata * Tue Jan 27 2009 Seth Vidal - 0.9.6-6 - one more patch set to make sure modifyrepo works with sha256's, too * Mon Jan 26 2009 Seth Vidal - 0.9.6-5 - add patch from upstream head for sha256 support xine-lib-1.1.16.2-3.el5 ----------------------- * Fri Feb 20 2009 Rex Dieter - 1.1.16.2-3 - xine-lib-devel muiltilib conflict (#477226) * Tue Feb 17 2009 Rex Dieter - 1.1.16.2-2 - xine-lib-safe-audio-pause3 patch (#486255, kdebug#180339) * Tue Feb 10 2009 Kevin Kofler - 1.1.16.2-1.1 - also patch the caca version check in configure(.ac) Changes in Fedora EPEL testing/4: django-authopenid-0.9.6-2.el4 ----------------------------- * Wed Feb 18 2009 Ian Weller 0.9.6-2 - Add patch from I. Vazquez (django-authopenid-0.9.6-keyword.patch) * Sun Feb 15 2009 Ian Weller 0.9.6-1 - Initial package build gromacs-4.0.4-1.el4 ------------------- * Tue Feb 17 2009 Jussi Lehtola - 4.0.4-1 - Update to 4.0.4. MochiKit-1.4.2-2.el4 -------------------- * Wed Feb 11 2009 Adam Miller 1.4.2-2 - Fix for bug 440052 - fixes path of MochiKit libs in source - Thanks to ivasquez for the awesome regex munin-1.2.6-4.el4 ----------------- * Wed Feb 18 2009 Andreas Thienemann - 1.2.6-4 - Updated dependencies to better reflect plugin requirements - Added hddtemp_smartctl patch to only scan for standby state on /dev/[sh]d? devices. perl-NOCpulse-Object-1.26.10-1.el4 ---------------------------------- * Wed Feb 18 2009 Miroslav Such? 1.26.10-1 - 485893 - add GPL headers to modules * Tue Feb 17 2009 Miroslav Such? 1.26.9-1 - add LICENSE - own NOCpulse dir - remove optimize flags * Wed Jan 28 2009 Dennis Gilmore 1.26.8-1 - BR perl(ExtUtils::MakeMaker) From buildsys at fedoraproject.org Sat Feb 21 00:26:34 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 Feb 2009 00:26:34 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-21 Message-ID: <20090221002634.779B71880E6@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 4 NEW calendar-1.25-3.el5 : Reminder utility koji-1.3.1-1.el5 NEW pyfits-1.3-4.el5 : Python interface to FITS NEW python-hashlib-20081119-4.el5 : Secure hash and message digest algorithm library Packages built and released for Fedora EPEL testing/4: 1 NEW calendar-1.25-3.el4 : Reminder utility Changes in Fedora EPEL testing/5: calendar-1.25-3.el5 ------------------- * Tue Feb 17 2009 David Cantrell - 1.25-3 - Use cvs status to get the revision number of calendar.c * Tue Feb 17 2009 David Cantrell - 1.25-2 - Fixed problems in export-calendar-source.sh - Set permissions on export-calendar-source.sh to 0644 * Thu Feb 12 2009 David Cantrell - 1.25-1 - Packaged OpenBSD's calendar(1) command from OpenBSD 4.4 koji-1.3.1-1.el5 ---------------- * Fri Feb 20 2009 Dennis Gilmore - 1.3.1-1 - update to 1.3.1 * Wed Feb 18 2009 Dennis Gilmore - 1.3.0-1 - update to 1.3.0 * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 1.2.6-2 - Rebuild for Python 2.6 pyfits-1.3-4.el5 ---------------- * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 1.3-4 - Rebuild for Python 2.6 python-hashlib-20081119-4.el5 ----------------------------- * Fri Feb 20 2009 Dennis Gilmore - 20081119-4 - review fixes (License TAG, doc files) * Thu Jan 29 2009 Seth Vidal - 20081119-3 - few minor spec cleanups - add Changelog to docs - first build and packaging Changes in Fedora EPEL testing/4: calendar-1.25-3.el4 ------------------- * Tue Feb 17 2009 David Cantrell - 1.25-3 - Use cvs status to get the revision number of calendar.c * Tue Feb 17 2009 David Cantrell - 1.25-2 - Fixed problems in export-calendar-source.sh - Set permissions on export-calendar-source.sh to 0644 * Thu Feb 12 2009 David Cantrell - 1.25-1 - Packaged OpenBSD's calendar(1) command from OpenBSD 4.4 From rayvd at bludgeon.org Mon Feb 23 08:45:32 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 23 Feb 2009 00:45:32 -0800 Subject: Anyone seen this before? Message-ID: <20090223084532.GA9128@bludgeon.org> http://buildsys.fedoraproject.org/logs/fedora-5-epel/1530-pyodbc-2.1.4-3.el5/ Having problems building an update to one of my packages in plague. It builds fine in a local mock setup I have (i386), but throws up the following error in what appears to be the PPC environment. It also looks to me like it's pulling in an older version of python for some reason? DEBUG backend.py:554: /usr/bin/yum --installroot /var/lib/mock/fedora-5-ppc-epel-867547da8866e23165d06e28b38354fc5ff867d1/root/ install 'python-devel >= 2.4' 'unixODBC-devel' DEBUG util.py:280: Executing command: /usr/bin/yum --installroot /var/lib/mock/fedora-5-ppc-epel-867547da8866e23165d06e28b38354fc5ff867d1/root/ install 'python-devel >= 2.4' 'unixODBC-devel' DEBUG util.py:256: python-devel-2.4.3-19.el5.ppc from rhel5-base has depsolving problems DEBUG util.py:256: --> Missing Dependency: python = 2.4.3-19.el5 is needed by package python-devel-2.4.3-19.el5.ppc (rhel5-base) DEBUG util.py:256: Error: Missing Dependency: python = 2.4.3-19.el5 is needed by package python-devel-2.4.3-19.el5.ppc (rhel5-base) DEBUG util.py:319: Child returncode was: 1 Shouldn't -21 be the current python? Anyways, not sure if this has anything to do with the recent outage (I did mention this to the infra team) or maybe just something boneheaded on my part... Ray From rayvd at bludgeon.org Mon Feb 23 16:12:50 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 23 Feb 2009 08:12:50 -0800 Subject: Anyone seen this before? In-Reply-To: <20090223084532.GA9128@bludgeon.org> References: <20090223084532.GA9128@bludgeon.org> Message-ID: <20090223161250.GA16047@bludgeon.org> On Mon, Feb 23, 2009 at 12:45:32AM -0800, Ray Van Dolson wrote: > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1530-pyodbc-2.1.4-3.el5/ > > Having problems building an update to one of my packages in plague. It > builds fine in a local mock setup I have (i386), but throws up the > following error in what appears to be the PPC environment. It also > looks to me like it's pulling in an older version of python for some > reason? > > DEBUG backend.py:554: /usr/bin/yum --installroot /var/lib/mock/fedora-5-ppc-epel-867547da8866e23165d06e28b38354fc5ff867d1/root/ install 'python-devel >= 2.4' 'unixODBC-devel' > DEBUG util.py:280: Executing command: /usr/bin/yum --installroot /var/lib/mock/fedora-5-ppc-epel-867547da8866e23165d06e28b38354fc5ff867d1/root/ install 'python-devel >= 2.4' 'unixODBC-devel' > DEBUG util.py:256: python-devel-2.4.3-19.el5.ppc from rhel5-base has depsolving problems > DEBUG util.py:256: --> Missing Dependency: python = 2.4.3-19.el5 is needed by package python-devel-2.4.3-19.el5.ppc (rhel5-base) > DEBUG util.py:256: Error: Missing Dependency: python = 2.4.3-19.el5 is needed by package python-devel-2.4.3-19.el5.ppc (rhel5-base) > DEBUG util.py:319: Child returncode was: 1 > > Shouldn't -21 be the current python? Anyways, not sure if this has > anything to do with the recent outage (I did mention this to the infra > team) or maybe just something boneheaded on my part... > Alright, so I don't think this is just me. Just tried rebuilding another known good package I maintain (and it hasn't changed for a long time): http://buildsys.fedoraproject.org/logs/fedora-5-epel/1536-pymssql-0.8.0-2.el5/ppc/job.log Same error. Ray From dennis at ausil.us Mon Feb 23 19:19:51 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 23 Feb 2009 13:19:51 -0600 Subject: Anyone seen this before? In-Reply-To: <20090223161250.GA16047@bludgeon.org> References: <20090223084532.GA9128@bludgeon.org> <20090223161250.GA16047@bludgeon.org> Message-ID: <200902231319.51805.dennis@ausil.us> On Monday 23 February 2009 10:12:50 am Ray Van Dolson wrote: > On Mon, Feb 23, 2009 at 12:45:32AM -0800, Ray Van Dolson wrote: > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1530-pyodbc-2.1.4-3. > >el5/ > > > > Having problems building an update to one of my packages in plague. It > > builds fine in a local mock setup I have (i386), but throws up the > > following error in what appears to be the PPC environment. It also > > looks to me like it's pulling in an older version of python for some > > reason? > > > > DEBUG backend.py:554: /usr/bin/yum --installroot > > /var/lib/mock/fedora-5-ppc-epel-867547da8866e23165d06e28b38354fc5ff867d1/ > >root/ install 'python-devel >= 2.4' 'unixODBC-devel' DEBUG util.py:280: > > Executing command: /usr/bin/yum --installroot > > /var/lib/mock/fedora-5-ppc-epel-867547da8866e23165d06e28b38354fc5ff867d1/ > >root/ install 'python-devel >= 2.4' 'unixODBC-devel' DEBUG util.py:256: > > python-devel-2.4.3-19.el5.ppc from rhel5-base has depsolving problems > > DEBUG util.py:256: --> Missing Dependency: python = 2.4.3-19.el5 is > > needed by package python-devel-2.4.3-19.el5.ppc (rhel5-base) DEBUG > > util.py:256: Error: Missing Dependency: python = 2.4.3-19.el5 is needed > > by package python-devel-2.4.3-19.el5.ppc (rhel5-base) DEBUG util.py:319: > > Child returncode was: 1 > > > > Shouldn't -21 be the current python? Anyways, not sure if this has > > anything to do with the recent outage (I did mention this to the infra > > team) or maybe just something boneheaded on my part... > > Alright, so I don't think this is just me. Just tried rebuilding > another known good package I maintain (and it hasn't changed for a long > time): > > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1536-pymssql-0.8.0-2.e >l5/ppc/job.log > > Same error. > > Ray it is being worked on Dennis From cassmodiah at fedoraproject.org Tue Feb 24 20:01:10 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Tue, 24 Feb 2009 21:01:10 +0100 Subject: autoconf and epel-5 Message-ID: <20090224210110.57ecd753@fedoraproject.org> Hi all, i have a little issue with autoconf and epel-5 the statement of the problem: in configure.ac stands: CXXFLAGS="-Wall -O2" to honor the rpmoptflags i removed this line and create a patch of my changes. now i have to run autoconf to implement my changes. no problem in fedora. in epel-5 it will abort: http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log my idea to handle this problem is: 1) run autoconf in fedora and create a diff of the changes (as patch1) 2) handle it in the specfile: %if 0%{?fedora} BuildRequires: autoconf %endif %prep %setup -q -n %{name}-%{srcversion} # Patch to remove CXXFLAGS from configure.ac %patch0 -p1 %if 0%{?rhel} # Patch for autoconf 2.60 %patch1 -p1 %endif %build %if 0%{?fedora} autoconf %endif is this the right way to solve this problem? i didn't found a helpful text passage in the packaging-guidelines -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp From smooge at gmail.com Tue Feb 24 20:28:39 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 24 Feb 2009 13:28:39 -0700 Subject: autoconf and epel-5 In-Reply-To: <20090224210110.57ecd753@fedoraproject.org> References: <20090224210110.57ecd753@fedoraproject.org> Message-ID: <80d7e4090902241228m17f4d46do87e0926e75d3eb64@mail.gmail.com> On Tue, Feb 24, 2009 at 1:01 PM, Simon Wesp wrote: > Hi all, > > i have a little issue with autoconf and epel-5 > > the statement of the problem: > > in configure.ac stands: > CXXFLAGS="-Wall -O2" > > to honor the rpmoptflags i removed this line and create a patch of my > changes. > > now i have to run autoconf to implement my changes. no problem in > fedora. in epel-5 it will abort: > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log > > > > my idea to handle this problem is: > > 1) run autoconf in fedora and create a diff of the changes (as patch1) > > 2) handle it in the specfile: > > %if 0%{?fedora} > BuildRequires: ? autoconf > %endif > > %prep > %setup -q -n %{name}-%{srcversion} > > # Patch to remove CXXFLAGS from configure.ac > %patch0 -p1 > > %if 0%{?rhel} > # Patch for autoconf 2.60 > %patch1 -p1 > %endif > > > %build > %if 0%{?fedora} > autoconf > %endif > > > is this the right way to solve this problem? i didn't found a helpful > text passage in the packaging-guidelines > That looks close to what the OpenSSH package used to do for dealing with various autoconf versions. However, not sure what is best practice either. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From a.badger at gmail.com Tue Feb 24 21:45:23 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 24 Feb 2009 13:45:23 -0800 Subject: autoconf and epel-5 In-Reply-To: <20090224210110.57ecd753@fedoraproject.org> References: <20090224210110.57ecd753@fedoraproject.org> Message-ID: <49A46A73.9060303@gmail.com> Simon Wesp wrote: > Hi all, > > i have a little issue with autoconf and epel-5 > > the statement of the problem: > > in configure.ac stands: > CXXFLAGS="-Wall -O2" > > to honor the rpmoptflags i removed this line and create a patch of my > changes. > > now i have to run autoconf to implement my changes. no problem in > fedora. in epel-5 it will abort: > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log > > > > my idea to handle this problem is: > > 1) run autoconf in fedora and create a diff of the changes (as patch1) > > 2) handle it in the specfile: > > %if 0%{?fedora} > BuildRequires: autoconf > %endif > > %prep > %setup -q -n %{name}-%{srcversion} > > # Patch to remove CXXFLAGS from configure.ac > %patch0 -p1 > > %if 0%{?rhel} > # Patch for autoconf 2.60 > %patch1 -p1 > %endif > > > %build > %if 0%{?fedora} > autoconf > %endif > > > is this the right way to solve this problem? i didn't found a helpful > text passage in the packaging-guidelines > That would work. But if you need a patch for EPEL, you might as well use the patch in Fedora as well and not run autoconf on either distro. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From cassmodiah at fedoraproject.org Tue Feb 24 21:54:27 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Tue, 24 Feb 2009 22:54:27 +0100 Subject: autoconf and epel-5 In-Reply-To: <49A46A73.9060303@gmail.com> References: <20090224210110.57ecd753@fedoraproject.org> <49A46A73.9060303@gmail.com> Message-ID: <20090224225427.41fac4ae@fedoraproject.org> Am Tue, 24 Feb 2009 13:45:23 -0800 schrieb Toshio Kuratomi : > That would work. But if you need a patch for EPEL, you might as well > use the patch in Fedora as well and not run autoconf on either distro. yeah, that would work, but the question is: "is this right or wrong?" i can use the patch for fedora, too, but it's more beautiful and more transparent if i use the patch for epel and the _real_ autoconf in fedora, or? -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp From a.badger at gmail.com Tue Feb 24 22:07:26 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 24 Feb 2009 14:07:26 -0800 Subject: autoconf and epel-5 In-Reply-To: <20090224225427.41fac4ae@fedoraproject.org> References: <20090224210110.57ecd753@fedoraproject.org> <49A46A73.9060303@gmail.com> <20090224225427.41fac4ae@fedoraproject.org> Message-ID: <49A46F9E.5000009@gmail.com> Simon Wesp wrote: > Am Tue, 24 Feb 2009 13:45:23 -0800 > schrieb Toshio Kuratomi : > >> That would work. But if you need a patch for EPEL, you might as well >> use the patch in Fedora as well and not run autoconf on either distro. > > yeah, that would work, but the question is: "is this right or wrong?" i > can use the patch for fedora, too, but it's more beautiful and more > transparent if i use the patch for epel and the _real_ autoconf in > fedora, or? > It's debatable. I usually argue that using autoconf is easier for a reviewer to see what's going on and better for getting the change upstream. But the other side of the coin is that different versions of autoconf produce different output and sometimes that output has subtle bugs. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From awilliam at redhat.com Tue Feb 24 22:06:15 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 24 Feb 2009 14:06:15 -0800 Subject: autoconf and epel-5 In-Reply-To: <20090224210110.57ecd753@fedoraproject.org> References: <20090224210110.57ecd753@fedoraproject.org> Message-ID: <1235513175.4829.37.camel@adam.local.net> On Tue, 2009-02-24 at 21:01 +0100, Simon Wesp wrote: > Hi all, > > i have a little issue with autoconf and epel-5 > > the statement of the problem: > > in configure.ac stands: > CXXFLAGS="-Wall -O2" > > to honor the rpmoptflags i removed this line and create a patch of my > changes. > > now i have to run autoconf to implement my changes. no problem in > fedora. in epel-5 it will abort: > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log The most authoritative thing I can find in the Wiki seems to frown on the practice of patching configure.ac in the first place: https://fedoraproject.org/wiki/PackagingDrafts/AutoConf "Autotools-generated source packages are intended to be buildable without requiring the autotools on the host system. autoconf, automake, libtoolize and the accompanying autoreconf shouldn't be used in the % prep or %build sections of a package's spec file. Applying a patch to update the configure scripts and Makefile.ins is preferred as the results are predictable and packages are more reproducible." If this is not in fact the agreed policy, I'd expect the agreed policy to show up more prominently in a Wiki search for 'autoconf'. :) Aside from that, I'd say did you read, and try, the advice you were given in the failure log? "You have another version of autoconf. It may work, but is not guaranteed to. If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'." i.e., see if it works with autoreconf. IMHO it is generally a good idea to use autoreconf rather than just autoconf anyway, because just using autoconf is more likely to fail if, say, we go up a major version of autoconf, and upstream source doesn't have a new release in that time. autoreconf has at least a better chance of succeeding in that situation (though it won't always). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dbn.lists at gmail.com Tue Feb 24 22:14:32 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 24 Feb 2009 14:14:32 -0800 Subject: autoconf and epel-5 In-Reply-To: <1235513175.4829.37.camel@adam.local.net> References: <20090224210110.57ecd753@fedoraproject.org> <1235513175.4829.37.camel@adam.local.net> Message-ID: <91705d080902241414y217a9051r15ea3dead7fa709b@mail.gmail.com> On Tue, Feb 24, 2009 at 2:06 PM, Adam Williamson wrote: > On Tue, 2009-02-24 at 21:01 +0100, Simon Wesp wrote: >> Hi all, >> >> i have a little issue with autoconf and epel-5 >> >> the statement of the problem: >> >> in configure.ac stands: >> CXXFLAGS="-Wall -O2" >> >> to honor the rpmoptflags i removed this line and create a patch of my >> changes. >> >> now i have to run autoconf to implement my changes. no problem in >> fedora. in epel-5 it will abort: >> http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log > > The most authoritative thing I can find in the Wiki seems to frown on > the practice of patching configure.ac in the first place: > > https://fedoraproject.org/wiki/PackagingDrafts/AutoConf > > "Autotools-generated source packages are intended to be buildable > without requiring the autotools on the host system. autoconf, automake, > libtoolize and the accompanying autoreconf shouldn't be used in the % > prep or %build sections of a package's spec file. Applying a patch to > update the configure scripts and Makefile.ins is preferred as the > results are predictable and packages are more reproducible." > > If this is not in fact the agreed policy, I'd expect the agreed policy > to show up more prominently in a Wiki search for 'autoconf'. :) > > Aside from that, I'd say did you read, and try, the advice you were > given in the failure log? > > "You have another version of autoconf. ?It may work, but is not > guaranteed to. > If you have problems, you may need to regenerate the build system entirely. > To do so, use the procedure documented by the package, typically `autoreconf'." > > i.e., see if it works with autoreconf. IMHO it is generally a good idea > to use autoreconf rather than just autoconf anyway, because just using > autoconf is more likely to fail if, say, we go up a major version of > autoconf, and upstream source doesn't have a new release in that time. > autoreconf has at least a better chance of succeeding in that situation > (though it won't always). Agreed. Just use "autoreconf -iv". Like Adam says, there's still a chance it will break, but autoreconf has a lot more smarts about using the autotools than you or I. The -i|--install is important if the project uses libtool. -- Dan From tibbs at math.uh.edu Tue Feb 24 22:41:37 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 24 Feb 2009 16:41:37 -0600 Subject: autoconf and epel-5 In-Reply-To: <1235513175.4829.37.camel@adam.local.net> (Adam Williamson's message of "Tue\, 24 Feb 2009 14\:06\:15 -0800") References: <20090224210110.57ecd753@fedoraproject.org> <1235513175.4829.37.camel@adam.local.net> Message-ID: >>>>> "AW" == Adam Williamson writes: AW> The most authoritative thing I can find in the Wiki seems to frown AW> on the practice of patching configure.ac in the first place: AW> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf Toshio already mentioned that this isn't in any way policy; I just want to reinforce the point that anyone can write anything anywhere in the wiki that sounds like packaging policy. Drafts are discussed by the packaging committee and may, after ratification by FESCo, be written into the packaging guidelines. All of the packaging guidelines exist in the Packaging namespace on the wiki. Any other page in the wiki may be the policy of some other SIG or committee, but is not an official Fedora packaging guideline. That isn't to say that such pages aren't useful. They provide useful points for discussion. There's simply no filter on them to ensure that they are balanced, reasonable or remotely sane. AW> If this is not in fact the agreed policy, I'd expect the agreed AW> policy to show up more prominently in a Wiki search for AW> 'autoconf'. :) There is no guideline relating to the use of autoconf. The situation is analogous to the absence of American federal legislation regulating the acceptable colors used to paint bike sheds. - J< From awilliam at redhat.com Tue Feb 24 23:10:21 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 24 Feb 2009 15:10:21 -0800 Subject: autoconf and epel-5 In-Reply-To: References: <20090224210110.57ecd753@fedoraproject.org> <1235513175.4829.37.camel@adam.local.net> Message-ID: <1235517021.4829.56.camel@adam.local.net> On Tue, 2009-02-24 at 16:41 -0600, Jason L Tibbitts III wrote: > >>>>> "AW" == Adam Williamson writes: > > AW> The most authoritative thing I can find in the Wiki seems to frown > AW> on the practice of patching configure.ac in the first place: > AW> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf > > Toshio already mentioned that this isn't in any way policy; I just > want to reinforce the point that anyone can write anything anywhere in > the wiki that sounds like packaging policy. I understand this, hence the qualified use of 'most authoritative'. > AW> If this is not in fact the agreed policy, I'd expect the agreed > AW> policy to show up more prominently in a Wiki search for > AW> 'autoconf'. :) > > There is no guideline relating to the use of autoconf. The situation > is analogous to the absence of American federal legislation regulating > the acceptable colors used to paint bike sheds. I would say this is an area where consistency of method is important. If discussion has dragged out with no decision being taken that's a shame, but I think it's not wasted effort to try and come up with an agreed and enforced policy for how changes to autotools-managed build scripts should be handled. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From buildsys at fedoraproject.org Wed Feb 25 16:14:26 2009 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Feb 2009 16:14:26 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2009-02-25 Message-ID: <20090225161426.42D9C18806F@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 11 NEW mingw32-nsis-2.43-3.el5 : Nullsoft Scriptable Install System NEW mingw32-nsiswrapper-3-3.el5 : Helper program for making NSIS Windows installers mirrormanager-1.2.9-1.el5 moodle-1.8.8-2.el5 NEW perl-NOCpulse-CLAC-1.9.8-1.el5 : NOCpulse Command Line Application framework for Perl NEW perl-SystemC-Vregs-1.461-1.el5 : Utility routines used by vregs Pound-2.4.4-1.el5 (!) python-shove-0.1.3-2.el5 : INVALID rebuild, not published! revisor-2.0.5.2-2.el5 s3cmd-0.9.9-1.el5 NEW ttf2pt1-3.4.4-7.el5 : TrueType to Adobe Type 1 font converter Packages built and released for Fedora EPEL testing/4: 3 moodle-1.8.8-2.el4 NEW perl-NOCpulse-CLAC-1.9.8-1.el4 : NOCpulse Command Line Application framework for Perl (!) python-shove-0.1.3-2.el4 : INVALID rebuild, not published! Changes in Fedora EPEL testing/5: mingw32-nsis-2.43-3.el5 ----------------------- * Sat Feb 21 2009 Richard W.M. Jones - 2.43-3 - Restore ExclusiveArch line (Levente Farkas). * Fri Feb 20 2009 Richard W.M. Jones - 2.43-2 - Rebuild for mingw32-gcc 4.4 * Fri Feb 13 2009 Levente Farkas - 2.43-1 - update to the latest upstream mingw32-nsiswrapper-3-3.el5 --------------------------- * Fri Feb 20 2009 Richard W.M. Jones - 3-3 - Rebuild for mingw32-gcc 4.4 mirrormanager-1.2.9-1.el5 ------------------------- * Mon Feb 23 2009 Matt Domsch - 1.2.9-1 - Adrian Reber: mirrorlist-server: check values returned by geoip before printing mirrorlist-server: ignore SIGCHLD to not have zombie processes server: also use project name and URL from config file for publiclist server: removed debug messages to decrease MM's verbosity server: make it work with Fedora's 10 python version - Jeroen van Meeuwen: Strip duplicate // from the path requested - Matt Domsch: revert publiclist_host() changes from 6a056929007b9b6bdf35367818e1212895c5bdec which weren't any faster and yet generated incorrect results. add item to TODO add push-mirroring doc mirrorlist: add trailing / to returned URLs to directories. Better handle Host creation form validation failure error case. moodle-1.8.8-2.el5 ------------------ * Mon Feb 23 2009 Jon Ciesla - 1.8.8-2 - Fixed cron. * Tue Feb 10 2009 Jon Ciesla - 1.8.8-1 - Update to 1.8.8. to fix CVE-2009-0499,0500,0501,0502. - Backported some fonts fixes. perl-NOCpulse-CLAC-1.9.8-1.el5 ------------------------------ * Thu Feb 19 2009 Miroslav Such? 1.9.8-1 - remove opt flags - add LICENSE - add GPL header to modules perl-SystemC-Vregs-1.461-1.el5 ------------------------------ * Fri Jan 09 2009 Chitlesh GOORAH 1.461-1 - new upstream release Pound-2.4.4-1.el5 ----------------- * Tue Feb 24 2009 Ruben Kerkhof 2.4.4-1 - Upstream released new version python-shove-0.1.3-2.el5 ------------------------ * Tue Jan 06 2009 Luke Macken 0.1.3-2 - Use consistent macros - Add comment about patch - Make rpmlint happy revisor-2.0.5.2-2.el5 --------------------- * Mon Feb 23 2009 Stefan Hartsuiker - 2.0.5.2-1 - Something went wrong with the previous build, fixing it. - specfile bump, git repo works according to the mailinglist s3cmd-0.9.9-1.el5 ----------------- * Tue Feb 24 2009 Lubomir Rintel (Good Data) - 0.9.9-1 - New upstream release * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 0.9.8.4-2 - Rebuild for Python 2.6 * Tue Nov 11 2008 Lubomir Rintel (Good Data) - 0.9.8.4-1 - New upstream release, URI encoding patch upstreamed * Fri Sep 26 2008 Lubomir Rintel (Good Data) - 0.9.8.3-4 - Try 3/65536 * Fri Sep 26 2008 Lubomir Rintel (Good Data) - 0.9.8.3-3 - Whoops, forgot to actually apply the patch. * Fri Sep 26 2008 Lubomir Rintel (Good Data) - 0.9.8.3-2 - Fix listing of directories with special characters in names * Thu Jul 31 2008 Lubomir Rintel (Good Data) - 0.9.8.3-1 - New upstream release: Avoid running out-of-memory in MD5'ing large files. ttf2pt1-3.4.4-7.el5 ------------------- * Sat Oct 18 2008 G?ran Uddeborg 3.4.4-7 - Don't build in parallel. Two calls of scripts/html2man on FONTS.html could step on each other toes. Changes in Fedora EPEL testing/4: moodle-1.8.8-2.el4 ------------------ * Mon Feb 23 2009 Jon Ciesla - 1.8.8-2 - Fixed cron. * Tue Feb 10 2009 Jon Ciesla - 1.8.8-1 - Update to 1.8.8. to fix CVE-2009-0499,0500,0501,0502. - Backported some fonts fixes. perl-NOCpulse-CLAC-1.9.8-1.el4 ------------------------------ * Thu Feb 19 2009 Miroslav Such? 1.9.8-1 - remove opt flags - add LICENSE - add GPL header to modules python-shove-0.1.3-2.el4 ------------------------ * Tue Jan 06 2009 Luke Macken 0.1.3-2 - Use consistent macros - Add comment about patch - Make rpmlint happy From dennis at ausil.us Wed Feb 25 15:12:07 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Feb 2009 09:12:07 -0600 Subject: moving to Koji Message-ID: <200902250912.12602.dennis@ausil.us> With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that. To move building to koji we need to get bodhi setup and redo the release engineering process to closely match that of Fedora. What this means is that you will need to file a ticket with releng to have a package added to the buildroot if you need to build against it. it also means that things can hit stable sooner. Ideally id like to make the change quickly and transparently. Right now im aiming to do it on a saturday in march. it will mean that we take plague downa nd disable builds in koji. we need to import epel into koji at that point in time. once everthing is imported and tagged, building can be enabled. All developers at that point in time will need to update there common checkouts to be able to build. This email is intended to start discussion on the migration and allow people to bring up any concerns that they have. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From rayvd at bludgeon.org Wed Feb 25 16:27:18 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 25 Feb 2009 08:27:18 -0800 Subject: moving to Koji In-Reply-To: <200902250912.12602.dennis@ausil.us> References: <200902250912.12602.dennis@ausil.us> Message-ID: <20090225162718.GA26330@bludgeon.org> On Wed, Feb 25, 2009 at 09:12:07AM -0600, Dennis Gilmore wrote: > With the koji upgrade on the weekend support was deployed for external repos. > this enables building of EPEL in koji. I have set up some tags and targets for > doing EPEL scratch builds. right now you can scratch build to dist-5E-epel > and dist-4E-epel. there is an issue i need to work around with EL-4 the old > hack we used to provide a kernel to ppc doesnt work. I am working on a > solution to that. For those of us who are weekend packagers and not super familiar with Koji, it'd be helpful to see an example or two of how I can test build some of my packages against these new targets. Can I do this with arguments to 'make' or do I need to call the koji cli client directly? > > To move building to koji we need to get bodhi setup and redo the release > engineering process to closely match that of Fedora. What this means is that > you will need to file a ticket with releng to have a package added to the > buildroot if you need to build against it. it also means that things can > hit stable sooner. > > Ideally id like to make the change quickly and transparently. Right now im > aiming to do it on a saturday in march. it will mean that we take plague > downa nd disable builds in koji. we need to import epel into koji at that > point in time. once everthing is imported and tagged, building can be enabled. > All developers at that point in time will need to update there common > checkouts to be able to build. > > This email is intended to start discussion on the migration and allow people > to bring up any concerns that they have. Ray From a.badger at gmail.com Wed Feb 25 16:42:46 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 25 Feb 2009 08:42:46 -0800 Subject: moving to Koji In-Reply-To: <200902250912.12602.dennis@ausil.us> References: <200902250912.12602.dennis@ausil.us> Message-ID: <49A57506.1050007@gmail.com> Dennis Gilmore wrote: > To move building to koji we need to get bodhi setup and redo the release > engineering process to closely match that of Fedora. What this means is that > you will need to file a ticket with releng to have a package added to the > buildroot if you need to build against it. it also means that things can > hit stable sooner. > Can we have a separate releng-epel group that can add packages to buildroots in epel, do bodhi pushes, etc? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From fedora at leemhuis.info Wed Feb 25 16:51:15 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Feb 2009 17:51:15 +0100 Subject: Looking for a "release manager" for "RPM Fusions repos for EL & EPEL" Message-ID: <49A57703.4000605@leemhuis.info> # CCed to epel-devel-list, as the audience there might be interested in # this mail as well; nevertheless please send replies to # rpmfusion-developers at lists.rpmfusion.org only, tia! Hi! As some of you may know: RPM Fusion ( http://rpmfusion.org/ ) not only supports Fedora, it also wants to support EL (e.g. RHEL and clones/derivatives like CentOS) & EPEL for EL >=5 similar to how RPM Fusion supports Fedora(?), as a lot of people asked for such a repo. The testing repositories for this are online and filled with the most important RPM Fusion packages for quite a while now; see http://thorstenl.blogspot.com/2008/11/rpm-fusion-for-el-in-early-testing.html for details how to enable those repos. In the past weeks there hasn't been much progress to move the packages to the normal repos and to officially announce support for EL & EPEL. The main reason for that: We have quite a few packagers that are interested in having the most important RPM Fusion packages available in a RPM Fusion for EL & EPEL, but afaics nobody really wants to do the surrounding work that is needed. Hence RPM Fusions look for a volunteers (or maybe two) that act a bit as "Release-Engineers/-Managers" for RPM Fusion's EL repos. The position means a bit of work, but not to much if everything works well. And the latter (making sure everything works well) is basically the job description already; e.g. make sure the repo as a whole work is in healthy state and now and in the future makes users and contributors glad. That means things like: - use the repo yourself on at least one, better more systems to get aware of any problems directly - watch or run repoclosure reports and poke maintainers if important problems are not fixed - poke maintainers if they don't fix other important bugs that might be bad for the repos reputation - watch the most important relevant communication channels (IRC, mailing lists, webforums and such that are EL specific) and look out for reports of general problems with the repo; help users, poke maintainers or improve docs if needed to avoid similar problems in the future - make sure new contributors find their way into the project and understand how things work - if important packages are missing in RPM Fusion's EL repos but are present in the repos for Fedora try to find a maintainer that takes care of the packages in RPM Fusion EL branch (there are a lot of RPM Fusion packages that are not yet in the EL branch) - help solving technical hurdles as they show up - interact with the EPEL project and its contributors where needed, as the RPM Fusion repos depend on the packages from EPEL - some others things that rel-eng in Fedora does for Fedora or I do for RPM Fusion IOW: politic and technical skills are needed for the job. Maybe more politic than technical skills, as trying to doing everything yourself could lead to a quick burn out. Note that above are just a few examples that outline how I think the job needs to be done(?). Some of those things above might sound like more work then they are actually; I otoh might have forgotten a few things in above list, so don't yell at me if it turns out to be more work then estimated later ;-) But don't be frightened, I'll help a bit here and there as well. Are you interested? Then drop me a mail in private or reply to rpmfusion-developers at lists.rpmfusion.org CU knurd (?) read as: rely on EL and EPEL, don't replace any packages from EL or EPEL, normally don't ship packages that could be in EPEL as well; (?) I'm doing that job for RPM Fusion's Fedora repos already; but I would prefer if someone else that actually uses EL more than I do does the job for RPM Fusion's EL repos From dennis at ausil.us Wed Feb 25 17:05:13 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Feb 2009 11:05:13 -0600 Subject: moving to Koji In-Reply-To: <20090225162718.GA26330@bludgeon.org> References: <200902250912.12602.dennis@ausil.us> <20090225162718.GA26330@bludgeon.org> Message-ID: <200902251105.14046.dennis@ausil.us> On Wednesday 25 February 2009 10:27:18 am Ray Van Dolson wrote: > On Wed, Feb 25, 2009 at 09:12:07AM -0600, Dennis Gilmore wrote: > > With the koji upgrade on the weekend support was deployed for external > > repos. this enables building of EPEL in koji. I have set up some tags and > > targets for doing EPEL scratch builds. right now you can scratch build > > to dist-5E-epel and dist-4E-epel. there is an issue i need to work > > around with EL-4 the old hack we used to provide a kernel to ppc doesnt > > work. I am working on a solution to that. > > For those of us who are weekend packagers and not super familiar with > Koji, it'd be helpful to see an example or two of how I can test build > some of my packages against these new targets. Can I do this with > arguments to 'make' or do I need to call the koji cli client directly? koji build dist-5E-epel --scratch koji build dist-4E-epel --scratch Dennis From fedora at leemhuis.info Wed Feb 25 17:08:02 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Feb 2009 18:08:02 +0100 Subject: moving to Koji In-Reply-To: <200902250912.12602.dennis@ausil.us> References: <200902250912.12602.dennis@ausil.us> Message-ID: <49A57AF2.7020408@leemhuis.info> On 25.02.2009 16:12, Dennis Gilmore wrote: > With the koji upgrade on the weekend support was deployed for external repos. > this enables building of EPEL in koji. I have set up some tags and targets for > doing EPEL scratch builds. right now you can scratch build to dist-5E-epel > and dist-4E-epel. there is an issue i need to work around with EL-4 the old > hack we used to provide a kernel to ppc doesnt work. I am working on a > solution to that. Sounds good. > To move building to koji we need to get bodhi setup and redo the release > engineering process to closely match that of Fedora. What this means is that > you will need to file a ticket with releng to have a package added to the > buildroot if you need to build against it. it also means that things can > hit stable sooner. Ehh, do we really want that apart from security updates or important bugfixes (which we can and do push within minutes these days already if needed)? I ask because the "monthly" move from testing to the porper repos has a important side-effect: I slows everything down when compared to the quickly moving Fedora, which for EL repos IMHO is something good. > [...] Cu knurd From dennis at ausil.us Wed Feb 25 17:10:22 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Feb 2009 11:10:22 -0600 Subject: moving to Koji In-Reply-To: <49A57506.1050007@gmail.com> References: <200902250912.12602.dennis@ausil.us> <49A57506.1050007@gmail.com> Message-ID: <200902251110.23059.dennis@ausil.us> On Wednesday 25 February 2009 10:42:46 am Toshio Kuratomi wrote: > Dennis Gilmore wrote: > > To move building to koji we need to get bodhi setup and redo the release > > engineering process to closely match that of Fedora. What this means is > > that you will need to file a ticket with releng to have a package added > > to the buildroot if you need to build against it. it also means that > > things can hit stable sooner. > > Can we have a separate releng-epel group that can add packages to > buildroots in epel, do bodhi pushes, etc? > > -Toshio Checking into this, there are some finer grained acls in the new koji but i dont not fully understand them. so im not sure if this is possible. Luke says that bodhi should be fine. I need to setup an epel signing box in phx to sign the packages on. we will continue to use the epel_signers group for epel releng Dennis From a.badger at gmail.com Wed Feb 25 17:21:45 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 25 Feb 2009 09:21:45 -0800 Subject: moving to Koji In-Reply-To: <49A57AF2.7020408@leemhuis.info> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> Message-ID: <49A57E29.4070601@gmail.com> Thorsten Leemhuis wrote: > On 25.02.2009 16:12, Dennis Gilmore wrote: >> With the koji upgrade on the weekend support was deployed for external >> repos. this enables building of EPEL in koji. I have set up some tags >> and targets for doing EPEL scratch builds. right now you can scratch >> build to dist-5E-epel and dist-4E-epel. there is an issue i need to >> work around with EL-4 the old hack we used to provide a kernel to ppc >> doesnt work. I am working on a solution to that. > > Sounds good. > >> To move building to koji we need to get bodhi setup and redo the >> release engineering process to closely match that of Fedora. What this >> means is that you will need to file a ticket with releng to have a >> package added to the buildroot if you need to build against it. it >> also means that things can hit stable sooner. > > Ehh, do we really want that apart from security updates or important > bugfixes (which we can and do push within minutes these days already if > needed)? > > I ask because the "monthly" move from testing to the porper repos has a > important side-effect: I slows everything down when compared to the > quickly moving Fedora, which for EL repos IMHO is something good. > I think this would still be possible with bodhi by having the epel_signers push to testing frequently but push to stable on a monthly basis. Have to ask releng/lmacken to be sure, though. If that does work it gives packagers the ability to leave things in the testing repo without having to explicitly tell people not to move it everytime a new push to stable is being prepared. Not sure if that would be "abused" though.... likely there would need to be guidance on whether it's proper usage of the testing repo to leave a package in there forever. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From fedora at leemhuis.info Wed Feb 25 19:11:23 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Feb 2009 20:11:23 +0100 Subject: moving to Koji In-Reply-To: <49A57E29.4070601@gmail.com> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <49A57E29.4070601@gmail.com> Message-ID: <49A597DB.3010809@leemhuis.info> On 25.02.2009 18:21, Toshio Kuratomi wrote: > Thorsten Leemhuis wrote: >> On 25.02.2009 16:12, Dennis Gilmore wrote: > [...] >>> To move building to koji we need to get bodhi setup and redo the >>> release engineering process to closely match that of Fedora. What this >>> means is that you will need to file a ticket with releng to have a >>> package added to the buildroot if you need to build against it. it >>> also means that things can hit stable sooner. >> Ehh, do we really want that apart from security updates or important >> bugfixes (which we can and do push within minutes these days already if >> needed)? >> I ask because the "monthly" move from testing to the porper repos has a >> important side-effect: I slows everything down when compared to the >> quickly moving Fedora, which for EL repos IMHO is something good. > > I think this would still be possible with bodhi by having the > epel_signers push to testing frequently but push to stable on a monthly > basis. Have to ask releng/lmacken to be sure, though. Luke, can you clarify? And if above works: can one push selected packages (security updates and those that fix other serious bugs) at any time while leaving the other, regular updates for the next monthly move? BTW, does the EPEL Steering Committee actually care about that or are they fine with a steady update stream instead of monthly pushes? > If that does work it gives packagers the ability to leave things in the > testing repo without having to explicitly tell people not to move it > everytime a new push to stable is being prepared. Not sure if that > would be "abused" though.... Yeah, it could make the whole testing repo completely useless if packagers push experimental updates to the testing repo with the intention to never move them to the stable repos :-/ > likely there would need to be guidance on > whether it's proper usage of the testing repo to leave a package in > there forever. Yeah, we need to put a rule in place here afaics. A time limit maybe? Could the steering committee maybe put that onto its todo list? BTW, does the EPEL Steering Committee still exist/meet at all? Cu knurd From jeff at osuosl.org Wed Feb 25 19:28:36 2009 From: jeff at osuosl.org (Jeff Sheltren) Date: Wed, 25 Feb 2009 11:28:36 -0800 Subject: moving to Koji In-Reply-To: <200902250912.12602.dennis@ausil.us> References: <200902250912.12602.dennis@ausil.us> Message-ID: On Feb 25, 2009, at 7:12 AM, Dennis Gilmore wrote: > With the koji upgrade on the weekend support was deployed for > external repos. > this enables building of EPEL in koji. I have set up some tags and > targets for > doing EPEL scratch builds. right now you can scratch build to > dist-5E-epel > and dist-4E-epel. there is an issue i need to work around with > EL-4 the old > hack we used to provide a kernel to ppc doesnt work. I am working > on a > solution to that. Dennis, this is awesome, thanks for your work on getting EPEL cured of the plague! -Jeff From jeff at osuosl.org Wed Feb 25 19:40:06 2009 From: jeff at osuosl.org (Jeff Sheltren) Date: Wed, 25 Feb 2009 11:40:06 -0800 Subject: meetings and some issues In-Reply-To: <20090209103415.4e0fe999@ohm.scrye.com> References: <20090209103415.4e0fe999@ohm.scrye.com> Message-ID: <3FBA74EA-25FF-4BF1-BE68-296E5F29E1EF@osuosl.org> On Feb 9, 2009, at 9:34 AM, Kevin Fenzi wrote: > Greetings. > > Since we haven't had an epel meeting in quite a while, I would like to > revisit the idea of a new meeting time. Perhaps we could setup a table > in the wiki for people to fill in and choose the best time that way? > Or perhaps someone would like to suggest a time? Yes, I think it's important for us to meet more frequently than we have been, at the very least to keep things fresh in our minds :) Can we setup a Doodle poll or something similar to find a time that would work for people? I'd like to get at least the steering committee members decided on a time, and others that are interested are of course welcome to participate. -Jeff From laxathom at fedoraproject.org Wed Feb 25 21:06:36 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 25 Feb 2009 22:06:36 +0100 Subject: moving to Koji In-Reply-To: <49A597DB.3010809@leemhuis.info> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <49A57E29.4070601@gmail.com> <49A597DB.3010809@leemhuis.info> Message-ID: <62bc09df0902251306j14c4c0edxb04252849443b654@mail.gmail.com> On Wed, Feb 25, 2009 at 8:11 PM, Thorsten Leemhuis wrote: > On 25.02.2009 18:21, Toshio Kuratomi wrote: >> >> Thorsten Leemhuis wrote: >>> >>> On 25.02.2009 16:12, Dennis Gilmore wrote: > >> [...] >>>> >>>> To move building to koji we need to get bodhi setup and redo the >>>> release engineering process to closely match that of Fedora. What this >>>> means is that you will need to file a ticket with releng to have a >>>> package added to the buildroot ?if you need to build against it. ? it >>>> also means that things can hit stable sooner. >>> >>> Ehh, do we really want that apart from security updates or important >>> bugfixes (which we can and do push within minutes these days already if >>> needed)? >>> I ask because the "monthly" move from testing to the porper repos has a >>> important side-effect: I slows everything down when compared to the >>> quickly moving Fedora, which for EL repos IMHO is something good. > >> >> >> I think this would still be possible with bodhi by having the >> epel_signers push to testing frequently but push to stable on a monthly >> basis. ?Have to ask releng/lmacken to be sure, though. > > Luke, can you clarify? And if above works: can one push selected packages > (security updates and those that fix other serious bugs) at any time while > leaving the other, regular updates for the next monthly move? Right, a such think is (should ?) possible as pushes are done manually iirc Track down all bodhi's security tag on EPEL packages and push them regulary. And as said above, let epel_signers do push to make sure that packages are really a security update. > > BTW, does the EPEL Steering Committee actually care about that or are they > fine with a steady update stream instead of monthly pushes? yeah, I'd say, keep our monthly updates for enhancements and bugfixes and improve push update for security fixes. > >> If that does work it gives packagers the ability to leave things in the >> testing repo without having to explicitly tell people not to move it >> everytime a new push to stable is being prepared. ?Not sure if that >> would be "abused" though.... +1 > > Yeah, it could make the whole testing repo completely useless if packagers > push experimental updates to the testing repo with the intention to never > move them to the stable repos ?:-/ Updates have life cycle in bodhi afaik. Packager can also remove themselves the update by revoke the request. I think the best way to avoid a such think os to update our EPEL guideline on push updates. We can also do a monthly check. > >> likely there would need to be guidance on >> whether it's proper usage of the testing repo to leave a package in >> there forever. Correct (though above). > > Yeah, we need to put a rule in place here afaics. A time limit maybe? Could > the steering committee maybe put that onto its todo list? Will do this week-end if that don't hurt anyone on the time. > > BTW, does the EPEL Steering Committee still exist/meet at all? > yeah, we're still alive ;) Meeting ? :: it's something i think that we (should improve ?) need to talk about. Kevin is doing a great job by handling our meeting as far as possible. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From laxathom at fedoraproject.org Wed Feb 25 21:24:48 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 25 Feb 2009 22:24:48 +0100 Subject: moving to Koji In-Reply-To: <200902250912.12602.dennis@ausil.us> References: <200902250912.12602.dennis@ausil.us> Message-ID: <62bc09df0902251324t3e8923bbpc55ef2998e64cc01@mail.gmail.com> 2009/2/25 Dennis Gilmore : > With the koji upgrade on the weekend support was deployed for external repos. > this enables building of EPEL in koji. I have set up some tags and targets for > doing EPEL scratch builds. ?right now you can scratch build to dist-5E-epel > and dist-4E-epel. ?there is an issue i need to work around with EL-4 ?the old > hack we used to provide a kernel to ppc doesnt work. ?I am working on a > solution to that. > > To move building to koji we need to get bodhi setup and redo the release > engineering process to closely match that of Fedora. What this means is that > you will need to file a ticket with releng to have a package added to the > buildroot ?if you need to build against it. ? it also means that things can > hit stable sooner. > > Ideally id like to make the change quickly and transparently. Right now im > aiming to do it on a saturday in march. ?it will mean that we take plague > downa nd disable builds in koji. we need to import epel into koji at that > point in time. once everthing is imported and tagged, building can be enabled. > All developers at that point in time will need to update there common > checkouts to be able to build. Would you mind file tickets on that, i'll take some. > > This email is intended to start discussion on the migration and allow people > to bring up any concerns that they have. > Do we have packages awaiting push from epel_signers ? if so, we should run that push then freeze updates before import epel to koji. [/me is thinking about other possible phases...] -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From dennis at ausil.us Wed Feb 25 22:15:30 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Feb 2009 16:15:30 -0600 Subject: moving to Koji In-Reply-To: <62bc09df0902251324t3e8923bbpc55ef2998e64cc01@mail.gmail.com> References: <200902250912.12602.dennis@ausil.us> <62bc09df0902251324t3e8923bbpc55ef2998e64cc01@mail.gmail.com> Message-ID: <200902251615.30679.dennis@ausil.us> On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote: > 2009/2/25 Dennis Gilmore : > > With the koji upgrade on the weekend support was deployed for external > > repos. this enables building of EPEL in koji. I have set up some tags and > > targets for doing EPEL scratch builds. ?right now you can scratch build > > to dist-5E-epel and dist-4E-epel. ?there is an issue i need to work > > around with EL-4 ?the old hack we used to provide a kernel to ppc doesnt > > work. ?I am working on a solution to that. > > > > To move building to koji we need to get bodhi setup and redo the release > > engineering process to closely match that of Fedora. What this means is > > that you will need to file a ticket with releng to have a package added > > to the buildroot ?if you need to build against it. ? it also means that > > things can hit stable sooner. > > > > Ideally id like to make the change quickly and transparently. Right now > > im aiming to do it on a saturday in march. ?it will mean that we take > > plague downa nd disable builds in koji. we need to import epel into koji > > at that point in time. once everthing is imported and tagged, building > > can be enabled. All developers at that point in time will need to update > > there common checkouts to be able to build. > > Would you mind file tickets on that, i'll take some. > > > This email is intended to start discussion on the migration and allow > > people to bring up any concerns that they have. > > Do we have packages awaiting push from epel_signers ? > if so, we should run that push then freeze updates before import epel to > koji. This is how i saw it going down 1) shut down plague 2) do epel push 3) manually run the sync one last time from buildsys to the primary mirror 3) import packages from primary mirror into koji 4) tag packages as appropriate in koji. 5) make changes to Makefile.common 6) send out notice that builds are open 7) do stable and testing composes from koji and verify that they are the same as whats on the primary mirror (one caveat there will only be the latest pkg not latest2) 8) profit 9) switch off buildsys.fp.o before we get there we need. compose box bodhi to know about EPEL some testing of compose process's Dennis From laxathom at fedoraproject.org Wed Feb 25 22:45:53 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 25 Feb 2009 23:45:53 +0100 Subject: moving to Koji In-Reply-To: <200902251615.30679.dennis@ausil.us> References: <200902250912.12602.dennis@ausil.us> <62bc09df0902251324t3e8923bbpc55ef2998e64cc01@mail.gmail.com> <200902251615.30679.dennis@ausil.us> Message-ID: <62bc09df0902251445y1708a5f6xbfc3df7a6584daf0@mail.gmail.com> On Wed, Feb 25, 2009 at 11:15 PM, Dennis Gilmore wrote: > On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote: >> >> Do we have packages awaiting push from epel_signers ? >> if so, we should run that push then freeze updates before import epel to >> koji. > This is how i saw it going down > + 0) send out notice that build are closed > 1) shut down plague > 2) do epel push > 3) manually run the sync one last time from buildsys to the primary mirror > 3) import packages from primary mirror into koji > 4) tag packages as appropriate in koji. > 5) make changes to Makefile.common > 6) send out notice that builds are open > 7) do stable and testing composes from koji and verify that they are the same > as whats on the primary mirror (one caveat there will only be the latest pkg > not latest2) > 8) profit > 9) switch off buildsys.fp.o Excellent. > > before we get there we need. > compose box How many ? afaik, most of our plague builders also do koji or will we need new setup for EPEL support ?. > bodhi to know about EPEL Luke, how much time do you need to make that happen ? Feel free to ask if you need any help. > some testing of compose process's + some testing of signing process's + some testing of push from bodhi Thanks for the migration step, -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From dennis at ausil.us Wed Feb 25 23:20:27 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Feb 2009 17:20:27 -0600 Subject: moving to Koji In-Reply-To: <62bc09df0902251445y1708a5f6xbfc3df7a6584daf0@mail.gmail.com> References: <200902250912.12602.dennis@ausil.us> <200902251615.30679.dennis@ausil.us> <62bc09df0902251445y1708a5f6xbfc3df7a6584daf0@mail.gmail.com> Message-ID: <200902251720.27942.dennis@ausil.us> On Wednesday 25 February 2009 04:45:53 pm Xavier Lamien wrote: > On Wed, Feb 25, 2009 at 11:15 PM, Dennis Gilmore wrote: > > On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote: > >> Do we have packages awaiting push from epel_signers ? > >> if so, we should run that push then freeze updates before import epel to > >> koji. > > > > This is how i saw it going down > > + 0) send out notice that build are closed There will need to be a few announcement emails sent out but yes :) > > 1) shut down plague > > 2) do epel push > > 3) manually run the sync one last time from buildsys to the primary > > mirror 3) import packages from primary mirror into koji > > 4) tag packages as appropriate in koji. > > 5) make changes to Makefile.common > > 6) send out notice that builds are open > > 7) do stable and testing composes from koji and verify that they are the > > same as whats on the primary mirror (one caveat there will only be the > > latest pkg not latest2) > > 8) profit > > 9) switch off buildsys.fp.o > > Excellent. > > > before we get there we need. > > compose box > > How many ? > afaik, most of our plague builders also do koji or will we need new setup > for EPEL support ?. 1 box to use for signing packages and doing sanity checks etc. > > bodhi to know about EPEL > > Luke, how much time do you need to make that happen ? > Feel free to ask if you need any help. > > > some testing of compose process's > > + some testing of signing process's > + some testing of push from bodhi > > Thanks for the migration step, From smooge at gmail.com Thu Feb 26 00:08:03 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 25 Feb 2009 17:08:03 -0700 Subject: meetings and some issues In-Reply-To: <3FBA74EA-25FF-4BF1-BE68-296E5F29E1EF@osuosl.org> References: <20090209103415.4e0fe999@ohm.scrye.com> <3FBA74EA-25FF-4BF1-BE68-296E5F29E1EF@osuosl.org> Message-ID: <80d7e4090902251608hf681903l6ff29d0384c6aabb@mail.gmail.com> On Wed, Feb 25, 2009 at 12:40 PM, Jeff Sheltren wrote: > On Feb 9, 2009, at 9:34 AM, Kevin Fenzi wrote: > >> Greetings. >> >> Since we haven't had an epel meeting in quite a while, I would like to >> revisit the idea of a new meeting time. Perhaps we could setup a table >> in the wiki for people to fill in and choose the best time that way? >> Or perhaps someone would like to suggest a time? > > Yes, I think it's important for us to meet more frequently than we have > been, at the very least to keep things fresh in our minds :) > > Can we setup a Doodle poll or something similar to find a time that would > work for people? ?I'd like to get at least the steering committee members > decided on a time, and others that are interested are of course welcome to > participate. > I am usually good in the afternoons. Mornings have become problematic. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mastahnke at gmail.com Thu Feb 26 02:53:55 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 25 Feb 2009 20:53:55 -0600 Subject: meetings and some issues In-Reply-To: <80d7e4090902251608hf681903l6ff29d0384c6aabb@mail.gmail.com> References: <20090209103415.4e0fe999@ohm.scrye.com> <3FBA74EA-25FF-4BF1-BE68-296E5F29E1EF@osuosl.org> <80d7e4090902251608hf681903l6ff29d0384c6aabb@mail.gmail.com> Message-ID: <31673515-423B-4064-BEA7-6CD007CF5613@gmail.com> On Feb 25, 2009, at 18:08, Stephen John Smoogen wrote: > On Wed, Feb 25, 2009 at 12:40 PM, Jeff Sheltren > wrote: >> On Feb 9, 2009, at 9:34 AM, Kevin Fenzi wrote: >> >>> Greetings. >>> >>> Since we haven't had an epel meeting in quite a while, I would >>> like to >>> revisit the idea of a new meeting time. Perhaps we could setup a >>> table >>> in the wiki for people to fill in and choose the best time that way? >>> Or perhaps someone would like to suggest a time? >> >> Yes, I think it's important for us to meet more frequently than we >> have >> been, at the very least to keep things fresh in our minds :) >> >> Can we setup a Doodle poll or something similar to find a time that >> would >> work for people? I'd like to get at least the steering committee >> members >> decided on a time, and others that are interested are of course >> welcome to >> participate. >> > > I am usually good in the afternoons. Mornings have become problematic. Me too. I'd like something after lunch and before dinner given an absolute choice. CST. > > > -- > Stephen J Smoogen. -- BSD/GNU/Linux > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list From michel.sylvan at gmail.com Thu Feb 26 17:13:08 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 26 Feb 2009 12:13:08 -0500 Subject: Looking for a "release manager" for "RPM Fusions repos for EL & EPEL" In-Reply-To: <49A57703.4000605@leemhuis.info> References: <49A57703.4000605@leemhuis.info> Message-ID: On Wed, Feb 25, 2009 at 11:51 AM, Thorsten Leemhuis wrote: > # CCed to epel-devel-list, as the audience there might be interested in > # this mail as well; nevertheless please send replies to > # rpmfusion-developers at lists.rpmfusion.org only, tia! > > Hi! > > As some of you may know: RPM Fusion ( http://rpmfusion.org/ ) not only > supports Fedora, it also wants to support EL (e.g. RHEL and > clones/derivatives like CentOS) & EPEL for EL >=5 similar to how RPM Fusion > supports Fedora(?), as a lot of people asked for such a repo. The testing > repositories for this are online and filled with the most important RPM > Fusion packages for quite a while now; see > http://thorstenl.blogspot.com/2008/11/rpm-fusion-for-el-in-early-testing.html > for details how to enable those repos. > > In the past weeks there hasn't been much progress to move the packages to > the normal repos and to officially announce support for EL & EPEL. The main > reason for that: We have quite a few packagers that are interested in having > the most important RPM Fusion packages available in a RPM Fusion for EL & > EPEL, but afaics nobody really wants to do the surrounding work that is > needed. Hence RPM Fusions look for a volunteers (or maybe two) that act a > bit as "Release-Engineers/-Managers" for RPM Fusion's EL repos. > > The position means a bit of work, but not to much if everything works well. > And the latter (making sure everything works well) is basically the job > description already; e.g. make sure the repo as a whole work is in healthy > state and now and in the future makes users and contributors glad. That > means things like: > Are there legal aspects to be considered? I'm a non-US citizen residing in the US, and I'm interested in this, but would rather stay away from having official responsibility for packages such as gstreamer-plugins-{ugly,bad}. Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From maxamillion at gmail.com Thu Feb 26 17:21:27 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 26 Feb 2009 11:21:27 -0600 Subject: Looking for a "release manager" for "RPM Fusions repos for EL & EPEL" In-Reply-To: References: <49A57703.4000605@leemhuis.info> Message-ID: I would be interested in participating (already package for EPEL but know that there are some things we can't put in EPEL but would be nice for EL to have). Unfortunately I completely lack the time to head up something like this, but would be more than willing to lend a hand if I am able. -Adam On Thu, Feb 26, 2009 at 11:13 AM, Michel Salim wrote: > On Wed, Feb 25, 2009 at 11:51 AM, Thorsten Leemhuis > wrote: >> # CCed to epel-devel-list, as the audience there might be interested in >> # this mail as well; nevertheless please send replies to >> # rpmfusion-developers at lists.rpmfusion.org only, tia! >> >> Hi! >> >> As some of you may know: RPM Fusion ( http://rpmfusion.org/ ) not only >> supports Fedora, it also wants to support EL (e.g. RHEL and >> clones/derivatives like CentOS) & EPEL for EL >=5 similar to how RPM Fusion >> supports Fedora(?), as a lot of people asked for such a repo. The testing >> repositories for this are online and filled with the most important RPM >> Fusion packages for quite a while now; see >> http://thorstenl.blogspot.com/2008/11/rpm-fusion-for-el-in-early-testing.html >> for details how to enable those repos. >> >> In the past weeks there hasn't been much progress to move the packages to >> the normal repos and to officially announce support for EL & EPEL. The main >> reason for that: We have quite a few packagers that are interested in having >> the most important RPM Fusion packages available in a RPM Fusion for EL & >> EPEL, but afaics nobody really wants to do the surrounding work that is >> needed. Hence RPM Fusions look for a volunteers (or maybe two) that act a >> bit as "Release-Engineers/-Managers" for RPM Fusion's EL repos. >> >> The position means a bit of work, but not to much if everything works well. >> And the latter (making sure everything works well) is basically the job >> description already; e.g. make sure the repo as a whole work is in healthy >> state and now and in the future makes users and contributors glad. That >> means things like: >> > Are there legal aspects to be considered? I'm a non-US citizen > residing in the US, and I'm interested in this, but would rather stay > away from having official responsibility for packages such as > gstreamer-plugins-{ugly,bad}. > > Regards, > > -- > mi?el salim ?? ?http://hircus.jaiku.com/ > IUCS ? ? ? ? ? ?msalim at cs.indiana.edu > Fedora ? ? ? ? ?salimma at fedoraproject.org > MacPorts ? ? ? ?hircus at macports.org > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From smooge at gmail.com Thu Feb 26 22:13:53 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Feb 2009 15:13:53 -0700 Subject: moving to Koji In-Reply-To: <49A57AF2.7020408@leemhuis.info> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> Message-ID: <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> On Wed, Feb 25, 2009 at 10:08 AM, Thorsten Leemhuis wrote: > On 25.02.2009 16:12, Dennis Gilmore wrote: >> >> With the koji upgrade on the weekend support was deployed for external >> repos. ?this enables building of EPEL in koji. I have set up some tags and >> targets for doing EPEL scratch builds. ?right now you can scratch build to >> dist-5E-epel and dist-4E-epel. ?there is an issue i need to work around with >> EL-4 ?the old hack we used to provide a kernel to ppc doesnt work. ?I am >> working on a solution to that. > > Sounds good. > >> To move building to koji we need to get bodhi setup and redo the release >> engineering process to closely match that of Fedora. What this means is that >> you will need to file a ticket with releng to have a package added to the >> buildroot ?if you need to build against it. ? it also means that things can >> hit stable sooner. > > Ehh, do we really want that apart from security updates or important > bugfixes (which we can and do push within minutes these days already if > needed)? > > I ask because the "monthly" move from testing to the porper repos has a > important side-effect: I slows everything down when compared to the quickly > moving Fedora, which for EL repos IMHO is something good. Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jonstanley at gmail.com Thu Feb 26 22:47:36 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 26 Feb 2009 17:47:36 -0500 Subject: moving to Koji In-Reply-To: <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> Message-ID: On Thu, Feb 26, 2009 at 5:13 PM, Stephen John Smoogen wrote: > Well I would like to have it that it actually has bodhi votes before > it can be moved. We can have a process for the number of votes needed, > but I would rather have something getting a couple of +1's that can be > tracked than a 1 month timeframe and no one looking at it. What about packages that don't get wide exposure? Are they to be forever barred from EPEL (they would be under this proposal)? From rayvd at bludgeon.org Thu Feb 26 22:59:58 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 26 Feb 2009 14:59:58 -0800 Subject: moving to Koji In-Reply-To: References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> Message-ID: <20090226225958.GA20606@bludgeon.org> On Thu, Feb 26, 2009 at 05:47:36PM -0500, Jon Stanley wrote: > On Thu, Feb 26, 2009 at 5:13 PM, Stephen John Smoogen wrote: > > > Well I would like to have it that it actually has bodhi votes before > > it can be moved. We can have a process for the number of votes needed, > > but I would rather have something getting a couple of +1's that can be > > tracked than a 1 month timeframe and no one looking at it. > > What about packages that don't get wide exposure? Are they to be > forever barred from EPEL (they would be under this proposal)? Yep, shoot.. I'd say most of my Fedora packages are niche enough that the users that do exist certainly know nothing of bodhi nor of how to give my update karma. :) Even fewer on the EPEL front. We'd all just be bugging each other to vote for our own updates :) From sundaram at fedoraproject.org Thu Feb 26 23:11:25 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 27 Feb 2009 04:41:25 +0530 Subject: moving to Koji In-Reply-To: <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> Message-ID: <49A7219D.6030907@fedoraproject.org> Stephen John Smoogen wrote: > > Well I would like to have it that it actually has bodhi votes before > it can be moved. We can have a process for the number of votes needed, > but I would rather have something getting a couple of +1's that can be > tracked than a 1 month timeframe and no one looking at it. You don't have a big enough community for any such process to work well. EPEL user and contributor base is still small. You should keep things relaxed up atleast until you get a larger base to cover. Rahul From jkeating at redhat.com Thu Feb 26 23:07:24 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Feb 2009 15:07:24 -0800 Subject: moving to Koji In-Reply-To: <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> Message-ID: <1235689644.9121.192.camel@localhost.localdomain> On Thu, 2009-02-26 at 15:13 -0700, Stephen John Smoogen wrote: > > Well I would like to have it that it actually has bodhi votes before > it can be moved. We can have a process for the number of votes needed, > but I would rather have something getting a couple of +1's that can be > tracked than a 1 month timeframe and no one looking at it. Small note, it was overly protective processes like these that contributed to the fall of Fedora Legacy. It's a really really hard balance to strike :/ -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Fri Feb 27 00:32:27 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Feb 2009 17:32:27 -0700 Subject: moving to Koji In-Reply-To: <1235689644.9121.192.camel@localhost.localdomain> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> <1235689644.9121.192.camel@localhost.localdomain> Message-ID: <80d7e4090902261632w44fbde4cqea467d1fe2a82601@mail.gmail.com> 2009/2/26 Jesse Keating : > On Thu, 2009-02-26 at 15:13 -0700, Stephen John Smoogen wrote: >> >> Well I would like to have it that it actually has bodhi votes before >> it can be moved. We can have a process for the number of votes needed, >> but I would rather have something getting a couple of +1's that can be >> tracked than a 1 month timeframe and no one looking at it. > > Small note, it was overly protective processes like these that > contributed to the fall of Fedora Legacy. ?It's a really really hard > balance to strike :/ > Well I didn't think of it as overly protective when I wrote it, but that is normally the case isnt it. I figured we have a small subset of packages that we maintain... and we have a process where stuff may sit in testing for a month but we have no feedback on whats there. Instead I figured we could have a process where we could see that a package was tested, by whom, and with what and could be considered 'stable'. My current I-havent-had-a-good-night-sleep-in-a-week feeling is that calling our repositories testing and stable is misleading. They are just snapshots that are more accurately called "this-month" and "next-month". My guess is that going further than that would require the resources that people pay Red Hat for :). -- Stephen J Smoogen. -- BSD/GNU/Linux 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 Fri Feb 27 09:25:22 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Feb 2009 10:25:22 +0100 Subject: moving to Koji In-Reply-To: <49A7219D.6030907@fedoraproject.org> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> <49A7219D.6030907@fedoraproject.org> Message-ID: <49A7B182.7090605@leemhuis.info> On 27.02.2009 00:11, Rahul Sundaram wrote: > Stephen John Smoogen wrote: > >> Well I would like to have it that it actually has bodhi votes before >> it can be moved. We can have a process for the number of votes needed, >> but I would rather have something getting a couple of +1's that can be >> tracked than a 1 month timeframe and no one looking at it. > You don't have a big enough community for any such process to work well. I tend to agree. > EPEL user and contributor base is still small. You should keep things > relaxed up atleast until you get a larger base to cover. Even then I'd say it bureaucracy that is better avoided. Cu knurd From fedora at leemhuis.info Fri Feb 27 15:29:16 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Feb 2009 16:29:16 +0100 Subject: Looking for a "release manager" for "RPM Fusions repos for EL & EPEL" In-Reply-To: References: <49A57703.4000605@leemhuis.info> Message-ID: <49A806CC.3000800@leemhuis.info> On 26.02.2009 18:13, Michel Salim wrote: > On Wed, Feb 25, 2009 at 11:51 AM, Thorsten Leemhuis > wrote: > [...] >> In the past weeks there hasn't been much progress to move the packages to >> the normal repos and to officially announce support for EL & EPEL. The main >> reason for that: We have quite a few packagers that are interested in having >> the most important RPM Fusion packages available in a RPM Fusion for EL & >> EPEL, but afaics nobody really wants to do the surrounding work that is >> needed. Hence RPM Fusions look for a volunteers (or maybe two) that act a >> bit as "Release-Engineers/-Managers" for RPM Fusion's EL repos. >> >> The position means a bit of work, but not to much if everything works well. >> And the latter (making sure everything works well) is basically the job >> description already; e.g. make sure the repo as a whole work is in healthy >> state and now and in the future makes users and contributors glad. That >> means things like: > Are there legal aspects to be considered? I'm a non-US citizen > residing in the US, Sorry, can really answer that as I'm not really familiar with such things in general or with US law. But it's afaics not like it's a official position (or something like that) which would make you responsible for what happens in the repo. But you certainly would be a "contributor". > and I'm interested in this, Sounds good! > but would rather stay > away from having official responsibility for packages such as > gstreamer-plugins-{ugly,bad}. A indicated in my earlier mail already: The main part of the job is make the repo as a whole work. That now and then might mean to take care of a packages as maintainer, but that doesn't have to be gstreamer-plugins-{ugly,bad} (which hans wanted to take care of himself iirc; seems he hasn't found time for it yet). Cu knurd From fedora at leemhuis.info Fri Feb 27 15:37:56 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Feb 2009 16:37:56 +0100 Subject: Looking for a "release manager" for "RPM Fusions repos for EL & EPEL" In-Reply-To: References: <49A57703.4000605@leemhuis.info> Message-ID: <49A808D4.3050709@leemhuis.info> On 26.02.2009 18:21, Adam Miller wrote: > I would be interested in participating (already package for EPEL but > know that there are some things we can't put in EPEL but would be nice > for EL to have). Unfortunately I completely lack the time to head up > something like this, but would be more than willing to lend a hand if > I am able. RPM Fusion (and its EL repos) is a open project just like Fedora and of course any help to improve it is highly appreciated. ;-) RPM Fusion further uses similar rules -- round about the Fedora and EPEL guidelines and rules with a few small exceptions/adjuments needed due to the different nature. The infrastructure is also similar -- currently CVS and plague just like EPEL. So if you want to package something for EL that can't be in EPEL that just submit it as review to bugzilla.rpmfusion.org ;-) If it's in RPM Fusion's repos for Fedora already then just step up as maintainer. The same rules as EPEL apply here: e.g. ask the maintainer of the Fedora branch if he's fine with you taking care of the package in the EL branch. So if you have a few spare cycles just look out for areas where you think improvements are needed and "just do it" ;-) CU knurd > On Thu, Feb 26, 2009 at 11:13 AM, Michel Salim wrote: >> On Wed, Feb 25, 2009 at 11:51 AM, Thorsten Leemhuis >> wrote: >>> # CCed to epel-devel-list, as the audience there might be interested in >>> # this mail as well; nevertheless please send replies to >>> # rpmfusion-developers at lists.rpmfusion.org only, tia! >>> >>> Hi! >>> >>> As some of you may know: RPM Fusion ( http://rpmfusion.org/ ) not only >>> supports Fedora, it also wants to support EL (e.g. RHEL and >>> clones/derivatives like CentOS) & EPEL for EL >=5 similar to how RPM Fusion >>> supports Fedora(?), as a lot of people asked for such a repo. The testing >>> repositories for this are online and filled with the most important RPM >>> Fusion packages for quite a while now; see >>> http://thorstenl.blogspot.com/2008/11/rpm-fusion-for-el-in-early-testing.html >>> for details how to enable those repos. >>> >>> In the past weeks there hasn't been much progress to move the packages to >>> the normal repos and to officially announce support for EL & EPEL. The main >>> reason for that: We have quite a few packagers that are interested in having >>> the most important RPM Fusion packages available in a RPM Fusion for EL & >>> EPEL, but afaics nobody really wants to do the surrounding work that is >>> needed. Hence RPM Fusions look for a volunteers (or maybe two) that act a >>> bit as "Release-Engineers/-Managers" for RPM Fusion's EL repos. >>> >>> The position means a bit of work, but not to much if everything works well. >>> And the latter (making sure everything works well) is basically the job >>> description already; e.g. make sure the repo as a whole work is in healthy >>> state and now and in the future makes users and contributors glad. That >>> means things like: >>> >> Are there legal aspects to be considered? I'm a non-US citizen >> residing in the US, and I'm interested in this, but would rather stay >> away from having official responsibility for packages such as >> gstreamer-plugins-{ugly,bad}. >> >> Regards, >> >> -- >> mi?el salim ? http://hircus.jaiku.com/ >> IUCS ? msalim at cs.indiana.edu >> Fedora ? salimma at fedoraproject.org >> MacPorts ? hircus at macports.org >> >> _______________________________________________ >> epel-devel-list mailing list >> epel-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/epel-devel-list >> > > > From skasal at redhat.com Fri Feb 27 11:26:27 2009 From: skasal at redhat.com (Stepan Kasal) Date: Fri, 27 Feb 2009 12:26:27 +0100 Subject: autoconf and epel-5 In-Reply-To: <20090224210110.57ecd753@fedoraproject.org> References: <20090224210110.57ecd753@fedoraproject.org> Message-ID: <20090227112626.GA15601@camelia.ucw.cz> Hello, [obviously, I wasn't able to _read_ the thread, but a quick grep seems to indicate my point has not been mentioned yet, at least the first solution I'm going to recommend] on Tue, Feb 24, 2009 at 09:01:10PM +0100, Simon Wesp wrote: > in configure.ac stands: > CXXFLAGS="-Wall -O2" As you surely know, this is a bug, please report it to hosts3d developers. CXXFLAGS can be overrided at any time, so you can let configure to hose the default and then override at make time: make CXXFLAGS='%{rpmoptflags}' and, to be sure, again in %install make CXXFLAGS='%{rpmoptflags}' install In theory, the checks performed by configure might be affected by the incorrect value of CXXFLAGS, but I do not think this is a problem in practice. That presents the easiest way to fix the issue. [Yes, stop reading here, unless you are really curious.] [Congratulations and kind regards to the wise ones who leave us at the moment. Stepan] > fedora. in epel-5 it will abort: > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log The error message says that the version of autoconf that has been used when aclocal.m4 was created is not compatible with the version you are currently using. Actually, this is only one of the complex interconnections between Autoconf and Automake. You always have to call aclocal, autoconf, and automake in the spec file. A simple way to refresh both of these is: BuildRequire: autoconf automake .. %build autoreconf -f -i That presents the second easiest solution. [Last chance to leave; good bye to the wise ones. Stepan] A side note: it is often mentioned that running autotools in spec file can trigger subtle bugs. That is true, but most of these bugs are caused by problematic code in configure.ac (or Makefile.am's), so the fix is to clean up these and submit the resulting patches upstream, which is generally a good thing. Back to our problem. Then come the solutions which patch generated files: 3) Third solution, with a bit of hacking: Since the change to configure.ac is minimal and you know the expected effect on configure, you can do the thing manually. In both cases, fix the date of configure.ac. Make would try to run aclocal, autoconf, and automake otherwise, resulting in subtle differences between builds depending on presence of autoconf and automake in the tree. You can either create a patch that deletes the line from configure: %prep .. # patches both configure.ac and configure %patch77 -p1 -b.cxxflags touch -r configure.ac.cxxflags configure.ac or use sed %prep .. touch -r configure.ac configure.mystamp sed -i /^CXXFLAGS=/d configure.ac configure touch -r configure.mystamp configure.ac rm configure.mystamp 4) Fourth solution would be to create a patch that contains all the results of autoreconf run. Though it might seem that the Fedora Packaging Guidelines encourage this type of solution, it the most tricky one. You have to take care of all the following things: - you have to have automake installed on the machine and include also the patches to aclocal.m4 and all the Makefile.in's - OTOH, you should omit the contents of autom4te.cache subdirectory from the new tree - you have to get the timestamps right, e.g. by reorganizing the diffs for individial files in the patch; configure.ac has to be the oldest, then aclocal.m4, then all others (configure and Makefile.in's) Happy hacking, Stepan From smooge at gmail.com Fri Feb 27 23:25:28 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 27 Feb 2009 16:25:28 -0700 Subject: moving to Koji In-Reply-To: <49A7B182.7090605@leemhuis.info> References: <200902250912.12602.dennis@ausil.us> <49A57AF2.7020408@leemhuis.info> <80d7e4090902261413v5b54bc49k80d0d339412fac0a@mail.gmail.com> <49A7219D.6030907@fedoraproject.org> <49A7B182.7090605@leemhuis.info> Message-ID: <80d7e4090902271525j3a88a7dev7ad25824e45bdd59@mail.gmail.com> On Fri, Feb 27, 2009 at 2:25 AM, Thorsten Leemhuis wrote: > On 27.02.2009 00:11, Rahul Sundaram wrote: >> >> Stephen John Smoogen wrote: >> >>> Well I would like to have it that it actually has bodhi votes before >>> it can be moved. We can have a process for the number of votes needed, >>> but I would rather have something getting a couple of +1's that can be >>> tracked than a 1 month timeframe and no one looking at it. >> >> You don't have a big enough community for any such process to work well. > > I tend to agree. > >> EPEL user and contributor base is still small. You should keep things >> relaxed up atleast until you get a larger base to cover. > > Even then I'd say it bureaucracy that is better avoided. > Ok the definition of a bureaucracy from wikipedia is: Bureaucracy is the structure and set of regulations in place to control activity, usually in large organizations and government. As opposed to adhocracy, it is represented by standardized procedure (rule-following) that dictates the execution of most or all processes within the body, formal division of powers, hierarchy, and relationships. In practice the interpretation and execution of policy can lead to informal influence. My guess is that the group would prefer an adhocracy Adhocracy is a type of organization being antonymous to bureaucracy. The term was first popularized in 1970 by Alvin Toffler[1], and has since become often used in the theory of management of organizations (particularly online organizations), further developed by academics such as Henry Mintzberg. http://en.wikipedia.org/wiki/Adhocracy It requires sophisticated and often automated technical systems to develop and thrive.[1] Characteristics of an adhocracy: * highly organic structure[2] * little formalization of behavior[2][1] * job specialization based on formal training[2] * a tendency to group the specialists in functional units for housekeeping purposes but to deploy them in small, market-based project teams to do their work[2] * a reliance on liaison devices to encourage mutual adjustment, the key coordinating mechanism, within and between these teams[2][3] * low standardization of procedures, because they stifle innovation[1] * roles not clearly defined[1] * selective decentralization[1] * work organization rests on specialized teams[1] * power-shifts to specialized teams * horizontal job specialization[3] * high cost of communication[3] * culture based on democratic and non-bureaucratic work [3] If that is what people are wanting.. then we will need to show how we are considering these packages Enterprise ready... otherwise lets get rid of the pretext of 'stable' and push towards making the tools to make it work. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"