Bug 2088014 - [python-sphinx-issues][epel]: please build python-sphinx-issues in epel9
Summary: [python-sphinx-issues][epel]: please build python-sphinx-issues in epel9
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: python-sphinx-issues
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kaleb KEITHLEY
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-18 16:30 UTC by Kaleb KEITHLEY
Modified: 2022-11-15 18:31 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 18:31:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kaleb KEITHLEY 2022-05-18 16:30:42 UTC
Description of problem:

python-sphinx-issues is a BR for python-werkzeug->python-flask->python-opentelemetry->python-xds-protos->grpc->libarrow, which in turn is a BR ceph quincy (17.2.x). While ceph itself will not (ever) be built in EPEL, there are Ceph developers who want to use CentOS Stream or RHEL with EPEL.

Note: libarrow and all its dependencies, including python-sphinx-issues, are already available from the CentOS Storage SIG. I'm told though that many Ceph devs prefer to use EPEL over the CentOS Storage SIG.

Version-Release number of selected component (if applicable):

python-sphinx-issues-3.0.1

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

It builds as is from the rawhide sources (see https://koji.fedoraproject.org/koji/taskinfo?taskID=87207361
)

If you don't wish to build python-sphinx-issues in EPEL yourself, please add the epel-packagers-sig group as collaborator for epel* branches, or (less preferable) add me (FAS: kkeithle) as a collaborator for epel* branches.

Thanks

Comment 1 Elliott Sales de Andrade 2022-05-20 02:02:57 UTC
I don't, so I've added the group.

Comment 2 Ben Beasley 2022-05-23 15:15:33 UTC
I am the package maintainer for grpc, python-xds-protos, and python-opentelemetry. It may be useful to build this for EPEL9, but it should not be required for grpc.

I am able to build python-opentelemetry for EPEL9 in a COPR[1] by disabling certain subpackages with missing dependencies. I already have a bootstrap build of grpc, and I expect to complete a non-bootstrap build shortly. At that point, I am just waiting on a couple of repository branch requests to go through before I can start real builds in a side tag.

[1] https://copr.fedorainfracloud.org/coprs/music/grpc-epel9/packages/

Comment 3 Ulrik Haugen 2022-05-30 13:29:18 UTC
I'd like to have it as it is a requirement for python-flask for which i have opened bz 2089764.

Comment 4 Ben Cotton 2022-08-09 13:16:13 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 5 Ulrik Haugen 2022-08-19 11:41:55 UTC
(In reply to Ulrik Haugen from comment #3)
> I'd like to have it as it is a requirement for python-flask for which i have
> opened bz 2089764.

Or presumably not as python-flask has now been built for epel9 without needing this.


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