Bug 2321199 - Please branch and build librttopo in epel10
Summary: Please branch and build librttopo in epel10
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: librttopo
Version: epel10
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sandro Mani
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 2318744
TreeView+ depends on / blocked
 
Reported: 2024-10-22 21:45 UTC by Troy Dawson
Modified: 2024-10-23 16:28 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-10-23 16:02:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.