This installs fine inside an x86_64 centos 10 container:

dnf install -y https://kojipkgs.fedoraproject.org//packages/python-wrapt/1.16.0/6.el10_0/x86_64/python3-wrapt-1.16.0-6.el10_0.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/python-pikepdf/8.8.0/4.el10_0/x86_64/python3-pikepdf-8.8.0-4.el10_0.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/python-deprecated/1.2.14/7.el10_0/noarch/python3-deprecated-1.2.14-7.el10_0.noarch.rpm

@kkeithle

Since this depends on python-wrapt and python-deprecated, would you please consider combining it into a multi-build update from a side tag so that all three updates hit the EPEL10 repos at the same time? We just finished this process for python-wrapt and python-deprecated, as discussed in FEDORA-EPEL-2024-25d5d4e449, to create the new update FEDORA-EPEL-2024-2ce4c21cfc.

To add python-pikepdf to that update, you would need to:

1. Unpush this update. (You can do this last instead of first, but it’s necessary in order to re-use the same build in a different update.)
2. Run koji tag epel10.0-build-side-101152 python-pikepdf-8.8.0-4.el10_0. (You don’t have to be the one who does this, but you might as well be.)
3. If another build in the side tag needed to rely on python-pikepdf, someone (anyone) would need to run koji wait-repo epel10.0-build-side-101152 --build=python-pikepdf-8.8.0-4.el10_0 --request, since side-tag repo regeneration is no longer automatic. In this case, this step can be skipped unless we end up trying to add python-cairocffi to the update too.
4. Let me know that you’ve done the above, so that I can “refresh” the list of builds in FEDORA-EPEL-2024-2ce4c21cfc from the side tag, modify the description, and associate #2325908 with the update.