Unpushing this in order to create a multi-build update with python-hpack and python-h2.

@carlwgeorge Thank you for noticing that! Working as a rust-sig member, I confirmed that rust-print_bytes doesn’t bring any new dependencies of its own, branched it for EPEL10, built it into the side tag, and added it to this update.

Works to build rust-libdeflate-sys and rust-libdeflater. I didn’t see anything disruptive in the upstream source diff.

Works to build rust-libdeflate-sys and rust-libdeflater. I didn’t see anything disruptive in the upstream source diff.

Works to build rust-libdeflate-sys and rust-libdeflater. I didn’t see anything disruptive in the upstream source diff.

This update has been unpushed.

This update is OK by itself, but a test fails with fastapi-cli 0.0.6, FEDORA-2024-f398660f8f. I’m patching that, rebuilding, and combining this update with that one.

This is, formally speaking, an incompatible update, although most users should not find it disruptive. The uv package has a permanent Updates Policy exception.

This is, formally speaking, an incompatible update, although most users should not find it disruptive. The uv package has a permanent Updates Policy exception.

Upstream pull request #9424 for Windows batch script activation turned out to be incorrect. For that reason, I’m going to modify this update with a fresh build, in which the backport of that PR is reverted. As long as I’m doing a new build, this will be uv-0.5.5, which came out just after I originally created this update.

Upstream pull request #9424 for Windows batch script activation turned out to be incorrect. For that reason, I’m going to modify this update with a fresh build, in which the backport of that PR is reverted. As long as I’m doing a new build, this will be uv-0.5.5, which came out just after I originally created this update.

@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.

Here’s the replacement update: FEDORA-EPEL-2024-2ce4c21cfc

I’ll try to coordinate getting python-pikepdf added to it as well.

Thanks!

I unpushed FEDORA-EPEL-2024-4bbcbd6c6d, then I requested an EPEL10 side tag (epel10.0-build-side-101152) and ran

$ koji tag epel10.0-build-side-101152 python-wrapt-1.17.0-2.el10_0
$ koji wait-repo epel10.0-build-side-101152 --build=python-wrapt-1.17.0-2.el10_0 --request

so python-wrapt is now available for other builds in the side tag.

You can now either unpush this update and run

$ koji tag epel10.0-build-side-101152 python-deprecated-1.2.14-7.el10_0
$ koji wait-repo epel10.0-build-side-101152 --build=python-deprecated-1.2.14-7.el10_0 --request

or you can build a later NVR of python-deprecated with fedpkg build --target=epel10.0-build-side-101152. You or someone else will still need to run the koji wai-repo … command on the resulting build before it‘s available for any other builds to use, since side-tag repo regeneration isn’t automatic anymore. In this case, with a newer python-deprecated build, I think creating a new update from the side tag should obsolete this update – although unpushing it doesn’t hurt.

This update has been unpushed.

Unpushing in order to create a multi-build update with at least python-deprecated, and hopefully also python-pikepdf.

Ok, let’s do it.

I wonder if we could get @kkeithle to do the same for FEDORA-EPEL-2024-ce568eaa56, which depends on python-deprecated. Let’s get python-wrapt and python-deprecated set up first.

I’ll unpush python-wrapt, create a side tag, tag in the python-wrapt build, and follow up here.