epel-announce

epel-announce@lists.fedoraproject.org

1 participants
216 discussions

Re: [EPEL-devel] Heads-up: retiring python-django3 from EPEL 9 and EPEL 8
by Michel Lind 09 Jun '26

09 Jun '26

On Thu, 2026-02-26 at 11:08 +0000, Michel Lind wrote: > On Thu, 2026-02-26 at 10:37 +0000, Michel Lind wrote: > > > > For epel8 I'm less sure what to do - I looked into branching > > python- > > django4.2 for epel8 in the past and IIRC it's not trivial - but > > there > > are more dependent packages that would be affected: > > > > > > ❯ fedrq-pydeps-verbose.sh django -b epel8 > > + fedrq whatrequires 'python3dist(django)' -F > > multiline:source,requires > > -b epel8 > > + grep 'python3dist(django)' > > cobbler3.2 : python3dist(django) < 4 > > python-django-contrib-comments : python3dist(django) >= 1.11 > > python-django-contrib-comments : python3dist(django) >= 1.11 > > kobo : python3dist(django) >= 1.11 > > kobo : python3dist(django) >= 1.11 > > kobo : python3dist(django) >= 1.11 > > > > I can take a stab at branching python-django4.2 for epel8 again and > > report back, but if that proves difficult and there's objection to > > retiring python-django3 in epel8 I'd be more than happy to hand > > over > > the package to someone willing to handle or own the security > > issues. > > > Quick follow-up - Django 4.2.28 requires Python >= 3.8 and definitely > starts making use of newer Python features, e.g. > > > File "/builddir/build/BUILD/django- > 4.2.28/django/utils/functional.py", line 265 > if (_wrapped := self._wrapped) is empty: > ^ > SyntaxError: invalid syntax > > so building this in epel8 is likely a lot of work. If someone really > wants to keep django3 in epel8 I would recommend trying to backport > the > CVE fixes, and if they're doing that for epel8 anyway they might as > well also apply the fixes to epel9 if they want. But failing anyone > willing to take this I'd still recommend retiring this in epel9, > where > we don't actually need this package around anymore. > Per the discussion back in February - there has been no takers to pick up Django 3; the way forward will likely involve trying to branch and build python-django6 against one of the alternate Python runtimes (EL8 has up to Python 3.12 available) but this will involve branching and building a lot of dependencies. I'm not committing to doing this - I have not even got round to branching python-django6 for EPEL 10 yet. So any package depending on python-django3 in EPEL 8 will likely need to be retired as well. Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 0

Retiring espresso from EPEL8
by Jean-Noël Grad 27 Apr '26

27 Apr '26

