Description of problem: We discovered an incompatibility between Mixxx (RPM Fusion) and the new RubberBand version 1.9.1 that probably leads to invalid memory access with all kinds of undefined behavior in Mixxx. All releases f32-f35 are affected. https://github.com/breakfastquay/rubberband/issues/37 https://bugs.launchpad.net/mixxx/+bug/1921955 The issues are caused by different build options for KissFFT in Mixxx and RubberBand that affect the ABI. By switching from KissFFT to FFTW those issues could be avoided in the first place. The next version of RubberBand might include a new, internal FFT implementation. Until then using FFTW is the safe path. Version-Release number of selected component (if applicable): - Mixxx 2.3 - Rubberband 1.9.1 How reproducible: Always (at least during in tests) Steps to Reproduce: 1. Run the Mixxx test suite Actual results: Test failures Memory corruption and subsequent crashes Expected results: Tests succeed No crashes Additional info: A pull request for rawhide is already available but I didn't get any response. https://src.fedoraproject.org/rpms/rubberband/pull-request/1 The changes could easily be backported to all other Fedora releases.
Ping. This is a major issue for us that we cannot resolve easily without the help from Fedora. Apparently, due to relying on default build flags the dependency on FFTW got orphaned and is no longer used. I have updated and simplified the proposed patch. Only explicit build flags were missing to restore the behavior of RubberBand 1.9.0, i.e. using FFTW and libsamplerate.
Increased the severity to Hight to get a response.
Hi Michel, Could you take a look into this when you have a minute? I'm a proven packager and can help with the PR + builds + updates if necessary. Cheers, Ankur
I still didn't receive any response, neither to this bug report nor to the PR. PS: This makes me worry, because I was assuming that Fedora is a well maintained project and even promoted it.
Packages in Fedora are maintained by volunteers who work on packages in their free time. Things happen, things come up, so sometimes maintainers are unable to respond. This is why we have the non-responsive package maintainer process: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ The calendar shows that Michel was on parental leave a month ago, so I wouldn't be surprised if they're still busy with parental duties :) https://apps.fedoraproject.org/calendar/list/vacation/ I've dropped both maintainers an e-mail now, but please feel free to star the non responsive process as noted in the link above.
FEDORA-2021-9b4a1b1bb1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-9b4a1b1bb1
FEDORA-2021-353c19b795 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-353c19b795` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-353c19b795 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-9b4a1b1bb1 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-9b4a1b1bb1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9b4a1b1bb1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-353c19b795 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-9b4a1b1bb1 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.