vmemcache failed to build from source in Fedora rawhide/f33 https://koji.fedoraproject.org/koji/taskinfo?taskID=48362338 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Please fix vmemcache at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, vmemcache will be orphaned. Before branching of Fedora 34, vmemcache will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source
Created attachment 1709980 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 1709981 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1709982 [details] state.log
There's an LTO component here. I'll take it for now.
With LTO, calls to Zalloc within the DSO are turned into calls to calloc. Why? Nothing calls util_set_alloc_funcs & its got local scope from the DSO's point of view and thus Malloc is a constant (malloc) and thus Zalloc turns into malloc+memset which is then transformed into calloc). Those calls to calloc then go into the libc DSO which calls malloc which is satisfied by the libc DSO. That all bypasses the intercepts set up by the testsuite and as a result the accounting of how much space is allocated vs how much is freed is inaccurate. What this all means is the test is flawed and it should be intercepting calloc as well. In the mean time, I'm going to disable LTO for this package. It's still failing its testsuite, but not due to any LTO issues. The package maintainer needs to step in a fix the testsuite issues to resolve the FTBFS.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Fixed, in f33 and rawhide.