Seems fine. Packages that depend on it build correctly.
Seems fine. Packages that depend on it build correctly.
Seems fine. Packages that depend on it build correctly.
Seems fine. Packages that depend on it build correctly.
The new fedora-42-riscv64, fedora-43-riscv64, and rocky-10-riscv64 chroots all seem to work as expected.
Works as advertised. No longer warns about cross-directory hardlinks. Thanks!
The rust-drm package in this update still depends on the rust-image0.24 compat package. I’m updating this with a follow-up build to fix that.
This update has been unpushed.
This update is required for rustsec 0.31.0, which is part of a larger set of interrelated updates. I am therefore unpushing this standalone update. I will tag the build into a side tag and re-use it as part of a multi-build update.
This update has been unpushed.
This update is required for rustsec 0.31.0, which is part of a larger set of interrelated updates. I am therefore unpushing this standalone update. I will tag the build into a side tag and re-use it as part of a multi-build update.
Oops, I updated the build list too soon. A compatible ruff will be added to this update as soon as it finishes building.
Fixes both the tab completion bug and the interactive editor bug.
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.
I reported the problems with fedpkg update upstream in https://pagure.io/rpkg/issue/762.
This breaks any fedpkg command that opens an interactive editor. For example, using fedpkg update with EDITOR=vim in the environment, I get Vim: Warning: Input is not from a terminal while vim is starting up. After I finish editing, my terminal is trashed: input is not echoed and text is all over the place. Issuing a reset command mostly cleans it up. I think the cause is likely https://pagure.io/rpkg/c/0123ce42d214968defe74b8a05ba7d9c7ecfa6c1?branch=master, which was backported as a patch in https://src.fedoraproject.org/rpms/rpkg/c/3eb95a18a49c0e436b37d3f8794bef72d06f3713?branch=rawhide.
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.
Seems fine. Packages that depend on it build correctly.