Args...yes. You are right. Sorry, my mistake.
/etc/cron.daily/freshclam fails with "WARNING: Can't get information about user clamav." -> freshclam --user=clam required
Resolving Dependencies --> Running transaction check ---> Package perl-Mail- Box.noarch 0:2.097-1.el5.1 set to be updated --> Processing Dependency: perl(File::FcntlLock) for package: perl-Mail-Box --> Finished Dependency Resolution perl-Mail-Box-2.097-1.el5.1.noarch from epel-testing has depsolving problems --> Missing Dependency: perl(File::FcntlLock) is needed by package perl-Mail-Box-2.097-1.el5.1.noarch (epel-testing) Error: Missing Dependency: perl(File::FcntlLock) is needed by package perl-Mail-Box-2.097-1.el5.1.noarch (epel-testing)
Please push to stable ASAP
The new ejabberd version is running on all my productive machines since 2010-12-22 without any issue.
The new apcupsd version is running on all my productive machines since 2010-12-09 without any issue.
The new bacula version is running on all my productive machines since 2010-03-26; I didn't find any incompatibilities for the time being.
The update seems to work - at least no failures during the whole day here.
Waiting until RHEL 5.6 is not a solution. EPEL is not allowed to break RHEL.
From my point of view you are simply not allowed to provide a library having the same soname and same soversion as RHEL 5 does - this violates the EPEL policy right now, because we conflict with RHEL as our upstream.
Conflicting with samba3x is NOT the correct solution. Because now, a "yum install samba3x" fails with "libtalloc-2.0.1-3.el5.x86_64 from epel-testing has depsolving problems: libtalloc conflicts with samba3x-common" - because of "Processing Dependency: libtalloc.so.1()(64bit) for package: samba3x"
For my employer, this update introduced a regression/new bug: https://bugzilla.redhat.com/show_bug.cgi?id=713829