Description of problem: ClamAV's 'make check' fails on Fedora 13, looks like the Fedora package doesn't run 'make check'. Version-Release number of selected component (if applicable): 0.96.x How reproducible: Always Steps to Reproduce: 1. Build ClamAV 2. Run 'make check' Actual results: check3_clamd.sh fails due to RH bug #598498/#640286 Expected results: 'make check' run when/after package is built, problem discovered earlier Additional info: Since 'make check' was not run I only found #598498 when testing 'make check' on RHEL6 beta, which was closed as notabug. Since Fedora 13 has experimental malloc enabled in libc too, and 'make check' doesn't fail there (or so I thought), I thought it is RHEL6 specific and didn't investigate further. It turns out the problem (from bug #640286) exists in Fedora 13's libc as well, See bug #640286: 8 threads ask for 1MB each, and considering the default 10MB stack that should total ~88MB, yet it tries to allocate ~547MB which is way more than requested. Something is seriously wrong with --enable-experimental-malloc in glibc in RHEL6 and Fedora 13. Had Fedora packages run 'make check' this would have been discovered (and hopefully fixed) earlier. BTW increasing ulimit in the scripts allows 'make check' to succeed, but that only masks the libc bug.
clamav-0.96.4-1400.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/clamav-0.96.4-1400.fc14
clamav-0.96.4-1300.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/clamav-0.96.4-1300.fc13
ok; I will execute 'make check' but ignore errors for now because tests do not seem to work properly (on my local f13 machine 4 expected-fail tests succeed, on fedora koji they work, fedora koji f14 checks fail, f15 are ok).
(In reply to comment #3) > ok; I will execute 'make check' but ignore errors for now OK, Thanks. > because tests do not > seem to work properly (on my local f13 machine 4 expected-fail tests succeed, > on fedora koji they work, fedora koji f14 checks fail, f15 are ok). Can you send me the 'make check' output for those that fail? For 0.97 I dropped the LLVM parts of make check, so if you want you can give a try to latest git code, and see if 'make check' passes now.
clamav-0.96.4-1400.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update clamav'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/clamav-0.96.4-1400.fc14
Created attachment 458847 [details] local f13 'make check' errors
@comment 4: http://kojipkgs.fedoraproject.org/packages/clamav/0.96.4/1400.fc14/data/logs/x86_64/build.log
(In reply to comment #6) > Created attachment 458847 [details] > local f13 'make check' errors Thanks. The XPASS is in a garbage collector test, ClamAV doesn't use it though, so you can ignore it (as far as ClamAV is concerned). Interesting that it only XPASSes on Fedora though. (In reply to comment #7) > @comment 4: > > http://kojipkgs.fedoraproject.org/packages/clamav/0.96.4/1400.fc14/data/logs/x86_64/build.log That one looks like a python bug: Testing: 0 ..Fatal Python error: Couldn't create autoTLSkey mapping /bin/sh: line 1: 23286 Aborted (core dumped) /builddir/build/BUILD/clamav-0.96.4/libclamav/c++/llvm/utils/lit/lit.py -s -v --no-tcl-as-sh CodeGen ExecutionEngine Integer Verifier In 0.97 the LLVM tests won't be run anymore [*], and the remaining tests won't use python, so hopefully all tests will pass there. [*] Because for 0.97 (and even for 0.96.4 actually) you can link to system's LLVM 2.8 libs. You just need to pass --with-system-llvm=/path/to/llvm-config, and then the embedded copy of LLVM won't be built/used.
clamav-0.96.4-1400.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
clamav-0.96.4-1300.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.