Bug 2320146

Hello,

Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/

This package fails to install and maintainers are advised to take one of the following actions:

 - Fix this bug and close this bugzilla once the update makes it to the repository.
   (The same script that posted this comment will eventually close this bugzilla
   when the fixed package reaches the repository, so you don't have to worry about it.)

or

 - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet.

or

 - Orphan the package if you no longer plan to maintain it.


If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue.
This package may be orphaned in 7+ weeks.
This is the first reminder (step 3) from the policy.

Don't hesitate to ask for help on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ if you are unsure how to fix this bug.

I'm still looking for a solution but CubicSDR appears to be largely unmaintained upstream and is incompatible with the latest rtaudio release.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Blocks the uprade to f42 (dnf, haven't tried other methods) if it is installed. I guess I'll just uninstall it for now, but it would be nice to have it available on f42 again. Are there any alternatives you can recommend in case we can't fix it? I wonder whether it should be patched, forked or replaced by something else in case the upstream maintainer stays unresponsive.

For my case CubicSDR is the only user of librtaudio, so seems like F41->F42 upgrade could be unblocked with ignoring rtaudio package.
`dnf distro-sync --releasever=42 -x rtaudio` allows it, at least. I'll test it soon.

If the upstream maintainer stays unresponsive - is it allowed by Fedora policies to apply an own patch for such a build issues? I'd try to prepare such a fix if so.

Some temporary solution might be to switch USE_SYSTEM_RTAUDIO off in CubicSDR cmake config and build using the copy included into CubicSDR sources. But upstream fix is better of course.

Thanks for the idea, I wouldn't dare to use any other upgrade method then the official one but reinstalling the f41 rtaudio afterwards might work as a temporary workaround. (I believe that is what you'd achieve with the command.)

Fixing build issues by an own patch is commonplace, I haven't reviewed the rules in detail but I'm confident to say that it is allowed. I have no idea how complex such a patch would be for this issue, I've patched some build issues in mupen64plus for example which were just a few import lines. Sending those patches upstream is recommended though, as well as adding a comment to the spec file which points to the upstream PR. (Not all packagers follow this recommendation.)

For using the included copy (vendoring) I'd need to consult the packaging guidelines, I think it is allowed under certain conditions, but that should checked imo. Patching would be the preferred way if it is not too complicated. Let me know if I can be of assistance :)

Someone just commented on the Github issue, maybe there are useful pointers on how to patch it: https://github.com/cjcliffe/CubicSDR/issues/1038

(In reply to David Auer from comment #7)
Yes, installing rtaudio-5.*.fc41.* to F42 should give the same result I guess. Assuming that the specific installation has no users of it other than CubicSDR.

As for patch, seems like v6-only fix might be really small: https://salsa.debian.org/debian-hamradio-team/soapysdr/soapyaudio/-/commit/499e87f20942754050e68e61b0d370c53d34bdcd
It might be not suitable for upstream because of breaking compatibility with v5. But we don't need it for F42-specific patch, as far as I understand.

I already reproduced the build issue at F42 and will try to patch it in a way similar to the linked above. It seems like the simplest fix for F42 before upstream prepares its own.

Created attachment 2086161 [details]
possible fix using new rtaudio api

Attached patch unblocks the build if added as Patch1 to CubicSDR.spec in F42.
Needs more testing and review - I have insufficient experience with C++.
(Most of changes are indents because of removed try/catch block)

Alternatively I can make a patch for https://src.fedoraproject.org/rpms/CubicSDR.git
or another review service if exists.

Might be helpful: http://www.music.mcgill.ca/~gary/rtaudio/errors.html (official rtaudio page)