From updates at fedoraproject.org Tue Jan 5 22:32:37 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 05 Jan 2010 22:32:37 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100105223257.B758810F8F1@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing gromacs-4.0.7-1.el4 ocsinventory-agent-1.1.2-1.el4 openwsman-2.2.0-7.el4 phpMyAdmin-2.11.9.6-3.el4 python-pip-0.6.1-4.el4 Details about builds: ================================================================================ gromacs-4.0.7-1.el4 (FEDORA-EPEL-2010-0014) Fast, Free and Flexible Molecular Dynamics -------------------------------------------------------------------------------- Update Information: Update to 4.0.7. -------------------------------------------------------------------------------- ChangeLog: * Thu Dec 31 2009 Jussi Lehtola - 4.0.7-1 - Update to 4.0.7. * Fri May 22 2009 Jussi Lehtola - 4.0.5-1 - Update to 4.0.5. - Change spec %defines to %globals. - Add debug subpackages to make debugging of GROMACS possible. -------------------------------------------------------------------------------- ================================================================================ ocsinventory-agent-1.1.2-1.el4 (FEDORA-EPEL-2010-0019) Open Computer and Software Inventory Next Generation client -------------------------------------------------------------------------------- Update Information: Upstream Changelog: 1.1.2 Sun, 27 Dec 2009 17:24:43 +0100 * Avoid problem with dmidecode -V output on RHEL3.9 (Remi COLLET) * Fix internal --delaytime handling. That's seconds, not hours! * Download.pm: improve a error message 1.1.1 Mon, 21 Dec 2009 22:38:12 +0100 * NETWORKS/VIRTUALDEV should be 1 or 0 * FreeBSD: Fix CPU detection (David DURIEUX) * Virtualization::Qemu, fix kvm detection * Don't run brctl if it's not installed * Various wording fixes (Vincent KNECHT) * LP: #494908 Agent fails to retrieve info file when a package is activated only with the server name (Pascal DANEK) * LP: #495398 Fix RedHat version detection (St?phane URBANOVSKI) * LP: #490774 Fix PowerPC CPU detection on Linux, thanks darkpep for the bug report -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 3 2010 Remi Collet 1.1.2-1 - update to 1.1.2 - missing perl(Net::IP) requires * Tue Dec 22 2009 Remi Collet 1.1.1-1 - update to 1.1.1 - add Requires: which -------------------------------------------------------------------------------- ================================================================================ openwsman-2.2.0-7.el4 (FEDORA-EPEL-2010-0028) Opensource Implementation of WS-Management -------------------------------------------------------------------------------- Update Information: Updated the spec file to follow the upstream packaging and made few other changes to make sure the server starts properly without any failures while creating an openssl certificate. -------------------------------------------------------------------------------- ChangeLog: * Thu Dec 31 2009 Praveen K Paladugu - 2.2.0-7 - Removed the dependency on libcurl-devel and added curl-devel. - remove the hard coding of ruby while determing the sitearch and sitelibs. * Mon Dec 28 2009 Praveen K Paladugu - 2.2.0-6 - Changed the random file used for creating an openssl cert * Mon Dec 28 2009 Praveen K Paladugu - 2.2.0-5 - Added a few Build dependencies * Mon Dec 28 2009 Praveen K Paladugu - 2.2.0-4 - Following the upstream packaging, updated the spec file to break the - package into server, client, lib components. -------------------------------------------------------------------------------- ================================================================================ phpMyAdmin-2.11.9.6-3.el4 (FEDORA-EPEL-2010-0013) Web based MySQL browser written in php -------------------------------------------------------------------------------- Update Information: - Added missing blowfish secret entry in default config (#540871) - Backported patch to hash blowfish secret for cookie auth (#540891) - Require php-mcrypt for cookie authentication (#526979) -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 4 2010 Robert Scheck 2.11.9.6-3 - Require php-mcrypt for cookie authentication (#526979) * Mon Jan 4 2010 Robert Scheck 2.11.9.6-2 - Added missing blowfish secret entry in default config (#540871) - Backported patch to hash blowfish secret for cookie auth (#540891) -------------------------------------------------------------------------------- References: [ 1 ] Bug #540871 - Missing blowfish secret entry in sample config in /etc/phpMyAdmin https://bugzilla.redhat.com/show_bug.cgi?id=540871 [ 2 ] Bug #540891 - blowfish secret for cookie authentication is not hashed / fails if size too long https://bugzilla.redhat.com/show_bug.cgi?id=540891 [ 3 ] Bug #526979 - phpmyadmin should requires php-mcrypt ? https://bugzilla.redhat.com/show_bug.cgi?id=526979 -------------------------------------------------------------------------------- ================================================================================ python-pip-0.6.1-4.el4 (FEDORA-EPEL-2010-0021) Pip installs packages. Python packages. An easy_install replacement -------------------------------------------------------------------------------- Update Information: Make sure the RPM depends on python-setuptools -------------------------------------------------------------------------------- ChangeLog: -------------------------------------------------------------------------------- References: [ 1 ] Bug #551078 - [abrt] crash detected in python-pip-0.6.1-3.fc12 https://bugzilla.redhat.com/show_bug.cgi?id=551078 -------------------------------------------------------------------------------- From updates at fedoraproject.org Tue Jan 5 22:32:37 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 05 Jan 2010 22:32:37 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100105223257.CDE1A10F8F3@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing 389-ds-base-1.2.5-0.5.rc4.el5 ReviewBoard-1.0.5.1-2.el5 cciss_vol_status-1.06-2.el5 collectl-3.3.6-1.el5 dbus-cxx-0.5.1-1.el5 git-bugzilla-0-0.2.20091211git.el5 glusterfs-2.0.9-1.el5 gromacs-4.0.7-1.el5 gstreamer-java-1.3-1.el5 hspell-1.1-2.el5 maxima-5.20.1-2.el5 ocsinventory-agent-1.1.2-1.el5 openwsman-2.2.0-5.el5 osutil-1.3.1-1.el5.1 perl-Text-CSV-1.10-3.el5 phpMyAdmin-2.11.9.6-3.el5 pki-common-1.3.0-6.el5 pki-java-tools-1.3.0-4.el5.1 python-djblets-0.5.6-0.el5 python-pip-0.6.1-4.el5 pywbem-0.7.0-3.el5 report-0.4-3.el5 squirrel-2.2.4-1.el5 vpnc-0.5.3-6.el5 wxMaxima-0.8.4-1.el5 zfs-fuse-0.6.0-6.el5 Details about builds: ================================================================================ 389-ds-base-1.2.5-0.5.rc4.el5 (FEDORA-EPEL-2010-0007) 389 Directory Server (base) -------------------------------------------------------------------------------- Update Information: This is 1.2.5 Release Candidate 4 (.rc4) -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 4 2010 Rich Megginson - 1.2.5-0.5.rc4 - 1.2.5.rc4 release * Thu Dec 17 2009 Rich Megginson - 1.2.5-0.4.rc3 - 1.2.5.rc3 release -------------------------------------------------------------------------------- References: [ 1 ] Bug #533025 - Tracking bug for 389 Directory Server 1.2.5 https://bugzilla.redhat.com/show_bug.cgi?id=533025 -------------------------------------------------------------------------------- ================================================================================ ReviewBoard-1.0.5.1-2.el5 (FEDORA-EPEL-2010-0026) Web-based code review tool -------------------------------------------------------------------------------- Update Information: New package for ReviewBoard -------------------------------------------------------------------------------- ================================================================================ cciss_vol_status-1.06-2.el5 (FEDORA-EPEL-2010-0012) Show status of logical drives attached to HP Smartarray controllers -------------------------------------------------------------------------------- Update Information: A very lightweight program to report the status of logical drives on Smart Array controllers and also fibre channel attached MSA1000. -------------------------------------------------------------------------------- References: [ 1 ] Bug #547427 - Review Request: cciss_vol_status - show status of logical drives attached to HP Smartarray controllers https://bugzilla.redhat.com/show_bug.cgi?id=547427 -------------------------------------------------------------------------------- ================================================================================ collectl-3.3.6-1.el5 (FEDORA-EPEL-2010-0027) An utility to collect various linux performance data -------------------------------------------------------------------------------- Update Information: - upgrade to upstream version 3.3.6 - changelog: http://collectl.sourceforge.net/Releases.html -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 5 2010 Dan Hor?k 3.3.6-1 - upgrade to upstream version 3.3.6 -------------------------------------------------------------------------------- ================================================================================ dbus-cxx-0.5.1-1.el5 (FEDORA-EPEL-2010-0001) C++ bindings for the DBus library -------------------------------------------------------------------------------- Update Information: dbus-cxx is a C++ wrapper for the dbus library http://dbus-cxx.sourceforge.net ===== 0.5.1 ===== This release fixes a bug in the append iterator when a second child container is used. Thanks to Tyler Conant for hunting this one down. -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 4 2010 Rick L Vinyard Jr - 0.5.1-1 - New release -------------------------------------------------------------------------------- ================================================================================ git-bugzilla-0-0.2.20091211git.el5 (FEDORA-EPEL-2010-0003) Attach patches to a bugzilla bug -------------------------------------------------------------------------------- ================================================================================ glusterfs-2.0.9-1.el5 (FEDORA-EPEL-2010-0016) Cluster File System -------------------------------------------------------------------------------- Update Information: Update to 2.0.9. -------------------------------------------------------------------------------- ChangeLog: * Sat Jan 2 2010 Jonathan Steffan - 2.0.9-1 - Update to 2.0.9 -------------------------------------------------------------------------------- ================================================================================ gromacs-4.0.7-1.el5 (FEDORA-EPEL-2010-0004) Fast, Free and Flexible Molecular Dynamics -------------------------------------------------------------------------------- Update Information: Update to 4.0.7. -------------------------------------------------------------------------------- ChangeLog: * Thu Dec 31 2009 Jussi Lehtola - 4.0.7-1 - Update to 4.0.7. * Fri May 22 2009 Jussi Lehtola - 4.0.5-1 - Update to 4.0.5. - Change spec %defines to %globals. - Add debug subpackages to make debugging of GROMACS possible. -------------------------------------------------------------------------------- ================================================================================ gstreamer-java-1.3-1.el5 (FEDORA-EPEL-2010-0010) Java interface to the gstreamer framework -------------------------------------------------------------------------------- ChangeLog: * Sat Dec 26 2009 Levente Farkas - 1.3-1 - update to version 1.3 * Fri Jul 24 2009 Fedora Release Engineering - 1.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild -------------------------------------------------------------------------------- ================================================================================ hspell-1.1-2.el5 (FEDORA-EPEL-2010-0005) A Hebrew spell checker -------------------------------------------------------------------------------- Update Information: update to new upstream version and fix spec typo -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 1 2010 Dan Kenigsberg - 1.1-2 - Rebase to upstream version 1.1 and fix spec typos. * Thu Dec 31 2009 Dan Kenigsberg - 1.1-1 - Rebase to upstream version 1.1 * Fri Jul 24 2009 Fedora Release Engineering - 1.0-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Tue Feb 24 2009 Fedora Release Engineering - 1.0-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sun Sep 21 2008 Ville Skytt? - 1.0-11 - Fix Patch0:/%patch mismatch. * Thu Jul 31 2008 Tom "spot" Callaway - 1.0-10 - fix license tag * Wed May 14 2008 Caolan McNamara - 1.0-9 - Resolves: rhbz#313231 build hspell.so instead of a .a -------------------------------------------------------------------------------- ================================================================================ maxima-5.20.1-2.el5 (FEDORA-EPEL-2009-1053) Symbolic Computation Program -------------------------------------------------------------------------------- Update Information: Maxima 5.20 is a bug fix and feature enhancement release. See also, http://www.math.utexas.edu/pipermail/maxima/2009/019967.html -------------------------------------------------------------------------------- ChangeLog: * Wed Dec 16 2009 Stephen Beahm - 5.20.1-2 - enable rmaxima (#551910) * Tue Dec 15 2009 Rex Dieter - 5.20.1-1 - maxima-5.20.1 (#547012) * Thu Dec 10 2009 Rex Dieter - 5.20.0-1 - maxima-5.20.0 * Mon Oct 26 2009 Rex Dieter - 5.19.2-3 - rebuild (sbcl) * Tue Sep 29 2009 Rex Dieter - 5.19.2-2 - rebuild (cmucl) * Sun Aug 30 2009 Rex Dieter - 5.19.2-1 - maxima-5.19.2 * Sat Aug 22 2009 Rex Dieter - 5.19.1-1 - maxima-5.19.1 - -gui: optimize scriptlets * Tue Aug 18 2009 Rex Dieter - 5.19.0-2 - safer evaluation of %sbcl_ver macro * Sat Aug 1 2009 Rex Dieter - 5.19.0-1 - maxima-5.19.0 -------------------------------------------------------------------------------- References: [ 1 ] Bug #551910 - enable rmaxima https://bugzilla.redhat.com/show_bug.cgi?id=551910 -------------------------------------------------------------------------------- ================================================================================ ocsinventory-agent-1.1.2-1.el5 (FEDORA-EPEL-2010-0018) Open Computer and Software Inventory Next Generation client -------------------------------------------------------------------------------- Update Information: Upstream Changelog: 1.1.2 Sun, 27 Dec 2009 17:24:43 +0100 * Avoid problem with dmidecode -V output on RHEL3.9 (Remi COLLET) * Fix internal --delaytime handling. That's seconds, not hours! * Download.pm: improve a error message 1.1.1 Mon, 21 Dec 2009 22:38:12 +0100 * NETWORKS/VIRTUALDEV should be 1 or 0 * FreeBSD: Fix CPU detection (David DURIEUX) * Virtualization::Qemu, fix kvm detection * Don't run brctl if it's not installed * Various wording fixes (Vincent KNECHT) * LP: #494908 Agent fails to retrieve info file when a package is activated only with the server name (Pascal DANEK) * LP: #495398 Fix RedHat version detection (St?phane URBANOVSKI) * LP: #490774 Fix PowerPC CPU detection on Linux, thanks darkpep for the bug report -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 3 2010 Remi Collet 1.1.2-1 - update to 1.1.2 - missing perl(Net::IP) requires * Tue Dec 22 2009 Remi Collet 1.1.1-1 - update to 1.1.1 - add Requires: which -------------------------------------------------------------------------------- ================================================================================ openwsman-2.2.0-5.el5 (FEDORA-EPEL-2010-0017) Opensource Implementation of WS-Management -------------------------------------------------------------------------------- Update Information: Updated the spec file to follow the upstream packaging and made few other changes to make sure the server starts properly without any failures while creating an openssl certificate. -------------------------------------------------------------------------------- ChangeLog: * Tue Dec 29 2009 Praveen K Paladugu - 2.2.0-5 - Updating the spec file to follow the upstream packaging format. -------------------------------------------------------------------------------- ================================================================================ osutil-1.3.1-1.el5.1 (FEDORA-EPEL-2010-0024) Operating System Utilities JNI Package -------------------------------------------------------------------------------- Update Information: Operating System Utilities Java Native Interface (JNI) -------------------------------------------------------------------------------- ChangeLog: * Mon Dec 14 2009 Kevin Wright 1.3.1-1 - Removed BuildRequires bash - Removed 'with exceptions' from License -------------------------------------------------------------------------------- References: [ 1 ] Bug #521983 - New package for Dogtag PKI: osutil https://bugzilla.redhat.com/show_bug.cgi?id=521983 -------------------------------------------------------------------------------- ================================================================================ perl-Text-CSV-1.10-3.el5 (FEDORA-EPEL-2010-0002) Comma-separated values manipulator -------------------------------------------------------------------------------- Update Information: Text::CSV provides facilities for the composition and decomposition of comma- separated values. An instance of the Text::CSV class can combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and can utilize any user-specified characters as delimiters, separators, and escapes so it is perhaps better called ASV (anything separated values) rather than just CSV. -------------------------------------------------------------------------------- References: [ 1 ] Bug #483406 - Review Request: perl-Text-CSV - Comma-separated values manipulator https://bugzilla.redhat.com/show_bug.cgi?id=483406 -------------------------------------------------------------------------------- ================================================================================ phpMyAdmin-2.11.9.6-3.el5 (FEDORA-EPEL-2010-0015) Web based MySQL browser written in php -------------------------------------------------------------------------------- Update Information: - Added missing blowfish secret entry in default config (#540871) - Backported patch to hash blowfish secret for cookie auth (#540891) - Require php-mcrypt for cookie authentication (#526979) -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 4 2010 Robert Scheck 2.11.9.6-3 - Require php-mcrypt for cookie authentication (#526979) * Mon Jan 4 2010 Robert Scheck 2.11.9.6-2 - Added missing blowfish secret entry in default config (#540871) - Backported patch to hash blowfish secret for cookie auth (#540891) -------------------------------------------------------------------------------- References: [ 1 ] Bug #540871 - Missing blowfish secret entry in sample config in /etc/phpMyAdmin https://bugzilla.redhat.com/show_bug.cgi?id=540871 [ 2 ] Bug #540891 - blowfish secret for cookie authentication is not hashed / fails if size too long https://bugzilla.redhat.com/show_bug.cgi?id=540891 [ 3 ] Bug #526979 - phpmyadmin should requires php-mcrypt ? https://bugzilla.redhat.com/show_bug.cgi?id=526979 -------------------------------------------------------------------------------- ================================================================================ pki-common-1.3.0-6.el5 (FEDORA-EPEL-2010-0025) Dogtag Certificate System - PKI Common Framework -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Common Framework -------------------------------------------------------------------------------- References: [ 1 ] Bug #522207 - New Package for Dogtag PKI: pki-common https://bugzilla.redhat.com/show_bug.cgi?id=522207 -------------------------------------------------------------------------------- ================================================================================ pki-java-tools-1.3.0-4.el5.1 (FEDORA-EPEL-2010-0009) Dogtag Certificate System - PKI Java-Based Tools -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Java Tools -------------------------------------------------------------------------------- References: [ 1 ] Bug #521995 - New Package for Dogtag PKI:pki-java-tools https://bugzilla.redhat.com/show_bug.cgi?id=521995 -------------------------------------------------------------------------------- ================================================================================ python-djblets-0.5.6-0.el5 (FEDORA-EPEL-2010-0006) A collection of useful classes and functions for Django -------------------------------------------------------------------------------- Update Information: New package for python-djblets (a dependency of ReviewBoard) -------------------------------------------------------------------------------- ================================================================================ python-pip-0.6.1-4.el5 (FEDORA-EPEL-2010-0022) Pip installs packages. Python packages. An easy_install replacement -------------------------------------------------------------------------------- Update Information: Make sure RPM depends on python-setuptools. -------------------------------------------------------------------------------- ChangeLog: -------------------------------------------------------------------------------- References: [ 1 ] Bug #551078 - [abrt] crash detected in python-pip-0.6.1-3.fc12 https://bugzilla.redhat.com/show_bug.cgi?id=551078 -------------------------------------------------------------------------------- ================================================================================ pywbem-0.7.0-3.el5 (FEDORA-EPEL-2010-0023) Python WBEM Client and Provider Interface -------------------------------------------------------------------------------- ================================================================================ report-0.4-3.el5 (FEDORA-EPEL-2010-0029) Incident reporting library -------------------------------------------------------------------------------- ================================================================================ squirrel-2.2.4-1.el5 (FEDORA-EPEL-2010-0020) High level imperative/OO programming language -------------------------------------------------------------------------------- Update Information: update to 2.2.4 -fixed bug in functions with default parameters -------------------------------------------------------------------------------- ChangeLog: * Sun Dec 27 2009 Dan Hor?k 2.2.4-1 - update to upstream version 2.2.4 * Wed Jul 1 2009 Dan Hor?k 2.2.3-1 - update to upstream version 2.2.3 * Wed Feb 25 2009 Fedora Release Engineering - 2.2.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild -------------------------------------------------------------------------------- ================================================================================ vpnc-0.5.3-6.el5 (FEDORA-EPEL-2010-0008) IPSec VPN client compatible with Cisco equipment -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 5 2010 Huzaifa Sidhpurwala - 0.5.3-6 - Include vpnc-cleanup * Tue Jan 5 2010 Huzaifa Sidhpurwala - 0.5.3-4 - Build from F-12 branch * Sun Jul 26 2009 Fedora Release Engineering - 0.5.3-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Wed Feb 25 2009 Fedora Release Engineering - 0.5.3-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Thu Nov 20 2008 Tomas Mraz - 0.5.3-2 - upgrade to new version - fix race in vpnc-cleanup (#465315) * Thu Jul 24 2008 Tomas Mraz - 0.5.1-6 - do not modify domain in resolv.conf (#446404) - clean up modified resolv.conf on startup (#455899) * Sat Apr 5 2008 Michal Schmidt - 0.5.1-5 - vpnc-script: fix 'ip link ...' syntax. * Thu Apr 3 2008 Tomas Mraz - 0.5.1-4 - drop autogenerated perl requires (#440304) - compute MTU based on default route device (#433846) * Wed Feb 20 2008 Fedora Release Engineering - 0.5.1-3 - Autorebuild for GCC 4.3 * Tue Nov 13 2007 Tomas Mraz - 0.5.1-2 - try to make DPD less sensitive (#345281) * Thu Sep 20 2007 Tomas Mraz - 0.5.1-1 - upgrade to latest upstream * Mon Sep 3 2007 Tomas Mraz - 0.4.0-4 - fix long standing bug causing problems on x86_64 (#232565) now for real * Wed Aug 22 2007 Tomas Mraz - 0.4.0-3 - license tag fix -------------------------------------------------------------------------------- References: [ 1 ] Bug #531403 - Please add vpnc >= 0.5.1 (preferably 0.5.3) to EPEL repo https://bugzilla.redhat.com/show_bug.cgi?id=531403 [ 2 ] Bug #453950 - vpnc 0.4.0 unable to connect to Cisco VPN concentrator https://bugzilla.redhat.com/show_bug.cgi?id=453950 -------------------------------------------------------------------------------- ================================================================================ wxMaxima-0.8.4-1.el5 (FEDORA-EPEL-2009-1053) Graphical user interface for Maxima -------------------------------------------------------------------------------- Update Information: Maxima 5.20 is a bug fix and feature enhancement release. See also, http://www.math.utexas.edu/pipermail/maxima/2009/019967.html -------------------------------------------------------------------------------- ChangeLog: * Tue Dec 22 2009 Rex Dieter - 0.8.4-1 - wxMaxima-0.8.4 * Fri Nov 13 2009 Rex Dieter - 0.8.3a-1.1 - Requires: maxima >= 5.19 (#521722) * Sun Oct 25 2009 Rex Dieter - 0.8.3a-1 - wxMaxima-0.8.3a (#530915) -------------------------------------------------------------------------------- References: [ 1 ] Bug #551910 - enable rmaxima https://bugzilla.redhat.com/show_bug.cgi?id=551910 -------------------------------------------------------------------------------- ================================================================================ zfs-fuse-0.6.0-6.el5 (FEDORA-EPEL-2010-0011) ZFS ported to Linux FUSE -------------------------------------------------------------------------------- Update Information: Relaxed dependency for fuse from version 2.8 to 2.7 to allow installation on RHEL/Centos -------------------------------------------------------------------------------- References: [ 1 ] Bug #551610 - EPEL package is dependent on fuse 2.8.x which is not present on RHEL/Centos https://bugzilla.redhat.com/show_bug.cgi?id=551610 -------------------------------------------------------------------------------- From vpivaini at cs.helsinki.fi Thu Jan 7 21:17:25 2010 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Thu, 07 Jan 2010 23:17:25 +0200 Subject: Moin orphaned in EL-4 and EL-5 Message-ID: <1262899045.1753.13.camel@lightweight> Hi, I've orphaned the moin package in the EL-4 and EL-5 branches. I will keep maintaining the package in Fedora >= 11. I'll quote an earlier mail I sent to the EPEL list: "I took ownership of the moin package in Fedora and EPEL for about six months ago. I haven't gotten around to doing almost anything to it, though, mostly because I have to admit that I'm not that interested in EPEL since I don't run any EL installations myself. The other hurdle in updating moin is that the package in EPEL is really old by now. It's in version 1.5 and the newest upstream version is 1.9. If there was an update submitted for moin, we'd need to also have some instructions on how to convert the wiki data into a format which is suitable for the new version, and frankly, I don't know how to do that, since I've only gotten involved with moin during the 1.7 era. All I know is that trying to go from 1.5 to 1.6 was really difficult when it was tested with the Fedora wiki data back when Fedora was still running moin." I hope someone who cares about having moin in EPEL would take over the package and figure out how the data upgrade process would be best described to the users of the package or how to backport security patches from the maintained releases. If not, I think we could also retire moin from EPEL completely. -- Ville-Pekka Vainio From updates at fedoraproject.org Thu Jan 7 21:44:10 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Thu, 07 Jan 2010 21:44:10 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100107214434.4963D10F8F9@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing BareBonesBrowserLaunch-2.0-2.el5 gnucash-2.2.9-3.el5 mediawiki-LdapAccount-0.1-1.el5 orbited-0.7.10-3.el5 puppet-0.25.2-1.el5.1 report-0.5-1.el5 udunits2-2.1.11-1.el5 varnish-2.0.6-2.el5 Details about builds: ================================================================================ BareBonesBrowserLaunch-2.0-2.el5 (FEDORA-EPEL-2010-0033) Simple library to launch a browser window from Java -------------------------------------------------------------------------------- Update Information: Utility class to open a web page from a Swing application in the user's default browser. -------------------------------------------------------------------------------- ================================================================================ gnucash-2.2.9-3.el5 (FEDORA-EPEL-2010-0036) Finance management application -------------------------------------------------------------------------------- Update Information: This updates GnuCash to the latest upstream minor release, which includes a variety of bug fixes. See http://gnucash.org/#090224-2-2-9.news for the upstream release announcement, which goes into more detail on the bugs fixed. -------------------------------------------------------------------------------- ChangeLog: * Thu Dec 10 2009 Bill Nottingham - Fix accelerators (#533019, #541915) * Wed Aug 12 2009 Ville Skytt? - 2.2.9-3 - Use lzma compressed upstream tarball. * Fri Jul 24 2009 Fedora Release Engineering - 2.2.9-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Thu Mar 5 2009 Bill Nottingham - 2.2.9-1 - update to 2.2.9 * Tue Feb 24 2009 Fedora Release Engineering - 2.2.8-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Mon Dec 22 2008 Bill Nottingham - 2.2.8-2 - fix crash resulting from earlier crash fix (#474511, ) * Tue Dec 16 2008 Bill Nottingham - 2.2.8-1 - update to 2.2.8 * Fri Dec 5 2008 Bill Nottingham - 2.2.7-2 - fix crash with glib-2.19 (#474511, ) -------------------------------------------------------------------------------- ================================================================================ mediawiki-LdapAccount-0.1-1.el5 (FEDORA-EPEL-2009-1073) Use LDAP as account source for medaiwiki -------------------------------------------------------------------------------- Update Information: New package. -------------------------------------------------------------------------------- References: [ 1 ] Bug #548203 - Review Request: mediawiki-LdapAccount - Use LDAP as an account source for medaiwiki https://bugzilla.redhat.com/show_bug.cgi?id=548203 -------------------------------------------------------------------------------- ================================================================================ orbited-0.7.10-3.el5 (FEDORA-EPEL-2010-0030) A browser(javascript)->tcp bridge -------------------------------------------------------------------------------- Update Information: Initial release of Orbited for F12, F11, and EL5 -------------------------------------------------------------------------------- References: [ 1 ] Bug #499476 - Review Request: orbited - A browser(javascript)->tcp bridge https://bugzilla.redhat.com/show_bug.cgi?id=499476 -------------------------------------------------------------------------------- ================================================================================ puppet-0.25.2-1.el5.1 (FEDORA-EPEL-2010-0031) A network tool for managing many disparate systems -------------------------------------------------------------------------------- Update Information: The update from 0.24.x to 0.25.x brings many, many changes and improvements to puppet. The upstream release notes cover them in detail: http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes Of note is that 0.25.x clients do not work with 0.24.x masters, so it is important to update the master before or at the same time as clients. -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1.1 - Replace %define with %global for macros * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1 - Update to 0.25.2 - Fixes CVE-2010-0156, tmpfile security issue (#502881) - Install auth.conf, puppetqd manpage, and queuing examples/docs * Wed Nov 25 2009 Jeroen van Meeuwen - 0.25.1-1 - New upstream version * Tue Oct 27 2009 Todd Zullinger - 0.25.1-0.3 - Update to 0.25.1 - Include the pi program and man page (R.I.Pienaar) * Sat Oct 17 2009 Todd Zullinger - 0.25.1-0.2.rc2 - Update to 0.25.1rc2 * Tue Sep 22 2009 Todd Zullinger - 0.25.1-0.1.rc1 - Update to 0.25.1rc1 - Move puppetca to puppet package, it has uses on client systems - Drop redundant %doc from manpage %file listings * Fri Sep 4 2009 Todd Zullinger - 0.25.0-1 - Update to 0.25.0 - Fix permissions on /var/log/puppet (#495096) - Install emacs mode and vim syntax files (#491437) - Install ext/ directory in %{_datadir}/puppet (/usr/share/puppet) -------------------------------------------------------------------------------- References: [ 1 ] Bug #502881 - CVE-2010-0156 puppet: several insecure tempfile creation issues https://bugzilla.redhat.com/show_bug.cgi?id=502881 -------------------------------------------------------------------------------- ================================================================================ report-0.5-1.el5 (FEDORA-EPEL-2010-0039) Incident reporting library -------------------------------------------------------------------------------- ================================================================================ udunits2-2.1.11-1.el5 (FEDORA-EPEL-2010-0035) A library for manipulating units of physical quantities -------------------------------------------------------------------------------- Update Information: The Unidata units utility, udunits2, supports conversion of unit specifications between formatted and binary forms, arithmetic manipulation of unit specifications, and conversion of values between compatible scales of measurement. A unit is the amount by which a physical quantity is measured. For example: Physical Quantity Possible Unit _________________ _____________ time weeks distance centimeters power watts This utility works interactively and has two modes. In one mode, both an input and output unit specification are given, causing the utility to print the conversion between them. In the other mode, only an input unit specification is given. This causes the utility to print the definition -- in standard units -- of the input unit. -------------------------------------------------------------------------------- ================================================================================ varnish-2.0.6-2.el5 (FEDORA-EPEL-2010-0032) High-performance HTTP accelerator -------------------------------------------------------------------------------- ChangeLog: * Wed Dec 23 2009 Ingvar Hagelund - 2.0.6-2 - Added a test that enables jemalloc on ppc if the kernel is not a rhel5 kernel (as on redhat builders) - Removed tests c00031.vtc and r00387on rhel4/ppc as they fail on the Red Hat ppc builders (but works on my rhel4 ppc instance) - Added a patch that fixes broken changes-2.0.6.html in doc * Mon Dec 14 2009 Ingvar Hagelund - 2.0.6-1 - New upstream release - Removed patches for libjemalloc, as they are added upstream -------------------------------------------------------------------------------- From updates at fedoraproject.org Thu Jan 7 21:44:10 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Thu, 07 Jan 2010 21:44:10 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100107214434.44A3310F8F1@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing varnish-2.0.6-2.el4 Details about builds: ================================================================================ varnish-2.0.6-2.el4 (FEDORA-EPEL-2010-0038) High-performance HTTP accelerator -------------------------------------------------------------------------------- Update Information: New upstream release -------------------------------------------------------------------------------- ChangeLog: * Wed Dec 23 2009 Ingvar Hagelund - 2.0.6-2 - Added a test that enables jemalloc on ppc if the kernel is not a rhel5 kernel (as on redhat builders) - Removed tests c00031.vtc and r00387on rhel4/ppc as they fail on the Red Hat ppc builders (but works on my rhel4 ppc instance) - Added a patch that fixes broken changes-2.0.6.html in doc * Mon Dec 14 2009 Ingvar Hagelund - 2.0.6-1 - New upstream release - Removed patches for libjemalloc, as they are added upstream -------------------------------------------------------------------------------- From kevin at scrye.com Fri Jan 8 16:29:43 2010 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 8 Jan 2010 09:29:43 -0700 Subject: Moin orphaned in EL-4 and EL-5 In-Reply-To: <1262899045.1753.13.camel@lightweight> References: <1262899045.1753.13.camel@lightweight> Message-ID: <20100108092943.17154aea@ohm.scrye.com> On Thu, 07 Jan 2010 23:17:25 +0200 Ville-Pekka Vainio wrote: ...snip... > I hope someone who cares about having moin in EPEL would take over the > package and figure out how the data upgrade process would be best > described to the users of the package or how to backport security > patches from the maintained releases. If not, I think we could also > retire moin from EPEL completely. Yeah. Lets give it a week or two and see if anyone shows interest. Thanks for letting us know! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at tummy.com Fri Jan 8 16:30:50 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 8 Jan 2010 09:30:50 -0700 Subject: Plan for today's EPEL meeting - 2010-01-08 Message-ID: <20100108093050.1cc61e90@ohm.scrye.com> Here's the topic list for todays EPEL meeting, which will take place at 21:00 UTC in #fedora-meeting on irc.freenode.net. - Status update on action items - smooge: Blocking packages already in RHEL - Fuse for 5.4 status - Moin - Any takers? - Plans for upcoming meetings - Open Floor If there is something else that folks would like to discuss, please followup to this email or mention it in the Open Floor section of the meeting at the end. Hope to see everyone there! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at scrye.com Fri Jan 8 21:30:22 2010 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 8 Jan 2010 14:30:22 -0700 Subject: Meeting summary/notes from today's EPEL meeting - 2010-01-08 In-Reply-To: <20100108093050.1cc61e90@ohm.scrye.com> References: <20100108093050.1cc61e90@ohm.scrye.com> Message-ID: <20100108143022.4c38dc55@ohm.scrye.com> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/epel.2010-01-08-20.59.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/epel.2010-01-08-20.59.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/epel.2010-01-08-20.59.log.html Meeting started by nirik at 20:59:47 UTC (full logs). Meeting summary Init Process (nirik, 20:59:58) Moin (nirik, 21:09:20) https://fedoraproject.org/wikiold (nirik, 21:14:42) Plans for upcoming meetings (nirik, 21:17:14) Open Floor (nirik, 21:19:54) Meeting ended at 21:27:55 UTC (full logs). I think we need to look at one or more of the following: 1. Change meeting time so more people can attend. 2. Meet every other week, or once a month or something. 3. Use our meeting times to work on bugs or other ongoing tasks. We just don't have enough going on for full one hour meetings every week. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From smooge at gmail.com Fri Jan 8 21:37:44 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 8 Jan 2010 14:37:44 -0700 Subject: Meeting summary/notes from today's EPEL meeting - 2010-01-08 In-Reply-To: <20100108143022.4c38dc55@ohm.scrye.com> References: <20100108093050.1cc61e90@ohm.scrye.com> <20100108143022.4c38dc55@ohm.scrye.com> Message-ID: <80d7e4091001081337p617b15fch96dcd4d8fe85870d@mail.gmail.com> And I still havent gotten used to DST ending here. I thought it was at 1500 and missed this. The moving of the meeting to some other time would be nice. On Fri, Jan 8, 2010 at 2:30 PM, Kevin Fenzi wrote: > Minutes: ? ? ? ?http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/epel.2010-01-08-20.59.html > Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/epel.2010-01-08-20.59.txt > Log: ? ? ? ? ? ?http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/epel.2010-01-08-20.59.log.html > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From maxamillion at fedoraproject.org Mon Jan 11 19:35:39 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Mon, 11 Jan 2010 13:35:39 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel Message-ID: As the subject notes, nagios is in fact shipped by RedHat. Details Description: Nagios is a program that will monitor hosts and services on your network. It has the ability to send email or page alerts when a problem arises and when a problem is resolved. Nagios is written in C and is designed to run under Linux (and some other *NIX variants) as a background process, intermittently running checks on various services that you specify. The actual service checks are performed by separate "plugin" programs which return the status of the checks to Nagios. The plugins are available at http://sourceforge.net/projects/nagiosplug. This package provides the core program, web interface, and documentation files for Nagios. Development files are built as a separate package. Arch: AMD64 Available Archs: AMD64 Available From: Red Hat HPC Solution (v. 5 for 64-bit x86_64) Vendor: Red Hat, Inc. Source RPM: nagios-2.12-6.1.el5.src.rpm MD5 Sum: 993fd4eb767f0981c662637a7f53a009 Package Size: 2,302,710 bytes Payload Size: 5,328,032 bytes Build Host: hs20-bc2-5.build.redhat.com Build Date: 10/12/09 7:39:15 AM PDT License: GPLv2 Group: Applications/System RPM Version: 4.4.2.3 The reason I wanted to bring this up is that we say in our policy that we do not ship packages that are shipped by RedHat in RHEL. But this being a subscription channel that is not extremely popular, do we want to revise that policy to say that we don't ship packages that are not in the base channel of desktop/workstation/server/ap as those are the most common or do we want to stick to the current policy quite strictly? Just food for thought, it was a topic of conversation in #rhel today. -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From smooge at gmail.com Mon Jan 11 21:27:47 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 11 Jan 2010 14:27:47 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: Message-ID: <80d7e4091001111327t3b8949c9gd094b784e4794b08@mail.gmail.com> On Mon, Jan 11, 2010 at 12:35 PM, Adam Miller wrote: > As the subject notes, nagios is in fact shipped by RedHat. > ..... > The reason I wanted to bring this up is that we say in our policy that > we do not ship packages that are shipped by RedHat in RHEL. But this > being a subscription channel that is not extremely popular, do we want > to revise that policy to say that we don't ship packages that are not > in the base channel of desktop/workstation/server/ap as those are the > most common or do we want to stick to the current policy quite > strictly? As I understood it.. it was only for the base RHEL channels. Channels which are not available from a base subscription were not considered covered by our policy. > Just food for thought, it was a topic of conversation in #rhel today. > > -AdamM > > -- > http://maxamillion.googlepages.com > --------------------------------------------------------- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From jonstanley at gmail.com Mon Jan 11 21:28:14 2010 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 11 Jan 2010 16:28:14 -0500 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: Message-ID: On Mon, Jan 11, 2010 at 2:35 PM, Adam Miller wrote: > The reason I wanted to bring this up is that we say in our policy that > we do not ship packages that are shipped by RedHat in RHEL. But this > being a subscription channel that is not extremely popular, do we want > to revise that policy to say that we don't ship packages that are not > in the base channel of desktop/workstation/server/ap as those are the > most common or do we want to stick to the current policy quite > strictly? In what context was it brought up? I'm inclined to think that we just go with Base/Virt/Clustering/ClusterStorage (the things you get with AP). We already ship 389 in EPEL, which is the upstream for RHDS. I don't really see nagios as being any different. On another note, Nagios for monitoring HPC deployments? Seriously? :) From maxamillion at fedoraproject.org Mon Jan 11 21:40:20 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Mon, 11 Jan 2010 15:40:20 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001111327t3b8949c9gd094b784e4794b08@mail.gmail.com> References: <80d7e4091001111327t3b8949c9gd094b784e4794b08@mail.gmail.com> Message-ID: On Mon, Jan 11, 2010 at 3:27 PM, Stephen John Smoogen wrote: > On Mon, Jan 11, 2010 at 12:35 PM, Adam Miller > wrote: >> As the subject notes, nagios is in fact shipped by RedHat. >> > ..... >> The reason I wanted to bring this up is that we say in our policy that >> we do not ship packages that are shipped by RedHat in RHEL. But this >> being a subscription channel that is not extremely popular, do we want >> to revise that policy to say that we don't ship packages that are not >> in the base channel of desktop/workstation/server/ap as those are the >> most common or do we want to stick to the current policy quite >> strictly? > > As I understood it.. it was only for the base RHEL channels. Channels > which are not available from a base subscription were not considered > covered by our policy. https://fedoraproject.org/wiki/EPEL/FAQ#How_is_EPEL_different_from_other_third_party_repositories_for_RHEL_and_derivatives.3F Third bullet point down. > >> Just food for thought, it was a topic of conversation in #rhel today. >> >> -AdamM >> >> -- >> http://maxamillion.googlepages.com >> --------------------------------------------------------- >> () ?ascii ribbon campaign - against html e-mail >> /\ ?www.asciiribbon.org ? - against proprietary attachments >> >> _______________________________________________ >> epel-devel-list mailing list >> epel-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/epel-devel-list >> > > > > -- > Stephen J Smoogen. > > Ah, but a man's reach should exceed his grasp. Or what's a heaven for? > -- Robert Browning > > _______________________________________________ > 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 maxamillion at fedoraproject.org Mon Jan 11 21:41:22 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Mon, 11 Jan 2010 15:41:22 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: Message-ID: On Mon, Jan 11, 2010 at 3:28 PM, Jon Stanley wrote: > On Mon, Jan 11, 2010 at 2:35 PM, Adam Miller > wrote: >> The reason I wanted to bring this up is that we say in our policy that >> we do not ship packages that are shipped by RedHat in RHEL. But this >> being a subscription channel that is not extremely popular, do we want >> to revise that policy to say that we don't ship packages that are not >> in the base channel of desktop/workstation/server/ap as those are the >> most common or do we want to stick to the current policy quite >> strictly? > > In what context was it brought up? I'm inclined to think that we just > go with Base/Virt/Clustering/ClusterStorage (the things you get with > AP). ?We already ship 389 in EPEL, which is the upstream for RHDS. I > don't really see nagios as being any different. > Honestly not sure, I came in half way through the conversation trying to defend EPEL for not shipping (or should not be shipping) something that RedHat does already. > On another note, Nagios for monitoring HPC deployments? Seriously? :) Agreed, I'd go ganglia. > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From mastahnke at gmail.com Mon Jan 11 23:03:20 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 11 Jan 2010 17:03:20 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: Message-ID: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> What channel is nagios shipped in? If it's part of RHX (or whatever that's been renamed to recently) it was desired to be out of scope originally. At the one of the last RH Summits (I am thinking Boston 2 years ago) we discussed RHX and working with ISVs on getting software into EPEL rather than a separate shipping channel. We never really decided on anything though. I guess we need more discussion on the specifics of nagios, but I do wonder if we could revise the policy to be things covered in an AP subscription. Otherwise, it's makes the desirability of EPEL rather low. If I am running Enterprise Linux but don't have a good method to get systems management tools, programming libraries and authentication services, I probably wouldn't use EPEL for very long. I'd switch to something else. EPEL was designed to pair with RHEL. EPEL + RHEL should roughly match the Fedora package collection. If it's RHEL + EPEL + Extra Channel1 + Extra Channel2, ..... that's a difficult sell. Some people see value in support/subscription on layered products, and some do not. stahnma From maxamillion at gmail.com Tue Jan 12 01:20:52 2010 From: maxamillion at gmail.com (Adam Miller) Date: Mon, 11 Jan 2010 19:20:52 -0600 Subject: Fwd: Iotop with Python2.4 RHEL5 In-Reply-To: <3d8471ca1001111456i7593e4dyb5539d1f2c833748@mail.gmail.com> References: <3d8471ca1001111456i7593e4dyb5539d1f2c833748@mail.gmail.com> Message-ID: Thought I'd throw this to the list so that there can be celebration! -AdamM ---------- Forwarded message ---------- From: Guillaume Chazarain Date: Mon, Jan 11, 2010 at 4:56 PM Subject: Iotop with Python2.4 RHEL5 To: Guillaume Chazarain Hello, You are receiving this email because you expressed interest at some point in running iotop on an unsupported configuration at the time: RHEL5 with python2.4. Thanks to the work of Jiri Olsa , iotop is now compatible with python2.4 so I just released iotop-0.4 which supports python2.4. In addition, the necessary kernel support has been backported in RHEL5. Thanks. -- Guillaume -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From djuran at redhat.com Tue Jan 12 07:41:41 2010 From: djuran at redhat.com (David Juran) Date: Tue, 12 Jan 2010 09:41:41 +0200 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> Message-ID: <1263282101.3724.3.camel@localhost.localdomain> On Mon, 2010-01-11 at 17:03 -0600, Michael Stahnke wrote: > EPEL was designed to pair with RHEL. EPEL + RHEL should roughly match > the Fedora package collection. If it's RHEL + EPEL + Extra Channel1 + > Extra Channel2, ..... that's a difficult sell. Some people see value > in support/subscription on layered products, and some do not. So how about a policy where EPEL keeps the version the same as the one in ExtraChannel but with a lower release number? This way people not subscribing to ExtraChannel will get the software and people who do subscribe to the channel will get the version from Red Hat. -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- 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 trevor.hemsley at codefarm.com Tue Jan 12 10:31:55 2010 From: trevor.hemsley at codefarm.com (Trevor Hemsley) Date: Tue, 12 Jan 2010 10:31:55 +0000 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <1263282101.3724.3.camel@localhost.localdomain> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> Message-ID: <4B4C4F9B.102@codefarm.com> On 12/01/2010 07:41, David Juran wrote: > On Mon, 2010-01-11 at 17:03 -0600, Michael Stahnke wrote: > > >> EPEL was designed to pair with RHEL. EPEL + RHEL should roughly match >> the Fedora package collection. If it's RHEL + EPEL + Extra Channel1 + >> Extra Channel2, ..... that's a difficult sell. Some people see value >> in support/subscription on layered products, and some do not. >> > So how about a policy where EPEL keeps the version the same as the one > in ExtraChannel but with a lower release number? This way people not > subscribing to ExtraChannel will get the software and people who do > subscribe to the channel will get the version from Red Hat. > In this case, the version of Nagios in the RHEL repo is a version 2 release and that's almost prehistoric and uses a different syntax for its config files than the far more widely used V3. In EPEL I think we have V3.0.6 and even that's getting pretty old as v3.2.0 is in rpmforge and on the Nagios web site. Be much easier if RH orphaned the V2 release in that repo. -- Trevor Hemsley Infrastructure Engineer ................................................. * C A L Y P S O * Brighton, UK OFFICE +44 (0) 1273 666 350 FAX +44 (0) 1273 666 351 ................................................. www.calypso.com This electronic-mail might contain confidential information intended only for the use by the entity named. If the reader of this message is not the intended recipient, the reader is hereby notified that any dissemination, distribution or copying is strictly prohibited. * P * /*/ Please consider the environment before printing this e-mail /*/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmadams at hiwaay.net Tue Jan 12 14:01:34 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 12 Jan 2010 08:01:34 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <4B4C4F9B.102@codefarm.com> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> Message-ID: <20100112140134.GC1497270@hiwaay.net> Once upon a time, Trevor Hemsley said: > In this case, the version of Nagios in the RHEL repo is a version 2 > release and that's almost prehistoric and uses a different syntax for > its config files than the far more widely used V3. In EPEL I think we > have V3.0.6 and even that's getting pretty old as v3.2.0 is in rpmforge > and on the Nagios web site. No, the EPEL-5 version of Nagios is also the really old 2.12. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From maxamillion at fedoraproject.org Tue Jan 12 15:25:51 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Tue, 12 Jan 2010 09:25:51 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <20100112140134.GC1497270@hiwaay.net> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> Message-ID: All this discussion is great and I think everyone has had solid concerns and good points but it still leaves the original question unanswered. Do we stick to our policy as is or do we want to make a revision? -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From inode0 at gmail.com Tue Jan 12 15:34:04 2010 From: inode0 at gmail.com (inode0) Date: Tue, 12 Jan 2010 09:34:04 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> Message-ID: On Tue, Jan 12, 2010 at 9:25 AM, Adam Miller wrote: > All this discussion is great and I think everyone has had solid > concerns and good points but it still leaves the original question > unanswered. > > Do we stick to our policy as is or do we want to make a revision? It seems to me looking in from the outside that you have already made a revision to the policy by including 389, nagios, and possibly other things. Might as well move on the figuring out what the real policy is going to be and correctly documenting it. John From maxamillion at fedoraproject.org Tue Jan 12 15:36:47 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Tue, 12 Jan 2010 09:36:47 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> Message-ID: On Tue, Jan 12, 2010 at 9:34 AM, inode0 wrote: > On Tue, Jan 12, 2010 at 9:25 AM, Adam Miller > wrote: >> All this discussion is great and I think everyone has had solid >> concerns and good points but it still leaves the original question >> unanswered. >> >> Do we stick to our policy as is or do we want to make a revision? > > It seems to me looking in from the outside that you have already made > a revision to the policy by including 389, nagios, and possibly other > things. Might as well move on the figuring out what the real policy is > going to be and correctly documenting it. > Well that's kind of my point, if we stick to the policy as it stands then we need to pull the violating packages. -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From mastahnke at gmail.com Tue Jan 12 15:48:47 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 12 Jan 2010 09:48:47 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> Message-ID: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> >>> Do we stick to our policy as is or do we want to make a revision? I propose a revision. I propose we don't step on anything in the AP channels. Also, if we are having a collision problem with other Red Hat provided layered channels, a bug could be filed and we could attempt to resolve it by a lower package number or something. It's not that I blatantly want to ignore other channels, it's that if we exclude all of those products in EPEL, EPEL becomes less useful to the enterprise customers it was aimed at. >> >> It seems to me looking in from the outside that you have already made >> a revision to the policy by including 389, nagios, and possibly other >> things. Might as well move on the figuring out what the real policy is >> going to be and correctly documenting it. 389 isn't a policy violation, Red Hat does not ship it. They ship Red Hat DS, which is based from 389 but not the same thing. I would assume we could ship spacewalk, freeipa and others in a similar fashion. stahnma From inode0 at gmail.com Tue Jan 12 16:09:09 2010 From: inode0 at gmail.com (inode0) Date: Tue, 12 Jan 2010 10:09:09 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> Message-ID: On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke wrote: >>>> Do we stick to our policy as is or do we want to make a revision? > I propose a revision. ?I propose we don't step on anything in the AP > channels. ?Also, if we are having a collision problem with other Red > Hat provided layered channels, a bug could be filed and we could > attempt to resolve it by a lower package number or something. ?It's > not that I blatantly want to ignore other channels, it's that if we > exclude all of those products in EPEL, EPEL becomes less useful to the > enterprise customers it was aimed at. > >>> It seems to me looking in from the outside that you have already made >>> a revision to the policy by including 389, nagios, and possibly other >>> things. Might as well move on the figuring out what the real policy is >>> going to be and correctly documenting it. > > 389 isn't a policy violation, Red Hat does not ship it. ?They ship Red > Hat DS, which is based from 389 but not the same thing. ?I would > assume we could ship spacewalk, freeipa and others in a similar > fashion. If it doesn't conflict with an installed RHDS it isn't a problem. I see it as something of a problem if it does regardless of the policy. I assume that all the 389 packages probably have different names so it is likely safe but I don't know what else it might pull into the repo if anything. And given the fact that Red Hat is now naming packages delivered with Satellite as spacewalk-* I'm not very confident that the wall between what is upstream and what Red Hat provides is secure enough to avoid conflicts in any of these products. My understanding of EPEL's mission was that it would allow me to begin with a RHEL + layered product box, configure EPEL, get additional stuff without creating new problems. I think that is a wonderful mission. If this becomes I can begin with a box with anything I can get from AP, configure EPEL, get additional stuff without creating new problems I think we have a slightly less wonderful mission abstractly but perhaps a more effective mission in the real world. John From smooge at gmail.com Tue Jan 12 17:00:50 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 10:00:50 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> Message-ID: <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> On Tue, Jan 12, 2010 at 9:09 AM, inode0 wrote: > On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke wrote: >>>>> Do we stick to our policy as is or do we want to make a revision? >> I propose a revision. ?I propose we don't step on anything in the AP >> channels. ?Also, if we are having a collision problem with other Red >> Hat provided layered channels, a bug could be filed and we could >> attempt to resolve it by a lower package number or something. ?It's >> not that I blatantly want to ignore other channels, it's that if we >> exclude all of those products in EPEL, EPEL becomes less useful to the >> enterprise customers it was aimed at. >> >>>> It seems to me looking in from the outside that you have already made >>>> a revision to the policy by including 389, nagios, and possibly other >>>> things. Might as well move on the figuring out what the real policy is >>>> going to be and correctly documenting it. >> >> 389 isn't a policy violation, Red Hat does not ship it. ?They ship Red >> Hat DS, which is based from 389 but not the same thing. ?I would >> assume we could ship spacewalk, freeipa and others in a similar >> fashion. > > If it doesn't conflict with an installed RHDS it isn't a problem. I > see it as something of a problem if it does regardless of the policy. > I assume that all the 389 packages probably have different names so it > is likely safe but I don't know what else it might pull into the repo > if anything. > > And given the fact that Red Hat is now naming packages delivered with > Satellite as spacewalk-* I'm not very confident that the wall between > what is upstream and what Red Hat provides is secure enough to avoid > conflicts in any of these products. > > My understanding of EPEL's mission was that it would allow me to begin > with a RHEL + layered product box, configure EPEL, get additional > stuff without creating new problems. I think that is a wonderful > mission. > > If this becomes I can begin with a box with anything I can get from > AP, configure EPEL, get additional stuff without creating new problems > I think we have a slightly less wonderful mission abstractly but > perhaps a more effective mission in the real world. Ok this is the problem with strict policies versus writing to intention: If Red Hat were to mirror everything in EPEL as a channel called "Unsupported Community Packages from EPEL" our logical conclusion would be to remove all those packages from EPEL... which would remove them from that channel, which means we could add packages back to EPEL which would... So what is the intention that we are wanting? And can we write to that. Here is a list of things that come to mind in no meant order. 1) We do not wish to replace or conflict with the channels from a Base install. [EG if its on the DVD RHEL provides we don't replace or conflict.] 2) We do not know what is in all the other RHN channels. We do not know what will be in an update either. 3) Red Hat people would like that their 'free' versions of packages were in EPEL (the spacewalk people would like spacewalk, the 389 people would like 389, etc) as it allows them to push newer packages to people who are testing them in real environments. 4) However inclusion of this will cause problems with other RH products. So how should we word it to best work out intention, should we look at our own layering of stuff, or something else... and whatever we decide lets do it.. this seems like the 8th time this discussion has come up. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From chrismcc at pricegrabber.com Tue Jan 12 17:41:00 2010 From: chrismcc at pricegrabber.com (Christopher) Date: Tue, 12 Jan 2010 09:41:00 -0800 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> Message-ID: <1263318060.2474.1.camel@localhost> On Tue, 2010-01-12 at 10:00 -0700, Stephen John Smoogen wrote: > Ok this is the problem with strict policies versus writing to intention: > > If Red Hat were to mirror everything in EPEL as a channel called > "Unsupported Community Packages from EPEL" our logical conclusion > would be to remove all those packages from EPEL... which would remove > them from that channel, which means we could add packages back to EPEL > which would... > > So what is the intention that we are wanting? And can we write to > that. Here is a list of things that come to mind in no meant order. > > 1) We do not wish to replace or conflict with the channels from a Base > install. [EG if its on the DVD RHEL provides we don't replace or > conflict.] > 2) We do not know what is in all the other RHN channels. We do not > know what will be in an update either. > 3) Red Hat people would like that their 'free' versions of packages > were in EPEL (the spacewalk people would like spacewalk, the 389 > people would like 389, etc) as it allows them to push newer packages > to people who are testing them in real environments. Possibly RH could use a one-higher Epoch in their channels. Everybody wins. > 4) However inclusion of this will cause problems with other RH products. > > So how should we word it to best work out intention, should we look at > our own layering of stuff, or something else... and whatever we decide > lets do it.. this seems like the 8th time this discussion has come up. > > -- Christopher McCrory "The guy that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works. From steve.traylen at cern.ch Tue Jan 12 18:17:16 2010 From: steve.traylen at cern.ch (Steve Traylen) Date: Tue, 12 Jan 2010 19:17:16 +0100 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> Message-ID: On Tue, Jan 12, 2010 at 4:48 PM, Michael Stahnke wrote: >>>> Do we stick to our policy as is or do we want to make a revision? Just to check these extra channels with nagios in for instance are not available from CentOS or similar are they? Moving to an expected base below EPEL that is bigger than CentOS will surly create a problem for many people. > I propose a revision. ?I propose we don't step on anything in the AP > channels. ?Also, if we are having a collision problem with other Red > Hat provided layered channels, a bug could be filed and we could > attempt to resolve it by a lower package number or something. ?It's > not that I blatantly want to ignore other channels, it's that if we > exclude all of those products in EPEL, EPEL becomes less useful to the > enterprise customers it was aimed at. > > >>> >>> It seems to me looking in from the outside that you have already made >>> a revision to the policy by including 389, nagios, and possibly other >>> things. Might as well move on the figuring out what the real policy is >>> going to be and correctly documenting it. > > 389 isn't a policy violation, Red Hat does not ship it. ?They ship Red > Hat DS, which is based from 389 but not the same thing. ?I would > assume we could ship spacewalk, freeipa and others in a similar > fashion. > > > stahnma > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Steve Traylen From smooge at gmail.com Tue Jan 12 19:49:46 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 12:49:46 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> Message-ID: <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> On Tue, Jan 12, 2010 at 11:17 AM, Steve Traylen wrote: > On Tue, Jan 12, 2010 at 4:48 PM, Michael Stahnke wrote: >>>>> Do we stick to our policy as is or do we want to make a revision? > > Just to check these extra channels with nagios in for instance are not available > from CentOS or similar are they? Moving to an expected base below EPEL that > is bigger than CentOS will surly create a problem for many people. > No they are not available in the base channels of CentOS. To be honest, I think those are the 'channels' we should stick to for checking what is in or not in EPEL. It leads to other logic loops but for the most part we can agree that is a good base to look at. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From updates at fedoraproject.org Tue Jan 12 20:08:52 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 12 Jan 2010 20:08:52 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100112200926.5C55110FA51@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing R-car-1.2-16.1.el4 dsniff-2.4-0.8.b1.el4 fftw-3.2.2-3.el4 puppet-0.25.3-1.el4 python-kid-0.9.6-6.el4 voms-1.9.14.3-1.el4 Details about builds: ================================================================================ R-car-1.2-16.1.el4 (FEDORA-EPEL-2010-0055) Companion to Applied Regression package for R -------------------------------------------------------------------------------- Update Information: * Update to 1.2-16. * Rebuild for R 2.10 -------------------------------------------------------------------------------- ChangeLog: * Fri Nov 13 2009 Orion Poplawski 1.2-16.1 - Rebuild for R 2.10.0 * Wed Nov 4 2009 Orion Poplawski 1.2-16 - Update to 1.2-16 * Fri Oct 2 2009 Orion Poplawski 1.2-15 - Update to 1.2-15 * Mon Aug 10 2009 Orion Poplawski 1.2-8 - Update to 1.2-14 * Fri Jul 24 2009 Fedora Release Engineering - 1.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Tue Mar 10 2009 Orion Poplawski 1.2-6 - Update to 1.2-12 * Mon Feb 23 2009 Fedora Release Engineering - 1.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Wed Jan 14 2009 Orion Poplawski 1.2-5 - Update to 1.2-11 * Thu Oct 23 2008 Orion Poplawski 1.2-4 - Update to 1.2-9 * Wed May 7 2008 Orion Poplawski 1.2-3 - Update to 1.2-8 - Fix URLs -------------------------------------------------------------------------------- ================================================================================ dsniff-2.4-0.8.b1.el4 (FEDORA-EPEL-2010-0060) Tools for network auditing and penetration testing -------------------------------------------------------------------------------- Update Information: Added build requirement to libXmu-devel for webspy (#553230) -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 8 2010 Robert Scheck 2.4-0.8.b1 - Added build requirement to libXmu-devel for webspy (#553230) * Fri Aug 21 2009 Tomas Mraz - 2.4-0.7.b1 - rebuilt with new openssl * Fri Jul 24 2009 Fedora Release Engineering - 2.4-0.6.b1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Mon Feb 23 2009 Robert Scheck 2.4-0.5.b1 - Rebuild against gcc 4.4 and rpm 4.6 * Sat Aug 30 2008 Robert Scheck 2.4-0.4.b1 - Re-diffed dsniff url log escaping patch for no fuzz -------------------------------------------------------------------------------- References: [ 1 ] Bug #553230 - The webspy binary is missing https://bugzilla.redhat.com/show_bug.cgi?id=553230 -------------------------------------------------------------------------------- ================================================================================ fftw-3.2.2-3.el4 (FEDORA-EPEL-2010-0043) Fast Fourier Transform library -------------------------------------------------------------------------------- Update Information: Update to 3.2 series, bringing notable performance boosts. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 8 2010 Jussi Lehtola 3.2.2-3 - Same thing, but without changing Name tag to fftw3. * Fri Jan 8 2010 Jussi Lehtola 3.2.2-2 - Revert package name change due to RPMForge compatibility (fftw is version 2 series in RPMForge). * Fri Jan 1 2010 Jussi Lehtola 3.2.2-1 - Update to 3.2.2 from rawhide tree. - Change name of package to fftw(-devel) to conform with Package Naming Guidelines. -------------------------------------------------------------------------------- ================================================================================ puppet-0.25.3-1.el4 (FEDORA-EPEL-2010-0046) A network tool for managing many disparate systems -------------------------------------------------------------------------------- Update Information: The update from 0.24.x to 0.25.x brings many, many changes and improvements to puppet. The upstream release notes cover them in detail: http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes Of note is that 0.25.x clients do not work with 0.24.x masters, so it is important to update the master before or at the same time as clients. -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 11 2010 Todd Zullinger - 0.25.3-1 - Update to 0.25.3 * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1.1 - Replace %define with %global for macros * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1 - Update to 0.25.2 - Fixes CVE-2010-0156, tmpfile security issue (#502881) - Install auth.conf, puppetqd manpage, and queuing examples/docs * Wed Nov 25 2009 Jeroen van Meeuwen - 0.25.1-1 - New upstream version * Tue Oct 27 2009 Todd Zullinger - 0.25.1-0.3 - Update to 0.25.1 - Include the pi program and man page (R.I.Pienaar) * Sat Oct 17 2009 Todd Zullinger - 0.25.1-0.2.rc2 - Update to 0.25.1rc2 * Tue Sep 22 2009 Todd Zullinger - 0.25.1-0.1.rc1 - Update to 0.25.1rc1 - Move puppetca to puppet package, it has uses on client systems - Drop redundant %doc from manpage %file listings * Fri Sep 4 2009 Todd Zullinger - 0.25.0-1 - Update to 0.25.0 - Fix permissions on /var/log/puppet (#495096) - Install emacs mode and vim syntax files (#491437) - Install ext/ directory in %{_datadir}/puppet (/usr/share/puppet) -------------------------------------------------------------------------------- References: [ 1 ] Bug #502881 - CVE-2010-0156 puppet: several insecure tempfile creation issues https://bugzilla.redhat.com/show_bug.cgi?id=502881 -------------------------------------------------------------------------------- ================================================================================ python-kid-0.9.6-6.el4 (FEDORA-EPEL-2010-0044) Kid - A simple and pythonic XML template language -------------------------------------------------------------------------------- Update Information: This update contains a patch to escape ]]> to ]]> in serialization.py as it is required by the XML standard. -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 10 2010 Till Maas - 0.9.6-6 - Escape ]]> as ]]> in serialization.py to create valid XML - https://bugzilla.redhat.com/show_bug.cgi?id=528729 - Adjust BR for EPEL * Sun Jul 26 2009 Fedora Release Engineering - 0.9.6-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Thu Feb 26 2009 Fedora Release Engineering - 0.9.6-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 0.9.6-3 - Rebuild for Python 2.6 * Tue Aug 28 2007 Konstantin Ryabitsev - 0.9.6-2 - BR: python-setuptools-devel - Drop explicit BR: python-devel -------------------------------------------------------------------------------- References: [ 1 ] Bug #528729 - python-kid: serialization.py does not escape > to > https://bugzilla.redhat.com/show_bug.cgi?id=528729 -------------------------------------------------------------------------------- ================================================================================ voms-1.9.14.3-1.el4 (FEDORA-EPEL-2010-0058) Virtual Organization Membership Service -------------------------------------------------------------------------------- Update Information: New upstream release -------------------------------------------------------------------------------- ChangeLog: * Mon Dec 28 2009 Mattias Ellert - 1.9.14.3-1 - Upstream 1.9.14.3 (CVS tag glite-security-voms_R_1_9_14_3) -------------------------------------------------------------------------------- From updates at fedoraproject.org Tue Jan 12 20:08:53 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 12 Jan 2010 20:08:53 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100112200926.742E410FA74@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing R-car-1.2-16.1.el5 bip-0.8.4-1.el5 dsniff-2.4-0.8.b1.el5 fftw-3.2.2-3.el5 glpi-data-injection-1.7.2-1.el5 glusterfs-2.0.9-1.el5 hspell-1.1-3.1.el5 orbited-0.7.10-3.el5 perl-OpenGL-0.62-2.el5 puppet-0.25.3-1.el5 python-daemon-1.5.2-3.el5 python-kid-0.9.6-6.el5 qrupdate-1.1.0-2.el5 tomcatjss-1.2.0-2.el5 viewvc-1.1.3-2.el5 voms-1.9.14.3-1.el5 Details about builds: ================================================================================ R-car-1.2-16.1.el5 (FEDORA-EPEL-2010-0056) Companion to Applied Regression package for R -------------------------------------------------------------------------------- Update Information: * Update to 1.2-16. * Rebuild for R 2.10 -------------------------------------------------------------------------------- ChangeLog: * Fri Nov 13 2009 Orion Poplawski 1.2-16.1 - Rebuild for R 2.10.0 * Wed Nov 4 2009 Orion Poplawski 1.2-16 - Update to 1.2-16 * Fri Oct 2 2009 Orion Poplawski 1.2-15 - Update to 1.2-15 * Mon Aug 10 2009 Orion Poplawski 1.2-8 - Update to 1.2-14 * Fri Jul 24 2009 Fedora Release Engineering - 1.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Tue Mar 10 2009 Orion Poplawski 1.2-6 - Update to 1.2-12 * Mon Feb 23 2009 Fedora Release Engineering - 1.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Wed Jan 14 2009 Orion Poplawski 1.2-5 - Update to 1.2-11 * Thu Oct 23 2008 Orion Poplawski 1.2-4 - Update to 1.2-9 * Wed May 7 2008 Orion Poplawski 1.2-3 - Update to 1.2-8 - Fix URLs -------------------------------------------------------------------------------- ================================================================================ bip-0.8.4-1.el5 (FEDORA-EPEL-2010-0052) IRC Bouncer -------------------------------------------------------------------------------- Update Information: - Fixes a fatal() on gamesurge networks. - Fix build OpenSSL detection issue. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 8 2010 Lorenzo Villani - 0.8.4-1 - 0.8.4 -------------------------------------------------------------------------------- ================================================================================ dsniff-2.4-0.8.b1.el5 (FEDORA-EPEL-2010-0041) Tools for network auditing and penetration testing -------------------------------------------------------------------------------- Update Information: Added build requirement to libXmu-devel for webspy (#553230) -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 8 2010 Robert Scheck 2.4-0.8.b1 - Added build requirement to libXmu-devel for webspy (#553230) * Fri Aug 21 2009 Tomas Mraz - 2.4-0.7.b1 - rebuilt with new openssl * Fri Jul 24 2009 Fedora Release Engineering - 2.4-0.6.b1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Mon Feb 23 2009 Robert Scheck 2.4-0.5.b1 - Rebuild against gcc 4.4 and rpm 4.6 * Sat Aug 30 2008 Robert Scheck 2.4-0.4.b1 - Re-diffed dsniff url log escaping patch for no fuzz -------------------------------------------------------------------------------- References: [ 1 ] Bug #553230 - The webspy binary is missing https://bugzilla.redhat.com/show_bug.cgi?id=553230 -------------------------------------------------------------------------------- ================================================================================ fftw-3.2.2-3.el5 (FEDORA-EPEL-2010-0042) Fast Fourier Transform library -------------------------------------------------------------------------------- Update Information: Update to 3.2 series, bringing notable performance boosts. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 8 2010 Jussi Lehtola 3.2.2-3 - Same thing, but without changing Name tag to fftw3. * Fri Jan 8 2010 Jussi Lehtola 3.2.2-2 - Revert package name change due to RPMForge compatibility (fftw is version 2 series in RPMForge). * Fri Jan 1 2010 Jussi Lehtola 3.2.2-1 - Update to 3.2.2 from rawhide tree. - Change name of package to fftw(-devel) to conform with Package Naming Guidelines. -------------------------------------------------------------------------------- ================================================================================ glpi-data-injection-1.7.2-1.el5 (FEDORA-EPEL-2010-0051) Plugin for importing data into GLPI -------------------------------------------------------------------------------- Update Information: Upstream Changelog; Version 1.7.2 #1772: Import new fields in entity Version 1.7.1 #1670: Integration with genericobject plugin #1765: When updating network port, the logical number is always set to 1 -------------------------------------------------------------------------------- ChangeLog: * Fri Dec 10 2010 Remi Collet - 1.7.2-1 - update to 1.7.2 - fix URL + Source (link to new forge) -------------------------------------------------------------------------------- ================================================================================ glusterfs-2.0.9-1.el5 (FEDORA-EPEL-2010-0016) Cluster File System -------------------------------------------------------------------------------- Update Information: Update to 2.0.9. -------------------------------------------------------------------------------- ChangeLog: * Sat Jan 2 2010 Jonathan Steffan - 2.0.9-1 - Update to 2.0.9 -------------------------------------------------------------------------------- ================================================================================ hspell-1.1-3.1.el5 (FEDORA-EPEL-2010-0040) A Hebrew spell checker -------------------------------------------------------------------------------- Update Information: drop hunspell reference from spec as hunspell in not in EPEL5. -------------------------------------------------------------------------------- ChangeLog: * Sat Jan 9 2010 Dan Kenigsberg - 1.1-3.1 - Rebuild without hunspell * Fri Jan 1 2010 Dan Kenigsberg - 1.1-2 - Rebase to upstream version 1.1 and fix spec typos. * Thu Dec 31 2009 Dan Kenigsberg - 1.1-1 - Rebase to upstream version 1.1 * Fri Jul 24 2009 Fedora Release Engineering - 1.0-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Tue Feb 24 2009 Fedora Release Engineering - 1.0-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sun Sep 21 2008 Ville Skytt? - 1.0-11 - Fix Patch0:/%patch mismatch. * Thu Jul 31 2008 Tom "spot" Callaway - 1.0-10 - fix license tag * Wed May 14 2008 Caolan McNamara - 1.0-9 - Resolves: rhbz#313231 build hspell.so instead of a .a -------------------------------------------------------------------------------- ================================================================================ orbited-0.7.10-3.el5 (FEDORA-EPEL-2010-0057) A browser(javascript)->tcp bridge -------------------------------------------------------------------------------- Update Information: Initial release of Orbited for EL-5 -------------------------------------------------------------------------------- ================================================================================ perl-OpenGL-0.62-2.el5 (FEDORA-EPEL-2010-0045) Perl OpenGL bindings -------------------------------------------------------------------------------- ================================================================================ puppet-0.25.3-1.el5 (FEDORA-EPEL-2010-0054) A network tool for managing many disparate systems -------------------------------------------------------------------------------- Update Information: The update from 0.24.x to 0.25.x brings many, many changes and improvements to puppet. The upstream release notes cover them in detail: http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes Of note is that 0.25.x clients do not work with 0.24.x masters, so it is important to update the master before or at the same time as clients. -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 11 2010 Todd Zullinger - 0.25.3-1 - Update to 0.25.3 * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1.1 - Replace %define with %global for macros * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1 - Update to 0.25.2 - Fixes CVE-2010-0156, tmpfile security issue (#502881) - Install auth.conf, puppetqd manpage, and queuing examples/docs * Wed Nov 25 2009 Jeroen van Meeuwen - 0.25.1-1 - New upstream version * Tue Oct 27 2009 Todd Zullinger - 0.25.1-0.3 - Update to 0.25.1 - Include the pi program and man page (R.I.Pienaar) * Sat Oct 17 2009 Todd Zullinger - 0.25.1-0.2.rc2 - Update to 0.25.1rc2 * Tue Sep 22 2009 Todd Zullinger - 0.25.1-0.1.rc1 - Update to 0.25.1rc1 - Move puppetca to puppet package, it has uses on client systems - Drop redundant %doc from manpage %file listings * Fri Sep 4 2009 Todd Zullinger - 0.25.0-1 - Update to 0.25.0 - Fix permissions on /var/log/puppet (#495096) - Install emacs mode and vim syntax files (#491437) - Install ext/ directory in %{_datadir}/puppet (/usr/share/puppet) -------------------------------------------------------------------------------- References: [ 1 ] Bug #502881 - CVE-2010-0156 puppet: several insecure tempfile creation issues https://bugzilla.redhat.com/show_bug.cgi?id=502881 -------------------------------------------------------------------------------- ================================================================================ python-daemon-1.5.2-3.el5 (FEDORA-EPEL-2010-0059) Library to implement a well-behaved Unix daemon process -------------------------------------------------------------------------------- Update Information: Initial release of python-daemon for EL-5 -------------------------------------------------------------------------------- ================================================================================ python-kid-0.9.6-6.el5 (FEDORA-EPEL-2010-0049) Kid - A simple and pythonic XML template language -------------------------------------------------------------------------------- Update Information: This update contains a patch to escape ]]> to ]]> in serialization.py as it is required by the XML standard. -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 10 2010 Till Maas - 0.9.6-6 - Escape ]]> as ]]> in serialization.py to create valid XML - https://bugzilla.redhat.com/show_bug.cgi?id=528729 - Adjust BR for EPEL * Sun Jul 26 2009 Fedora Release Engineering - 0.9.6-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Thu Feb 26 2009 Fedora Release Engineering - 0.9.6-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 0.9.6-3 - Rebuild for Python 2.6 * Tue Aug 28 2007 Konstantin Ryabitsev - 0.9.6-2 - BR: python-setuptools-devel - Drop explicit BR: python-devel -------------------------------------------------------------------------------- References: [ 1 ] Bug #528729 - python-kid: serialization.py does not escape > to > https://bugzilla.redhat.com/show_bug.cgi?id=528729 -------------------------------------------------------------------------------- ================================================================================ qrupdate-1.1.0-2.el5 (FEDORA-EPEL-2010-0048) A Fortran library for fast updates of QR and Cholesky decompositions -------------------------------------------------------------------------------- Update Information: Update to 1.1.0. -------------------------------------------------------------------------------- ChangeLog: -------------------------------------------------------------------------------- ================================================================================ tomcatjss-1.2.0-2.el5 (FEDORA-EPEL-2010-0050) JSSE implementation using JSS for Tomcat -------------------------------------------------------------------------------- Update Information: A Java Secure Socket Extension (JSSE) implementation using Java Security Services (JSS) for Tomcat 5.5. -------------------------------------------------------------------------------- References: [ 1 ] Bug #521979 - New Package for Dogtag PKI: tomcatjss https://bugzilla.redhat.com/show_bug.cgi?id=521979 -------------------------------------------------------------------------------- ================================================================================ viewvc-1.1.3-2.el5 (FEDORA-EPEL-2010-0047) Browser interface for CVS and SVN version control repositories -------------------------------------------------------------------------------- Update Information: Upstream issue #445: http://viewvc.tigris.org/issues/show_bug.cgi?id=445 -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 8 2010 Bojan Smojver - 1.1.3-2 - patch upstream issue #445 -------------------------------------------------------------------------------- ================================================================================ voms-1.9.14.3-1.el5 (FEDORA-EPEL-2010-0053) Virtual Organization Membership Service -------------------------------------------------------------------------------- Update Information: New upstream release -------------------------------------------------------------------------------- ChangeLog: * Mon Dec 28 2009 Mattias Ellert - 1.9.14.3-1 - Upstream 1.9.14.3 (CVS tag glite-security-voms_R_1_9_14_3) -------------------------------------------------------------------------------- From maxamillion at fedoraproject.org Tue Jan 12 20:20:35 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Tue, 12 Jan 2010 14:20:35 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> References: <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> Message-ID: Here's a proposal: Let's make an alteration to our current policy to something of the effect that "we do not ship any package that has an openly available RPM/SRPM located in any child directory of ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to verify that there will be no conflicts as not all channels are published." Beyond that I don't think there is any realistic expectation of us to know what we could potentially conflict with if the information is not publicly available. -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From smooge at gmail.com Tue Jan 12 20:27:35 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 13:27:35 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> Message-ID: <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller wrote: > Here's a proposal: > > Let's make an alteration to our current policy to something of the > effect that "we do not ship any package that has an openly available > RPM/SRPM located in any child directory of > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to > verify that there will be no conflicts as not all channels are > published." > > Beyond that I don't think there is any realistic expectation of us to > know what we could potentially conflict with if the information is not > publicly available. > > -AdamM "EPEL is purely a complimentary add-on repository and does not replace packages in RHEL or layered products." to "EPEL is purely a complimentary add-on repository and does not replace packages in RHEL. [Package conflicts are determined by what is openly available from Red Hat's tree (currently located at ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] > -- > http://maxamillion.googlepages.com > --------------------------------------------------------- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From maxamillion at fedoraproject.org Tue Jan 12 20:30:55 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Tue, 12 Jan 2010 14:30:55 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> References: <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> Message-ID: On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: > On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller > wrote: >> Here's a proposal: >> >> Let's make an alteration to our current policy to something of the >> effect that "we do not ship any package that has an openly available >> RPM/SRPM located in any child directory of >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to >> verify that there will be no conflicts as not all channels are >> published." >> >> Beyond that I don't think there is any realistic expectation of us to >> know what we could potentially conflict with if the information is not >> publicly available. >> >> -AdamM > > "EPEL is purely a complimentary add-on repository and does not replace > packages in RHEL or layered products." > > to > > "EPEL is purely a complimentary add-on repository and does not replace > packages in RHEL. [Package conflicts are determined by what is openly > available from Red Hat's tree (currently located at > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] > I like it, +1 here. Should we put this to a vote at the next meeting or do we want to take a poll here on the mailing list? -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From smooge at gmail.com Tue Jan 12 20:34:34 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 13:34:34 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> Message-ID: <80d7e4091001121234h1d6392a3i3c057a53a70c7642@mail.gmail.com> On Tue, Jan 12, 2010 at 1:30 PM, Adam Miller wrote: > On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: >> On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller >> wrote: >>> Here's a proposal: >>> >>> Let's make an alteration to our current policy to something of the >>> effect that "we do not ship any package that has an openly available >>> RPM/SRPM located in any child directory of >>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to >>> verify that there will be no conflicts as not all channels are >>> published." >>> >>> Beyond that I don't think there is any realistic expectation of us to >>> know what we could potentially conflict with if the information is not >>> publicly available. >>> >>> -AdamM >> >> "EPEL is purely a complimentary add-on repository and does not replace >> packages in RHEL or layered products." >> >> to >> >> "EPEL is purely a complimentary add-on repository and does not replace >> packages in RHEL. [Package conflicts are determined by what is openly >> available from Red Hat's tree (currently located at >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] >> > > > I like it, +1 here. Should we put this to a vote at the next meeting > or do we want to take a poll here on the mailing list? > > -AdamM > We should take a poll on the list and finalize on Friday meeting. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From mastahnke at gmail.com Tue Jan 12 21:05:46 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 12 Jan 2010 15:05:46 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121234h1d6392a3i3c057a53a70c7642@mail.gmail.com> References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> <80d7e4091001121234h1d6392a3i3c057a53a70c7642@mail.gmail.com> Message-ID: <7874d9dd1001121305q5e7168a6m86ce0badccbcfa09@mail.gmail.com> I'll +1 it. From inode0 at gmail.com Tue Jan 12 22:21:13 2010 From: inode0 at gmail.com (inode0) Date: Tue, 12 Jan 2010 16:21:13 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> References: <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> Message-ID: On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: > "EPEL is purely a complimentary add-on repository and does not replace > packages in RHEL or layered products." > > to > > "EPEL is purely a complimentary add-on repository and does not replace > packages in RHEL. [Package conflicts are determined by what is openly > available from Red Hat's tree (currently located at > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] I would appreciate you putting up with one more serious question from the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT, RHWAS, and more fall into this new category and since the upstream versions of many of those have been suggested as desirable targets for inclusion in EPEL can you help me understand what a package conflict means in this case? Is it a conflict at the package level? Is it a conflict at the file level? John From smooge at gmail.com Tue Jan 12 22:44:47 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 15:44:47 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> Message-ID: <80d7e4091001121444t35f2be14sa460e2e126fb4cac@mail.gmail.com> On Tue, Jan 12, 2010 at 3:21 PM, inode0 wrote: > On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: >> "EPEL is purely a complimentary add-on repository and does not replace >> packages in RHEL or layered products." >> >> to >> >> "EPEL is purely a complimentary add-on repository and does not replace >> packages in RHEL. [Package conflicts are determined by what is openly >> available from Red Hat's tree (currently located at >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] > > I would appreciate you putting up with one more serious question from > the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT, > RHWAS, and more fall into this new category and since the upstream > versions of many of those have been suggested as desirable targets for > inclusion in EPEL can you help me understand what a package conflict > means in this case? Is it a conflict at the package level? Is it a > conflict at the file level? I am not sure what you mean fall into this new category. None of the channels listed above seem to be in ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ [Nor are some of them on ftp://ftp.redhat.com/ in a form that could be used to build file/package conflicts from.] Could you define it a bit better for me? -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From inode0 at gmail.com Wed Jan 13 00:08:56 2010 From: inode0 at gmail.com (inode0) Date: Tue, 12 Jan 2010 18:08:56 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121444t35f2be14sa460e2e126fb4cac@mail.gmail.com> References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> <80d7e4091001121444t35f2be14sa460e2e126fb4cac@mail.gmail.com> Message-ID: On Tue, Jan 12, 2010 at 4:44 PM, Stephen John Smoogen wrote: > On Tue, Jan 12, 2010 at 3:21 PM, inode0 wrote: >> On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: >>> "EPEL is purely a complimentary add-on repository and does not replace >>> packages in RHEL or layered products." >>> >>> to >>> >>> "EPEL is purely a complimentary add-on repository and does not replace >>> packages in RHEL. [Package conflicts are determined by what is openly >>> available from Red Hat's tree (currently located at >>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] >> >> I would appreciate you putting up with one more serious question from >> the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT, >> RHWAS, and more fall into this new category and since the upstream >> versions of many of those have been suggested as desirable targets for >> inclusion in EPEL can you help me understand what a package conflict >> means in this case? Is it a conflict at the package level? Is it a >> conflict at the file level? > > I am not sure what you mean fall into this new category. None of the > channels listed above seem to be in > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ [Nor are some of > them on ftp://ftp.redhat.com/ in a form that could be used to build > file/package conflicts from.] > > Could you define it a bit better for me? You need to drill down a bit to see them. ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/ John From k.georgiou at imperial.ac.uk Wed Jan 13 01:21:22 2010 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Wed, 13 Jan 2010 01:21:22 +0000 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> Message-ID: <20100113012122.GA8137@imperial.ac.uk> On Tue, Jan 12, 2010 at 02:20:35PM -0600, Adam Miller wrote: > Here's a proposal: > > Let's make an alteration to our current policy to something of the > effect that "we do not ship any package that has an openly available > RPM/SRPM located in any child directory of > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to > verify that there will be no conflicts as not all channels are > published." With a quick look I see puppet, facter, ruby-shadow, jfreechart, python-cheetah, python-simplejson, cobbler, perl-GD, TurboGears, python-kerberos available there... Kostas Georgiou From smooge at gmail.com Wed Jan 13 01:31:13 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 18:31:13 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <20100113012122.GA8137@imperial.ac.uk> References: <1263282101.3724.3.camel@localhost.localdomain> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <20100113012122.GA8137@imperial.ac.uk> Message-ID: <80d7e4091001121731m46764c46j384040c164b1d9b4@mail.gmail.com> On Tue, Jan 12, 2010 at 6:21 PM, Kostas Georgiou wrote: > On Tue, Jan 12, 2010 at 02:20:35PM -0600, Adam Miller wrote: > >> Here's a proposal: >> >> Let's make an alteration to our current policy to something of the >> effect that "we do not ship any package that has an openly available >> RPM/SRPM located in any child directory of >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to >> verify that there will be no conflicts as not all channels are >> published." > > With a quick look I see puppet, facter, ruby-shadow, jfreechart, > python-cheetah, python-simplejson, cobbler, perl-GD, TurboGears, > python-kerberos available there... Well put butter on me and call me a bisquit. That pretty much says 'screw me'.. well on the other hand... it makes EPEL much smaller to deal with :). Ok let me think this over a bit more and figure out a better wording. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From smooge at gmail.com Wed Jan 13 01:32:22 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 12 Jan 2010 18:32:22 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> <80d7e4091001121444t35f2be14sa460e2e126fb4cac@mail.gmail.com> Message-ID: <80d7e4091001121732i252d7cdcma4de55023589ce24@mail.gmail.com> On Tue, Jan 12, 2010 at 5:08 PM, inode0 wrote: > On Tue, Jan 12, 2010 at 4:44 PM, Stephen John Smoogen wrote: >> On Tue, Jan 12, 2010 at 3:21 PM, inode0 wrote: >>> On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: >>>> "EPEL is purely a complimentary add-on repository and does not replace >>>> packages in RHEL or layered products." >>>> >>>> to >>>> >>>> "EPEL is purely a complimentary add-on repository and does not replace >>>> packages in RHEL. [Package conflicts are determined by what is openly >>>> available from Red Hat's tree (currently located at >>>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] >>> >>> I would appreciate you putting up with one more serious question from >>> the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT, >>> RHWAS, and more fall into this new category and since the upstream >>> versions of many of those have been suggested as desirable targets for >>> inclusion in EPEL can you help me understand what a package conflict >>> means in this case? Is it a conflict at the package level? Is it a >>> conflict at the file level? >> >> I am not sure what you mean fall into this new category. None of the >> channels listed above seem to be in >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ [Nor are some of >> them on ftp://ftp.redhat.com/ in a form that could be used to build >> file/package conflicts from.] >> >> Could you define it a bit better for me? > > You need to drill down a bit to see them. > > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/ Well how the henry did I miss them when I did a find earlier.. they are there.. but I didnt see them. hmmm time to think about this a bit more. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From mmcgrath at redhat.com Wed Jan 13 01:38:59 2010 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Jan 2010 19:38:59 -0600 (CST) Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> Message-ID: On Tue, 12 Jan 2010, inode0 wrote: > On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: > > "EPEL is purely a complimentary add-on repository and does not replace > > packages in RHEL or layered products." > > > > to > > > > "EPEL is purely a complimentary add-on repository and does not replace > > packages in RHEL. [Package conflicts are determined by what is openly > > available from Red Hat's tree (currently located at > > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] > > I would appreciate you putting up with one more serious question from > the perspective of a user. Since RHEIPA, RHSAT, RHDirServ, RHCERT, > RHWAS, and more fall into this new category and since the upstream > versions of many of those have been suggested as desirable targets for > inclusion in EPEL can you help me understand what a package conflict > means in this case? Is it a conflict at the package level? Is it a > conflict at the file level? > I'm conflicted about this for a lot of reasons. First, I'm the nagios packager (though orphaning if anyone wants it. I've been meaning to for a while but have been too lazy) The second concern is that other packages fall into this category. For my job in Fedora, Turbogears is a big deal. Right now the people that package TurboGears actually work with me in Fedora Infrasturcture. So when we have a problem, it magically goes away. At the same time though. The point of EPEL from the start as I understood it is we don't replace packages in RHEL and we don't allow EPEL to be a way to route around or not pay for channels (which is why we don't ship the cluster suite). The whole deal was to provide not just extra packages for enterprise linux but also peace of mind for people that use RHEL. This is a tough position to be in, it really is. I'm going to think on it some but I'm more inclined to say if RH ships it we remove it from EPEL even though I'm 95% sure that's going to make my life in Fedora Infrastructure harder. /me goes to think some more. -Mike From wolfy at nobugconsulting.ro Wed Jan 13 08:53:15 2010 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 13 Jan 2010 10:53:15 +0200 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <7874d9dd1001121305q5e7168a6m86ce0badccbcfa09@mail.gmail.com> References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> <80d7e4091001121234h1d6392a3i3c057a53a70c7642@mail.gmail.com> <7874d9dd1001121305q5e7168a6m86ce0badccbcfa09@mail.gmail.com> Message-ID: <4B4D89FB.2060607@nobugconsulting.ro> Michael Stahnke wrote: > I'll +1 it. > > +1 from me, too From paul at city-fan.org Wed Jan 13 09:26:55 2010 From: paul at city-fan.org (Paul Howarth) Date: Wed, 13 Jan 2010 09:26:55 +0000 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> References: <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> Message-ID: <4B4D91DF.6060809@city-fan.org> On 12/01/10 20:27, Stephen John Smoogen wrote: > On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller > wrote: >> Here's a proposal: >> >> Let's make an alteration to our current policy to something of the >> effect that "we do not ship any package that has an openly available >> RPM/SRPM located in any child directory of >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ but we are unable to >> verify that there will be no conflicts as not all channels are >> published." >> >> Beyond that I don't think there is any realistic expectation of us to >> know what we could potentially conflict with if the information is not >> publicly available. >> >> -AdamM > > "EPEL is purely a complimentary add-on repository and does not replace > packages in RHEL or layered products." > > to > > "EPEL is purely a complimentary add-on repository and does not replace > packages in RHEL. [Package conflicts are determined by what is openly > available from Red Hat's tree (currently located at > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] s/complimentary/complementary/ Paul. From opensource at till.name Wed Jan 13 11:24:09 2010 From: opensource at till.name (Till Maas) Date: Wed, 13 Jan 2010 12:24:09 +0100 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001121234h1d6392a3i3c057a53a70c7642@mail.gmail.com> References: <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001121149n351b92d8wd91247dd0746eacc@mail.gmail.com> <80d7e4091001121227s7148ff51x1e27f7d60674e667@mail.gmail.com> <80d7e4091001121234h1d6392a3i3c057a53a70c7642@mail.gmail.com> Message-ID: <20100113112409.GB3450@genius.kawo2.rwth-aachen.de> On Tue, Jan 12, 2010 at 01:34:34PM -0700, Stephen John Smoogen wrote: > On Tue, Jan 12, 2010 at 1:30 PM, Adam Miller > wrote: > > On Tue, Jan 12, 2010 at 2:27 PM, Stephen John Smoogen wrote: > >> On Tue, Jan 12, 2010 at 1:20 PM, Adam Miller > >> wrote: > >> "EPEL is purely a complimentary add-on repository and does not replace > >> packages in RHEL or layered products." > >> > >> to > >> > >> "EPEL is purely a complimentary add-on repository and does not replace > >> packages in RHEL. [Package conflicts are determined by what is openly > >> available from Red Hat's tree (currently located at > >> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/) ] > >> > > > > > > I like it, +1 here. Should we put this to a vote at the next meeting > > or do we want to take a poll here on the mailing list? > > > > -AdamM > > > > We should take a poll on the list and finalize on Friday meeting. Imho before there is a decision, the consequences of it should be explained to people who do not use RHEL. Which packages will this make remove from EPEL? Afaics, there are 13 repositories involved to find conflicts, therefore someone who really uses RHEL can probably create a list of affected packages a lot easier, compare it with EPEL and show which packages would be removed. This has to be done anyhow if the new policy is accepted, otherwise you cannot enforce it, so better do it before the change. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mattdm at mattdm.org Wed Jan 13 13:41:58 2010 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Jan 2010 08:41:58 -0500 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <1263318060.2474.1.camel@localhost> References: <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> Message-ID: <20100113134158.GA21022@jadzia.bu.edu> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote: > Possibly RH could use a one-higher Epoch in their channels. Everybody > wins. That's the path of madness. Let's please not encourage it. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From smooge at gmail.com Wed Jan 13 16:11:33 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 13 Jan 2010 09:11:33 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <20100113134158.GA21022@jadzia.bu.edu> References: <1263282101.3724.3.camel@localhost.localdomain> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> Message-ID: <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller wrote: > On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote: >> Possibly RH could use a one-higher Epoch in their channels. ?Everybody >> wins. > > That's the path of madness. Let's please not encourage it. > We also checked and rpm doesn't allow us to use an EPOCH of -1 (for even more madness). I think in the end, we are going to either rebuild what they have in that channel OR not ship it. Joy. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From wolfy at nobugconsulting.ro Wed Jan 13 19:13:47 2010 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 13 Jan 2010 21:13:47 +0200 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> References: <1263282101.3724.3.camel@localhost.localdomain> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> Message-ID: <4B4E1B6B.4060008@nobugconsulting.ro> On 01/13/2010 06:11 PM, Stephen John Smoogen wrote: > On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller wrote: > >> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote: >> >>> Possibly RH could use a one-higher Epoch in their channels. Everybody >>> wins. >>> >> That's the path of madness. Let's please not encourage it. >> >> > > We also checked and rpm doesn't allow us to use an EPOCH of -1 (for > even more madness). > > I think in the end, we are going to either rebuild what they have in > that channel OR not ship it. Joy. > > or recommend using yum-priorities and use priority=1 for base / updates / RHN and >=2 for EPEL. From updates at fedoraproject.org Wed Jan 13 19:01:40 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Wed, 13 Jan 2010 19:01:40 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100113190215.C87D91103D4@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing 389-ds-base-1.2.5-1.el5 pki-ca-1.3.0-6.el5.1 pki-selinux-1.3.1-1.el5 rfkill-0.3-3.1.el5 Details about builds: ================================================================================ 389-ds-base-1.2.5-1.el5 (FEDORA-EPEL-2010-0061) 389 Directory Server (base) -------------------------------------------------------------------------------- Update Information: This is the official 1.2.5 release. It is essentially the same as 1.2.5.rc4. -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 12 2010 Rich Megginson - 1.2.5-1 - 1.2.5 final release * Mon Jan 4 2010 Rich Megginson - 1.2.5-0.5.rc4 - 1.2.5.rc4 release * Thu Dec 17 2009 Rich Megginson - 1.2.5-0.4.rc3 - 1.2.5.rc3 release -------------------------------------------------------------------------------- References: [ 1 ] Bug #533025 - Tracking bug for 389 Directory Server 1.2.5 https://bugzilla.redhat.com/show_bug.cgi?id=533025 -------------------------------------------------------------------------------- ================================================================================ pki-ca-1.3.0-6.el5.1 (FEDORA-EPEL-2010-0063) Dogtag Certificate System - Certificate Authority -------------------------------------------------------------------------------- Update Information: The Dogtag Certificate Authority -------------------------------------------------------------------------------- References: [ 1 ] Bug #522210 - New Package for Dogtag PKI: pki-ca https://bugzilla.redhat.com/show_bug.cgi?id=522210 -------------------------------------------------------------------------------- ================================================================================ pki-selinux-1.3.1-1.el5 (FEDORA-EPEL-2010-0064) Dogtag Certificate System - PKI Selinux Policies -------------------------------------------------------------------------------- Update Information: Dogtag Security Enhanced Linux -------------------------------------------------------------------------------- References: [ 1 ] Bug #521255 - New package for Dogtag PKI: pki-selinux https://bugzilla.redhat.com/show_bug.cgi?id=521255 -------------------------------------------------------------------------------- ================================================================================ rfkill-0.3-3.1.el5 (FEDORA-EPEL-2010-0062) A tool for enabling and disabling wireless devices -------------------------------------------------------------------------------- Update Information: Add rfkill utility to EPEL for .el5... -------------------------------------------------------------------------------- References: [ 1 ] Bug #555116 - Add rfkill utility to EPEL for .el5 https://bugzilla.redhat.com/show_bug.cgi?id=555116 -------------------------------------------------------------------------------- From inode0 at gmail.com Wed Jan 13 19:50:26 2010 From: inode0 at gmail.com (inode0) Date: Wed, 13 Jan 2010 13:50:26 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <4B4E1B6B.4060008@nobugconsulting.ro> References: <1263282101.3724.3.camel@localhost.localdomain> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> Message-ID: On Wed, Jan 13, 2010 at 1:13 PM, Manuel Wolfshant wrote: > or recommend using yum-priorities and use priority=1 for base / updates / > RHN and >=2 for EPEL. I don't believe yum-priorities works with yum-rhn-plugin nor is it available on RHN or in EPEL and I know it isn't going to work pre-RHEL5. John From wolfy at nobugconsulting.ro Wed Jan 13 20:12:03 2010 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 13 Jan 2010 22:12:03 +0200 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <1263282101.3724.3.camel@localhost.localdomain> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> Message-ID: <4B4E2913.8030903@nobugconsulting.ro> On 01/13/2010 09:50 PM, inode0 wrote: > On Wed, Jan 13, 2010 at 1:13 PM, Manuel Wolfshant > wrote: > >> or recommend using yum-priorities and use priority=1 for base / updates / >> RHN and >=2 for EPEL. >> > > I don't believe yum-priorities works with yum-rhn-plugin nor is it > available on RHN or in EPEL and I know it isn't going to work > pre-RHEL5. > > The extras repository from Centos 4 carries both yum-plugin-priorities-0.0.7-2.c4.noarch.rpm and yum-plugin-protectbase-1.1-1.c4.noarch.rpm and they work just fine. From mastahnke at gmail.com Wed Jan 13 20:14:07 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 13 Jan 2010 14:14:07 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <4B4E2913.8030903@nobugconsulting.ro> References: <1263282101.3724.3.camel@localhost.localdomain> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> <4B4E2913.8030903@nobugconsulting.ro> Message-ID: <7874d9dd1001131214o43649a20vc654a9a35366ab9d@mail.gmail.com> > > The extras repository from Centos 4 carries both > yum-plugin-priorities-0.0.7-2.c4.noarch.rpm and > yum-plugin-protectbase-1.1-1.c4.noarch.rpm and they work just fine. RHEL 4 doesn't ship with yum to start with. It still uses up2date. From inode0 at gmail.com Wed Jan 13 20:19:12 2010 From: inode0 at gmail.com (inode0) Date: Wed, 13 Jan 2010 14:19:12 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <4B4E2913.8030903@nobugconsulting.ro> References: <1263282101.3724.3.camel@localhost.localdomain> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> <4B4E2913.8030903@nobugconsulting.ro> Message-ID: On Wed, Jan 13, 2010 at 2:12 PM, Manuel Wolfshant wrote: > On 01/13/2010 09:50 PM, inode0 wrote: >> >> On Wed, Jan 13, 2010 at 1:13 PM, Manuel Wolfshant >> wrote: >> >>> >>> or recommend using yum-priorities and use priority=1 for base / updates / >>> RHN and >=2 for EPEL. >>> >> >> I don't believe yum-priorities works with yum-rhn-plugin nor is it >> available on RHN or in EPEL and I know it isn't going to work >> pre-RHEL5. >> >> > > The extras repository from Centos 4 carries both > yum-plugin-priorities-0.0.7-2.c4.noarch.rpm and > yum-plugin-protectbase-1.1-1.c4.noarch.rpm and they work just fine. CentOS doesn't use RHN. Have you tested any this against RHN? John From chrismcc at pricegrabber.com Wed Jan 13 23:28:55 2010 From: chrismcc at pricegrabber.com (Christopher) Date: Wed, 13 Jan 2010 15:28:55 -0800 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <4B4E1B6B.4060008@nobugconsulting.ro> References: <1263282101.3724.3.camel@localhost.localdomain> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> Message-ID: <1263425335.2869.4.camel@localhost> Hello... On Wed, 2010-01-13 at 21:13 +0200, Manuel Wolfshant wrote: > On 01/13/2010 06:11 PM, Stephen John Smoogen wrote: > > On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller wrote: > > > >> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote: > >> > >>> Possibly RH could use a one-higher Epoch in their channels. Everybody > >>> wins. > >>> > >> That's the path of madness. Let's please not encourage it. > >> > >> > > > > We also checked and rpm doesn't allow us to use an EPOCH of -1 (for > > even more madness). > > > > I think in the end, we are going to either rebuild what they have in > > that channel OR not ship it. Joy. > > > > > or recommend using yum-priorities and use priority=1 for base / updates > / RHN and >=2 for EPEL. > cost works in default RHEL5 from man yum.conf cost relative cost of accessing this repository. Useful for weighing one repo's packages as greater/less than any other. defaults to 1000 /etc/yum.repos.d/epel.repo could contain cost=1001 yes? no? maybe? I use cost=100 so my local repo always wins against rhn > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list -- Christopher McCrory "The guy that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works. From inode0 at gmail.com Wed Jan 13 23:54:35 2010 From: inode0 at gmail.com (inode0) Date: Wed, 13 Jan 2010 17:54:35 -0600 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <1263425335.2869.4.camel@localhost> References: <1263282101.3724.3.camel@localhost.localdomain> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> <1263425335.2869.4.camel@localhost> Message-ID: On Wed, Jan 13, 2010 at 5:28 PM, Christopher wrote: > cost works in default RHEL5 > > from man yum.conf > > ?cost ?relative ?cost ?of ?accessing ?this repository. Useful for > ?weighing one repo's packages as ?greater/less ?than ?any ?other. > ?defaults to 1000 > > /etc/yum.repos.d/epel.repo could contain cost=1001 > > yes? no? maybe? > > I use cost=100 so my local repo always wins against rhn Does it really work? I honestly don't know but being in the yum docs isn't persuasive evidence that it will work against RHN channels which are not ordinary yum repositories. The yum-rhn-plugin has to support it for it to work with RHN and until very recently it supported pretty much nothing. I believe in 5.3 or thereabouts yum-rhn-plugin first allowed the ability to even specify enabled/disabled for individual RHN channels. With RHEL5 people can always use includepkgs with EPEL so there does in fact exist a way to mitigate conflicts but ... All these yum-based suggestions though leave me scratching my head a little. Let's stipulate for argument's sake that some yum dance would give us a way to work around conflicts. If I need to worry about conflicts and set up this or that to avoid them or mitigate danger, then I feel like I've lost one of the key selling features of EPEL. I do those dances for rpmforge, EPEL was supposed to make my life easier. So I think the question just fundamentally comes down to do we want to avoid conflicts or do we want a really large and useful package set more. Good arguments can be made for both directions and both directions come with a price. Not an easy choice to make. Can we have our cake and eat it too with multiple EPEL repos? One for conflicts and one guaranteed to be free of conflicts? With a price we can but can we pay that price? John From djuran at redhat.com Thu Jan 14 08:11:21 2010 From: djuran at redhat.com (David Juran) Date: Thu, 14 Jan 2010 10:11:21 +0200 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: <4B4E1B6B.4060008@nobugconsulting.ro> References: <1263282101.3724.3.camel@localhost.localdomain> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> Message-ID: <1263456681.3804.9.camel@localhost.localdomain> On Wed, 2010-01-13 at 21:13 +0200, Manuel Wolfshant wrote: > On 01/13/2010 06:11 PM, Stephen John Smoogen wrote: > > On Wed, Jan 13, 2010 at 6:41 AM, Matthew Miller wrote: > > > >> On Tue, Jan 12, 2010 at 09:41:00AM -0800, Christopher wrote: > >> > >>> Possibly RH could use a one-higher Epoch in their channels. Everybody > >>> wins. > >>> > >> That's the path of madness. Let's please not encourage it. > >> > >> > > > > We also checked and rpm doesn't allow us to use an EPOCH of -1 (for > > even more madness). > > > > I think in the end, we are going to either rebuild what they have in > > that channel OR not ship it. Joy. +1 > or recommend using yum-priorities and use priority=1 for base / updates > / RHN and >=2 for EPEL. In addition to what everyone else already mentioned, this will cause a problem if someone first installs a version from EPEL and then subscribes to the Red Hat Channel. If the version in EPEL then is higher, the package will be "orphaned". -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- 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 rjones at redhat.com Thu Jan 14 12:47:21 2010 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 Jan 2010 12:47:21 +0000 Subject: EPEL 5 build of ntfs-3g Message-ID: <20100114124721.GA12346@amd.home.annexia.org> Hi spot, ntfs-3g is branched for EL-5, but we noticed there is no build. http://cvs.fedoraproject.org/viewvc/EL-5/ntfs-3g/ Since FUSE was added to the RHEL 5.4 kernel, it is possible to build ntfs-3g (which is a FUSE module), indeed we have done a scratch build already: http://koji.fedoraproject.org/koji/taskinfo?taskID=1920739 Do you mind if I build this in EL-5? Also do you mind if I backport from Rawhide? Although there are not any specific features we need, we do all our libguestfs testing against later versions of ntfs-3g, and AIUI there should be no backwards compatibility issues for EPEL users (partly because it's not an API and partly because there is no build for EPEL users at the moment anyway). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From chrismcc at pricegrabber.com Thu Jan 14 18:02:44 2010 From: chrismcc at pricegrabber.com (Christopher) Date: Thu, 14 Jan 2010 10:02:44 -0800 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <1263282101.3724.3.camel@localhost.localdomain> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> <80d7e4091001120900l575aecebn11e96c4edb78b85@mail.gmail.com> <1263318060.2474.1.camel@localhost> <20100113134158.GA21022@jadzia.bu.edu> <80d7e4091001130811x4d673903w19dfb53312e436a0@mail.gmail.com> <4B4E1B6B.4060008@nobugconsulting.ro> <1263425335.2869.4.camel@localhost> Message-ID: <1263492164.5438.20.camel@localhost> Hello... On Wed, 2010-01-13 at 17:54 -0600, inode0 wrote: > On Wed, Jan 13, 2010 at 5:28 PM, Christopher wrote: > > cost works in default RHEL5 > > > > from man yum.conf > > > > cost relative cost of accessing this repository. Useful for > > weighing one repo's packages as greater/less than any other. > > defaults to 1000 > > > > /etc/yum.repos.d/epel.repo could contain cost=1001 > > > > yes? no? maybe? > > > > I use cost=100 so my local repo always wins against rhn > > Does it really work? I honestly don't know but being in the yum docs > isn't persuasive evidence that it will work against RHN channels which > are not ordinary yum repositories. The yum-rhn-plugin has to support > it for it to work with RHN and until very recently it supported pretty > much nothing. I believe in 5.3 or thereabouts yum-rhn-plugin first > allowed the ability to even specify enabled/disabled for individual > RHN channels. > It works in RHEL 5.4, I cannot test other versions. > With RHEL5 people can always use includepkgs with EPEL so there does > in fact exist a way to mitigate conflicts but ... > > All these yum-based suggestions though leave me scratching my head a > little. Let's stipulate for argument's sake that some yum dance would > give us a way to work around conflicts. If I need to worry about > conflicts and set up this or that to avoid them or mitigate danger, > then I feel like I've lost one of the key selling features of EPEL. I > do those dances for rpmforge, EPEL was supposed to make my life > easier. > Agreed. > So I think the question just fundamentally comes down to do we want to > avoid conflicts or do we want a really large and useful package set > more. Good arguments can be made for both directions and both > directions come with a price. Not an easy choice to make. Can we have > our cake and eat it too with multiple EPEL repos? One for conflicts > and one guaranteed to be free of conflicts? With a price we can but > can we pay that price? > > John > What about something like; EPEL MUST NOT conflict with the main RHEL base. ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/ EPEL SHOULD NOT conflict with anything in the RH add-on products, as considered on a case by case basis. A specific example. Red Hat Enterprise MRG, http://www.redhat.com/mrg/, ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS . EPEL should not also offer any of the core packages in that product. But puppet/facter are in EPEL, and AFAICT were in EPEL before MRG was a product. puppet/facter are not the core product, but help to configure the core product. In this case EPEL should work with RH so that both repos can contain puppet/facter. This could be RH using an Epoch+1, EPEL using a higher cost, RH testing MRG with puppet from EPEL, or some other solution. So, IMHO, the EPEL policy should be something like "We don't want to trump RedHat's products" -- Christopher McCrory "The guy that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works. From smooge at gmail.com Thu Jan 14 20:41:00 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Jan 2010 13:41:00 -0700 Subject: nagios shipped by RedHat, but in a specific subscription channel In-Reply-To: References: <7874d9dd1001111503q16491183nf65d99c4815e1a34@mail.gmail.com> <1263282101.3724.3.camel@localhost.localdomain> <4B4C4F9B.102@codefarm.com> <20100112140134.GC1497270@hiwaay.net> <7874d9dd1001120748o27e97313y586d2354a6cd95bb@mail.gmail.com> Message-ID: <80d7e4091001141241s1a094254o173ee641fce089f3@mail.gmail.com> On Tue, Jan 12, 2010 at 9:09 AM, inode0 wrote: > On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke wrote: > My understanding of EPEL's mission was that it would allow me to begin > with a RHEL + layered product box, configure EPEL, get additional > stuff without creating new problems. I think that is a wonderful > mission. I think that was one vision. The issue is that it is almost impossible in practicality to accomplish. Especially when some RH channels replace stuff that is in core (MRTG). It makes the job of EPEL a lot more of reacting to unknown forces and also makes it hard when say we have been putting cobbler or puppet in and then a previous version shows up on RHN. We can remove our version but its not going to fix the person who has the newer version and then never gets updates to what is in RHN. I will be making a list of all these sub-packages today.. will see what would need to be removed. > If this becomes I can begin with a box with anything I can get from > AP, configure EPEL, get additional stuff without creating new problems > I think we have a slightly less wonderful mission abstractly but > perhaps a more effective mission in the real world. > > John > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From kevin at tummy.com Thu Jan 14 22:16:15 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 14 Jan 2010 15:16:15 -0700 Subject: Plan for tomorrow's EPEL meeting - 2010-01-15 Message-ID: <20100114151615.5de7f2ed@ohm.scrye.com> Here's the topic list for tomorrows EPEL meeting, which will take place at 21:00 UTC in #fedora-meeting on irc.freenode.net. - Status update on action items - smooge: Blocking packages already in RHEL - Fuse for 5.4 status - Moin - Any takers? - Blocking EPEL packages that are in RHEL s - Open Floor If there is something else that folks would like to discuss, please followup to this email or mention it in the Open Floor section of the meeting at the end. Hope to see everyone there! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mastahnke at gmail.com Thu Jan 14 23:54:46 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 14 Jan 2010 17:54:46 -0600 Subject: Plan for tomorrow's EPEL meeting - 2010-01-15 In-Reply-To: <20100114151615.5de7f2ed@ohm.scrye.com> References: <20100114151615.5de7f2ed@ohm.scrye.com> Message-ID: <7874d9dd1001141554k5ef0fc19n4fe6badca9abc075@mail.gmail.com> On Thu, Jan 14, 2010 at 4:16 PM, Kevin Fenzi wrote: > Here's the topic list for tomorrows EPEL meeting, which will take > place at 21:00 UTC in #fedora-meeting on irc.freenode.net. > > - Status update on action items > ? - smooge: Blocking packages already in RHEL > ? ?- Fuse for 5.4 status > - Moin - Any takers? > - Blocking EPEL packages that are in RHEL s > - Open Floor > I'd like to continue the discussion started in the nagios thread. This feels like an extremely critical decision for EPEL. stahnma From kevin at tummy.com Fri Jan 15 00:01:38 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 14 Jan 2010 17:01:38 -0700 Subject: Plan for tomorrow's EPEL meeting - 2010-01-15 In-Reply-To: <7874d9dd1001141554k5ef0fc19n4fe6badca9abc075@mail.gmail.com> References: <20100114151615.5de7f2ed@ohm.scrye.com> <7874d9dd1001141554k5ef0fc19n4fe6badca9abc075@mail.gmail.com> Message-ID: <20100114170138.71d18189@ohm.scrye.com> On Thu, 14 Jan 2010 17:54:46 -0600 Michael Stahnke wrote: > On Thu, Jan 14, 2010 at 4:16 PM, Kevin Fenzi wrote: > > Here's the topic list for tomorrows EPEL meeting, which will take > > place at 21:00 UTC in #fedora-meeting on irc.freenode.net. > > > > - Status update on action items > > ? - smooge: Blocking packages already in RHEL > > ? ?- Fuse for 5.4 status > > - Moin - Any takers? > > - Blocking EPEL packages that are in RHEL s > > - Open Floor > > > I'd like to continue the discussion started in the nagios thread. > This feels like an extremely critical decision for EPEL. Yeah, that was supposed to be the: Blocking EPEL packages that are in RHEL s line that got cut off. ;( Blocking EPEL package that are in any RHEL channel kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From smooge at gmail.com Fri Jan 15 00:21:31 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Jan 2010 17:21:31 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL Message-ID: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> Ok there are 76 direct conflicts between RH sub-channels and EPEL PyYAML TurboGears bea-stax cobbler facter gsoap idm-console-framework jabberd jcommon jfreechart jss libapreq2 libyaml nocpulse-common osutil perl-BerkeleyDB perl-Class-MethodMaker perl-Class-Singleton perl-Config-IniFiles perl-Crypt-DES perl-Crypt-GeneratePassword perl-DBD-SQLite perl-DateTime perl-Error perl-FreezeThaw perl-GD perl-HTML-TableExtract perl-IO-stringy perl-MIME-Lite perl-MIME-tools perl-MailTools perl-NOCpulse-CLAC perl-NOCpulse-Debug perl-NOCpulse-Gritch perl-NOCpulse-Object perl-NOCpulse-SetID perl-NOCpulse-Utils perl-Net-SNMP perl-Network-IPv4Addr perl-Params-Validate perl-Parse-RecDescent perl-SOAP-Lite perl-XML-Generator pki-native-tools pki-util puppet python-TestGears python-boto python-cheetah python-cherrypy python-configobj python-decoratortools python-formencode python-json python-kerberos python-kid python-krbV python-netaddr python-nose python-paste python-paste-deploy python-paste-script python-protocols python-psycopg2 python-ruledispatch python-simplejson python-sqlalchemy python-sqlite2 python-sqlobject python-tgfastdata python-turbocheetah python-turbojson python-turbokid ruby-shadow spacewalk-proxy-docs symkey Walking the chain a couple of times.. I come up with 114 packages that need to be removed because of secondary dependencies.. I might have missed a few though (because well just because 389-ds is removed.. it doesn't remove the other 389 ones.) 389-console 389-ds CGSI-gSOAP-devel Django Django-doc Django-south PyQuante bcfg2-server bodhi-client bodhi-server django-authority django-contact-form django-evolution django-filter django-flash django-notification django-pagination django-piston django-profile django-sorting django-tagging django-typepad duplicity fedora-packager func gajim gsoap-devel inkscape jcommon-javadoc jcommon-xml jfreechart-javadoc kobo-hub koji koji-builder koji-hub koji-hub-plugins koji-utils koji-web libapreq2-devel libyaml-devel mars-sim mars-sim-javadoc mash mimedefang mirrormanager mock munin numpy pki-util-javadoc plague-builder puppet-server pyfacebook pyfits pygrace pypar python-Coherence python-Lightbox python-Scriptaculous python-TurboMail python-elixir python-fedora python-louie python-matplotlib python-migrate python-mwclient python-mwlib python-numdisplay python-peak-rules python-peak-util-addons python-peak-util-assembler python-prioritized-methods python-psycopg2-doc python-psycopg2-zope python-remoteobjects python-repoze-what-plugins-sql python-repoze-what-quickstart python-repoze-who python-repoze-who-plugins-sa python-repoze-who-testutil python-shove python-sprox python-storm-postgresql python-storm-sqlite python-tgcaptcha python-tgext-crud python-toscawidgets python-turboflot python-tw-forms python-tw-jquery python-twitter python-typepad python-webflash python-wsgiproxy repoview revisor-cobbler rho roundup sagator-webq scipy smolt smolt-firstboot smolt-gui smolt-server stonevpn supybot-fedora supybot-koji translate-toolkit translate-toolkit-devel trytond trytond-openoffice trytond-webdav typepad-motion viewmtn virtaal ================ found this by first looking for conflicts in packages and then doing a reverse walk with for i in $( cat file-of-conflicts ); do repoquery --disablerepo="*" --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done So out of 2389 packages we would need to remove 190. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From kevin at tummy.com Fri Jan 15 00:28:45 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 14 Jan 2010 17:28:45 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> Message-ID: <20100114172845.51489a0d@ohm.scrye.com> On Thu, 14 Jan 2010 17:21:31 -0700 Stephen John Smoogen wrote: > Ok there are 76 direct conflicts between RH sub-channels and EPEL Which sub-channels exactly? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From smooge at gmail.com Fri Jan 15 01:01:37 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Jan 2010 18:01:37 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <20100114172845.51489a0d@ohm.scrye.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100114172845.51489a0d@ohm.scrye.com> Message-ID: <80d7e4091001141701i4761affcu279530758707ad97@mail.gmail.com> On Thu, Jan 14, 2010 at 5:28 PM, Kevin Fenzi wrote: > On Thu, 14 Jan 2010 17:21:31 -0700 > Stephen John Smoogen wrote: > >> Ok there are 76 direct conflicts between RH sub-channels and EPEL > > Which sub-channels exactly? Everything with src.rpms under ftp://ftp.redhat.com//redhat/linux/enterprise [5 I need to look at 4 also] JBWFK RHCERT RHDirServ RHEIPA RHEMRG RHNPROXY RHNSAT RHWAS I would expect there are other channels that I am not aware of ... but these are the ones that people can replicate tests from. > kevin > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From dennis at ausil.us Fri Jan 15 02:06:25 2010 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 14 Jan 2010 20:06:25 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001141701i4761affcu279530758707ad97@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100114172845.51489a0d@ohm.scrye.com> <80d7e4091001141701i4761affcu279530758707ad97@mail.gmail.com> Message-ID: <201001142006.35181.dennis@ausil.us> On Thursday 14 January 2010 07:01:37 pm Stephen John Smoogen wrote: > On Thu, Jan 14, 2010 at 5:28 PM, Kevin Fenzi wrote: > > On Thu, 14 Jan 2010 17:21:31 -0700 > > > > Stephen John Smoogen wrote: > >> Ok there are 76 direct conflicts between RH sub-channels and EPEL > > > > Which sub-channels exactly? Packages in satellite, directory server, and certificate system are expected to possibly cause conflicts. the open source equivilent are branded under diferent product names and are undergoing work explictly to get them into epel. I know i personally pulled a bunch of the packages from epel to put into satellite and if we pull them from epel i would be extremely disappointed. In the satellite case you only have a supported satellite server if you use software from the rhn channels adding epel to a satellite box will immediately make you unsupported. Dennis > Everything with src.rpms under > ftp://ftp.redhat.com//redhat/linux/enterprise [5 I need to look at 4 > also] > > JBWFK > RHCERT > RHDirServ > RHEIPA > RHEMRG > RHNPROXY > RHNSAT > RHWAS > > I would expect there are other channels that I am not aware of ... but > these are the ones that people can replicate tests from. > > > kevin > > > > _______________________________________________ > > epel-devel-list mailing list > > epel-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/epel-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From inode0 at gmail.com Fri Jan 15 02:20:29 2010 From: inode0 at gmail.com (inode0) Date: Thu, 14 Jan 2010 20:20:29 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <201001142006.35181.dennis@ausil.us> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100114172845.51489a0d@ohm.scrye.com> <80d7e4091001141701i4761affcu279530758707ad97@mail.gmail.com> <201001142006.35181.dennis@ausil.us> Message-ID: On Thu, Jan 14, 2010 at 8:06 PM, Dennis Gilmore wrote: > On Thursday 14 January 2010 07:01:37 pm Stephen John Smoogen wrote: >> On Thu, Jan 14, 2010 at 5:28 PM, Kevin Fenzi wrote: >> > On Thu, 14 Jan 2010 17:21:31 -0700 >> > >> > Stephen John Smoogen wrote: >> >> Ok there are 76 direct conflicts between RH sub-channels and EPEL >> > >> > Which sub-channels exactly? > > Packages in satellite, directory server, and certificate system are expected to > possibly cause conflicts. ?the open source equivilent are branded under > diferent product names and are undergoing work explictly to get them into > epel. That is interesting. > I know i personally pulled a bunch of the packages from epel to put into > satellite and if we pull them from epel i would be extremely disappointed. > In the satellite case you only have a supported satellite server if you use > software from the rhn channels ?adding epel to a satellite box will > immediately make you unsupported. Adding EPEL makes a RHEL box of any sort unsupported, but Red Hat is not a stickler about this unless what you have done is likely the cause your problem. Then you remove it and reproduce. Thinking more about this I do think someone running a layered product would probably be much less likely to use a third party repo though than other random RHEL boxes would be. If Red Hat is using EPEL as an upstream for its layered products I think EPEL should be able to expect some cooperation from Red Hat in the future. John From mastahnke at gmail.com Fri Jan 15 03:40:22 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 14 Jan 2010 21:40:22 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> Message-ID: <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> If EPEL would pull all of those packages it would become basically useless to me. stahnma From inode0 at gmail.com Fri Jan 15 03:44:01 2010 From: inode0 at gmail.com (inode0) Date: Thu, 14 Jan 2010 21:44:01 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> Message-ID: On Thu, Jan 14, 2010 at 9:40 PM, Michael Stahnke wrote: > > If EPEL would pull all of those packages it would become basically > useless to me. I don't really see how pulling all those packages can be the direction we go. Way too disruptive to EPEL users at this point. John From a.badger at gmail.com Fri Jan 15 03:43:46 2010 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 Jan 2010 22:43:46 -0500 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> Message-ID: <20100115034346.GF17736@clingman.lan> On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: > > ================ > found this by first looking for conflicts in packages and then doing a > reverse walk with > for i in $( cat file-of-conflicts ); do repoquery --disablerepo="*" > --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done > Wait a minute.... So the first list is conflicts with with RHEL layered products. We're saying, these packages are in our new definition of RHEL and thereforewe need to drop them. I'm with you so far. But why the second list? If the package is in RHEL, then we need to check the second list and see if they can build/work with the version in RHEL, right? Not outright drop? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rayvd at bludgeon.org Fri Jan 15 03:55:01 2010 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 14 Jan 2010 19:55:01 -0800 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> Message-ID: <20100115035500.GA32571@bludgeon.org> On Thu, Jan 14, 2010 at 09:44:01PM -0600, inode0 wrote: > On Thu, Jan 14, 2010 at 9:40 PM, Michael Stahnke wrote: > > > > If EPEL would pull all of those packages it would become basically > > useless to me. > > I don't really see how pulling all those packages can be the direction > we go. Way too disruptive to EPEL users at this point. > Guess they could be moved to an "epel-unpure" repository. :) (In favor of the status quo personally not having read all the discussion yet...) Ray From smooge at gmail.com Fri Jan 15 04:21:11 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Jan 2010 21:21:11 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <20100115034346.GF17736@clingman.lan> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> Message-ID: <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi wrote: > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: >> >> ================ >> found this by first looking for conflicts in packages and then doing a >> reverse walk with >> for i in $( cat file-of-conflicts ?); do repoquery ?--disablerepo="*" >> --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done >> > Wait a minute.... So the first list is conflicts with ?with > RHEL layered products. ?We're saying, these packages are in our new > definition of RHEL and thereforewe need to drop them. ?I'm with you so far. > > But why the second list? ?If the package is in RHEL, then we need to check > the second list and see if they can build/work with the version in RHEL, > right? ?Not outright drop? The packages are in channels that are layered onto RHEL and not available to customers who have not bought those products. Only the SRPMS are available. Thus building those packages would be impossible for someone who is trying to build stuff on CentOS or in the build system. So basically you have to pull them because you can't build them IF you following the rule as written. Personally I think the point is we have to rewrite the rule to basically if its in ftp://ftp.redhat.com/pub/redhat/linux/enterprise/*/os/ we dont' replace/overwrite.. but otherwise caveat empor. Especially since one of the things EPEL allows for RH is to have packages that they know are packaged to standards, work with EL (at somepoint of time) that they can then pull back into layered products. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From cmadams at hiwaay.net Fri Jan 15 04:46:56 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 14 Jan 2010 22:46:56 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> Message-ID: <20100115044656.GB1371520@hiwaay.net> Once upon a time, Stephen John Smoogen said: > Personally I think the point is we have to rewrite the rule to > basically if its in > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/*/os/ we dont' > replace/overwrite.. but otherwise caveat empor. Especially since one > of the things EPEL allows for RH is to have packages that they know > are packaged to standards, work with EL (at somepoint of time) that > they can then pull back into layered products. It is Extra Packages for Enterprise Linux, not EP for Satellite Server (or MRG, etc.). Don't overlap with RHEL (Server and Workstation) and leave it at that. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From a.badger at gmail.com Fri Jan 15 05:06:08 2010 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 15 Jan 2010 00:06:08 -0500 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> Message-ID: <20100115050608.GK17736@clingman.lan> On Thu, Jan 14, 2010 at 09:21:11PM -0700, Stephen John Smoogen wrote: > On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi wrote: > > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: > >> > >> ================ > >> found this by first looking for conflicts in packages and then doing a > >> reverse walk with > >> for i in $( cat file-of-conflicts ?); do repoquery ?--disablerepo="*" > >> --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done > >> > > Wait a minute.... So the first list is conflicts with ?with > > RHEL layered products. ?We're saying, these packages are in our new > > definition of RHEL and thereforewe need to drop them. ?I'm with you so far. > > > > But why the second list? ?If the package is in RHEL, then we need to check > > the second list and see if they can build/work with the version in RHEL, > > right? ?Not outright drop? > > The packages are in channels that are layered onto RHEL and not > available to customers who have not bought those products. Only the > SRPMS are available. Thus building those packages would be impossible > for someone who is trying to build stuff on CentOS or in the build > system. So basically you have to pull them because you can't build > them IF you following the rule as written. > > Personally I think the point is we have to rewrite the rule to > basically if its in > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/*/os/ we dont' > replace/overwrite.. but otherwise caveat empor. Especially since one > of the things EPEL allows for RH is to have packages that they know > are packaged to standards, work with EL (at somepoint of time) that > they can then pull back into layered products. > Yep. If the alternative is going to take us into the realm of not having certain packages in EPEL because something it depends on is in a layered product and not in the layered products themselves then that option is doesn't make much sense for us. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From orion at cora.nwra.com Fri Jan 15 05:29:10 2010 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 14 Jan 2010 22:29:10 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <20100115044656.GB1371520@hiwaay.net> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <20100115044656.GB1371520@hiwaay.net> Message-ID: <4B4FFD26.3070909@cora.nwra.com> On 1/14/2010 9:46 PM, Chris Adams wrote: > It is Extra Packages for Enterprise Linux, not EP for Satellite Server > (or MRG, etc.). Don't overlap with RHEL (Server and Workstation) and > leave it at that. > +1. If this changes, I'll be much less interested in EPEL. Orion From djuran at redhat.com Fri Jan 15 08:06:05 2010 From: djuran at redhat.com (David Juran) Date: Fri, 15 Jan 2010 10:06:05 +0200 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> Message-ID: <1263542765.3804.22.camel@localhost.localdomain> On Thu, 2010-01-14 at 21:21 -0700, Stephen John Smoogen wrote: > On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi wrote: > > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: > > > > But why the second list? If the package is in RHEL, then we need to check > > the second list and see if they can build/work with the version in RHEL, > > right? Not outright drop? > > The packages are in channels that are layered onto RHEL and not > available to customers who have not bought those products. Only the > SRPMS are available. Thus building those packages would be impossible > for someone who is trying to build stuff on CentOS or in the build > system. So basically you have to pull them because you can't build > them IF you following the rule as written. I think we've been through this before, but if EPEL would ship the same version that Red Hat does of the layered products then there wouldn't be any conflict for those who have the layered product and the one's who do have the layered product can still enjoy the package. Or am I missing something here? Also, doesn't CentOS ship re-builds of the layared products? -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- 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 wolfy at nobugconsulting.ro Fri Jan 15 08:19:50 2010 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 15 Jan 2010 10:19:50 +0200 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> Message-ID: <4B502526.50002@nobugconsulting.ro> Michael Stahnke wrote: > > If EPEL would pull all of those packages it would become basically > useless to me. > > +100 here From dburklan at NMDP.ORG Fri Jan 15 13:54:33 2010 From: dburklan at NMDP.ORG (Dan Burkland) Date: Fri, 15 Jan 2010 07:54:33 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> Message-ID: <864520E139D6854083B6143334E76A00774375E1@EXCH07MB01.NMDP.ORG> > -----Original Message----- > From: epel-devel-list-bounces at redhat.com [mailto:epel-devel-list- > bounces at redhat.com] On Behalf Of Michael Stahnke > Sent: Thursday, January 14, 2010 9:40 PM > To: EPEL development disccusion > Subject: Re: Packages duplicated between EL-5 sub-channels and EPEL > > > If EPEL would pull all of those packages it would become basically > useless to me. > > > stahnma > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list I also agree with the above statement. From maxamillion at fedoraproject.org Fri Jan 15 14:20:37 2010 From: maxamillion at fedoraproject.org (Adam Miller) Date: Fri, 15 Jan 2010 08:20:37 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <1263542765.3804.22.camel@localhost.localdomain> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <1263542765.3804.22.camel@localhost.localdomain> Message-ID: On Fri, Jan 15, 2010 at 2:06 AM, David Juran wrote: > On Thu, 2010-01-14 at 21:21 -0700, Stephen John Smoogen wrote: >> On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi wrote: >> > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: > >> > >> > But why the second list? ?If the package is in RHEL, then we need to check >> > the second list and see if they can build/work with the version in RHEL, >> > right? ?Not outright drop? >> >> The packages are in channels that are layered onto RHEL and not >> available to customers who have not bought those products. Only the >> SRPMS are available. Thus building those packages would be impossible >> for someone who is trying to build stuff on CentOS or in the build >> system. So basically you have to pull them because you can't build >> them IF you following the rule as written. > > I think we've been through this before, but if EPEL would ship the same > version that Red Hat does of the layered products then there wouldn't be > any conflict for those who have the layered product and the one's who do > have the layered product can still enjoy the package. Or am I missing > something here? > It would conflict because you have essentially the same package, same version, same release, etc. but from two different sources. This is what the yum-priorities plugin exists to solve but it is not known to work with RHN so CentOS users are fine, but RHEL users are hosed. > Also, doesn't CentOS ship re-builds of the layared products? > Yes, they do. -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From inode0 at gmail.com Fri Jan 15 14:32:28 2010 From: inode0 at gmail.com (inode0) Date: Fri, 15 Jan 2010 08:32:28 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <20100115035500.GA32571@bludgeon.org> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> Message-ID: On Thu, Jan 14, 2010 at 9:55 PM, Ray Van Dolson wrote: > On Thu, Jan 14, 2010 at 09:44:01PM -0600, inode0 wrote: >> On Thu, Jan 14, 2010 at 9:40 PM, Michael Stahnke wrote: >> > >> > If EPEL would pull all of those packages it would become basically >> > useless to me. >> >> I don't really see how pulling all those packages can be the direction >> we go. Way too disruptive to EPEL users at this point. >> > > Guess they could be moved to an "epel-unpure" repository. :) > > (In favor of the status quo personally not having read all the > discussion yet...) Having given this some more thought here is what I think we should try to do. (1) Allow things that come from layered products to be replaced (here I am defining layered products as being those from channels not associated with AP). (2) Try to keep a current list of conflicts so they can be easily excluded from the EPEL repo by the user in advance (i.e., at EPEL configuration time) and announce new conflicts somewhere so the exclude list can be kept up to do more or less to minimize conflicts for those who just don't want them. Having such a current list commented out in the epel-release might work really well for the user?! That is a little extra work to help those who want only the "pure" version of the repo by enabling them to do something to create it and would let people who don't care about it just go on about their business as usual. John From rmeggins at redhat.com Fri Jan 15 16:21:05 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 Jan 2010 09:21:05 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> Message-ID: <4B5095F1.5060207@redhat.com> inode0 wrote: > On Thu, Jan 14, 2010 at 9:55 PM, Ray Van Dolson wrote: > >> On Thu, Jan 14, 2010 at 09:44:01PM -0600, inode0 wrote: >> >>> On Thu, Jan 14, 2010 at 9:40 PM, Michael Stahnke wrote: >>> >>>> >>>> If EPEL would pull all of those packages it would become basically >>>> useless to me. >>>> >>> I don't really see how pulling all those packages can be the direction >>> we go. Way too disruptive to EPEL users at this point. >>> >>> >> Guess they could be moved to an "epel-unpure" repository. :) >> >> (In favor of the status quo personally not having read all the >> discussion yet...) >> > > Having given this some more thought here is what I think we should try to do. > > (1) Allow things that come from layered products to be replaced (here > I am defining layered products as being those from channels not > associated with AP). > I can think of a specific case that will break something. Let's say for example that I am a RHEL customer, and I'm running Red Hat Directory Server. The packages idm-console-framework-N and adminutil-N come from that channel. Now let's say I set up EPEL on this box for something unrelated to directory server (e.g. I need to use git). Since 389 is also in EPEL, there are packages idm-console-framework-M and adminutil-M in EPEL, where version N < M and version N is not compatible with M. If I then do a yum update, yum is going to update idm-console-framework and adminutil to the M versions, breaking my directory server. This is unacceptable. > (2) Try to keep a current list of conflicts so they can be easily > excluded from the EPEL repo by the user in advance (i.e., at EPEL > configuration time) and announce new conflicts somewhere so the > exclude list can be kept up to do more or less to minimize conflicts > for those who just don't want them. Having such a current list > commented out in the epel-release might work really well for the > user?! > So in my case above, how could we provide an exclusion list that says "pull idm-console-framework and adminutil only from the RH channel unless the system is not subscribed to the RH channel"? > That is a little extra work to help those who want only the "pure" > version of the repo by enabling them to do something to create it and > would let people who don't care about it just go on about their > business as usual. > I think EPEL is extremely useful to have, even if packages like spacewalk, directory server, and cert system are not in it. As a user of EPEL, I find it very useful. As a 389 developer who wants a wider audience, though, I really like being able to use EPEL as a distribution channel for 389 (having had a private yum repo for this for years as the alternative :P. The only other alternative to this is centos-ds, which is not suitable for the purpose of 389 development, which is to get the 389 bits into the hands of as many people as possible, and release early and often. Perhaps we should have a "base" EPEL channel and "layered" channels on top? That way, I could use the base EPEL channel for things like git, etc. If I then wanted to use spacewalk or 389, I could add the epel-spacewalk.repo or epel-389.repo to my yum config and get those channels. By doing so, I would know explicitly that I am doing something that would break the corresponding RH package, rather than getting a nasty surprise. > John > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From opensource at till.name Fri Jan 15 17:00:58 2010 From: opensource at till.name (Till Maas) Date: Fri, 15 Jan 2010 18:00:58 +0100 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> Message-ID: <20100115170058.GF28756@genius.kawo2.rwth-aachen.de> On Thu, Jan 14, 2010 at 09:21:11PM -0700, Stephen John Smoogen wrote: > On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi wrote: > > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: > >> > >> ================ > >> found this by first looking for conflicts in packages and then doing a > >> reverse walk with > >> for i in $( cat file-of-conflicts ?); do repoquery ?--disablerepo="*" > >> --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done > >> > > Wait a minute.... So the first list is conflicts with ?with > > RHEL layered products. ?We're saying, these packages are in our new > > definition of RHEL and thereforewe need to drop them. ?I'm with you so far. > > > > But why the second list? ?If the package is in RHEL, then we need to check > > the second list and see if they can build/work with the version in RHEL, > > right? ?Not outright drop? > > The packages are in channels that are layered onto RHEL and not > available to customers who have not bought those products. Only the > SRPMS are available. Thus building those packages would be impossible > for someone who is trying to build stuff on CentOS or in the build > system. So basically you have to pull them because you can't build > them IF you following the rule as written. On CentOS all of the conflicting packages except these two seem to be available: perl-Network-IPv4Addr python-json I searched for the packages with this query: repoquery --qf "%{name}" --repofrompath centos-core,http://ftp.halifax.rwth-aachen.de/centos/5.4/os/i386/ --repofrompath centos-updates,http://ftp.halifax.rwth-aachen.de/centos/5.4/updates/i386/ $PACKAGE_LIST Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From rayvd at bludgeon.org Fri Jan 15 17:08:24 2010 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 15 Jan 2010 09:08:24 -0800 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <4B5095F1.5060207@redhat.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> <4B5095F1.5060207@redhat.com> Message-ID: <20100115170822.GA3061@bludgeon.org> On Fri, Jan 15, 2010 at 09:21:05AM -0700, Rich Megginson wrote: > >(1) Allow things that come from layered products to be replaced (here > >I am defining layered products as being those from channels not > >associated with AP). > I can think of a specific case that will break something. > > Let's say for example that I am a RHEL customer, and I'm running Red > Hat Directory Server. The packages idm-console-framework-N and > adminutil-N come from that channel. > > Now let's say I set up EPEL on this box for something unrelated to > directory server (e.g. I need to use git). Since 389 is also in > EPEL, there are packages idm-console-framework-M and adminutil-M in > EPEL, where version N < M and version N is not compatible with M. > If I then do a yum update, yum is going to update > idm-console-framework and adminutil to the M versions, breaking my > directory server. This is unacceptable. > > >(2) Try to keep a current list of conflicts so they can be easily > >excluded from the EPEL repo by the user in advance (i.e., at EPEL > >configuration time) and announce new conflicts somewhere so the > >exclude list can be kept up to do more or less to minimize conflicts > >for those who just don't want them. Having such a current list > >commented out in the epel-release might work really well for the > >user?! > > So in my case above, how could we provide an exclusion list that > says "pull idm-console-framework and adminutil only from the RH > channel unless the system is not subscribed to the RH channel"? > Maybe we need an EPEL yum plugin with some smarts to help figure out this sorta stuff. :) (That leaves up2date out on a limb I guess though) The exclude= seems a little hacky and bound to cause problems. > >That is a little extra work to help those who want only the "pure" > >version of the repo by enabling them to do something to create it and > >would let people who don't care about it just go on about their > >business as usual. > I think EPEL is extremely useful to have, even if packages like > spacewalk, directory server, and cert system are not in it. As a > user of EPEL, I find it very useful. > > As a 389 developer who wants a wider audience, though, I really like > being able to use EPEL as a distribution channel for 389 (having had > a private yum repo for this for years as the alternative :P. The > only other alternative to this is centos-ds, which is not suitable > for the purpose of 389 development, which is to get the 389 bits > into the hands of as many people as possible, and release early and > often. > > Perhaps we should have a "base" EPEL channel and "layered" channels > on top? That way, I could use the base EPEL channel for things like > git, etc. If I then wanted to use spacewalk or 389, I could add the > epel-spacewalk.repo or epel-389.repo to my yum config and get those > channels. By doing so, I would know explicitly that I am doing > something that would break the corresponding RH package, rather than > getting a nasty surprise. In the end, this might be the simplest. The sysadmin will just have to know what they're doing and actively choose to include the "layered" channels and exclude the necessary packages. Ray From cmadams at hiwaay.net Fri Jan 15 18:49:27 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 15 Jan 2010 12:49:27 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <4B5095F1.5060207@redhat.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> <4B5095F1.5060207@redhat.com> Message-ID: <20100115184927.GA1055473@hiwaay.net> Once upon a time, Rich Megginson said: > Perhaps we should have a "base" EPEL channel and "layered" channels on > top? The problem with that is that you would need something like: epel-base: packages that don't conflict with any known RH channels epel-not-ds: packages that don't conflict with RH DS channel epel-not-sat: packages that don't conflict with RH Satellite channel ... I don't know how you'd manage that (especially if you had a server subscribed to multiple RH channels). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mastahnke at gmail.com Fri Jan 15 19:29:00 2010 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 15 Jan 2010 13:29:00 -0600 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <20100115184927.GA1055473@hiwaay.net> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> <4B5095F1.5060207@redhat.com> <20100115184927.GA1055473@hiwaay.net> Message-ID: <7874d9dd1001151129t2979121et496d64fc0217c809@mail.gmail.com> > > The problem with that is that you would need something like: > > epel-base: packages that don't conflict with any known RH channels > epel-not-ds: packages that don't conflict with RH DS channel > epel-not-sat: packages that don't conflict with RH Satellite channel > ... The more I think about it, the more I think the root cause of these issues is Red Hat not trying (very hard) to work with EPEL. The steering committee has tried a number of times to get a point person involved in RHEL and other products to act as an interface for EPEL and had only minimal success. I have a few questions for RH in general, and their view of EPEL. 1. When Red Hat decides to pull a package into RHEL or a layered channel, where do they pull the package from? It's been quite obvious they don't pull from EPEL source as they have released versions below what EPEL has in the repo on several occasions. Was there any effort to use the EPEL package, or work with the current maintainer of the package in the EPEL/Fedora space? 2. Does Red Hat want EPEL to have the tools system administrators and developers commonly need? I understand RH offering additional packages for an additional subscription. If a company sees value in a subscription, they will buy it. However, if my company had to buy a channel for puppet, nagios, createrepo, etc, it would not be cost effective to use RHEL at all. 3. Does RH publish what packages they have available in all channels anywhere publicly? That way, EPEL could be slightly more agile in its ability to block/update/manage package changes impacted from RH. At the RH Summit, RH preaches involvement from the community and specifically the Fedora community however, it is a two-way street. EPEL can't just react to every change that Red Hat decides to make and on RHEL and have it work perfectly each time. EPEL tries hard to be the best package repository it can be, because we believe in the RHEL family of products, however we are only on the receiving end. I realize I haven't offered a whole lot of solutions here, but if we had more information it may be easier to come to agreement on one. stahnma From rayvd at bludgeon.org Fri Jan 15 19:37:00 2010 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 15 Jan 2010 11:37:00 -0800 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <7874d9dd1001151129t2979121et496d64fc0217c809@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> <4B5095F1.5060207@redhat.com> <20100115184927.GA1055473@hiwaay.net> <7874d9dd1001151129t2979121et496d64fc0217c809@mail.gmail.com> Message-ID: <20100115193659.GA3462@bludgeon.org> On Fri, Jan 15, 2010 at 01:29:00PM -0600, Michael Stahnke wrote: > > > > The problem with that is that you would need something like: > > > > epel-base: packages that don't conflict with any known RH channels > > epel-not-ds: packages that don't conflict with RH DS channel > > epel-not-sat: packages that don't conflict with RH Satellite channel > > ... > > The more I think about it, the more I think the root cause of these > issues is Red Hat not trying (very hard) to work with EPEL. The > steering committee has tried a number of times to get a point person > involved in RHEL and other products to act as an interface for EPEL > and had only minimal success. I have a few questions for RH in > general, and their view of EPEL. > > 1. When Red Hat decides to pull a package into RHEL or a layered > channel, where do they pull the package from? It's been quite obvious > they don't pull from EPEL source as they have released versions below > what EPEL has in the repo on several occasions. Was there any effort > to use the EPEL package, or work with the current maintainer of the > package in the EPEL/Fedora space? > > 2. Does Red Hat want EPEL to have the tools system administrators and > developers commonly need? I understand RH offering additional > packages for an additional subscription. If a company sees value in a > subscription, they will buy it. However, if my company had to buy a > channel for puppet, nagios, createrepo, etc, it would not be cost > effective to use RHEL at all. > > 3. Does RH publish what packages they have available in all channels > anywhere publicly? That way, EPEL could be slightly more agile in its > ability to block/update/manage package changes impacted from RH. > > At the RH Summit, RH preaches involvement from the community and > specifically the Fedora community however, it is a two-way street. > EPEL can't just react to every change that Red Hat decides to make and > on RHEL and have it work perfectly each time. EPEL tries hard to be > the best package repository it can be, because we believe in the RHEL > family of products, however we are only on the receiving end. > > I realize I haven't offered a whole lot of solutions here, but if we > had more information it may be easier to come to agreement on one. > > stahnma Assuming we can realistically expect answers to the above from RH in a reasonable amount of time, I'd say getting these points addressed would be a blocker on this entire problem. No sense in beginning to implement technical solutions for a moving target... Ray From smooge at gmail.com Fri Jan 15 20:41:08 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 15 Jan 2010 13:41:08 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <7874d9dd1001151129t2979121et496d64fc0217c809@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <7874d9dd1001141940h5d41c898v251aa0c86ab20f53@mail.gmail.com> <20100115035500.GA32571@bludgeon.org> <4B5095F1.5060207@redhat.com> <20100115184927.GA1055473@hiwaay.net> <7874d9dd1001151129t2979121et496d64fc0217c809@mail.gmail.com> Message-ID: <80d7e4091001151241r1527cc4asa5ec3742bb02256f@mail.gmail.com> On Fri, Jan 15, 2010 at 12:29 PM, Michael Stahnke wrote: >> >> The problem with that is that you would need something like: >> >> epel-base: packages that don't conflict with any known RH channels >> epel-not-ds: packages that don't conflict with RH DS channel >> epel-not-sat: packages that don't conflict with RH Satellite channel >> ... > > The more I think about it, the more I think the root cause of these > issues is Red Hat not trying (very hard) to work with EPEL. ?The > steering committee has tried a number of times to get a point person > involved in RHEL and other products to act as an interface for EPEL > and had only minimal success. ?I have a few questions for RH in > general, and their view of EPEL. > > 1. ?When Red Hat decides to pull a package into RHEL or a layered > channel, where do they pull the package from? It's been quite obvious > they don't pull from EPEL source as they have released versions below > what EPEL has in the repo on several occasions. Was there any effort > to use the EPEL package, or work with the current maintainer of the > package in the EPEL/Fedora space? Ok the first issue is a common one that people have when dealing with a group.. expecting the group to have one policy that everyone will follow etc. For the purposes of this discussion, there is no 'Red Hat' deciding things... there are a couple hundred developers deciding things as best they can at some particular moment.. Some will pull something out of Fedora, some will package it up (either because they don't think to look in EPEL or Fedora or what was there didn't meet what they wanted.) The second issue is that EPEL moves forward faster than RH products do. A package may be pulled out of EPEL but when it finally comes out its been 3-6 months and whats in EPEL has moved on. Or the developer will stick in stuff into EPEL that people don't want because its too new (cobbler development was this way). > 2. ?Does Red Hat want EPEL to have the tools system administrators and > developers commonly need? ?I understand RH offering additional > packages for an additional subscription. ?If a company sees value in a > subscription, they will buy it. ?However, if my company had to buy a > channel for puppet, nagios, createrepo, etc, it would not be cost > effective to use RHEL at all. This question can't be answered due to the fact that there is no one Red Hat policy/group. Red Hat would need to be an ultra fascist organization where everyone gets a brain implant that the Black Committee would toggle to say "We all do this". Red Hat is too much a free-form meritocracy where you have 400 developers saying 800 things, 100 marketing people saying 1000 other things, and half a dozen VP's coming up with even more things, and 1500+ support people having to deal with all the permutations that come from what development, marketing, sales, etc have put out. It is much better to deal with it like you deal with the kernel. We can ask Linus for general things... but in the end getting him to say that all developers will do this and this is not going to happen. [It is one of those things that people coming into the company seem to have to learn over and over again.. they can raise the staff of Aaron over their head as many times as they want... the water will part when it damn well pleases.] > 3. ?Does RH publish what packages they have available in all channels > anywhere publicly? ?That way, EPEL could be slightly more agile in its > ability to block/update/manage package changes impacted from RH. I don't think so as most of the channels are run by separate groups. Most have their own sub-cultures and release structures. I will say that seeing what was in ftp.redhat.com seemed a vast improvement over the years. > At the RH Summit, RH preaches involvement from the community and > specifically the Fedora community however, it is a two-way street. > EPEL can't just react to every change that Red Hat decides to make and > on RHEL and have it work perfectly each time. ?EPEL tries hard to be > the best package repository it can be, because we believe in the RHEL > family of products, however we are only on the receiving end. > > I realize I haven't offered a whole lot of solutions here, but if we > had more information it may be easier to come to agreement on one. > > stahnma > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From kevin at tummy.com Fri Jan 15 22:34:00 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 15 Jan 2010 15:34:00 -0700 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100114151615.5de7f2ed@ohm.scrye.com> References: <20100114151615.5de7f2ed@ohm.scrye.com> Message-ID: <20100115153400.33ffd4ba@ohm.scrye.com> http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/epel.2010-01-15-21.00.html http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/epel.2010-01-15-21.00.log.html http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/epel.2010-01-15-21.00.log.txt http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/epel.2010-01-15-21.00.txt Meeting started by nirik at 21:00:17 UTC (full logs). Meeting summary Init process (nirik, 21:00:30) Status update on action items (nirik, 21:03:39) Moin - Any takers? (nirik, 21:07:20) EPEL swimming in the RHEL channels (nirik, 21:23:24) ACTION: smooge will generate a list of packages that are not following our new current policy. (nirik, 22:03:43) ACTION: dgilmore or nirik will block them. (nirik, 22:04:12) Open Floor (nirik, 22:06:01) Meeting ended at 22:16:12 UTC (full logs). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From opensource at till.name Sat Jan 16 11:07:35 2010 From: opensource at till.name (Till Maas) Date: Sat, 16 Jan 2010 12:07:35 +0100 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100115153400.33ffd4ba@ohm.scrye.com> References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> Message-ID: <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> Hiyas, On Fri, Jan 15, 2010 at 03:34:00PM -0700, Kevin Fenzi wrote: > EPEL swimming in the RHEL channels (nirik, 21:23:24) > ACTION: smooge will generate a list of packages that are not following our new current policy. (nirik, 22:03:43) > ACTION: dgilmore or nirik will block them. (nirik, 22:04:12) is there now a new policy or will the currenty policy stay ? And what does the policy say? Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kevin at tummy.com Sat Jan 16 19:52:13 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Sat, 16 Jan 2010 12:52:13 -0700 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> Message-ID: <20100116125213.4d61ef61@ohm.scrye.com> On Sat, 16 Jan 2010 12:07:35 +0100 Till Maas wrote: > Hiyas, > > On Fri, Jan 15, 2010 at 03:34:00PM -0700, Kevin Fenzi wrote: > > > EPEL swimming in the RHEL channels (nirik, 21:23:24) > > ACTION: smooge will generate a list of packages that are not > > following our new current policy. (nirik, 22:03:43) ACTION: > > dgilmore or nirik will block them. (nirik, 22:04:12) > > is there now a new policy or will the currenty policy stay ? And what > does the policy say? Sorry, we should have spelled that out in the summary. EPEL packages must never conflict with packages in RHEL-AP. EPEL packages can conflict with packages in other RHEL channels. EPEL maintainers should be open to communication from RHEL maintainers and try and accommodate them by not shipping specific packages, or by adjusting the package in EPEL to better handle a conflicting package in a channel on a case by case basis. At least I think thats what we all agreed to? Comments/clarifications/etc? We need to word this up nicer, update the wiki, and send an email to the announce list. Anyone want to help with any of those parts? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Jan 16 23:46:52 2010 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 16 Jan 2010 17:46:52 -0600 (CST) Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100116125213.4d61ef61@ohm.scrye.com> References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> <20100116125213.4d61ef61@ohm.scrye.com> Message-ID: On Sat, 16 Jan 2010, Kevin Fenzi wrote: > On Sat, 16 Jan 2010 12:07:35 +0100 > Till Maas wrote: > > > Hiyas, > > > > On Fri, Jan 15, 2010 at 03:34:00PM -0700, Kevin Fenzi wrote: > > > > > EPEL swimming in the RHEL channels (nirik, 21:23:24) > > > ACTION: smooge will generate a list of packages that are not > > > following our new current policy. (nirik, 22:03:43) ACTION: > > > dgilmore or nirik will block them. (nirik, 22:04:12) > > > > is there now a new policy or will the currenty policy stay ? And what > > does the policy say? > > Sorry, we should have spelled that out in the summary. > > EPEL packages must never conflict with packages in RHEL-AP. > EPEL packages can conflict with packages in other RHEL channels. > EPEL maintainers should be open to communication from RHEL maintainers > and try and accommodate them by not shipping specific packages, or by > adjusting the package in EPEL to better handle a conflicting package in > a channel on a case by case basis. > > At least I think thats what we all agreed to? > Comments/clarifications/etc? > > We need to word this up nicer, update the wiki, and send an email to > the announce list. Anyone want to help with any of those parts? > I know I should know what AP stands for but... what does AP stand for in RHEL-AP? -Mike From rayvd at bludgeon.org Sun Jan 17 00:03:22 2010 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Sat, 16 Jan 2010 16:03:22 -0800 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> <20100116125213.4d61ef61@ohm.scrye.com> Message-ID: <20100117000321.GA15417@bludgeon.org> On Sat, Jan 16, 2010 at 05:46:52PM -0600, Mike McGrath wrote: > On Sat, 16 Jan 2010, Kevin Fenzi wrote: > > > On Sat, 16 Jan 2010 12:07:35 +0100 > > Till Maas wrote: > > > > > Hiyas, > > > > > > On Fri, Jan 15, 2010 at 03:34:00PM -0700, Kevin Fenzi wrote: > > > > > > > EPEL swimming in the RHEL channels (nirik, 21:23:24) > > > > ACTION: smooge will generate a list of packages that are not > > > > following our new current policy. (nirik, 22:03:43) ACTION: > > > > dgilmore or nirik will block them. (nirik, 22:04:12) > > > > > > is there now a new policy or will the currenty policy stay ? And what > > > does the policy say? > > > > Sorry, we should have spelled that out in the summary. > > > > EPEL packages must never conflict with packages in RHEL-AP. > > EPEL packages can conflict with packages in other RHEL channels. > > EPEL maintainers should be open to communication from RHEL maintainers > > and try and accommodate them by not shipping specific packages, or by > > adjusting the package in EPEL to better handle a conflicting package in > > a channel on a case by case basis. > > > > At least I think thats what we all agreed to? > > Comments/clarifications/etc? > > > > We need to word this up nicer, update the wiki, and send an email to > > the announce list. Anyone want to help with any of those parts? > > > > I know I should know what AP stands for but... what does AP stand for in > RHEL-AP? > Advanced Platform? (Assuming this means including the Clustering channels and such) Ray From opensource at till.name Sun Jan 17 08:10:23 2010 From: opensource at till.name (Till Maas) Date: Sun, 17 Jan 2010 09:10:23 +0100 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100116125213.4d61ef61@ohm.scrye.com> References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> <20100116125213.4d61ef61@ohm.scrye.com> Message-ID: <20100117081023.GC18314@genius.kawo2.rwth-aachen.de> On Sat, Jan 16, 2010 at 12:52:13PM -0700, Kevin Fenzi wrote: > On Sat, 16 Jan 2010 12:07:35 +0100 > Till Maas wrote: > > > Hiyas, > > > > On Fri, Jan 15, 2010 at 03:34:00PM -0700, Kevin Fenzi wrote: > > > > > EPEL swimming in the RHEL channels (nirik, 21:23:24) > > > ACTION: smooge will generate a list of packages that are not > > > following our new current policy. (nirik, 22:03:43) ACTION: > > > dgilmore or nirik will block them. (nirik, 22:04:12) > > > > is there now a new policy or will the currenty policy stay ? And what > > does the policy say? > > Sorry, we should have spelled that out in the summary. > > EPEL packages must never conflict with packages in RHEL-AP. > EPEL packages can conflict with packages in other RHEL channels. > EPEL maintainers should be open to communication from RHEL maintainers > and try and accommodate them by not shipping specific packages, or by > adjusting the package in EPEL to better handle a conflicting package in > a channel on a case by case basis. > > At least I think thats what we all agreed to? > Comments/clarifications/etc? Please explain from which repos RHEL-AP is composed for both RHEL 4 and 5. Maybe I am really the only maintaining packages in EPEL, but I do only know kind of how CentoOS works and is splitted in Repositories. But they use RHEL AS afaics, so their package set already seems to differ. Also the mock config should probably be configured to use only the packages from CentOS that are supposed to exist in BuildRoots for EPEL. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From opensource at till.name Sun Jan 17 08:23:03 2010 From: opensource at till.name (Till Maas) Date: Sun, 17 Jan 2010 09:23:03 +0100 Subject: RFE: add buildsys-build to comps, add buildsys macros to epel-release In-Reply-To: <200906040954.12129.opensource@till.name> References: <200905261408.17072.opensource@till.name> <200906022138.59564.till.maas@till.name> <200906030727.10274.dennis@ausil.us> <200906040954.12129.opensource@till.name> Message-ID: <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> On Thu, Jun 04, 2009 at 09:53:55AM +0200, Till Maas wrote: > On Wed June 3 2009, Dennis Gilmore wrote: > > On Tuesday 02 June 2009 02:38:53 pm Till Maas wrote: > > > On Monday 01 June 2009 15:49:20 Jeff Sheltren wrote: > > > > On May 26, 2009, at 5:08 AM, Till Maas wrote: > > > > There is one: > > > http://cvs.fedoraproject.org/viewvc/comps/comps-el5.xml.in?view=log > > > I just created the buildsys-build group from the contents of the > > > buildsys- build package I have. Btw. who maintains the package list for > > > EPEL? I noticed it differs from the F11 one. > > > > It is maintainer managed the same as fedora. if no one updates it that it > > doesnt get updated. if you want you packages listed its up to you to add > > them. > > I meant the package list of the minimum build root. For the Fedora Collection > afaik rel-eng maintains it. Somebody is probably doing the same for EPEL. > > > > > > 2) Add the rpm macros from > > > > > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- > > > > > macros-5-4.el5.noarch.rpm > > > > im honestly not sure if we should add the macros to epel-release it would > > mean then that you must have epel enabled in your mock config to build for > > EL-4 and EL-5. it would also mean that we need to have mock updated for all > > active releases with new epel configs since the existing configs would be > > broken. which would need to be tightly controlled. since epel-testing or > > epel building would be broken during the stages of transition. mock could > > be useful for people building things for rhel but not epel. if Red Hat > > decides to add them to redhat-release or centos adds them to centos-release > > we will end up with conflicts (im not aware of any plans to add them but im > > not really in the know) however it is really the right place for them. > > though we could possibly get away with making the comps group require > > epel-release and not buildsys-macros. > > I already made the comps group require epel-release and not buildsys-macros. > Also there is no need to remove the groups repo at the specified URL, > therefore nothing should break during the transisiton and also old configs > will still work. We can first update epel-release and once it is in stable > update the mock config files. The problem with conflicts between EPEL and > future releases of RHEL exists with every package in EPEL, therefore it is not > a big problem. I just verified that at least the buildsys-build group is not synced to mirrors. Can we somehow move forward on this? If adding the rpm macros to epel-release is really a problem, can we move the package to a proper EPEL repository instead? When I proposed this long a ago for the Fedora packages, it was not done, because they went away eventually. So if nobody complains, I will just create a new package to get this done. But it would be really nice if this could be managed by the people maintaining these packages, to keep them in sync. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From opensource at till.name Sun Jan 17 08:39:59 2010 From: opensource at till.name (Till Maas) Date: Sun, 17 Jan 2010 09:39:59 +0100 Subject: RFE: add buildsys-build to comps, add buildsys macros to epel-release In-Reply-To: <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> References: <200905261408.17072.opensource@till.name> <200906022138.59564.till.maas@till.name> <200906030727.10274.dennis@ausil.us> <200906040954.12129.opensource@till.name> <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> Message-ID: <20100117083959.GE18314@genius.kawo2.rwth-aachen.de> On Sun, Jan 17, 2010 at 09:23:03AM +0100, Till Maas wrote: > I just verified that at least the buildsys-build group is not synced to Sorry for the confusion, the buildsys-build group is synced, but still progress needs to be made. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From laxathom at fedoraproject.org Sun Jan 17 13:19:14 2010 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sun, 17 Jan 2010 14:19:14 +0100 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100117000321.GA15417@bludgeon.org> References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> <20100116125213.4d61ef61@ohm.scrye.com> <20100117000321.GA15417@bludgeon.org> Message-ID: <62bc09df1001170519r7711809cp90da195eb527a452@mail.gmail.com> On Sun, Jan 17, 2010 at 1:03 AM, Ray Van Dolson wrote: > On Sat, Jan 16, 2010 at 05:46:52PM -0600, Mike McGrath wrote: >> On Sat, 16 Jan 2010, Kevin Fenzi wrote: >> >> > On Sat, 16 Jan 2010 12:07:35 +0100 >> > Till Maas wrote: >> > >> > > Hiyas, >> > > >> > > On Fri, Jan 15, 2010 at 03:34:00PM -0700, Kevin Fenzi wrote: >> > > >> > > > EPEL swimming in the RHEL channels (nirik, 21:23:24) >> > > > ACTION: smooge will generate a list of packages that are not >> > > > following our new current policy. (nirik, 22:03:43) ACTION: >> > > > dgilmore or nirik will block them. (nirik, 22:04:12) >> > > >> > > is there now a new policy or will the currenty policy stay ? And what >> > > does the policy say? >> > >> > Sorry, we should have spelled that out in the summary. >> > >> > EPEL packages must never conflict with packages in RHEL-AP. >> > EPEL packages can conflict with packages in other RHEL channels. >> > EPEL maintainers should be open to communication from RHEL maintainers >> > and try and accommodate them by not shipping specific packages, or by >> > adjusting the package in EPEL to better handle a conflicting package in >> > a channel on a case by case basis. >> > >> > At least I think thats what we all agreed to? >> > Comments/clarifications/etc? >> > >> > We need to word this up nicer, update the wiki, and send an email to >> > the announce list. Anyone want to help with any of those parts? >> > >> >> I know I should know what AP stands for but... what does AP stand for in >> RHEL-AP? >> > > Advanced Platform? ?(Assuming this means including the Clustering > channels and such) > Correct. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From djuran at redhat.com Mon Jan 18 07:41:39 2010 From: djuran at redhat.com (David Juran) Date: Mon, 18 Jan 2010 09:41:39 +0200 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <1263542765.3804.22.camel@localhost.localdomain> Message-ID: <1263800499.3804.47.camel@localhost.localdomain> On Fri, 2010-01-15 at 08:20 -0600, Adam Miller wrote: > On Fri, Jan 15, 2010 at 2:06 AM, David Juran wrote: > > On Thu, 2010-01-14 at 21:21 -0700, Stephen John Smoogen wrote: > >> On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi wrote: > >> > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote: > > > > I think we've been through this before, but if EPEL would ship the same > > version that Red Hat does of the layered products then there wouldn't be > > any conflict for those who have the layered product and the one's who do > > have the layered product can still enjoy the package. Or am I missing > > something here? > > > > It would conflict because you have essentially the same package, same > version, same release, etc. but from two different sources. Sorry, what I meant was that the release number should be lower in EPEL. I.e. the EPEL package would be identical to the RHEL one except that the release number would be lower. -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- 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 jonstanley at gmail.com Mon Jan 18 07:52:50 2010 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 18 Jan 2010 02:52:50 -0500 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <1263800499.3804.47.camel@localhost.localdomain> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <1263542765.3804.22.camel@localhost.localdomain> <1263800499.3804.47.camel@localhost.localdomain> Message-ID: On Mon, Jan 18, 2010 at 2:41 AM, David Juran wrote: > Sorry, what I meant was that the release number should be lower in EPEL. > I.e. the EPEL package would be identical to the RHEL one except that the > release number would be lower. Generally with a package like 389 or something, you'll have a NEWER version in EPEL than what is in the layered product channel, as EPEL carries the upstream source. not the released source of the RH product - therefore, unless development is stagnant (which one certainly hopes is not the case), then the version in EPEL is necessarily going to be newer than that in the respective RHN channel. Am I missing something incredibly obvious here? From djuran at redhat.com Mon Jan 18 08:24:16 2010 From: djuran at redhat.com (David Juran) Date: Mon, 18 Jan 2010 10:24:16 +0200 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <1263542765.3804.22.camel@localhost.localdomain> <1263800499.3804.47.camel@localhost.localdomain> Message-ID: <1263803056.3804.70.camel@localhost.localdomain> On Mon, 2010-01-18 at 02:52 -0500, Jon Stanley wrote: > On Mon, Jan 18, 2010 at 2:41 AM, David Juran wrote: > > > Sorry, what I meant was that the release number should be lower in EPEL. > > I.e. the EPEL package would be identical to the RHEL one except that the > > release number would be lower. > > Generally with a package like 389 or something, you'll have a NEWER > version in EPEL than what is in the layered product channel, as EPEL > carries the upstream source. not the released source of the RH product > - therefore, unless development is stagnant (which one certainly hopes > is not the case), then the version in EPEL is necessarily going to be > newer than that in the respective RHN channel. > > Am I missing something incredibly obvious here? Maybe the point is moot now after Friday's meeting (which I didn't attend due to real-life interference) but this really raises the question, what is the purpose of EPEL? *) Is it to provide cutting edge versions of layered products on top of RHEL? Isn't running plain Fedora a better choice then? Of course I see the point in getting more people to test e.g. the latest greatest 389 version. But is that really the primary mission for EPEL? And maybe it still can be done by creating e.g. a 389-ds package (under the name 389-ds and taking care of file system conflicts) that doesn't conflict with redhat-ds. *) Is it to provide layered products to those not willing to pay for Red Hat support? Isn't that the mission of CentOS? *) Is it to provide Extra Packages for Enterprise Linux (-: I.e. a set of packages that for various reasons are not included in RHEL but are in Fedora. That does not really imply that the version of that extra package should be the latest end greatest version. In my opinion, the package version in EPEL should mirror the stable policy of RHEL by preferring stability over cutting-edge. -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- 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 Mon Jan 18 12:03:18 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 18 Jan 2010 05:03:18 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <1263803056.3804.70.camel@localhost.localdomain> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <1263542765.3804.22.camel@localhost.localdomain> <1263800499.3804.47.camel@localhost.localdomain> <1263803056.3804.70.camel@localhost.localdomain> Message-ID: <80d7e4091001180403u769102f7wdf82e0ae75a3e171@mail.gmail.com> On Mon, Jan 18, 2010 at 1:24 AM, David Juran wrote: > On Mon, 2010-01-18 at 02:52 -0500, Jon Stanley wrote: >> On Mon, Jan 18, 2010 at 2:41 AM, David Juran wrote: >> >> > Sorry, what I meant was that the release number should be lower in EPEL. >> > I.e. the EPEL package would be identical to the RHEL one except that the >> > release number would be lower. >> >> Generally with a package like 389 or something, you'll have a NEWER >> version in EPEL than what is in the layered product channel, as EPEL >> carries the upstream source. not the released source of the RH product >> - therefore, unless development is stagnant (which one certainly hopes >> is not the case), then the version in EPEL is necessarily going to be >> newer than that in the respective RHN channel. >> >> Am I missing something incredibly obvious here? > > Maybe the point is moot now after Friday's meeting (which I didn't > attend due to real-life interference) but this really raises the > question, what is the purpose of EPEL? > > *) Is it to provide cutting edge versions of layered products on top of > RHEL? Isn't running plain Fedora a better choice then? Of course I see > the point in getting more people to test e.g. the latest greatest 389 > version. But is that really the primary mission for EPEL? And maybe it > still can be done by creating e.g. a 389-ds package (under the name > 389-ds and taking care of file system conflicts) that doesn't conflict > with redhat-ds. For many of the people who want to run/test Red Hat projects (cobbler, satellite, ds) to test where the product is going Fedora makes NO sense for them. They aren't looking to update daily to keep up with fixes, their internal methodologies may require the base OS to go through various tests which means the Fedora OS is nearly EOL before they can use it, etc. Testing the products on what they deploy in production is what they want to do. [I have worked in 3 different places where I had to do this.. and before EPEL I would have to take the Fedora stuff, recompile on RHEL and then test/debug what didn't work.] > *) Is it to provide layered products to those not willing to pay for Red > Hat support? Isn't that the mission of CentOS? That is NOT what we are doing. If we were doing that we would be taking the src.rpms from the channel and rebuilding them... (eg centos-ds etc). What for the 389, cobbler, etc groups is a channel where they can reach the people they are developing the product for and give them the ability to give feedback. > *) Is it to provide Extra Packages for Enterprise Linux (-: > ?I.e. a set of packages that for various reasons are not included in > RHEL but are in Fedora. That does not really imply that the version of > that extra package should be the latest end greatest version. In my > opinion, the package version in EPEL should mirror the stable policy of > RHEL by preferring stability over cutting-edge. > Well it might have been that but it would require more co-operation from Red Hat to do that than I think is possible. By the time we find out puppet, nagios, etc are in a RH subproduct the EPEL have already been moved forward to meet bugs etc. Moving the packages back to -1 release means: 1) People who got a newer version of puppet,nagios, etc earlier will not see any updates and their version may still break the RHN product if they installed it. 2) People who do install the older version of puppet, nagios etc will not see any upstream bugfixes because RH nor EPEL would update regularly (looking at the updates to those subpackages in the channel). 3) Removing, deprecating the packages on the list would hamstring enough people that we might as well close shop. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From kevin at tummy.com Mon Jan 18 17:32:07 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 18 Jan 2010 10:32:07 -0700 Subject: RFE: add buildsys-build to comps, add buildsys macros to epel-release In-Reply-To: <20100117083959.GE18314@genius.kawo2.rwth-aachen.de> References: <200905261408.17072.opensource@till.name> <200906022138.59564.till.maas@till.name> <200906030727.10274.dennis@ausil.us> <200906040954.12129.opensource@till.name> <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> <20100117083959.GE18314@genius.kawo2.rwth-aachen.de> Message-ID: <20100118103207.6fd317c8@ohm.scrye.com> On Sun, 17 Jan 2010 09:39:59 +0100 Till Maas wrote: > On Sun, Jan 17, 2010 at 09:23:03AM +0100, Till Maas wrote: > > > I just verified that at least the buildsys-build group is not > > synced to > > Sorry for the confusion, the buildsys-build group is synced, but still > progress needs to be made. So, what is left here? Adding macros to epel-release? Whats the advantage of doing things that way again? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at tummy.com Mon Jan 18 17:39:16 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 18 Jan 2010 10:39:16 -0700 Subject: Summary/Minutes from todays EPEL meeting - 2010-01-15 In-Reply-To: <20100117081023.GC18314@genius.kawo2.rwth-aachen.de> References: <20100114151615.5de7f2ed@ohm.scrye.com> <20100115153400.33ffd4ba@ohm.scrye.com> <20100116110735.GD12510@genius.kawo2.rwth-aachen.de> <20100116125213.4d61ef61@ohm.scrye.com> <20100117081023.GC18314@genius.kawo2.rwth-aachen.de> Message-ID: <20100118103916.26bd6130@ohm.scrye.com> On Sun, 17 Jan 2010 09:10:23 +0100 Till Maas wrote: > Please explain from which repos RHEL-AP is composed for both RHEL 4 > and 5. Maybe I am really the only maintaining packages in EPEL, but I > do only know kind of how CentoOS works and is splitted in > Repositories. But they use RHEL AS afaics, so their package set > already seems to differ. I'm not 100% sure here now that I think about it. (I am also mainly a centos user). I think this is everything thats produced from: (for 5): /pub/ftp.redhat.com/redhat/linux/enterprise/5Client /pub/ftp.redhat.com/redhat/linux/enterprise/5Server/en/os/ (for 4): /pub/ftp.redhat.com/redhat/linux/enterprise/4/en/os Can someone with more understanding of RHEL channels confirm that? > Also the mock config should probably be configured to use only the > packages from CentOS that are supposed to exist in BuildRoots for > EPEL. I think thats the case, as CentOS base uses this same set. (At least that was my understanding). kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From opensource at till.name Mon Jan 18 18:59:20 2010 From: opensource at till.name (Till Maas) Date: Mon, 18 Jan 2010 19:59:20 +0100 Subject: RFE: add buildsys-build to comps, add buildsys macros to epel-release In-Reply-To: <20100118103207.6fd317c8@ohm.scrye.com> References: <200905261408.17072.opensource@till.name> <200906022138.59564.till.maas@till.name> <200906030727.10274.dennis@ausil.us> <200906040954.12129.opensource@till.name> <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> <20100117083959.GE18314@genius.kawo2.rwth-aachen.de> <20100118103207.6fd317c8@ohm.scrye.com> Message-ID: <20100118185920.GG14135@genius.kawo2.rwth-aachen.de> On Mon, Jan 18, 2010 at 10:32:07AM -0700, Kevin Fenzi wrote: > On Sun, 17 Jan 2010 09:39:59 +0100 > Till Maas wrote: > > > On Sun, Jan 17, 2010 at 09:23:03AM +0100, Till Maas wrote: > > > > > I just verified that at least the buildsys-build group is not > > > synced to > > > > Sorry for the confusion, the buildsys-build group is synced, but still > > progress needs to be made. > > So, what is left here? Adding macros to epel-release? Yes, or some other package in EPEL. > Whats the advantage of doing things that way again? The mock config can be changed to not use this repo that only provides unsigned RPMs: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ Then one can a lot easier enable gpgcheck in the mock config. Currently it involves downloading and auditing the rpms in above repo and mirror it locally. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kevin at tummy.com Mon Jan 18 19:35:43 2010 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 18 Jan 2010 12:35:43 -0700 Subject: RFE: add buildsys-build to comps, add buildsys macros to epel-release In-Reply-To: <20100118185920.GG14135@genius.kawo2.rwth-aachen.de> References: <200905261408.17072.opensource@till.name> <200906022138.59564.till.maas@till.name> <200906030727.10274.dennis@ausil.us> <200906040954.12129.opensource@till.name> <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> <20100117083959.GE18314@genius.kawo2.rwth-aachen.de> <20100118103207.6fd317c8@ohm.scrye.com> <20100118185920.GG14135@genius.kawo2.rwth-aachen.de> Message-ID: <20100118123543.450828b7@ohm.scrye.com> On Mon, 18 Jan 2010 19:59:20 +0100 Till Maas wrote: > > The mock config can be changed to not use this repo that only provides > unsigned RPMs: > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ > > Then one can a lot easier enable gpgcheck in the mock config. > Currently it involves downloading and auditing the rpms in above repo > and mirror it locally. Perhaps we could just sign those packages? (Possibly with a different key)? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From chrismcc at pricegrabber.com Mon Jan 18 19:59:50 2010 From: chrismcc at pricegrabber.com (Christopher) Date: Mon, 18 Jan 2010 11:59:50 -0800 Subject: technical solution/workaround for EPEL vs. RH sub channel Message-ID: <1263844790.2307.29.camel@localhost> Hello... What about the following idea as a solution to RH vs. EPEL conflicting packages? Extend yum either in the core code or as a plugin to allow exclude=@group. Then the EPEL repo could contain groups @rh-sub-channel-foo, etc. with EPEL packages that conflict. That would allow the sysadmin to selectively exclude packages for RH sub projects they get via RHN. Even if there are technical problems with RHEL4 or RHEL5, this approach could still work with RHEL6. yes? no? maybe? The epel.repo file could contain something like: # repo file for epel # If you wish to avoid conflicting with a RedHat channel you subscribe # to, you can use exclude="@rh-group-foo". # get get the list of groups group run # yum grouplist --disablerepo='*' --enablerepo=epel # or see http://some.url/EPEL # # warning subscribing to RH sub channels and EPEL without checking for # package conflicts may kill kittens. [epel] name=Extra Packages for Enterprise Linux 5 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch= $basearch failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL # exclude="@rh-group foo" -- Christopher McCrory "The guy that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works. From opensource at till.name Mon Jan 18 20:05:49 2010 From: opensource at till.name (Till Maas) Date: Mon, 18 Jan 2010 21:05:49 +0100 Subject: RFE: add buildsys-build to comps, add buildsys macros to epel-release In-Reply-To: <20100118123543.450828b7@ohm.scrye.com> References: <200905261408.17072.opensource@till.name> <200906022138.59564.till.maas@till.name> <200906030727.10274.dennis@ausil.us> <200906040954.12129.opensource@till.name> <20100117082302.GD18314@genius.kawo2.rwth-aachen.de> <20100117083959.GE18314@genius.kawo2.rwth-aachen.de> <20100118103207.6fd317c8@ohm.scrye.com> <20100118185920.GG14135@genius.kawo2.rwth-aachen.de> <20100118123543.450828b7@ohm.scrye.com> Message-ID: <20100118200549.GJ14135@genius.kawo2.rwth-aachen.de> On Mon, Jan 18, 2010 at 12:35:43PM -0700, Kevin Fenzi wrote: > On Mon, 18 Jan 2010 19:59:20 +0100 > Till Maas wrote: > > > > The mock config can be changed to not use this repo that only provides > > unsigned RPMs: > > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ > > > > Then one can a lot easier enable gpgcheck in the mock config. > > Currently it involves downloading and auditing the rpms in above repo > > and mirror it locally. > > Perhaps we could just sign those packages? > (Possibly with a different key)? I don't think that it would be easier, but if it is done, then please with the same key to kind of ensure that it is stored carefully. Here is btw the discussion from 2007 about the same issue but for Fedora: http://lists.fedoraproject.org/pipermail/devel/2007-June/104640.html Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From smooge at gmail.com Mon Jan 18 20:14:51 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 18 Jan 2010 13:14:51 -0700 Subject: technical solution/workaround for EPEL vs. RH sub channel In-Reply-To: <1263844790.2307.29.camel@localhost> References: <1263844790.2307.29.camel@localhost> Message-ID: <80d7e4091001181214u22409850t5a47c298feddfdd@mail.gmail.com> On Mon, Jan 18, 2010 at 12:59 PM, Christopher wrote: > Hello... > > ?What about the following idea as a solution to RH vs. EPEL conflicting > packages? ?Extend yum either in the core code or as a plugin to allow > exclude=@group. ?Then the EPEL repo could contain groups > @rh-sub-channel-foo, etc. with EPEL packages that conflict. ?That would > allow the sysadmin to selectively exclude packages for RH sub projects > they get via RHN. ?Even if there are technical problems with RHEL4 or > RHEL5, this approach could still work with RHEL6. > > yes? no? maybe? > I think this has been bandied about, and it does look good as a long term solution.. however it seems that it isn't simple below the surface. 1) The interaction of the yum RHN plugin seems to override other plugins for some people. This possibly means we need to have Red Hat fix its yum and plugin to work with this... 2) This would only solve it for EL-5... EL6 might work but may need changes also.. and EL-4 would need a complete different solution. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From updates at fedoraproject.org Mon Jan 18 23:24:25 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Mon, 18 Jan 2010 23:24:25 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100118232623.AED6E10F8C5@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing augeas-0.7.0-1.el4 plpa-1.3.2-4.el4 python-IPy-0.70-1.el4 Details about builds: ================================================================================ augeas-0.7.0-1.el4 (FEDORA-EPEL-2010-0075) A library for changing configuration files -------------------------------------------------------------------------------- Update Information: See http://augeas.net/news.html for details -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 14 2010 David Lutterkort - 0.7.0-1 - Remove patch vim-ftdetect-syntax.patch. It's upstream -------------------------------------------------------------------------------- ================================================================================ plpa-1.3.2-4.el4 (FEDORA-EPEL-2010-0066) Portable Linux Processor Affinity -------------------------------------------------------------------------------- Update Information: First PLPA packge for EPEL4. -------------------------------------------------------------------------------- References: [ 1 ] Bug #530230 - Review Request: plpa - Portable Linux Processor Affinity https://bugzilla.redhat.com/show_bug.cgi?id=530230 -------------------------------------------------------------------------------- ================================================================================ python-IPy-0.70-1.el4 (FEDORA-EPEL-2010-0080) Python module for handling IPv4 and IPv6 Addresses and Networks -------------------------------------------------------------------------------- Update Information: New "major" version because it may break compatibility * Fix __cmp__(): IP('0.0.0.0/0') and IP('0.0.0.0') are not equal * Fix IP.net() of the network "::/0": "::" instead of "0.0.0.0". IPy 0.63 should fix this bug, but it wasn't. -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 10 2010 Matt Domsch - 0.70-1 - Version 0.70 (2009-10-29) * New "major" version because it may break compatibility * Fix __cmp__(): IP('0.0.0.0/0') and IP('0.0.0.0') are not equal * Fix IP.net() of the network "::/0": "::" instead of "0.0.0.0". IPy 0.63 should fix this bug, but it wasn't. * Sun Aug 30 2009 Matt Domsch - 0.63-1 - Fix formatting of "IPv4 in IPv6" network: IP('::ffff:192.168.10.0/120') * Sun Jul 26 2009 Fedora Release Engineering - 0.62-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Thu Feb 26 2009 Fedora Release Engineering - 0.62-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 0.62-2 - Rebuild for Python 2.6 * Sat Nov 22 2008 Matt Domsch - 0.62-1 - new upstream version - Fix reverse DNS of IPv6 address: use ".ip6.arpa." suffix instead of deprecated ".ip6.int." suffix - Patch from Aras Vaichas allowing the [-1] operator to work with an IP object of size 1. -------------------------------------------------------------------------------- From updates at fedoraproject.org Mon Jan 18 23:24:26 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Mon, 18 Jan 2010 23:24:26 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100118232623.D487910F8D8@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing 389-admin-1.1.10-0.3.a3.el5 BackupPC-3.1.0-5.el5 ReviewBoard-1.0.5.1-2.1.el5 augeas-0.7.0-1.el5 dogtag-pki-ca-ui-1.3.0-4.el5 dogtag-pki-common-ui-1.3.0-4.el5 firmware-tools-2.1.9-1.el5 gparted-0.4.8-1.el5 hercstudio-1.1.0-1.el5 mozilla-noscript-1.9.9.35-4.el5 perl-Test-File-Contents-0.05-5.el5 php-suhosin-0.9.29-3.el5 pki-ca-1.3.0-7.el5 pki-common-1.3.0-8.el5 pki-setup-1.3.1-1.el5 plpa-1.3.2-4.el5 pootle-2.0.1-5.el5 python-IPy-0.70-1.el5 tomcatjss-1.2.0-3.el5 Details about builds: ================================================================================ 389-admin-1.1.10-0.3.a3.el5 (FEDORA-EPEL-2010-0071) 389 Administration Server (admin) -------------------------------------------------------------------------------- Update Information: This is alpha release 3 of 1.1.10 - this is primarily to fix some ICU genrb related build issues found on rawhide and other platforms -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 14 2010 Rich Megginson - 1.1.10.a3-0.3 - the 1.1.10.a3 release - make sure we can find ICU genrb on all platforms * Fri Dec 18 2009 Rich Megginson - 1.1.10.a2-0.2 - the 1.1.10.a2 release - fix problem with genrb path on F-12 and later * Thu Oct 8 2009 Rich Megginson - 1.1.10.a1-1 - the 1.1.10.a1 release -------------------------------------------------------------------------------- ================================================================================ BackupPC-3.1.0-5.el5 (FEDORA-EPEL-2010-0079) High-performance backup system -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 17 2010 Johan Cwiklinski 3.1.0-5 - Really fix selinux labelling backup directory (bug #525948) * Fri Jan 15 2010 Johan Cwiklinski 3.1.0-4 - Fix selinux labelling backup directory (bug #525948) - Fix security bug (bug #518412) - Fix SELinux policy module for UserEmailInfo.pl file -------------------------------------------------------------------------------- References: [ 1 ] Bug #525948 - yum upgrade BackupPC takes 12 hours to complete https://bugzilla.redhat.com/show_bug.cgi?id=525948 -------------------------------------------------------------------------------- ================================================================================ ReviewBoard-1.0.5.1-2.1.el5 (FEDORA-EPEL-2010-0076) Web-based code review tool -------------------------------------------------------------------------------- Update Information: New package for ReviewBoard, a web-based code-review tool -------------------------------------------------------------------------------- References: [ 1 ] Bug #487097 - Review Request: ReviewBoard - web based code review tool https://bugzilla.redhat.com/show_bug.cgi?id=487097 -------------------------------------------------------------------------------- ================================================================================ augeas-0.7.0-1.el5 (FEDORA-EPEL-2010-0067) A library for changing configuration files -------------------------------------------------------------------------------- Update Information: See http://augeas.net/news.html for details -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 14 2010 David Lutterkort - 0.7.0-1 - Remove patch vim-ftdetect-syntax.patch. It's upstream -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-ca-ui-1.3.0-4.el5 (FEDORA-EPEL-2010-0086) Dogtag Certificate System - Certificate Authority User Interface -------------------------------------------------------------------------------- Update Information: Dogtag Certificate System - Certificate Authority User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #522208 - New Package for Dogtag PKI: dogtag-pki-ca-ui https://bugzilla.redhat.com/show_bug.cgi?id=522208 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-common-ui-1.3.0-4.el5 (FEDORA-EPEL-2010-0081) Dogtag Certificate System - PKI Common Framework User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Common Framework User Interface -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 14 2010 Matthew Harmsen 1.3.0-4 - Bugzilla Bug #522204 - New Package for Dogtag PKI: dogtag-pki-common-ui - Removed "Requires: bash" -------------------------------------------------------------------------------- References: [ 1 ] Bug #522204 - New Package for Dogtag PKI: dogtag-pki-common-ui https://bugzilla.redhat.com/show_bug.cgi?id=522204 -------------------------------------------------------------------------------- ================================================================================ firmware-tools-2.1.9-1.el5 (FEDORA-EPEL-2010-0065) Scripts and tools to manage firmware and BIOS updates -------------------------------------------------------------------------------- Update Information: minor enhancements - Changed bootstrap_firmware to output extra strings for pci devices with and without subven/subdev. - Added logger for updates. - add override for storage-topdir to the cli --update command -------------------------------------------------------------------------------- ChangeLog: * Fri Dec 11 2009 Matt Domsch - 2.1.9-1 - minor enhancements - Changed bootstrap_firmware to output extra strings for pci devices with and without subven/subdev. - Added logger for updates. - add override for storage-topdir to the cli --update command * Fri Jul 24 2009 Fedora Release Engineering - 2.1.5-2.1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild -------------------------------------------------------------------------------- ================================================================================ gparted-0.4.8-1.el5 (FEDORA-EPEL-2010-0074) Gnome Partition Editor -------------------------------------------------------------------------------- Update Information: Fix usb automounting issue, while updating to the (near) latest. -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 18 2010 Deji Akingunola - 0.4.8-1 - New upstream version - Remove the hal policy file created by gparted (if it's still there) on upgrade (Should fix BZ #550590) -------------------------------------------------------------------------------- References: [ 1 ] Bug #550590 - Gparted prevents USB Automounting https://bugzilla.redhat.com/show_bug.cgi?id=550590 -------------------------------------------------------------------------------- ================================================================================ hercstudio-1.1.0-1.el5 (FEDORA-EPEL-2010-0068) GUI front-end to the Hercules mainframe Emulator -------------------------------------------------------------------------------- Update Information: update to new upstream version 1.1.0 -------------------------------------------------------------------------------- ChangeLog: * Sat Jan 16 2010 Dan Hor?k - 1.1.0-1 - update to 1.1.0 -------------------------------------------------------------------------------- ================================================================================ mozilla-noscript-1.9.9.35-4.el5 (FEDORA-EPEL-2010-0069) Javascript whitelist extension for Mozilla Firefox -------------------------------------------------------------------------------- Update Information: Initial build of this package. -------------------------------------------------------------------------------- References: [ 1 ] Bug #555751 - Review Request: mozilla-noscript - Javascript whitelist extension for Mozilla Firefox https://bugzilla.redhat.com/show_bug.cgi?id=555751 -------------------------------------------------------------------------------- ================================================================================ perl-Test-File-Contents-0.05-5.el5 (FEDORA-EPEL-2010-0072) Test routines for examining the contents of files -------------------------------------------------------------------------------- References: [ 1 ] Bug #533773 - Build perl-Test-File-Contents for EL-5 https://bugzilla.redhat.com/show_bug.cgi?id=533773 -------------------------------------------------------------------------------- ================================================================================ php-suhosin-0.9.29-3.el5 (FEDORA-EPEL-2010-0073) Suhosin is an advanced protection system for PHP installations -------------------------------------------------------------------------------- Update Information: Initial package for EPEL -------------------------------------------------------------------------------- ================================================================================ pki-ca-1.3.0-7.el5 (FEDORA-EPEL-2010-0082) Dogtag Certificate System - Certificate Authority -------------------------------------------------------------------------------- Update Information: The Dogtag Certificate Authority -------------------------------------------------------------------------------- References: [ 1 ] Bug #475895 - Disallow creation of an initial login shell https://bugzilla.redhat.com/show_bug.cgi?id=475895 -------------------------------------------------------------------------------- ================================================================================ pki-common-1.3.0-8.el5 (FEDORA-EPEL-2010-0078) Dogtag Certificate System - PKI Common Framework -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Common Framework -------------------------------------------------------------------------------- References: [ 1 ] Bug #441974 - CA Setup Wizard cannot create new Security Domain. https://bugzilla.redhat.com/show_bug.cgi?id=441974 -------------------------------------------------------------------------------- ================================================================================ pki-setup-1.3.1-1.el5 (FEDORA-EPEL-2010-0084) Dogtag Certificate system - PKI Instance Creation and Removal Scripts -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Setup Framework -------------------------------------------------------------------------------- References: [ 1 ] Bug #475895 - Disallow creation of an initial login shell https://bugzilla.redhat.com/show_bug.cgi?id=475895 -------------------------------------------------------------------------------- ================================================================================ plpa-1.3.2-4.el5 (FEDORA-EPEL-2010-0085) Portable Linux Processor Affinity -------------------------------------------------------------------------------- Update Information: First PLPA packge for EPEL5. -------------------------------------------------------------------------------- References: [ 1 ] Bug #530230 - Review Request: plpa - Portable Linux Processor Affinity https://bugzilla.redhat.com/show_bug.cgi?id=530230 -------------------------------------------------------------------------------- ================================================================================ pootle-2.0.1-5.el5 (FEDORA-EPEL-2010-0077) Localization and translation management web application -------------------------------------------------------------------------------- Update Information: Pootle is web application for managing distributed or crowdsourced translation. It's features include:: * Translation of Gettext PO and XLIFF files. * Submitting to remote version control systems (VCS). * Managing groups of translators * Online webbased or offline translation * Quality checks -------------------------------------------------------------------------------- ================================================================================ python-IPy-0.70-1.el5 (FEDORA-EPEL-2010-0070) Python module for handling IPv4 and IPv6 Addresses and Networks -------------------------------------------------------------------------------- Update Information: New "major" version because it may break compatibility * Fix __cmp__(): IP('0.0.0.0/0') and IP('0.0.0.0') are not equal * Fix IP.net() of the network "::/0": "::" instead of "0.0.0.0". IPy 0.63 should fix this bug, but it wasn't. -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 10 2010 Matt Domsch - 0.70-1 - Version 0.70 (2009-10-29) * New "major" version because it may break compatibility * Fix __cmp__(): IP('0.0.0.0/0') and IP('0.0.0.0') are not equal * Fix IP.net() of the network "::/0": "::" instead of "0.0.0.0". IPy 0.63 should fix this bug, but it wasn't. * Sun Aug 30 2009 Matt Domsch - 0.63-1 - Fix formatting of "IPv4 in IPv6" network: IP('::ffff:192.168.10.0/120') * Sun Jul 26 2009 Fedora Release Engineering - 0.62-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Thu Feb 26 2009 Fedora Release Engineering - 0.62-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sat Nov 29 2008 Ignacio Vazquez-Abrams - 0.62-2 - Rebuild for Python 2.6 * Sat Nov 22 2008 Matt Domsch - 0.62-1 - new upstream version - Fix reverse DNS of IPv6 address: use ".ip6.arpa." suffix instead of deprecated ".ip6.int." suffix - Patch from Aras Vaichas allowing the [-1] operator to work with an IP object of size 1. -------------------------------------------------------------------------------- ================================================================================ tomcatjss-1.2.0-3.el5 (FEDORA-EPEL-2010-0083) JSSE implementation using JSS for Tomcat -------------------------------------------------------------------------------- Update Information: Java Security Services (JSS) for Tomcat 5.5 -------------------------------------------------------------------------------- References: [ 1 ] Bug #441974 - CA Setup Wizard cannot create new Security Domain. https://bugzilla.redhat.com/show_bug.cgi?id=441974 -------------------------------------------------------------------------------- From rmeggins at redhat.com Tue Jan 19 16:56:12 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 19 Jan 2010 09:56:12 -0700 Subject: Packages duplicated between EL-5 sub-channels and EPEL In-Reply-To: <80d7e4091001180403u769102f7wdf82e0ae75a3e171@mail.gmail.com> References: <80d7e4091001141621w1900624bs3d49a991a9b02252@mail.gmail.com> <20100115034346.GF17736@clingman.lan> <80d7e4091001142021oa9de391sc5fa4e4d59077985@mail.gmail.com> <1263542765.3804.22.camel@localhost.localdomain> <1263800499.3804.47.camel@localhost.localdomain> <1263803056.3804.70.camel@localhost.localdomain> <80d7e4091001180403u769102f7wdf82e0ae75a3e171@mail.gmail.com> Message-ID: <4B55E42C.6010106@redhat.com> Stephen John Smoogen wrote: > On Mon, Jan 18, 2010 at 1:24 AM, David Juran wrote: > >> On Mon, 2010-01-18 at 02:52 -0500, Jon Stanley wrote: >> >>> On Mon, Jan 18, 2010 at 2:41 AM, David Juran wrote: >>> >>> >>>> Sorry, what I meant was that the release number should be lower in EPEL. >>>> I.e. the EPEL package would be identical to the RHEL one except that the >>>> release number would be lower. >>>> >>> Generally with a package like 389 or something, you'll have a NEWER >>> version in EPEL than what is in the layered product channel, as EPEL >>> carries the upstream source. not the released source of the RH product >>> - therefore, unless development is stagnant (which one certainly hopes >>> is not the case), then the version in EPEL is necessarily going to be >>> newer than that in the respective RHN channel. >>> >>> Am I missing something incredibly obvious here? >>> >> Maybe the point is moot now after Friday's meeting (which I didn't >> attend due to real-life interference) but this really raises the >> question, what is the purpose of EPEL? >> >> *) Is it to provide cutting edge versions of layered products on top of >> RHEL? Isn't running plain Fedora a better choice then? Of course I see >> the point in getting more people to test e.g. the latest greatest 389 >> version. But is that really the primary mission for EPEL? And maybe it >> still can be done by creating e.g. a 389-ds package (under the name >> 389-ds and taking care of file system conflicts) that doesn't conflict >> with redhat-ds. >> > > For many of the people who want to run/test Red Hat projects (cobbler, > satellite, ds) to test where the product is going Fedora makes NO > sense for them. They aren't looking to update daily to keep up with > fixes, their internal methodologies may require the base OS to go > through various tests which means the Fedora OS is nearly EOL before > they can use it, etc. Testing the products on what they deploy in > production is what they want to do. [I have worked in 3 different > places where I had to do this.. and before EPEL I would have to take > the Fedora stuff, recompile on RHEL and then test/debug what didn't > work.] > Right. Speaking for 389 - it seems that most people running 389 are trying to support long term production environments - they don't want to run Fedora on these environments - they don't want that sort of base OS churn on their production environments, but don't mind the churn of 389 (or they just pick and choose which releases to upgrade to). Many (I'm guessing roughly half) of 389 users run some sort of EL instead of Fedora. > >> *) Is it to provide layered products to those not willing to pay for Red >> Hat support? Isn't that the mission of CentOS? >> > > That is NOT what we are doing. If we were doing that we would be > taking the src.rpms from the channel and rebuilding them... (eg > centos-ds etc). What for the 389, cobbler, etc groups is a channel > where they can reach the people they are developing the product for > and give them the ability to give feedback. > And this feedback is extremely valuable. About half of 389 users run it on EL, some of them in high volume, long lasting production environments, and getting this sort of usage data and feedback from recent releases of 389 is invaluable to the 389 team. If we (389 team) had to, we would provide our own yum repo of EL packages (which we did for a couple of years until someone finally put 389 into EPEL). >> *) Is it to provide Extra Packages for Enterprise Linux (-: >> I.e. a set of packages that for various reasons are not included in >> RHEL but are in Fedora. That does not really imply that the version of >> that extra package should be the latest end greatest version. In my >> opinion, the package version in EPEL should mirror the stable policy of >> RHEL by preferring stability over cutting-edge. >> >> > > Well it might have been that but it would require more co-operation > from Red Hat to do that than I think is possible. By the time we find > out puppet, nagios, etc are in a RH subproduct the EPEL have already > been moved forward to meet bugs etc. Moving the packages back to -1 > release means: > > 1) People who got a newer version of puppet,nagios, etc earlier will > not see any updates and their version may still break the RHN product > if they installed it. > 2) People who do install the older version of puppet, nagios etc will > not see any upstream bugfixes because RH nor EPEL would update > regularly (looking at the updates to those subpackages in the > channel). > 3) Removing, deprecating the packages on the list would hamstring > enough people that we might as well close shop. > > > From updates at fedoraproject.org Tue Jan 19 22:58:03 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 19 Jan 2010 22:58:03 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100119230002.D8EAD10F8EC@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing fail2ban-0.8.4-23.el4 varnish-2.0.6-2.el4 Details about builds: ================================================================================ fail2ban-0.8.4-23.el4 (FEDORA-EPEL-2010-0091) Ban IPs that make too many password failures -------------------------------------------------------------------------------- Update Information: New version from upstream. -------------------------------------------------------------------------------- ChangeLog: * Tue Sep 15 2009 Adam Miller - 0.8.4-23 - Rebuild for EPEL (First release of 0.8.4) * Fri Sep 11 2009 Axel Thimm - 0.8.4-23 - update to 0.8.4. * Wed Sep 2 2009 Axel Thimm - 0.8.3-22 - Update to a newer svn snapshot to fix python 2.6 issue. * Thu Aug 27 2009 Axel Thimm - 0.8.3-21 - Log to syslog (RH bug #491983). Also deals with RH bug #515116. - Check inodes of log files (RH bug #503852). * Wed Mar 4 2009 Adam Miller - 0.8.3-18 - Rebuild For EPEL * Sat Feb 14 2009 Axel Thimm - 0.8.3-18 - Fix CVE-2009-0362 (Fedora bugs #485461, #485464, #485465, #485466). -------------------------------------------------------------------------------- ================================================================================ varnish-2.0.6-2.el4 (FEDORA-EPEL-2010-0038) High-performance HTTP accelerator -------------------------------------------------------------------------------- Update Information: New upstream release -------------------------------------------------------------------------------- ChangeLog: * Wed Dec 23 2009 Ingvar Hagelund - 2.0.6-2 - Added a test that enables jemalloc on ppc if the kernel is not a rhel5 kernel (as on redhat builders) - Removed tests c00031.vtc and r00387on rhel4/ppc as they fail on the Red Hat ppc builders (but works on my rhel4 ppc instance) - Added a patch that fixes broken changes-2.0.6.html in doc * Mon Dec 14 2009 Ingvar Hagelund - 2.0.6-1 - New upstream release - Removed patches for libjemalloc, as they are added upstream -------------------------------------------------------------------------------- From updates at fedoraproject.org Tue Jan 19 22:58:03 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 19 Jan 2010 22:58:03 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100119230002.EA2B710F8EE@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing dogtag-pki-common-ui-1.3.1-1.el5 dokuwiki-0-0.4.20091225.c.el5 fail2ban-0.8.4-23.el5 fcgi-2.4.0-12.el5 mock-1.0.3-1.el5 perl-Data-Report-0.10-4.el5 perl-OpenGL-0.62-2.el5 pki-silent-1.3.0-5.el5 varnish-2.0.6-2.el5 Details about builds: ================================================================================ dogtag-pki-common-ui-1.3.1-1.el5 (FEDORA-EPEL-2010-0092) Dogtag Certificate System - PKI Common Framework User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Common Framework User Interface -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 18 2010 Matthew Harmsen 1.3.1-1 - Bugzilla Bug #522204 - New Package for Dogtag PKI: dogtag-pki-common-ui - Fixed various licensing headers * Thu Jan 14 2010 Matthew Harmsen 1.3.0-4 - Bugzilla Bug #522204 - New Package for Dogtag PKI: dogtag-pki-common-ui - Removed "Requires: bash" -------------------------------------------------------------------------------- References: [ 1 ] Bug #522204 - New Package for Dogtag PKI: dogtag-pki-common-ui https://bugzilla.redhat.com/show_bug.cgi?id=522204 -------------------------------------------------------------------------------- ================================================================================ dokuwiki-0-0.4.20091225.c.el5 (FEDORA-EPEL-2010-0090) Standards compliant simple to use wiki -------------------------------------------------------------------------------- Update Information: - Fix CSRF bug Secunia advisory SA38205, dokuwiki bug #1853 http://secunia.com/advisories/38205/3/ - Fix Security ACL bypass bug Secunia advisory SA38183, dokuwiki bug #1847 http://secunia.com/advisories/38183/3/ - Upgrade to the latest upstream - Fix bugzilla bug #556494 -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 19 2010 Andrew Colin Kissa - 0-0.4.20091225.c - Fix CSRF bug Secunia advisory SA38205, dokuwiki bug #1853 - Fix Security ACL bypass bug Secunia advisory SA38183, dokuwiki bug #1847 - Upgrade to the latest upstream - Fix bugzilla bug #556494 -------------------------------------------------------------------------------- References: [ 1 ] Bug #556494 - dokuwiki CSRF vulnerability in ACL manager https://bugzilla.redhat.com/show_bug.cgi?id=556494 -------------------------------------------------------------------------------- ================================================================================ fail2ban-0.8.4-23.el5 (FEDORA-EPEL-2010-0093) Ban IPs that make too many password failures -------------------------------------------------------------------------------- Update Information: New version from upstream. -------------------------------------------------------------------------------- ChangeLog: * Tue Sep 15 2009 Adam Miller - 0.8.4-23 - Rebuild for EPEL (First release of 0.8.4) * Fri Sep 11 2009 Axel Thimm - 0.8.4-23 - update to 0.8.4. * Wed Sep 2 2009 Axel Thimm - 0.8.3-22 - Update to a newer svn snapshot to fix python 2.6 issue. * Thu Aug 27 2009 Axel Thimm - 0.8.3-21 - Log to syslog (RH bug #491983). Also deals with RH bug #515116. - Check inodes of log files (RH bug #503852). -------------------------------------------------------------------------------- ================================================================================ fcgi-2.4.0-12.el5 (FEDORA-EPEL-2010-0094) FastCGI development kit -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 18 2010 Chris Weyl - 2.4.0-12 - drop perl .so provides filtering, as it may have multiarch rpm implications * Fri Dec 4 2009 Stepan Kasal - 2.4.0-11 - rebuild against perl 5.10.1 * Fri Jul 24 2009 Fedora Release Engineering - 2.4.0-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Sun Mar 1 2009 Chris Weyl - 2.4.0-9 - Stripping bad provides of private Perl extension libs * Tue Feb 24 2009 Fedora Release Engineering - 2.4.0-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Sun Feb 15 2009 Till Maas - 2.4.0-7 - Add missing #include to make it compile with gcc 4.4 * Tue Oct 14 2008 Chris Weyl - 2.4.0-6 - package up the perl bindings in their own subpackage * Wed Feb 20 2008 Fedora Release Engineering - 2.4.0-5 - Autorebuild for GCC 4.3 -------------------------------------------------------------------------------- References: [ 1 ] Bug #498450 - fcgi package in EPEL5 doesn't provide the perl bindings https://bugzilla.redhat.com/show_bug.cgi?id=498450 -------------------------------------------------------------------------------- ================================================================================ mock-1.0.3-1.el5 (FEDORA-EPEL-2010-0089) Builds packages inside chroots -------------------------------------------------------------------------------- Update Information: added --unpriv mode to --shell -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 18 2010 Clark Williams - 1.0.3-1 - add logic for handling --unpriv with --shell (BZ# 522505) -------------------------------------------------------------------------------- References: [ 1 ] Bug #522505 - --unpriv only works with --chroot https://bugzilla.redhat.com/show_bug.cgi?id=522505 -------------------------------------------------------------------------------- ================================================================================ perl-Data-Report-0.10-4.el5 (FEDORA-EPEL-2010-0088) A flexible plugin-driven reporting framework -------------------------------------------------------------------------------- Update Information: Data::Report is a framework for report generation. You define the columns, add the data row by row, and get reports in text, HTML, CSV and so on. Textual ornaments like extra empty lines, dashed lines, and cell lines can be added in a way similar to HTML style sheets. -------------------------------------------------------------------------------- References: [ 1 ] Bug #483286 - Review Request: perl-Data-Report - A flexible plugin-driven reporting framework https://bugzilla.redhat.com/show_bug.cgi?id=483286 [ 2 ] Bug #550192 - mysql-zrm requires the not yet branched perl-data-report https://bugzilla.redhat.com/show_bug.cgi?id=550192 -------------------------------------------------------------------------------- ================================================================================ perl-OpenGL-0.62-2.el5 (FEDORA-EPEL-2010-0045) Perl OpenGL bindings -------------------------------------------------------------------------------- ================================================================================ pki-silent-1.3.0-5.el5 (FEDORA-EPEL-2010-0087) Dogtag Certificate System - Silent Installer -------------------------------------------------------------------------------- Update Information: The Dogtag Silent Installer -------------------------------------------------------------------------------- References: [ 1 ] Bug #521996 - New Package for Dogtag PKI: pki-silent https://bugzilla.redhat.com/show_bug.cgi?id=521996 -------------------------------------------------------------------------------- ================================================================================ varnish-2.0.6-2.el5 (FEDORA-EPEL-2010-0032) High-performance HTTP accelerator -------------------------------------------------------------------------------- ChangeLog: * Wed Dec 23 2009 Ingvar Hagelund - 2.0.6-2 - Added a test that enables jemalloc on ppc if the kernel is not a rhel5 kernel (as on redhat builders) - Removed tests c00031.vtc and r00387on rhel4/ppc as they fail on the Red Hat ppc builders (but works on my rhel4 ppc instance) - Added a patch that fixes broken changes-2.0.6.html in doc * Mon Dec 14 2009 Ingvar Hagelund - 2.0.6-1 - New upstream release - Removed patches for libjemalloc, as they are added upstream -------------------------------------------------------------------------------- From updates at fedoraproject.org Wed Jan 20 22:40:39 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Wed, 20 Jan 2010 22:40:39 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100120224245.C2A9310F8B1@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing puppet-0.25.3-2.el4 superiotool-0-0.21.20100120svn4931.el4 torque-2.3.9-1.el4 Details about builds: ================================================================================ puppet-0.25.3-2.el4 (FEDORA-EPEL-2010-0095) A network tool for managing many disparate systems -------------------------------------------------------------------------------- Update Information: The update from 0.24.x to 0.25.x brings many, many changes and improvements to puppet. The upstream release notes cover them in detail: http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes Of note is that 0.25.x clients do not work with 0.24.x masters, so it is important to update the master before or at the same time as clients. -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 19 2010 Todd Zullinger - 0.25.3-2 - Apply upstream patch to fix cron resources (upstream #2845) * Mon Jan 11 2010 Todd Zullinger - 0.25.3-1 - Update to 0.25.3 * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1.1 - Replace %define with %global for macros * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1 - Update to 0.25.2 - Fixes CVE-2010-0156, tmpfile security issue (#502881) - Install auth.conf, puppetqd manpage, and queuing examples/docs * Wed Nov 25 2009 Jeroen van Meeuwen - 0.25.1-1 - New upstream version * Tue Oct 27 2009 Todd Zullinger - 0.25.1-0.3 - Update to 0.25.1 - Include the pi program and man page (R.I.Pienaar) * Sat Oct 17 2009 Todd Zullinger - 0.25.1-0.2.rc2 - Update to 0.25.1rc2 * Tue Sep 22 2009 Todd Zullinger - 0.25.1-0.1.rc1 - Update to 0.25.1rc1 - Move puppetca to puppet package, it has uses on client systems - Drop redundant %doc from manpage %file listings * Fri Sep 4 2009 Todd Zullinger - 0.25.0-1 - Update to 0.25.0 - Fix permissions on /var/log/puppet (#495096) - Install emacs mode and vim syntax files (#491437) - Install ext/ directory in %{_datadir}/puppet (/usr/share/puppet) -------------------------------------------------------------------------------- References: [ 1 ] Bug #502881 - CVE-2010-0156 puppet: several insecure tempfile creation issues https://bugzilla.redhat.com/show_bug.cgi?id=502881 -------------------------------------------------------------------------------- ================================================================================ superiotool-0-0.21.20100120svn4931.el4 (FEDORA-EPEL-2010-0102) Simple program for detecting Super I/O on your mainboard -------------------------------------------------------------------------------- Update Information: %changelog * Wed Jan 20 2010 Peter Lemenkov 0-0.21.20100120svn4931 - Fixed svn URL. - svn ver. 4931. - Add detection and dump support for the Winbond WPCD376I. - Add detection support for the SMSC FDC37M602. -------------------------------------------------------------------------------- ChangeLog: * Wed Jan 20 2010 Peter Lemenkov 0-0.21.20100120svn4931 - Fixed svn URL. - svn ver. 4931. - Add detection and dump support for the Winbond WPCD376I. - Add detection support for the SMSC FDC37M602. -------------------------------------------------------------------------------- ================================================================================ torque-2.3.9-1.el4 (FEDORA-EPEL-2010-0098) Tera-scale Open-source Resource and QUEue manager -------------------------------------------------------------------------------- Update Information: Includes a fix to a problem where non-root users could not execute manager or operator tasks even though they were included in the operators and managers lists. For example a user could not terminate pbs_server even though the user was given access. -------------------------------------------------------------------------------- From updates at fedoraproject.org Wed Jan 20 22:40:39 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Wed, 20 Jan 2010 22:40:39 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100120224245.C6D9E10F8CB@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing dogtag-pki-console-ui-1.3.0-4.el5 dogtag-pki-kra-ui-1.3.0-4.el5 dogtag-pki-ocsp-ui-1.3.0-4.el5 dogtag-pki-ra-ui-1.3.0-5.el5 dogtag-pki-tks-ui-1.3.0-4.el5 dogtag-pki-tps-ui-1.3.0-6.el5 pki-kra-1.3.0-4.el5 pki-ocsp-1.3.0-4.el5 puppet-0.25.3-2.el5 superiotool-0-0.21.20100120svn4931.el5 torque-2.3.9-1.el5 Details about builds: ================================================================================ dogtag-pki-console-ui-1.3.0-4.el5 (FEDORA-EPEL-2010-0100) Dogtag Certificate System - PKI Console User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Console User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553483 - Review Request: dogtag-pki-console-ui - The Dogtag PKI Console User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553483 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-kra-ui-1.3.0-4.el5 (FEDORA-EPEL-2010-0107) Dogtag Certificate System - Data Recovery Authority User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Data Recovery Authority User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553742 - Review Request: dogtag-pki-kra-ui - The Dogtag Data Recovery Authority User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553742 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-ocsp-ui-1.3.0-4.el5 (FEDORA-EPEL-2010-0096) Dogtag Certificate System - Online Certificate Status Protocol User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Online Certificate Status Protocol User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553843 - Review Request: dogtag-pki-ocsp-ui The Dogtag Online Certificate Status Protocol User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553843 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-ra-ui-1.3.0-5.el5 (FEDORA-EPEL-2010-0108) Dogtag Certificate System - Registration Authority User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Registration Authority User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553848 - Review Request: dogtag-pki-ra-ui - The Dogtag Registration Authority User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553848 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-tks-ui-1.3.0-4.el5 (FEDORA-EPEL-2010-0106) Dogtag Certificate System - Token Key Service User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Token Key Service User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553845 - Review Request: dogtag-pki-tks-ui - The Dogtag Token Key Service User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553845 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-tps-ui-1.3.0-6.el5 (FEDORA-EPEL-2010-0105) Dogtag Certificate System - Token Processing System User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Token Processing System User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553851 - Review Request: dogtag-pki-tps-ui - The Dogtag Token Processing System User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553851 -------------------------------------------------------------------------------- ================================================================================ pki-kra-1.3.0-4.el5 (FEDORA-EPEL-2010-0099) Dogtag Certificate System - Data Recovery Manager -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Data Recovery Manager -------------------------------------------------------------------------------- References: [ 1 ] Bug #553842 - Review Request: pki-kra - Dogtag Data Recovery Manager https://bugzilla.redhat.com/show_bug.cgi?id=553842 -------------------------------------------------------------------------------- ================================================================================ pki-ocsp-1.3.0-4.el5 (FEDORA-EPEL-2010-0104) Dogtag Certificate System - Online Certificate Status Protocol Manager -------------------------------------------------------------------------------- Update Information: Dogtag PKI Online Certificate Status Protocol Manager -------------------------------------------------------------------------------- References: [ 1 ] Bug #553844 - Review Request: pki-ocsp - Dogtag Online Certificate Status Protocol Manager https://bugzilla.redhat.com/show_bug.cgi?id=553844 -------------------------------------------------------------------------------- ================================================================================ puppet-0.25.3-2.el5 (FEDORA-EPEL-2010-0097) A network tool for managing many disparate systems -------------------------------------------------------------------------------- Update Information: The update from 0.24.x to 0.25.x brings many, many changes and improvements to puppet. The upstream release notes cover them in detail: http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes Of note is that 0.25.x clients do not work with 0.24.x masters, so it is important to update the master before or at the same time as clients. -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 19 2010 Todd Zullinger - 0.25.3-2 - Apply upstream patch to fix cron resources (upstream #2845) * Mon Jan 11 2010 Todd Zullinger - 0.25.3-1 - Update to 0.25.3 * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1.1 - Replace %define with %global for macros * Tue Jan 5 2010 Todd Zullinger - 0.25.2-1 - Update to 0.25.2 - Fixes CVE-2010-0156, tmpfile security issue (#502881) - Install auth.conf, puppetqd manpage, and queuing examples/docs * Wed Nov 25 2009 Jeroen van Meeuwen - 0.25.1-1 - New upstream version * Tue Oct 27 2009 Todd Zullinger - 0.25.1-0.3 - Update to 0.25.1 - Include the pi program and man page (R.I.Pienaar) * Sat Oct 17 2009 Todd Zullinger - 0.25.1-0.2.rc2 - Update to 0.25.1rc2 * Tue Sep 22 2009 Todd Zullinger - 0.25.1-0.1.rc1 - Update to 0.25.1rc1 - Move puppetca to puppet package, it has uses on client systems - Drop redundant %doc from manpage %file listings * Fri Sep 4 2009 Todd Zullinger - 0.25.0-1 - Update to 0.25.0 - Fix permissions on /var/log/puppet (#495096) - Install emacs mode and vim syntax files (#491437) - Install ext/ directory in %{_datadir}/puppet (/usr/share/puppet) -------------------------------------------------------------------------------- References: [ 1 ] Bug #502881 - CVE-2010-0156 puppet: several insecure tempfile creation issues https://bugzilla.redhat.com/show_bug.cgi?id=502881 -------------------------------------------------------------------------------- ================================================================================ superiotool-0-0.21.20100120svn4931.el5 (FEDORA-EPEL-2010-0101) Simple program for detecting Super I/O on your mainboard -------------------------------------------------------------------------------- Update Information: %changelog * Wed Jan 20 2010 Peter Lemenkov 0-0.21.20100120svn4931 - Fixed svn URL. - svn ver. 4931. - Add detection and dump support for the Winbond WPCD376I. - Add detection support for the SMSC FDC37M602. -------------------------------------------------------------------------------- ChangeLog: * Wed Jan 20 2010 Peter Lemenkov 0-0.21.20100120svn4931 - Fixed svn URL. - svn ver. 4931. - Add detection and dump support for the Winbond WPCD376I. - Add detection support for the SMSC FDC37M602. -------------------------------------------------------------------------------- ================================================================================ torque-2.3.9-1.el5 (FEDORA-EPEL-2010-0103) Tera-scale Open-source Resource and QUEue manager -------------------------------------------------------------------------------- Update Information: Includes a fix to a problem where non-root users could not execute manager or operator tasks even though they were included in the operators and managers lists. For example a user could not terminate pbs_server even though the user was given access. -------------------------------------------------------------------------------- From wdierkes at 5dollarwhitebox.org Wed Jan 20 23:27:05 2010 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Wed, 20 Jan 2010 17:27:05 -0600 Subject: technical solution/workaround for EPEL vs. RH sub channel In-Reply-To: <1263844790.2307.29.camel@localhost> References: <1263844790.2307.29.camel@localhost> Message-ID: On Jan 18, 2010, at 1:59 PM, Christopher wrote: > Hello... > > What about the following idea as a solution to RH vs. EPEL conflicting > packages? Extend yum either in the core code or as a plugin to allow > exclude=@group. Then the EPEL repo could contain groups > @rh-sub-channel-foo, etc. with EPEL packages that conflict. That would > allow the sysadmin to selectively exclude packages for RH sub projects > they get via RHN. Even if there are technical problems with RHEL4 or > RHEL5, this approach could still work with RHEL6. Personally, I would not recommend making any major changes to existing setup (EL4/5) and would look at making the changes for EL6. Depending on the impact of the changes of course. > The epel.repo file could contain something like: > > # repo file for epel > # If you wish to avoid conflicting with a RedHat channel you subscribe > # to, you can use exclude="@rh-group-foo". > # get get the list of groups group run > # yum grouplist --disablerepo='*' --enablerepo=epel > # or see http://some.url/EPEL > # > # warning subscribing to RH sub channels and EPEL without checking for > # package conflicts may kill kittens. > > [epel] > name=Extra Packages for Enterprise Linux 5 - $basearch > #baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch= > $basearch > failovermethod=priority > enabled=1 > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL > > # exclude="@rh-group foo" Forgive me if I'm missing something, so let me summarize what I think you are referring to: RHN [Sub] Channel contains packageA, packageB, etc. EPEL @sub-channel group also contains packageA, packageB, etc (or packages that conflict with them) The gaol being to allow EPEL to offer packages that conflict with packages provided by RHEL. Where I am not following is the exclude. Wouldn't 'exclude=@rh-group' in the epel.repo config file exclude the @rh-group in EPEL, rather than excluding the @rh-group in RHN? Additionally, something I'm unsure of is.... with the rhn plugin for yum, there are no 'per repo' [read channel] repo configs, therefore to exclude anything from RHN you have to globally exclude in yum.conf (meaning you would exclude the @group from all repos/channels). So if a sysadmin wants to exclude @group from RHN it would have to be a global exclude (or are you assuming that they wouldn't be subscribed to the sub-channel in RHN). As I said, forgive me if I"m missing something. --- derks From inode0 at gmail.com Wed Jan 20 23:50:56 2010 From: inode0 at gmail.com (inode0) Date: Wed, 20 Jan 2010 17:50:56 -0600 Subject: technical solution/workaround for EPEL vs. RH sub channel In-Reply-To: References: <1263844790.2307.29.camel@localhost> Message-ID: On Wed, Jan 20, 2010 at 5:27 PM, BJ Dierkes wrote: > On Jan 18, 2010, at 1:59 PM, Christopher wrote: >> The epel.repo file could contain something like: >> >> # repo file for epel >> # If you wish to avoid conflicting with a RedHat channel you subscribe >> # to, you can use exclude="@rh-group-foo". >> # get get the list of groups group run >> # yum grouplist --disablerepo='*' --enablerepo=epel >> # or see http://some.url/EPEL >> # >> # warning subscribing to RH sub channels and EPEL without checking for >> # package conflicts may kill kittens. >> >> [epel] >> name=Extra Packages for Enterprise Linux 5 - $basearch >> #baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch >> mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch= >> $basearch >> failovermethod=priority >> enabled=1 >> gpgcheck=1 >> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL >> >> # exclude="@rh-group foo" > > Forgive me if I'm missing something, so let me summarize what I think you are referring to: > > RHN [Sub] Channel contains packageA, packageB, etc. > EPEL @sub-channel group also contains packageA, packageB, etc (or packages that conflict with them) > > > The gaol being to allow EPEL to offer packages that conflict with packages provided by RHEL. ?Where I am not > following is the exclude. ?Wouldn't 'exclude=@rh-group' in the epel.repo config file exclude the @rh-group in > EPEL, rather than excluding the @rh-group in RHN? I think that would be the most desirable default configuration. Don't step on Red Hat provided packages. > Additionally, something I'm unsure of is.... with the rhn plugin for yum, there are no 'per repo' [read channel] repo > configs, therefore to exclude anything from RHN you have to globally exclude in yum.conf (meaning you would > exclude the @group from all repos/channels). ?So if a sysadmin wants to exclude @group from RHN it would have > to be a global exclude (or are you assuming that they wouldn't be subscribed to the sub-channel in RHN). > > As I said, forgive me if I"m missing something. There are per repo configs now in RHEL5, I believe they were added in 5.3 or so. For example, # cat /etc/yum/pluginconf.d/rhnplugin.conf [main] enabled = 1 gpgcheck = 1 [rhel-i386-server-5] enabled = 1 Other RHN channels can be configured similarly however there is not full support for everything we are used to in yum configs here. It is quite limited I believe and I don't know for sure what pieces actually work. John From cmadams at hiwaay.net Thu Jan 21 15:00:56 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 21 Jan 2010 09:00:56 -0600 Subject: Okay, how about this duplicate provides? Message-ID: <20100121150056.GB1175086@hiwaay.net> I was installing perl-LDAP on RHEL 5 (from RHN) when I noticed that yum was going to pull in several perl RPMs from EPEL. I see that there is a duplicated provide: # yum whatprovides 'perl(LWP::Protocol)' Loaded plugins: rhnplugin, security perl-SOAP-Lite-0.710.07-2.el5.noarch : Client and server side SOAP : implementation Repo : epel Matched from: Other : perl(LWP::Protocol) perl-libwww-perl-5.805-1.1.1.noarch : A Perl interface to the World-Wide Web Repo : rhel-x86_64-server-5 Matched from: Other : perl(LWP::Protocol) perl-libwww-perl is from RHN and perl-SOAP-Lite is from EPEL. Since yum matches the shortest name first, the EPEL package "wins". I'm guessing this is just another bogus provides that needs to be filtered out in perl-SOAP-Lite, but is anybody checking for this kind of "conflict" between RHEL and EPEL? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From smooge at gmail.com Thu Jan 21 15:31:40 2010 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 21 Jan 2010 08:31:40 -0700 Subject: Okay, how about this duplicate provides? In-Reply-To: <20100121150056.GB1175086@hiwaay.net> References: <20100121150056.GB1175086@hiwaay.net> Message-ID: <80d7e4091001210731h6d8ce9a2xd733d0578e8900bd@mail.gmail.com> On Thu, Jan 21, 2010 at 8:00 AM, Chris Adams wrote: > I was installing perl-LDAP on RHEL 5 (from RHN) when I noticed that yum > was going to pull in several perl RPMs from EPEL. ?I see that there is a > duplicated provide: > > # yum whatprovides 'perl(LWP::Protocol)' > Loaded plugins: rhnplugin, security > perl-SOAP-Lite-0.710.07-2.el5.noarch : Client and server side SOAP > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : implementation > Repo ? ? ? ?: epel > Matched from: > Other ? ? ? : perl(LWP::Protocol) > > > > perl-libwww-perl-5.805-1.1.1.noarch : A Perl interface to the World-Wide Web > Repo ? ? ? ?: rhel-x86_64-server-5 > Matched from: > Other ? ? ? : perl(LWP::Protocol) > > > > perl-libwww-perl is from RHN and perl-SOAP-Lite is from EPEL. ?Since yum > matches the shortest name first, the EPEL package "wins". > > I'm guessing this is just another bogus provides that needs to be > filtered out in perl-SOAP-Lite, but is anybody checking for this kind of > "conflict" between RHEL and EPEL? > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. Well since it caught you.. I would say no. no is checking for this. We need to put it on the get-er-done list. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From cmadams at hiwaay.net Thu Jan 21 16:26:04 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 21 Jan 2010 10:26:04 -0600 Subject: Okay, how about this duplicate provides? In-Reply-To: <80d7e4091001210731h6d8ce9a2xd733d0578e8900bd@mail.gmail.com> References: <20100121150056.GB1175086@hiwaay.net> <80d7e4091001210731h6d8ce9a2xd733d0578e8900bd@mail.gmail.com> Message-ID: <20100121162604.GD1175086@hiwaay.net> Once upon a time, Stephen John Smoogen said: > Well since it caught you.. I would say no. no is checking for this. We > need to put it on the get-er-done list. I guess I did ask an obvious question there, didn't I? :-) I did a quick check, and it doesn't look like it is too bad at this point. At least one is a bug in a RHEL package (MRTG providing SNMP_Session's perl modules). Not including package conflicts (such as perl-Net-Telnet), I see: - GraphicsMagick-perl perl(Turtle) (RHEL: ImageMagick-perl) - atlas liblapack.so.3()(64bit) (RHEL: lapack) - perl-GraphViz perl(DB) (RHEL: perl) - perl-POE-Test-Loops perl(Switch) (RHEL: perl) - perl-Perlilog perl(UNIVERSAL) (RHEL: perl) - perl-SNMP_Session perl(BER) (RHEL: mrtg) perl(SNMP_Session) (RHEL: mrtg) perl(SNMP_util) (RHEL: mrtg) perl(SNMPv1_Session) (RHEL: mrtg) perl(SNMPv2c_Session) (RHEL: mrtg) - perl-XML-XPathEngine perl(XML::XPathEngine::NodeSet) (RHEL: perl-XML-Twig) - perl-Test-Mock-LWP perl(HTTP::Request) (RHEL: perl-libwww-perl) perl(HTTP::Response) (RHEL: perl-libwww-perl) perl(LWP::UserAgent) (RHEL: perl-libwww-perl) - perl-SOAP-Lite perl(LWP::Protocol) (RHEL: perl-libwww-perl) I have filed a bug about perl-SOAP-Lite (BZ 557485), and I filed a bug about RHEL's MRTG a couple of months ago (BZ 532556). Some of these don't show up as a problem because the EPEL package has a longer name (so yum chooses the RHEL package first), but I would guess that's not behavior to depend on. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From updates at fedoraproject.org Thu Jan 21 23:32:44 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Thu, 21 Jan 2010 23:32:44 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100121233454.B345410F8AD@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing 389-admin-1.1.10-1.el5 dogtag-pki-tps-ui-1.3.1-1.el5 Details about builds: ================================================================================ 389-admin-1.1.10-1.el5 (FEDORA-EPEL-2010-0109) 389 Administration Server (admin) -------------------------------------------------------------------------------- Update Information: This is the final 1.1.10 release. -------------------------------------------------------------------------------- ChangeLog: * Wed Jan 20 2010 Rich Megginson - 1.1.10-1 - the 1.1.10 release - allow server to run unconfined if not built with selinux support * Thu Jan 14 2010 Rich Megginson - 1.1.10.a3-0.3 - the 1.1.10.a3 release - make sure we can find ICU genrb on all platforms * Fri Dec 18 2009 Rich Megginson - 1.1.10.a2-0.2 - the 1.1.10.a2 release - fix problem with genrb path on F-12 and later * Thu Oct 8 2009 Rich Megginson - 1.1.10.a1-1 - the 1.1.10.a1 release -------------------------------------------------------------------------------- References: [ 1 ] Bug #552419 - 389-admin-1.1.10-0.2.a2.el5 fails to start https://bugzilla.redhat.com/show_bug.cgi?id=552419 -------------------------------------------------------------------------------- ================================================================================ dogtag-pki-tps-ui-1.3.1-1.el5 (FEDORA-EPEL-2010-0110) Dogtag Certificate System - Token Processing System User Interface -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Token Processing System User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #553851 - Review Request: dogtag-pki-tps-ui - The Dogtag Token Processing System User Interface https://bugzilla.redhat.com/show_bug.cgi?id=553851 -------------------------------------------------------------------------------- From updates at fedoraproject.org Fri Jan 22 19:58:04 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Fri, 22 Jan 2010 19:58:04 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100122200018.52E5010F92B@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing phpMyAdmin-2.11.10-1.el4 Details about builds: ================================================================================ phpMyAdmin-2.11.10-1.el4 (FEDORA-EPEL-2010-0111) Web based MySQL browser written in php -------------------------------------------------------------------------------- Update Information: Changes for 2.11.10.0 (2009-12-07) - [core] safer handling of temporary files with open_basedir (thanks to Thijs Kinkhorst) - [core] do not automatically set and create TempDir, it might lead to security issue (thanks to Thijs Kinkhorst) - [setup] avoid usage of (un)serialize, what might be unsafe in some cases -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 21 2010 Robert Scheck 2.11.10-1 - Upstream released 2.11.10 (#557307) -------------------------------------------------------------------------------- References: [ 1 ] Bug #557307 - CVE-2008-7251 CVE-2008-7252 CVE-2009-4605 phpMyAdmin 2.x multiple vulnerabilities https://bugzilla.redhat.com/show_bug.cgi?id=557307 -------------------------------------------------------------------------------- From updates at fedoraproject.org Fri Jan 22 19:58:04 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Fri, 22 Jan 2010 19:58:04 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100122200018.6C7A410F9CE@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing cgdb-0.6.5-1.el5 gmrun-0.9.2-21.el5 gstreamer-java-1.3-2.el5 phpMyAdmin-2.11.10-1.el5 Details about builds: ================================================================================ cgdb-0.6.5-1.el5 (FEDORA-EPEL-2010-0112) CGDB is a curses-based interface to the GNU Debugger (GDB) -------------------------------------------------------------------------------- Update Information: - Bump to 0.6.5. -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 11 2010 Gilboa Davara - 0.6.5-1 - Bump to 0.6.5. * Fri Jul 24 2009 Fedora Release Engineering - 0.6.4-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Mon Feb 23 2009 Fedora Release Engineering - 0.6.4-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Mon Feb 18 2008 Fedora Release Engineering - 0.6.4-3 - Autorebuild for GCC 4.3 -------------------------------------------------------------------------------- ================================================================================ gmrun-0.9.2-21.el5 (FEDORA-EPEL-2010-0113) Lightweight "Run program" dialog box with search history and tab completion -------------------------------------------------------------------------------- Update Information: * 0.9.2-21 - Make the F12 patch optional on F11 and above. (EL-5 support) * 0.9.2-19 - Fix #511639. Should build on F12. - Add mouse wheel support. - Fix possible crash due total input size. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 22 2010 Gilboa Davara - 0.9.2-21 - Make the F12 optional on F11 and above. * Mon Jan 11 2010 Gilboa Davara - 0.9.2-19 - Fix #511639. Should build on F12. - Add mouse wheel support. - Fix possible crash due total input size. * Tue Feb 24 2009 Fedora Release Engineering - 0.9.2-16 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Tue Mar 4 2008 Gilboa Davara - 0.9.2-15 - Reapply Ville's xdg-utils patch. * Mon Feb 18 2008 Fedora Release Engineering - 0.9.2-13 - Autorebuild for GCC 4.3 -------------------------------------------------------------------------------- ================================================================================ gstreamer-java-1.3-2.el5 (FEDORA-EPEL-2010-0114) Java interface to the gstreamer framework -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 22 2010 Levente Farkas - 1.3-2 - drop test from jar -------------------------------------------------------------------------------- ================================================================================ phpMyAdmin-2.11.10-1.el5 (FEDORA-EPEL-2010-0115) Web based MySQL browser written in php -------------------------------------------------------------------------------- Update Information: Changes for 2.11.10.0 (2009-12-07) - [core] safer handling of temporary files with open_basedir (thanks to Thijs Kinkhorst) - [core] do not automatically set and create TempDir, it might lead to security issue (thanks to Thijs Kinkhorst) - [setup] avoid usage of (un)serialize, what might be unsafe in some cases -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 21 2010 Robert Scheck 2.11.10-1 - Upstream released 2.11.10 (#557307) -------------------------------------------------------------------------------- References: [ 1 ] Bug #557307 - CVE-2008-7251 CVE-2008-7252 CVE-2009-4605 phpMyAdmin 2.x multiple vulnerabilities https://bugzilla.redhat.com/show_bug.cgi?id=557307 -------------------------------------------------------------------------------- From updates at fedoraproject.org Tue Jan 26 23:45:55 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 26 Jan 2010 23:45:55 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100126234827.3490E10F9AC@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing R-2.10.1-1.el4 sipp-3.1-8.svn586.el4 Details about builds: ================================================================================ R-2.10.1-1.el4 (FEDORA-EPEL-2010-0135) A language for data analysis and graphics -------------------------------------------------------------------------------- Update Information: Update R to 2.10.1. For full changelog notes, see: http://cran.r-project.org/src/base/NEWS -------------------------------------------------------------------------------- ChangeLog: * Mon Dec 21 2009 Tom "spot" Callaway - 2.10.1-1 - update to 2.10.1 - enable static html pages -------------------------------------------------------------------------------- ================================================================================ sipp-3.1-8.svn586.el4 (FEDORA-EPEL-2010-0119) SIP test tool / traffic generator -------------------------------------------------------------------------------- Update Information: %changelog * Mon Jan 25 2010 Peter Lemenkov 3.1-8.svn586 - Update to svn ver. 586 (fixes lots of small but nasty issues) - Removed patch1, patch3 -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 25 2010 Peter Lemenkov 3.1-8.svn586 - Update to svn ver. 586 (fixes lots of small but nasty issues) - Removed patch1, patch3 * Fri Aug 21 2009 Tomas Mraz - 3.1-7 - rebuilt with new openssl * Sun Jul 26 2009 Fedora Release Engineering - 3.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild -------------------------------------------------------------------------------- From updates at fedoraproject.org Tue Jan 26 23:45:56 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Tue, 26 Jan 2010 23:45:56 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100126234827.542AC10F9B1@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing 389-admin-1.1.10-1.el5 389-ds-base-1.2.6-0.1.a1.el5 R-2.10.1-1.el5 RackTables-0.17.8-1.el5 arpack-2.1-13.el5 dbus-cxx-0.6.0-1.el5 dspam-3.9.0-3.el5 editarea-0.8.2-1.el5 garmindev-0.3.2-1.el5 ldns-1.6.4-2.el5 milia-0.3.0-2.el5 munin-1.4.3-2.el5 openvpn-2.1.1-2.el5 perl-Template-Toolkit-2.22-3.el5 php-pear-Net-SMTP-1.4.0-1.el5 php-pear-XML-Serializer-0.20.0-1.el5 pki-common-1.3.1-1.el5 pki-selinux-1.3.3-1.el5 pki-silent-1.3.1-1.el5 pki-util-1.3.0-5.el5 python-beaker-1.5.1-1.el5 sipp-3.1-8.svn586.el5 xl2tpd-1.2.5-1.el5 znc-0.078-1.el5 Details about builds: ================================================================================ 389-admin-1.1.10-1.el5 (FEDORA-EPEL-2010-0109) 389 Administration Server (admin) -------------------------------------------------------------------------------- Update Information: This is the final 1.1.10 release. -------------------------------------------------------------------------------- ChangeLog: * Wed Jan 20 2010 Rich Megginson - 1.1.10-1 - the 1.1.10 release - allow server to run unconfined if not built with selinux support * Thu Jan 14 2010 Rich Megginson - 1.1.10.a3-0.3 - the 1.1.10.a3 release - make sure we can find ICU genrb on all platforms * Fri Dec 18 2009 Rich Megginson - 1.1.10.a2-0.2 - the 1.1.10.a2 release - fix problem with genrb path on F-12 and later * Thu Oct 8 2009 Rich Megginson - 1.1.10.a1-1 - the 1.1.10.a1 release -------------------------------------------------------------------------------- References: [ 1 ] Bug #552419 - 389-admin-1.1.10-0.2.a2.el5 fails to start https://bugzilla.redhat.com/show_bug.cgi?id=552419 -------------------------------------------------------------------------------- ================================================================================ 389-ds-base-1.2.6-0.1.a1.el5 (FEDORA-EPEL-2010-0132) 389 Directory Server (base) -------------------------------------------------------------------------------- Update Information: This is the alpha 1 release of 1.2.6. It contains two new features - subtree rename, and full support for SELinux enforcement. It also contains several bug fixes. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 15 2010 Nathan Kinder - 1.2.6-0.1.a1 - 1.2.6.a1 release - Added SELinux policy and subpackages * Tue Jan 12 2010 Rich Megginson - 1.2.5-1 - 1.2.5 final release * Mon Jan 4 2010 Rich Megginson - 1.2.5-0.5.rc4 - 1.2.5.rc4 release * Thu Dec 17 2009 Rich Megginson - 1.2.5-0.4.rc3 - 1.2.5.rc3 release -------------------------------------------------------------------------------- References: [ 1 ] Bug #543590 - Tracking bug for 389 Directory Server 1.2.6 https://bugzilla.redhat.com/show_bug.cgi?id=543590 -------------------------------------------------------------------------------- ================================================================================ R-2.10.1-1.el5 (FEDORA-EPEL-2010-0122) A language for data analysis and graphics -------------------------------------------------------------------------------- Update Information: Update R to 2.10.1. For full changelog notes, see: http://cran.r-project.org/src/base/NEWS -------------------------------------------------------------------------------- ChangeLog: * Mon Dec 21 2009 Tom "spot" Callaway - 2.10.1-1 - update to 2.10.1 - enable static html pages -------------------------------------------------------------------------------- ================================================================================ RackTables-0.17.8-1.el5 (FEDORA-EPEL-2010-0125) A datacenter asset management system -------------------------------------------------------------------------------- Update Information: Rebase to v0.17.8 -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 21 2010 - 0.17.8 - Rebase to v0.17.8 * Sun Nov 15 2009 - 0.17.7-2 - Address broken dependancies for PPC and PPC64 * Sat Nov 14 2009 - 0.17.7-1 - Rebase to v0.17.7 * Sat Sep 26 2009 - 0.17.5-1 - Rebase to v0.17.5 -------------------------------------------------------------------------------- ================================================================================ arpack-2.1-13.el5 (FEDORA-EPEL-2010-0129) Fortran77 subroutines for solving large scale eigenvalue problems -------------------------------------------------------------------------------- Update Information: First release in EPEL. -------------------------------------------------------------------------------- ================================================================================ dbus-cxx-0.6.0-1.el5 (FEDORA-EPEL-2010-0136) C++ bindings for the DBus library -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 22 2010 Rick L Vinyard Jr - 0.6.0-1 - New release -------------------------------------------------------------------------------- ================================================================================ dspam-3.9.0-3.el5 (FEDORA-EPEL-2010-0126) A library and Mail Delivery Agent for Bayesian SPAM filtering -------------------------------------------------------------------------------- Update Information: Initial package release. -------------------------------------------------------------------------------- ================================================================================ editarea-0.8.2-1.el5 (FEDORA-EPEL-2010-0127) A replacement for the HTML textarea tag -------------------------------------------------------------------------------- Update Information: Rebase to v0.8.2 -------------------------------------------------------------------------------- ChangeLog: * Thu Jan 21 2010 Colin Coe - 0.8.2-1 - Rebase to v0.8.2 -------------------------------------------------------------------------------- ================================================================================ garmindev-0.3.2-1.el5 (FEDORA-EPEL-2010-0138) Drivers for communication with Garmin GPS devices -------------------------------------------------------------------------------- Update Information: - added support for eTrex Legend Cx - big endian fixes -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 26 2010 Dan Hor?k 0.3.2-1 - update to version 0.3.2 -------------------------------------------------------------------------------- ================================================================================ ldns-1.6.4-2.el5 (FEDORA-EPEL-2010-0123) Lowlevel DNS(SEC) library with API -------------------------------------------------------------------------------- Update Information: Various bugfixes over 1.6.1. A few crashers and a few zone data read fixes. Feature: A new ldns-python package was added. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 22 2010 Paul Wouters - 1.6.4-2 - libtool on EL-5 does not take --install as argument * Fri Jan 22 2010 Paul Wouters - 1.6.4-1 - Upgraded to 1.6.4 - Added ldns-python sub package - Patch for installing ldns-python files - Patch for rpath in ldns-python -------------------------------------------------------------------------------- ================================================================================ milia-0.3.0-2.el5 (FEDORA-EPEL-2010-0134) C++ cosmology library -------------------------------------------------------------------------------- Update Information: C++ cosmology library -------------------------------------------------------------------------------- ================================================================================ munin-1.4.3-2.el5 (FEDORA-EPEL-2010-0120) Network-wide graphing framework (grapher/gatherer) -------------------------------------------------------------------------------- Update Information: Major update to new stable 1.4.3 release. This update IS backward compatible with the previous 1.2.6 version, and offers performance improvements and many new plugins. Please test. -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 17 2010 Kevin Fenzi - 1.4.3-2 - Fix owner on state files. - Add some BuildRequires. - Make munin-node-configure only run on install, not upgrade. bug 540687 * Thu Dec 31 2009 Kevin Fenzi - 1.4.3-1 - Update to 1.4.3 * Thu Dec 17 2009 Ingvar Hagelund - 1.4.2-1 - New upstream release - Removed upstream packaged fonts - Added a patch that makes rrdtool use the system bitstream vera fonts on rhel < 6 and fedora < 11 * Fri Dec 11 2009 Ingvar Hagelund - 1.4.1-3 - More correct fedora and el versions for previous font path fix - Added a patch that fixes a quoting bug in GraphOld.pm, fixing fonts on el4 * Wed Dec 9 2009 Ingvar Hagelund - 1.4.1-2 - Remove jmx plugins when not supported (like on el4 and older fedora) - Correct font path on older distros like el5, el4 and fedora<11 * Fri Dec 4 2009 Kevin Fenzi - 1.4.1-1 - Update to 1.4.1 * Sat Nov 28 2009 Kevin Fenzi - 1.4.0-1 - Update to final 1.4.0 version * Sat Nov 21 2009 Kevin Fenzi - 1.4.0-0.1.beta - Update to beta 1.4.0 version. - Add common subpackage for common files. * Sun Nov 8 2009 Kevin Fenzi - 1.4.0-0.1.alpha - Initial alpha version of 1.4.0 * Sat Jul 25 2009 Fedora Release Engineering - 1.2.6-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Wed Feb 25 2009 Fedora Release Engineering - 1.2.6-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild -------------------------------------------------------------------------------- ================================================================================ openvpn-2.1.1-2.el5 (FEDORA-EPEL-2010-0121) A full-featured SSL VPN solution -------------------------------------------------------------------------------- Update Information: New stable. -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 4 2010 Jon Ciesla 2.1.1-2 - Fix init script *.sh sourcing, BZ 498348. - Added init script info block, BZ 392991, BZ 541219. * Fri Dec 11 2009 Steven Pritchard 2.1.1-1 - Update to 2.1.1. * Sat Nov 21 2009 Steven Pritchard 2.1-0.39.rc22 - Update to 2.1_rc22. * Thu Nov 12 2009 Steven Pritchard 2.1-0.38.rc21 - Update to 2.1_rc21. -------------------------------------------------------------------------------- References: [ 1 ] Bug #544944 - Upgrade openvpn in EPEL to the latest version availble in rawhide ie openvpn-2.1-0.39.rc22 https://bugzilla.redhat.com/show_bug.cgi?id=544944 -------------------------------------------------------------------------------- ================================================================================ perl-Template-Toolkit-2.22-3.el5 (FEDORA-EPEL-2010-0140) Template processing system -------------------------------------------------------------------------------- Update Information: Update to 2.22 -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 15 2010 Stepan Kasal - 2.22-3 - drop build requirements for TeX; LaTeX support has been removed in 2.14a - fix the Obsoletes tag * Fri Dec 4 2009 Stepan Kasal - 2.22-2 - rebuild against perl 5.10.1 * Sat Jul 25 2009 Tom "spot" Callaway - 2.22-1 - update to 2.22 - obsolete examples package, upstream got rid of them * Fri Mar 13 2009 Tom "spot" Callaway - 2.20-1 - update to 2.20 * Thu Feb 26 2009 Fedora Release Engineering - 2.19-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Wed Feb 27 2008 Tom "spot" Callaway - 2.19-4 - Rebuild for perl 5.10 (again) * Tue Feb 19 2008 Fedora Release Engineering - 2.19-3 - Autorebuild for GCC 4.3 * Mon Jan 28 2008 Tom "spot" Callaway - 2.19-2 - rebuild for new perl * Sun Aug 26 2007 Tom "spot" Callaway - 2.19-1 - 2.19 - license tag fix - rebuild for BuildID -------------------------------------------------------------------------------- References: [ 1 ] Bug #513748 - RFE: Update perl-Template-Toolkit to 2.22 https://bugzilla.redhat.com/show_bug.cgi?id=513748 -------------------------------------------------------------------------------- ================================================================================ php-pear-Net-SMTP-1.4.0-1.el5 (FEDORA-EPEL-2010-0130) Provides an implementation of the SMTP protocol -------------------------------------------------------------------------------- Update Information: Upstream Changelog: The data() method now accepts either a string or a file resource containing the message data. (Request #16962) -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 24 2010 Remi Collet 1.4.0-1 - update to 1.4.0 - add examples to %doc -------------------------------------------------------------------------------- ================================================================================ php-pear-XML-Serializer-0.20.0-1.el5 (FEDORA-EPEL-2010-0118) Swiss-army knife for reading and writing XML files -------------------------------------------------------------------------------- Update Information: Upstream changelog 0.20.0 - Request #13564: bool(false) is converted to empty string 0.19.2 - Bug #15602: attributes don't get escaped sometimes [lapo] 0.19.1 - Bug #14653: testNumberedObjects testcase fails [ashnazg] - Doc #8650 : Missing Information in the Manual [ashnazg] - Doc #13896: Bad info in the RSS feed tutorial [ashnazg] - switch to package.xml v2 0.19.0 - PEAR CS cleanup - Req #13856: License Change from PHP to BSD [ashnazg] - Bug #8048: Entities are not replaced in tags with attributes [schst] - Doc #12725: tuto link no more available -------------------------------------------------------------------------------- ChangeLog: * Sun Jan 24 2010 Remi Collet 0.20.0-1 - update to 0.20.0 - License is BSD (since 0.19.0) - rename XML_Serializer.xml to php-pear-XML-Serializer.xml - add tests - add %check (documentation only) -------------------------------------------------------------------------------- ================================================================================ pki-common-1.3.1-1.el5 (FEDORA-EPEL-2010-0133) Dogtag Certificate System - PKI Common Framework -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Common Framework User Interface -------------------------------------------------------------------------------- References: [ 1 ] Bug #547527 - dogtag does not work with latest 389 DS https://bugzilla.redhat.com/show_bug.cgi?id=547527 -------------------------------------------------------------------------------- ================================================================================ pki-selinux-1.3.3-1.el5 (FEDORA-EPEL-2010-0128) Dogtag Certificate System - PKI Selinux Policies -------------------------------------------------------------------------------- Update Information: Dogtag PKI Security Enhanced Linux -------------------------------------------------------------------------------- References: [ 1 ] Bug #521255 - New package for Dogtag PKI: pki-selinux https://bugzilla.redhat.com/show_bug.cgi?id=521255 -------------------------------------------------------------------------------- ================================================================================ pki-silent-1.3.1-1.el5 (FEDORA-EPEL-2010-0116) Dogtag Certificate System - Silent Installer -------------------------------------------------------------------------------- Update Information: The Dogtag Silent Installer -------------------------------------------------------------------------------- References: [ 1 ] Bug #558670 - Update pki-silent templates to work with pki component registries https://bugzilla.redhat.com/show_bug.cgi?id=558670 -------------------------------------------------------------------------------- ================================================================================ pki-util-1.3.0-5.el5 (FEDORA-EPEL-2010-0137) Dogtag Certificate System - PKI Utility Framework -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Utility Framework -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 25 2010 Matthew Harmsen 1.3.0-5 - Created "_sharedstatedir/tomcat5/common/lib/cmsutil.jar" link - Created "_sharedstatedir/tomcat5/common/lib/nsutil.jar" link -------------------------------------------------------------------------------- References: [ 1 ] Bug #521989 - New Package for Dogtag PKI:pki-util https://bugzilla.redhat.com/show_bug.cgi?id=521989 -------------------------------------------------------------------------------- ================================================================================ python-beaker-1.5.1-1.el5 (FEDORA-EPEL-2010-0131) WSGI middleware layer to provide sessions -------------------------------------------------------------------------------- Update Information: Release 1.5 (11/23/2009) ======================== * Update memcached to default to using pylibmc when available. * Fix bug when cache value doesn't exist causing has_key to throw an exception rather than return False. * Fix bug where getpid under GAE is used improperly to assume it should be a non- string. * Add cache_region decorator that works *before* configuration of the cache regions have been completed for use in module-level decorations. * Fix bug where has_value sees the value before its removed. * Improved accuracy of "dogpile" checker by removing dependency on "self" attributes, which seem to be slightly unreliable in highly concurrent scenarios. Release 1.4.2 (9/25/2009) ========================= * Fix bug where memcached may yank a value after the has_value but before the value can be fetched. * Fix properties for setting the path. * Fix the 'TypeError: argument must be an int, or have a fileno() method' erorr sporadically emitted by FileSynchronizer under moderate load. Release 1.4.1 (9/10/2009) ========================= * Fix verification of options to throw an error if a beaker param is an empty string. * Add CacheManager.invalidate function to easily invalidate cache spaces created by the use of the cache decorator. * Add CacheManager.region_invalidate function to easily invalidate cache spaces created by the use of the cache_region decorator. * Fix the InvalidCryptoBackendError exception triggering a TypeError. Release 1.4 (7/24/2009) ======================= * Fix bug with hmac on Python 2.4. * Fix bug with occasional ValueError from FileNamespaceManager.do_open. * Fixed bug with session files being saved despite being new and not saved. * Fixed bug with CacheMiddleware overwriting configuration with default arguments despite prior setting. * Fixed bug with SyntaxError not being caught properly in entry point discovery. * Changed to using BlobProperty for Google Datastore. * Added domain/path properties to the session. This allows one to dynamically set the cookie's domain and/or path on the fly, which will then be set on the cookie for the session. * Added support for cookie-based sessions in Jython via the JCE (Java Cryptography Extensions).. * Update Beaker database extensions to work with SQLAlchemy 0.6 PostgreSQL, and Jython. -------------------------------------------------------------------------------- ChangeLog: * Fri Jan 22 2010 Luke Macken - 1.5.1-1 - Update to 1.5.1 - Remove beaker-hmac2.4.patch, which made it into 1.4 upstream - Remove middleware-config.patch which is also upstream -------------------------------------------------------------------------------- ================================================================================ sipp-3.1-8.svn586.el5 (FEDORA-EPEL-2010-0139) SIP test tool / traffic generator -------------------------------------------------------------------------------- Update Information: %changelog * Mon Jan 25 2010 Peter Lemenkov 3.1-8.svn586 - Update to svn ver. 586 (fixes lots of small but nasty issues) - Removed patch1, patch3 -------------------------------------------------------------------------------- ChangeLog: * Mon Jan 25 2010 Peter Lemenkov 3.1-8.svn586 - Update to svn ver. 586 (fixes lots of small but nasty issues) - Removed patch1, patch3 * Fri Aug 21 2009 Tomas Mraz - 3.1-7 - rebuilt with new openssl * Sun Jul 26 2009 Fedora Release Engineering - 3.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild -------------------------------------------------------------------------------- ================================================================================ xl2tpd-1.2.5-1.el5 (FEDORA-EPEL-2010-0124) Layer 2 Tunnelling Protocol Daemon (RFC 2661) -------------------------------------------------------------------------------- Update Information: Upgraded to 1.2.3 which fixes interop with two Windows machines behind the same NAT router -------------------------------------------------------------------------------- ChangeLog: * Sat Jan 9 2010 Paul Wouters - 1.2.5-1 - Upgraded to 1.2.5. (fixes interop with two Windows machines behind same NAT) - Fix mix space/tab in spec file -------------------------------------------------------------------------------- ================================================================================ znc-0.078-1.el5 (FEDORA-EPEL-2010-0117) An advanced IRC bouncer -------------------------------------------------------------------------------- Update Information: Update to znc 0.078 -------------------------------------------------------------------------------- ChangeLog: * Wed Dec 30 2009 Nick Bebout - 0.078-1 - Update to znc 0.078 * Sun Dec 13 2009 Nick Bebout - 0.078-0.1.rc1 - Update to znc 0.078.rc1 -------------------------------------------------------------------------------- From pierre.casenove at almerys.com Thu Jan 28 14:51:38 2010 From: pierre.casenove at almerys.com (pierre.casenove at almerys.com) Date: Thu, 28 Jan 2010 15:51:38 +0100 Subject: OpenVPN 2.1.1 Message-ID: Hello list, Currently, openvpn 2.1.0 RC15 is included in EPEL 5. Final version 2.1.1 (adding official support for windows 7) has been released on 2009-12-11. the RPM are already available for FC 12 and FC 13. What is the process to have it in EPEL for RHEL 5? How long could it take (so that I can plan the 7 migration in my entreprise)? Thanks in advance, Pierre Casenove From paul at city-fan.org Thu Jan 28 15:04:56 2010 From: paul at city-fan.org (Paul Howarth) Date: Thu, 28 Jan 2010 15:04:56 +0000 Subject: OpenVPN 2.1.1 In-Reply-To: References: Message-ID: <4B61A798.6000203@city-fan.org> On 28/01/10 14:51, pierre.casenove at almerys.com wrote: > Hello list, > Currently, openvpn 2.1.0 RC15 is included in EPEL 5. Final version 2.1.1 > (adding official support for windows 7) has been released on 2009-12-11. > the RPM are already available for FC 12 and FC 13. > What is the process to have it in EPEL for RHEL 5? How long could it take > (so that I can plan the 7 migration in my entreprise)? openvpn-2.1.1-2.el5 was pushed to EPEL-5 updates-testing on the 26th January. It'll probably hit EPEL-5 proper in a couple of weeks. Paul. From pierre.casenove at almerys.com Thu Jan 28 15:06:50 2010 From: pierre.casenove at almerys.com (pierre.casenove at almerys.com) Date: Thu, 28 Jan 2010 16:06:50 +0100 Subject: OpenVPN 2.1.1 In-Reply-To: <4B61A798.6000203@city-fan.org> References: <4B61A798.6000203@city-fan.org> Message-ID: Thanks a lot for this clear, quick and precise answer! Pierre De : Paul Howarth A: epel-devel-list at redhat.com Date: 28/01/2010 16:06 Objet : Re: OpenVPN 2.1.1 Envoy? par : epel-devel-list-bounces at redhat.com On 28/01/10 14:51, pierre.casenove at almerys.com wrote: > Hello list, > Currently, openvpn 2.1.0 RC15 is included in EPEL 5. Final version 2.1.1 > (adding official support for windows 7) has been released on 2009-12-11. > the RPM are already available for FC 12 and FC 13. > What is the process to have it in EPEL for RHEL 5? How long could it take > (so that I can plan the 7 migration in my entreprise)? openvpn-2.1.1-2.el5 was pushed to EPEL-5 updates-testing on the 26th January. It'll probably hit EPEL-5 proper in a couple of weeks. Paul. _______________________________________________ epel-devel-list mailing list epel-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list From limb at jcomserv.net Thu Jan 28 15:08:41 2010 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 28 Jan 2010 09:08:41 -0600 Subject: OpenVPN 2.1.1 In-Reply-To: References: Message-ID: <4B61A879.9050407@jcomserv.net> pierre.casenove at almerys.com wrote: > Hello list, > Currently, openvpn 2.1.0 RC15 is included in EPEL 5. Final version 2.1.1 > (adding official support for windows 7) has been released on 2009-12-11. > the RPM are already available for FC 12 and FC 13. > What is the process to have it in EPEL for RHEL 5? How long could it take > (so that I can plan the 7 migration in my entreprise)? > > Thanks in advance, > > Pierre Casenove > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > Hi, I build and pushed that update. It's in Bodhi here: https://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-0121?_csrf_token=e6ea117d0820133d05c2ad2c651dff87a0771460 Grab it from Koji, test it. If it works for you, give it good Karma. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From updates at fedoraproject.org Thu Jan 28 21:16:06 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Thu, 28 Jan 2010 21:16:06 +0000 Subject: Fedora EPEL 4 updates-testing report Message-ID: <20100128211845.B4BA910FB36@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 4 updates-testing sagator-1.2.0-1.el4 Details about builds: ================================================================================ sagator-1.2.0-1.el4 (FEDORA-EPEL-2010-0147) Antivir/antispam gateway for smtp server -------------------------------------------------------------------------------- Update Information: New upstream release. This version has been updated to run well on Python 2.6 and with clamav 0.95+. There are some performance improvements, especially in greylist service, which now can run on high... load servers too. KID templates have been replaced by genshi, since genshi is faster and has better support on Linux distributions. -------------------------------------------------------------------------------- ChangeLog: * Tue Jul 28 2009 Jan ONDREJ (SAL) - 1.2.0-1 - Requires: smtpdaemon again for EPEL -------------------------------------------------------------------------------- From updates at fedoraproject.org Thu Jan 28 21:16:06 2010 From: updates at fedoraproject.org (updates at fedoraproject.org) Date: Thu, 28 Jan 2010 21:16:06 +0000 Subject: Fedora EPEL 5 updates-testing report Message-ID: <20100128211845.CEB7D10F95A@bastion2.fedora.phx.redhat.com> The following builds have been pushed to Fedora EPEL 5 updates-testing mldonkey-3.0.1-1.el5 mysql-mmm-2.0.10-4.el5 perl-Net-ARP-1.0.6-2.1.el5 perl-Net-Whois-1.9-2.el5 php-pear-PHP-CodeSniffer-1.2.2-1.el5 pki-ra-1.3.0-4.el5 repoview-0.6.4-1.el5 sagator-1.2.0-1.el5 supybot-fedora-0.2.7-1.el5 udis86-1.7-3.el5 Details about builds: ================================================================================ mldonkey-3.0.1-1.el5 (FEDORA-EPEL-2010-0150) Client for several P2P networks -------------------------------------------------------------------------------- Update Information: First working version for EPEL. -------------------------------------------------------------------------------- ================================================================================ mysql-mmm-2.0.10-4.el5 (FEDORA-EPEL-2010-0148) Multi-Master Replication Manager for MySQL -------------------------------------------------------------------------------- ================================================================================ perl-Net-ARP-1.0.6-2.1.el5 (FEDORA-EPEL-2010-0148) Create and Send ARP Packets -------------------------------------------------------------------------------- ================================================================================ perl-Net-Whois-1.9-2.el5 (FEDORA-EPEL-2010-0144) Get and parse "whois" domain data from InterNIC -------------------------------------------------------------------------------- Update Information: Initial import (#558388) -------------------------------------------------------------------------------- ================================================================================ php-pear-PHP-CodeSniffer-1.2.2-1.el5 (FEDORA-EPEL-2010-0146) PHP coding standards enforcement tool -------------------------------------------------------------------------------- Update Information: - upstream 1.2.2 ( bug:559170 ) - move phpcs into main package ( bug: 517775 ) - add php-common version requirement -------------------------------------------------------------------------------- ChangeLog: * Wed Jan 27 2010 Christof Damian 1.2.2-1 - upstream 1.2.2 ( bug:559170 ) - move phpcs into main package ( bug: 517775 ) - add php-common version requirement -------------------------------------------------------------------------------- ================================================================================ pki-ra-1.3.0-4.el5 (FEDORA-EPEL-2010-0141) Dogtag Certificate System - Registration Authority -------------------------------------------------------------------------------- Update Information: The Dogtag PKI Registration Authority -------------------------------------------------------------------------------- References: [ 1 ] Bug #553850 - Review Request: pki-ra - The Dogtag PKI Registration Authority https://bugzilla.redhat.com/show_bug.cgi?id=553850 -------------------------------------------------------------------------------- ================================================================================ repoview-0.6.4-1.el5 (FEDORA-EPEL-2010-0142) Creates a set of static HTML pages in a yum repository -------------------------------------------------------------------------------- Update Information: Fixes a problem on Fedora 12 and above. A few other minor bugfixes. -------------------------------------------------------------------------------- ChangeLog: * Wed Jan 27 2010 Konstantin Ryabitsev - 0.6.4-1 - Upstream 0.6.4 (bugfixes) -------------------------------------------------------------------------------- References: [ 1 ] Bug #498752 - No more "letters" pages with sqlite 3.6 https://bugzilla.redhat.com/show_bug.cgi?id=498752 [ 2 ] Bug #557844 - Update repoview to 0.6.4 https://bugzilla.redhat.com/show_bug.cgi?id=557844 -------------------------------------------------------------------------------- ================================================================================ sagator-1.2.0-1.el5 (FEDORA-EPEL-2010-0145) Antivir/antispam gateway for smtp server -------------------------------------------------------------------------------- Update Information: New upstream release. This version has been updated to run well on Python 2.6 and with clamav 0.95+. There are some performance improvements, especially in greylist service, which now can run on high... load servers too. KID templates have been replaced by genshi, since genshi is faster and has better support on Linux distributions. -------------------------------------------------------------------------------- ChangeLog: * Tue Jul 28 2009 Jan ONDREJ (SAL) - 1.2.0-1 - Requires: smtpdaemon again for EPEL -------------------------------------------------------------------------------- ================================================================================ supybot-fedora-0.2.7-1.el5 (FEDORA-EPEL-2010-0149) Plugin for Supybot to interact with Fedora services -------------------------------------------------------------------------------- Update Information: update to 0.2.7 upstream -------------------------------------------------------------------------------- ChangeLog: * Tue Jan 26 2010 Ian Weller - 0.2.7-1 - New upstream 0.2.7 -------------------------------------------------------------------------------- ================================================================================ udis86-1.7-3.el5 (FEDORA-EPEL-2010-0143) A disassembler library for x86 and x86-64 -------------------------------------------------------------------------------- Update Information: udis86 is a disassembler library (libudis86) for x86 and x86-64. The primary intent is to aid binary code analysis. -------------------------------------------------------------------------------- References: [ 1 ] Bug #543840 - Review Request: udis86 - A x86 disassembler library https://bugzilla.redhat.com/show_bug.cgi?id=543840 -------------------------------------------------------------------------------- From jeff at osuosl.org Fri Jan 29 21:18:41 2010 From: jeff at osuosl.org (Jeff Sheltren) Date: Fri, 29 Jan 2010 13:18:41 -0800 Subject: Bi-Weekly Meetings Message-ID: <4B6350B1.8020803@osuosl.org> We seem to have a lack of topics and a lack of attendance at EPEL meetings. Today we brought up the idea of moving the meetings to every other week instead of every week. I'm in favor of bi-weekly, at least for the time being. Please discuss :) -Jeff From kevin at scrye.com Fri Jan 29 21:29:08 2010 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 29 Jan 2010 14:29:08 -0700 Subject: Bi-Weekly Meetings In-Reply-To: <4B6350B1.8020803@osuosl.org> References: <4B6350B1.8020803@osuosl.org> Message-ID: <20100129142908.03932db9@ohm.scrye.com> On Fri, 29 Jan 2010 13:18:41 -0800 Jeff Sheltren wrote: > We seem to have a lack of topics and a lack of attendance at EPEL > meetings. Today we brought up the idea of moving the meetings to > every other week instead of every week. > > I'm in favor of bi-weekly, at least for the time being. > > Please discuss :) Fine with me I guess. The downside is that it's hard to remember which weeks are meeting weeks, and which are not. Also, if anyone would like to start chairing the meetings and gathering agenda that would be lovely. :) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: