Bug 2321199

Summary: Please branch and build librttopo in epel10
Product: [Fedora] Fedora EPEL Reporter: Troy Dawson <tdawson>
Component: librttopoAssignee: Sandro Mani <manisandro>
Status: CLOSED RAWHIDE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel10CC: manisandro
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-10-23 16:02:20 UTC Type: Bug
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: 2318744    

Description Troy Dawson 2024-10-22 21:45:28 UTC
Please branch and build librttopo in epel10

If you do not wish to maintain librttopo in epel10,
or do not think you will be able to do this in a timely manner,
I would be happy to be a co-maintainer of the package (FAS tdawson);
please add me through https://src.fedoraproject.org/rpms/librttopo/adduser

Comment 1 Sandro Mani 2024-10-22 21:57:31 UTC
Hmm, not sure what's going on here:

DEBUG util.py:461:  Error: 
DEBUG util.py:461:   Problem 1: conflicting requests
DEBUG util.py:461:    - nothing provides mingw32(libstdc++-6.dll) needed by mingw32-geos-3.13.0-1.el10_0.noarch from build
DEBUG util.py:461:   Problem 2: conflicting requests
DEBUG util.py:461:    - nothing provides mingw64(libstdc++-6.dll) needed by mingw64-geos-3.13.0-1.el10_0.noarch from build

Comment 2 Troy Dawson 2024-10-22 22:06:19 UTC
That's strange, I was able to do a local epel10 mock build of the rawhide package and it worked fine.

Comment 3 Sandro Mani 2024-10-22 22:11:17 UTC
Not all arches are affected: https://koji.fedoraproject.org/koji/taskinfo?taskID=125098879, looks like just aarch64 and s390x

Comment 4 Troy Dawson 2024-10-22 22:26:45 UTC
Looking through the CentOS Stream 10 repos, mingw32-libstdc++ packages are ONLY on x86_64.
I guess geos needs to not build it's mingw stuff on the other arches.

Comment 5 Sandro Mani 2024-10-23 07:15:31 UTC
So I guess it just dependes on the arch of the builder which will build the package, as the packages themselves are for the most part noarch. Not sure what is the best way to force an arch for the builder, except perhaps marking the mingw packages themselves ExclusiveArch at toplevel, and the subpackages noarch?

Comment 6 Troy Dawson 2024-10-23 14:31:26 UTC
librttopo itself, is not a noarch package.  It get's built on every arch, it is just those mingw sub-packages that are noarch.
There is a '%bcond_without mingw' at the top of the spec.  It looks like you should be able to arch conditionalize that.

%ifarch x86_64
%bcond_without mingw
%else
%bcond_with mingw
%endif

Comment 7 Sandro Mani 2024-10-23 14:34:56 UTC
Correct, indeed geos itself has

# MinGW ist x86_64 only in EPEL9+
%if 0%{?rhel} >= 9
%ifarch x86_64
%bcond_without mingw
%else
%bcond_with mingw
%endif
%else
%bcond_without mingw
%endif

Comment 8 Troy Dawson 2024-10-23 15:02:27 UTC
Yep, looks like that works, I did a scratch build, on all arches, with that conditional.
https://koji.fedoraproject.org/koji/taskinfo?taskID=125120776

Comment 10 Troy Dawson 2024-10-23 16:28:48 UTC
Thank you