The exact-version dependency on a shared library is unusual. It comes from https://src.fedoraproject.org/rpms/perl-Alien-Brotli/blob/rawhide/f/perl-Alien-Brotli.spec#_46. The rationale in the spec file makes sense, and it’s possible to query for it now that I know about it,

$ fedrq wr brotli libbrotli -F 'multiline:source,requires' | grep -E ':.*brotli.*='
brotli : libbrotli(aarch-64) = 1.1.0-10.fc44
brotli : libbrotli(aarch-64) = 1.1.0-10.fc44
brotli : brotli(aarch-64) = 1.1.0-10.fc44
brotli : pkgconfig(libbrotlicommon) >= 1.1.0
perl-Alien-Brotli : brotli = 1.1.0
perl-Alien-Brotli : libbrotli = 1.1.0

…but this certainly isn’t the kind of query I would normally run when updating a shared library compatibly, let alone with no ABI changes at all.

This update has been unpushed.

https://openqa.fedoraproject.org/tests/3972788#step/rmdepcheck/79 failed with:

Dependencies of other packages that would be BROKEN by the tested packages:
package: cachelib-17^20250203-1.fc43.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libgmock.so.1.15.2()(64bit)
  libgtest.so.1.15.2()(64bit)

This is good! That is only the one package that we expected to be broken.

The linker error in the ROCm packages is worked around by FEDORA-2025-db6bb2bdae. I successfully rebuilt hiprand, hipsolver, rocblas, and rocrand.

I rebuilt intel-npu-driver without difficulty.

I am still unable to rebuild cachelib due to issues stemming from Folly; the primary maintainer is aware, accepts that cachelib (a leaf package) will fail to install for now, and has encouraged me to continue.

Once I “refresh” the list of builds in this update, there should not be any problems with packages other than cachelib.

Tom Rix identified the problem with rebuilding the ROCm packages as https://bugzilla.redhat.com/show_bug.cgi?id=2415065 / https://sourceware.org/bugzilla/show_bug.cgi?id=33577. Monitoring for short-term activity to decide how to proceed.

I did rebuild intel-npu-driver in the side tag, so that at least will be picked up whenever I refresh the build list for this update.

I just reproduced the linker error in the ROCm packages in COPR with a simple rebuild of the pre-update gtest package in Rawhide, 1.15.2-4. So this has nothing to do at all with the gtest version update per se. Whatever is happening with the ROCm packages would have been triggered by any rebuild of gtest whatsoever.

Testing with scratch builds in the side tag, the ROCm packages (hiprand, hipsolver, rocblas, and rocrand) fail with a gnarly linker error. I can reproduce this in COPR, but only when I use a fresh gtest build, not when I use one from the latest impact check nine days ago. This seems to point at a recent toolchain regression. Unfortunately, I’m not really sure how to further debug, characterize, or usefully report it. I did try (in COPR) building gtest with clang instead of gcc, and that didn’t help, so the cause is not something unique to either clang or gcc.

Hmm, I was aware of cachelib, which is blocked by an FTBFS bug, https://bugzilla.redhat.com/show_bug.cgi?id=2384494, with roots in folly, which also FTBFS.

The others are news to me! I searched for dependent packages with repoquery --repo=rawhide --whatrequires 'libgtest*.so.*' and repoquery --repo=rawhide --whatrequires 'libgmock*.so.*' It seems like all of the missing packages (other than cachelib) are ExclusiveArch: x86_64, and I wasn’t able to discover them because I ran my query on an aarch64 machine. I’ll work on rebuilding hiprand, hipsolver, intel-npu-driver, rocblas, and rocrand. I’ll start with scratch builds in the side tags to see if there are any compatibility issues that need to be fixed.

This update has been unpushed.

Unpushing this since it’s low-priority and EPEL10.0 retirement is imminent.

Normally I wouldn’t +1 an update that I am primarily responsible for, but with @decathorpe’s +1 above, I think it’s justifiable in this case.

With some regret, I edited this yet again, in order to expedite a security fix for https://www.cve.org/CVERecord?id=CVE-2025-62727 in Starlette.

Seems fine in basic, routine git operations.

I’m going to try to stop editing this so that it can go stable.

With ruff and uv now both fully up to date, I’m going to try to stop editing this so that it can go stable.

With ruff and uv now both fully up to date, I’m going to try to stop editing this so that it can go stable.

With ruff and uv now both fully up to date, I’m going to try to stop editing this so that it can go stable.