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
.
Works to build and test python-inline-snapshot
.
Works for building rust-onefetch-2.22.0
, which requires the latest globset
.
Works for building rust-onefetch-2.22.0
, which requires the latest globset
.
Works for building rust-onefetch-2.22.0
, which requires the latest clap_complete
.
Works for building rust-onefetch-2.22.0
, which requires the latest clap_complete
.
Works for building rust-onefetch-2.22.0
, which requires gix
0.66.
Works for building rust-onefetch-2.22.0
, which requires gix
0.66.
Works to build rust-blake3-1.5.4
, https://src.fedoraproject.org/rpms/rust-blake3/pull-request/1.
Works for building rust-onefetch-2.22.0
, which requires gix
0.66.
Works for building rust-onefetch-2.22.0
, which requires the latest clap_complete
.
Works for building rust-onefetch-2.22.0
, which requires the latest globset
.
Works with https://src.fedoraproject.org/rpms/python-meson-python/pull-request/8.