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
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…
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>
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
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
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
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.
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
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
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