On Mon, Mar 9, 2026 at 1:49 PM Michel Lind michel@michel-slm.name wrote:

On Wed, 2026-02-25 at 19:17 +0200, Alexander Bokovoy via devel wrote:

...

On Срд, 25 лют 2026, Michel Lind wrote:

...

FYI - since this will get used by the CentOS mailing list infrastructure

Best regards,

-------- Forwarded Message -------- From: Michel Lind salimma@fedoraproject.org Reply-To: EPEL Development List epel-devel@lists.fedoraproject.org To: EPEL Development List epel-devel@lists.fedoraproject.org Cc: Development discussions related to Fedora devel@lists.fedoraproject.org, freeipa-maintainers@fedoraproject.org, Fabian Arrotin arrfab@centos.org, Greg Sutcliffe fedora@emeraldreverie.org, devel@lists.centos.org Subject: [EPEL-devel] EPEL 9 incompatible upgrade request for python- django-allauth; also surfacing a qrcode dependency issue with python3- ipalib Date: 02/24/2026 11:45:41 AM

Dear all,

At the request of the folks managing our mailing list infrastructure, I would like to request updating python-django-allauth to 0.62.1, needed to enforce SSO login flow for the mailman web UI.

The backward-incompatible changes according to upstream are in the changelog -- I was going to copy them here but it would distract from the conversation here; unfortunately this is before upstream adopted semver and there are sometimes backwards-breaking changes in what should be a patch release https://codeberg.org/allauth/django-allauth/raw/tag/0.62.1/ChangeLog.rst

I've created an update, https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-8e235e20a2

but disabled auto-push based on karma and time - so that infra teams can test this and we can also more easily test update paths. Please see my testing notes in the first comment on the update.

Of note, packaging wise, I've cherry-picked changes from the newer Fedora releases so this now enables extras subpackages. It does mean if you depend on some functionality considered extras (e.g. mfa, openid) you'd have to require python3.9dist(django-allauth[mfa]) or python3dist(django-allauth[mfa]) to get their dependencies installed -- substitute mfa with openid if that's what you need

Of note: the mfa extras depends on a newer qrcode (needs at least version 7, which came out all the way back in... 2021). Out of an abundance of caution I created a versioned compat package, python- qrcode8, where the binary RPM python3-qrcode explicitly conflicts with python3-qrcode-core instead of providing/obsoleting it like python3- qrcode does in Fedora.

This is not an issue if you don't install this extra; if you do, see the test notes - right now there is an issue that freeipa in Fedora https://src.fedoraproject.org/rpms/freeipa/blob/rawhide/f/freeipa.spec#_135-...

• even in Rawhide - and ipa in CentOS -

https://gitlab.com/redhat/centos-stream/rpms/ipa/-/blob/c9s/freeipa.spec?ref...

• have the dependency generator /disabled/ and unfortunately of the

two subpackages that require qrcode, one hardcodes the old python3- qrcode- core package name while the other does not, so if you need python3- django-allauth+mfa *and* ipa on the same host, you don't have the option of just swapping out python3-qrcode-core for the new python3- qrcode8

The minimal fix is simple enough - getting a Jira and MR filed for ipa in CentOS (two actually, one each for 9 and 10) and getting it also fixed in Rawhide - minimally we need to change the hardcoded python3- qrcode-core to be python%{python3_pkgversion}dist(qrcode) - but ideally we should also look into enabling the dependency generator instead of managing this by hand.

Please submit an MR but also maybe submit an update to newer version upstream? We wouldn't be against it if the change isn't too big.

Thank you! Sorry for the late response - I'll work on those this week.

This should be fixed in Fedora first, then it can be backported to CentOS.