We can’t add a build to a non-side-tag update, but we can unpush the update, tag the build into a side tag, and re-use it for a new update based on the side tag, without having to rebuild python-nibabel again.

I’m still doing local rebuilds to verify that everything else is OK. The things that depend on this have some seriously heavy tests.

While rpminspect claims “New package python3-tox-uv-1.15.0-1.fc41.noarch.rpm is empty (no payloads),” manual inspection of python3-tox-uv-1.15.0-1.fc41.noarch.rpm indicates that this diagnostic is (weirdly) spurious.

The update looks reasonable, installs correctly, and appears to resolve https://bugzilla.redhat.com/show_bug.cgi?id=2319202.

Replaced with FEDORA-2024-05dedb1a53 – with the same FastAPI build, plus additional builds related to Starlette 0.40.0.

This update has been unpushed.

Looks reasonable and passes automated CI tests.

All subpackages install – for an initial package that was just reviewed, that’s enough testing for me!

Works with https://src.fedoraproject.org/rpms/python-meson-python/pull-request/8.

As a follow-up, I used this to build rust-libcramjam0.2, which builds a C-ABI shared library with cargo-c and installs it in the system linker path, and I confirmed that the expected SONAME-based RPM provides is still present, i.e. libcramjam.so.0.2()(64bit).

As a follow-up, I used this to build rust-libcramjam, which builds a C-ABI shared library with cargo-c and installs it in the system linker path, and I confirmed that the expected SONAME-based RPM provides is still present, i.e. libcramjam.so.0.3()(64bit).

As a follow-up, I used this to build rust-libcramjam, which builds a C-ABI shared library with cargo-c and installs it in the system linker path, and I confirmed that the expected SONAME-based RPM provides is still present, i.e. libcramjam.so.0.3()(64bit).

I used this to build python-orjson – a package that did not define the __provides_exclude macro as a workaround for the SONAME issue – locally in mock. I used objdump -x to confirm that the unwanted SONAME was not present in the compiled Python extension shared library, and I used rpm -q --provides to confirm that the RPM did not contain unwanted automatic provides related to the compiled extension.

I used this to build python-orjson – a package that did not define the __provides_exclude macro as a workaround for the SONAME issue – locally in mock. I used objdump -x to confirm that the unwanted SONAME was not present in the compiled Python extension shared library, and I used rpm -q --provides to confirm that the RPM did not contain unwanted automatic provides related to the compiled extension.

I used this to build python-orjson – a package that did not define the __provides_exclude macro as a workaround for the SONAME issue – locally in mock. I used objdump -x to confirm that the unwanted SONAME was not present in the compiled Python extension shared library, and I used rpm -q --provides to confirm that the RPM did not contain unwanted automatic provides related to the compiled extension.

I take https://bodhi.fedoraproject.org/updates/FEDORA-2024-d853fb3f89#comment-3737964 back – I meant to post this on the F41 update first. For F40, I don’t have a new enough version of python-rich for python-inline-snapshot, and if I build it (locally, just for testing purposes), I end up with a few test failures on F40. I’m not investigating since I don’t need to ship python-inline-snapshot on F40, and I don’t have a reason to believe there is a problem with python-executing in particular.

Works to build and test python-inline-snapshot.