Bug 2381334

Summary:	open-amp: FTBFS with change proposal CMake 4.0
Product:	[Fedora] Fedora	Reporter:	Cristian Le <fedora>
Component:	open-amp	Assignee:	Peter Robinson <pbrobinson>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	pbrobinson
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-07-24 11:12:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2376114

Description Cristian Le 2025-07-16 16:52:52 UTC

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.

Comment 1 Peter Robinson 2025-07-18 09:06:43 UTC

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?

Comment 2 Cristian Le 2025-07-18 10:03:11 UTC

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.

Comment 3 Peter Robinson 2025-07-18 12:37:41 UTC

(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.

Comment 4 Peter Robinson 2025-07-18 12:40:09 UTC

Their reasons for that version is because of debian releases as outlined in this PR: https://github.com/OpenAMP/libmetal/pull/327

Comment 5 Cristian Le 2025-07-18 12:46:24 UTC

> 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.

Comment 6 Peter Robinson 2025-07-24 11:12:58 UTC

Updated to new upstream which has this fixed.