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.

Note that the positive karma does not re-enable auto-push to stable after negative karma disabled it. This update will need to be manually pushed to stable, or auto-push by karma and/or time will need to be manually re-enabled by @mfocko.

Either way, please ensure this reaches stable slightly after python-wrapt, so it doesn’t fail to install even briefly.

Ideally these would have been a multi-build update created from a side tag to begin with. If you want to, you could unpush this update, and I could unpush the python-wrapt update, and then I could tag both builds into a new side tag and create a combined update from that. I have done that before, and it works well. Just let me know if this is what you want.

Replaced by FEDORA-2024-3f4d4c0d43.

The upstream release notes for the packaged version claim it fixes the mentioned CVE’s, and the command-line tool passed a quick “smoke test” in a mock chroot.

It seems like https://bugzilla.redhat.com/show_bug.cgi?id=2327553 should be associated with this update, too.

The upstream release notes for the packaged version claim it fixes the mentioned CVE’s, and the command-line tool passed a quick “smoke test” in a mock chroot.

The upstream release notes for the packaged version claim it fixes the mentioned CVE’s, and the command-line tool passed a quick “smoke test” in a mock chroot.

The upstream release notes for the packaged version claim it fixes the mentioned CVE’s, and the command-line tool passed a quick “smoke test” in a mock chroot.

The upstream release notes for the packaged version claim it fixes the mentioned CVE’s, and the command-line tool passed a quick “smoke test” in a mock chroot.