epel-announce August 2025

epel-announce@lists.fedoraproject.org

3 participants
4 discussions

EPEL 10.1 mass branching
by Carl George 25 Aug '25

25 Aug '25

Howdy EPEL packagers, Release Engineering will branch epel10.1 from epel10 on 2025-08-25 (one week from today), in accordance with our overall branching strategy for EPEL 10. https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10 During the branching, we will temporarily disable builds to the epel10-candidate target, which is used when you run `fedpkg build` from the epel10 branch. If you are trying to create a build and receive an error about a target not existing, please try again later. We will send announcements when the branching is starting and when it is completed. -- Carl George

1 2

Retirement of four Rust library packages from the ICU4X stack
by Ben Beasley 13 Aug '25

13 Aug '25

The following packages correspond to Rust crates that were refactored away from the ICU4X[1] stack upstream between version 1.5 and version 2.0. See [2] and [3] for details. These packages have now been retired in the EPEL10 leading branch (10.1, not 10.0) and in EPEL9. - rust-icu_locid - rust-icu_locid_transform - rust-icu_locid_transform_data - rust-icu_provider_macros When we planned updates from ICU4X 1.5 to 2.0, we decided that letting these few packages fail to install in Fedora 41/42 and retiring them in EPEL9/10 would be less bad than branching 10-20 compat packages just to keep them installable. More details are available in the epel-devel list email[4] about these retirements. Since nothing outside the ICU4X stack ever depended on these four packages (making them leaf packages after the ICU4X 2.0 update), and since Rust library packages are in general only useful for building other packages rather than for end users, even developers, the retirement of these packages should have no effect on anyone in practice. [1] https://github.com/unicode-org/icu4x [2] https://src.fedoraproject.org/rpms/rust-idna_adapter/pull-request/1#comment-... <https://src.fedoraproject.org/rpms/rust-idna_adapter/pull-request/1#comment…> [3] https://bugzilla.redhat.com/show_bug.cgi?id=2383747#c1 [4] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraprojec…

1 0

EPEL-ANNOUNCEUpdating uv from 0.6.17 to 0.7.x in all Fedora releases and in EPEL10 leading branch
by Ben Beasley 09 Aug '25

09 Aug '25

In one week, 2025-05-18, or slightly later, I plan to update the uv package from 0.6.17 to 0.7.3 or a later 0.7.x release[1] in Fedora Rawhide, 42, and 41. (Fedora 40 will have reached its end-of-life by then.) I also plan to ship the same update to the EPEL10 leading branch, currently EPEL 10.1. In upstream’s words, “This release contains various changes that improve correctness and user experience, but could break some workflows; many changes have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes.” The exact changes are documented in the release notes for 0.7.0[2]. For stable releases Fedora 42 and 41, this update is permitted under a permanent exception to the Updates Policy[3]; for the EPEL10 leading branch, it is permitted under a semi-permanent exception for versions up to 1.0[4]. For EPEL “stable” branches (epel10.0), current policy does not allow SemVer-breaking updates of uv or of the library-only Rust packages upon which it depends, so uv 0.6.17[5] will be the final uv release in EPEL10.0 for the foreseeable future. Four packages in Fedora now depend on uv: fawltydeps, hatch, python-build, and python-tox-uv. A quick impact check using local mock builds did not reveal any incompatibilities. Additionally, a new dependency from translate-toolkit was found to be spurious, and I opened a PR to remove it[6]. I will also update python-uv-build[7], the new uv-based build backend, to the same version as uv. This package is still Rawhide-only for now. As long as nothing yet depends on it, I prefer to allow a little time for the ecosystem to work out any kinks before locking us into a particular minor release in stable branches. – Ben Beasley (FAS: music) [1] https://src.fedoraproject.org/rpms/uv/pull-request/54 [2] https://github.com/astral-sh/uv/releases/tag/0.7.0 [3] https://pagure.io/fesco/issue/3262 [4] https://pagure.io/epel/issue/317#comment-958123 [5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-445cab085a [6] https://src.fedoraproject.org/rpms/translate-toolkit/pull-request/13 [7] https://src.fedoraproject.org/rpms/python-uv-build/pull-request/6

1 4

EPEL-ANNOUNCEnetplan Incompatible Upgrade in EPEL 9
by Jonathan Wright 06 Aug '25

06 Aug '25

The update contains a soname bump but no known breaking changes - but many bug fixes. I've not found anything in EPEL that relies on or builds against netplan. In its current state, netplan in EPEL9 is pretty unmaintainable as upstream has diverged (and matured) a lot since the release we're on (0.105). In order to get it to a more maintainable state I'd like to get it updated to the current release (1.1.2). netplan moves much slower these days and it's a much more mature project and this update should set us up well for the rest of the EL9 lifecycle. I'll push this to stable next week per the incompatible updates policy <https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades…> . -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

epel-announce August 2025