\ Dear package maintainer, This is an automated bug created due to a FTBFS when rebuilding this package for the change proposal CMake 4.0. The rebuild is being tracked in https://copr.fedorainfracloud.org/coprs/cmake-4.0. See https://fedoraproject.org/wiki/Changes/CMake4.0 for more information on how to make the package compatible. More specifically, depending on the state of the project: - If it is actively maintained, please update the `cmake_minimum_required`, and instruct upstream to do so as well. To minimize future maintenance, please add a higher bound as well, preferrably with the highest CMake version being tested. You may use 4.0 as the higher bound as this is being tested in the tracked copr project. - If the project is not maintained, you may add `CMAKE_POLICY_VERSION_MINIMUM=3.5` as a CMake variable or environment variable. You can check the build locally following the instructions in the change proposal, or submit your build to the tracking copr project. Let me know if you encounter any issues, or need any other help.
Resolved for 2372324.
Do you mean to have this bug depend on https://bugzilla.redhat.com/show_bug.cgi?id=2372324 ? I don't see how the dependency is the other way around. Anyway, let me know if you managed to build with 4.0 and it all works well.
Rex hasn't been responding to requests so I'm currently working on getting access to maintain cantata. I've built what will be the updated package, which will be at 3.3.1, currently the 2.5.0 release is about 4 years old. I've updated the 3.3.1 package and it built fine for F43 with cmake4 changes, however it is currently failing when I tried another build. Here is the copr if you want to take a look: https://copr.fedorainfracloud.org/coprs/gbcox/dogfood/build/9280410/ I'll go ahead and change the assignee to me.
Latest rawhide copr build ok for cmake4: https://copr.fedorainfracloud.org/coprs/gbcox/dogfood/build/9280890/
Thanks, I take it that upstream has fixed any incompatibilities themselves. One question though, what's up with the `%if 0%{?fedora} >= 43` and calling `cmake` manually? The macros are still present before that.
(In reply to Cristian Le from comment #5) > Thanks, I take it that upstream has fixed any incompatibilities themselves. > One question though, what's up with the `%if 0%{?fedora} >= 43` and calling > `cmake` manually? The macros are still present before that. I was trying to do a conditional path for Fedora ≥ 43 since the %cmake macros are deprecated with CMake 4.0. The macros are only present in the %else block to support Fedora ≤ 42 builds. If it looks like they’re outside the conditional, I can double-check the structure or reformat for clarity. Was that what you were referring to? If I've done it wrong, please LMK. Also, yes for 3.3.1 things have been modified upstream.
`%cmake` macros are not deprecated. `%cmake3` macros are. Sorry if I made it confusing in the change proposal. Could you double-check that I did not write it the other way around there?
Thanks — I misunderstood and thought raw cmake was preferred for CMake 4.0. I’ll switch back to using %cmake, %cmake_build, and %cmake_install for Fedora ≥ 43 to stay consistent with packaging guidelines.