Description of problem: python-selenium is a BR for python-python-django->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-selenium, 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): 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=87402342) If you don't wish to build python-selenium 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
I am the package maintainer for both grpc and python-opentelemetry. It may or may not 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/
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
I am also interested in having an EPEL 9 build of python-selenium (but for itself and not for satisfying a dependency).
*** This bug has been marked as a duplicate of bug 2063715 ***