Fedora Account System
Red Hat Associate
Red Hat Customer
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/lecris/cmake-4.0/package/open-amp. 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.
According to the change all OLD options < 3.5 are being dropped, but open-amp has a check for 3.16 which is newer that 3.5 so I am not sure why this is a problem?
Are you referring to this commit https://github.com/OpenAMP/open-amp/commit/8c0c0c386b5799b54faf9613a191f66dee76e400? This was only present in v2025.04.0, but you can safely backport it. PS: You can suggest them to include a higher-bound policy if you wish to be kind to future maintainers.
(In reply to Cristian Le from comment #2) > Are you referring to this commit > https://github.com/OpenAMP/open-amp/commit/ > 8c0c0c386b5799b54faf9613a191f66dee76e400? This was only present in > v2025.04.0, but you can safely backport it. I'm planning on updating so that should be fine. > PS: You can suggest them to include a higher-bound policy if you wish to be > kind to future maintainers. Personally I'm not sure their reason to set a particular version and I don't think it's a distro maintainer to dictate to an upstream project versions, I would hope they're smart enough to set reasonable versions for considered reasons.
Their reasons for that version is because of debian releases as outlined in this PR: https://github.com/OpenAMP/libmetal/pull/327
> Personally I'm not sure their reason to set a particular version and I don't think it's a distro maintainer to dictate to an upstream project versions, I would hope they're smart enough to set reasonable versions for considered reasons. This is a safe recommendation you can make. For the most cases upstream is not aware of how `cmake_minimum_required` works, but if you set a higher bound matching *any* version they have in the CI, then it is a safe usage, and it minimizes the need to bump it in the downstream. > Their reasons for that version is because of debian releases as outlined in this PR: https://github.com/OpenAMP/libmetal/pull/327 That's only the reason for lower-bound, which indeed it is a more difficult point to consider. But anyway, thanks for the link, I'll contact upstream about it there.
Updated to new upstream which has this fixed.