Hi, I'm the maintainer of the `espresso` [1] package in Fedora and EPEL8, and one of the developers of the software. I'm following the documented procedure [2] to retire this package from EPEL8. More details are available in the epel-devel list email [3] about this retirement. Users of this package can build the software locally from sources with a smaller set of features at configure time (to avoid issues with missing dependencies) and inside a Python virtual environment (to install a SciPy version that isn't affected by CVEs). Best regards, Jean-Noël Grad ESPResSo project maintainer [1] https://src.fedoraproject.org/rpms/espresso [2] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ [3] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraprojec…

1 0

Notice: PoCL 3.1 will be retired from EPEL 9
by Alexander Lent 26 Apr '26

26 Apr '26

Dear EPEL Users, Per the policy[1], I am retiring the portable CPU implementation of OpenCL, PoCL 3.1, in EPEL 9. This package is not present in EPEL 8 or EPEL 10. I have no time or desire to fix issues with the package, which currently FTBFS due to failing tests. Anyone interested in un-retiring PoCL for EPEL 9 or branching it for EPEL 10 should feel free to reach out to me for assistance. If you want to continue using PoCL, you should compile and install a newer version from upstream sources. You might be able to use the latest upstream version, PoCL 7.1, since LLVM 19 is packaged for EPEL 9. [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_n… Best, Alexander F. Lent <lx(a)xanderlent.com>

1 0

Version 0.11 of uv sent to testing for EPEL10 leading branch
by Ben Beasley 23 Apr '26

23 Apr '26

Version 0.11.6 of uv is now on its way to testing[1] for the EPEL10 leading branch (10.3). See the upstream changelogs in general[2], and particularly the list of breaking changes introduced between 0.10.x and 0.11.x[3]. Upstream writes: This release includes changes to the networking stack used by uv. While we think that breakage will be rare, it is possible that these changes will result in the rejection of certificates previously trusted by uv so we have marked the change as breaking out of an abundance of caution. The changes are largely driven by the upgrade of reqwest, which powers uv's HTTP clients, to v0.13[4] which included some breaking changes to TLS certificate verification. Most users will not need to change anything; any breaking changes should be unintentional and related to certificate verification, especially in more advanced configurations. This update is allowed by a permanent exception to the EPEL updates policy[5], limited to leading branches and to versions through 1.0. I will push it to stable after no less than one week in testing, at which point I will send a follow-up email. [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-53c8876e55 [2] https://github.com/astral-sh/uv/blob/0.11.6/CHANGELOG.md [3] https://github.com/astral-sh/uv/blob/0.11.6/CHANGELOG.md#breaking-changes [4] https://seanmonstar.com/blog/reqwest-v013-rustls-default [5] https://pagure.io/epel/issue/317

1 1

Re: [EPEL-devel] Re: Heads-up: retiring python-django3 from EPEL 9 and EPEL 8
by Michel Lind 05 Mar '26

05 Mar '26

On Thu, 2026-02-26 at 11:08 +0000, Michel Lind wrote: > On Thu, 2026-02-26 at 10:37 +0000, Michel Lind wrote: > > > > For epel8 I'm less sure what to do - I looked into branching > > python- > > django4.2 for epel8 in the past and IIRC it's not trivial - but > > there > > are more dependent packages that would be affected: > > > > > > ❯ fedrq-pydeps-verbose.sh django -b epel8 > > + fedrq whatrequires 'python3dist(django)' -F > > multiline:source,requires > > -b epel8 > > + grep 'python3dist(django)' > > cobbler3.2 : python3dist(django) < 4 > > python-django-contrib-comments : python3dist(django) >= 1.11 > > python-django-contrib-comments : python3dist(django) >= 1.11 > > kobo : python3dist(django) >= 1.11 > > kobo : python3dist(django) >= 1.11 > > kobo : python3dist(django) >= 1.11 > > > > I can take a stab at branching python-django4.2 for epel8 again and > > report back, but if that proves difficult and there's objection to > > retiring python-django3 in epel8 I'd be more than happy to hand > > over > > the package to someone willing to handle or own the security > > issues. > > > Quick follow-up - Django 4.2.28 requires Python >= 3.8 and definitely > starts making use of newer Python features, e.g. > It's been a week, so I am retiring python-django3 from EPEL 9 today. Given there are more affected packages on EPEL 8 I am giving it another week to see if anyone wants to take it over. For anyone not using cobbler3.2, you can simply `sudo dnf swap python3- django3 python3-django4.2`. If you are using cobbler3.2 you'd need to swap that out for cobbler first. Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 0

Re: [EPEL-devel] Intent to retire: rust-pore in EPEL 8 and 9
by Michel Lind 05 Mar '26

05 Mar '26

On Thu, 2026-02-12 at 17:28 +0000, Michel Lind wrote: > Dear all, > > I currently maintain `rust-pore` across Fedora and EPEL, but > unfortunately development on the open source repo has stalled - this > was used at work but recent activity is mostly on an internal fork > (alas). > > Since it's causing an issue with keeping the set of Rust crates up to > date (it's needed patching to either compile with newer crates, or > has > to be compiled with compatibility packages), I'd like to request > having > it retired in EPEL 8 and 9. > It's been almost three weeks, so I have now retired rust-pore in EPEL 8 and 9. For those who are using the `pore` binary RPM you would need to switch back to using Google's `repo`. Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 0

EPEL 10.2 mass branching
by Diego Herrera 24 Feb '26

24 Feb '26

Hello EPEL packagers, Release Engineering will branch epel10.2 from epel10 on 2026-02-23 (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.

2 2

Ruff 0.15 in testing for EPEL10 leading branch
by Ben Beasley 21 Feb '26

21 Feb '26

Ruff 0.15.1 is now in testing[1] for the EPEL10 leading branch (10.2). This means that Ruff will now format Python code according to the 2026 edition of its style guide, including newly stabilized lint rules and behaviors. Please see BREAKING_CHANGES.md[2] for a list of potentially-breaking changes, and see the general changelogs [3] and blog post[4] for further context. I confirmed that none of these changes will cause any EPEL10 packages to fail to build or fail to install. Most people using ruff directly will only notice that the way ruff formats Python code changes in very small ways. If you have an application with tests that check ruff-formatted code against a string based on a previous version of ruff, you may need to update your sample output. Similarly, if you have a development pipeline that uses the system ruff package for formatting code, you may find that it suddenly wants to reformat some sources. This update is allowed by a permanent exception to the EPEL updates policy[5], limited to leading branches and to versions through 1.0. I will push it to stable after no less than one week in testing, at which point I will send a follow-up email. [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-306ec002ee [2] https://github.com/astral-sh/ruff/blob/0.15.1/BREAKING_CHANGES.md [3] https://github.com/astral-sh/ruff/blob/0.15.1/CHANGELOG.md [4] https://astral.sh/blog/ruff-v0.15.0 [5] https://pagure.io/epel/issue/350

1 1

Version 0.10 of uv sent to testing for EPEL10 leading branch
by Ben Beasley 21 Feb '26

21 Feb '26

Version 0.10.2 of uv is now on its way to testing[1] for the EPEL10 leading branch (10.2). See the upstream changelogs in general[2], and particularly the list of breaking changes introduced between 0.9.x and 0.10.x[3]. Upstream writes: Since we released uv 0.9.0 in October of 2025, we've accumulated various changes that improve correctness and user experience, but could break some workflows. This release contains those changes; many have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes. This release also includes the stabilization of preview features. Python upgrades are now stable, including the uv python upgrade command, uv python install --upgrade, and automatically upgrading Python patch versions in virtual environments when a new version is installed. The add-bounds and extra-build-dependencies settings are now stable. Finally, the uv workspace dir and uv workspace list utilities for writing scripts against workspace members are now stable. Again, most breaking changes are quite subtle, and most users will not need to change anything. This update is allowed by a permanent exception to the EPEL updates policy[4], limited to leading branches and to versions through 1.0. I will push it to stable after no less than one week in testing, at which point I will send a follow-up email. [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-69fe465f97 [2] https://github.com/astral-sh/uv/blob/0.10.2/CHANGELOG.md#0102 [3] https://github.com/astral-sh/uv/blob/0.10.2/CHANGELOG.md#breaking-changes [4] https://pagure.io/epel/issue/317

1 1

EPEL steering issue tracker forge mitration
by Diego Herrera 16 Feb '26

16 Feb '26

Hello all, I'm happy to announce that today we are migrating the steering committee issue tracker to the new forge at https://forge.fedoraproject.org/epel/steering. This will replace all the functions that were fulfilled by https://pagure.io/epel/issues, which is now archived and read-only. At this moment most of the heavy-lifting is already done, and the new forge is already available to be used. Best Regards Diego Herrera

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

epel-announce