Overview
Request 834369 accepted
- Update to 0.103.0
* clamd can now reload the signature database without blocking
scanning. This multi-threaded database reload improvement was made
possible thanks to a community effort.
- Non-blocking database reloads are now the default behavior. Some
systems that are more constrained on RAM may need to disable
non-blocking reloads as it will temporarily consume two times as
much memory. We added a new clamd config option
ConcurrentDatabaseReload, which may be set to no.
* Dropped clamav-str-h.patch (no longer needed)
* Fix clamav-milter.service (requires clamd.service to run)
Request History
adkorte created request
- Update to 0.103.0
* clamd can now reload the signature database without blocking
scanning. This multi-threaded database reload improvement was made
possible thanks to a community effort.
- Non-blocking database reloads are now the default behavior. Some
systems that are more constrained on RAM may need to disable
non-blocking reloads as it will temporarily consume two times as
much memory. We added a new clamd config option
ConcurrentDatabaseReload, which may be set to no.
* Dropped clamav-str-h.patch (no longer needed)
* Fix clamav-milter.service (requires clamd.service to run)
rmax accepted request
Thanks
@rmax, @toganm: review reminder
Is it intentional that you added
BuildRequires: valgrindonly as a comment?Yes. Uncommenting that line will indeed run the check_unit_vg.sh, check5_clamd_vg.sh, check6_clamd_vg.sh and check9_clamscan_vg.sh tests, but unfortunately three of them are failing at the moment (a couple of open file descriptors on exit, nothing serious as far as I can see).
I couldn't find a way to ignore the results of these test while still performing the others, other than commenting out this line. If it bothers you, I could also remove it (I now know how to run these tests, after fixing the line in the .spec file).
The commented-out line as such doesn't bother me at all, I was just wondering about the intention, because I also from time to time forget to comment stuff back in that I commented out temporarily while working on a package. Maybe a comment above the commented line would have been helpful to make the intentions clear.
With the help of upstream, I found what is going on. We use LTO by default for while already in Tumbleweed and this seems to strip some symbols that are needed for the following suppression rule for a known false positive: https://github.com/Cisco-Talos/clamav-devel/commit/8cfec0b245abfac9564c11012d67b19da004e927
With LTO disabled, this works and the valgrind tests pass. With LTO enabled, they fail.