On Tue, Feb 24, 2026 at 5:46 AM Michel Lind salimma@fedoraproject.org wrote:

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.

Given there are several potentially problematic issues here, I figure I'd try and get this discussed on the list and by EPSCo before proceeding.

Best regards,

-- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README -- _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

The EPEL policy exception to allow conflicts between compat packages is specific to devel subpackages, which aren't normally installed on end user systems. A runtime dependency like qrcode is not covered by this exception. Since python3-qrcode-core and python3-qrcode8 both provide `python3.9dist(qrcode)`, I'm worried that CentOS/RHEL packages could resolve that dependency with the EPEL package instead of the stock one.

I'd like to suggest a few alternate approaches.

1) Since this is specific to deployments of mailing list infrastructure, it may make more sense in a Copr or a CentOS SIG. Either of those would allow replacing stock packages as needed, and wouldn't need to be as cautious about the effects on other packages outside the scope of the Copr/SIG.

2) Target a non-default Python stack such as python3.12. You could package any version of django-allauth and qrcode you want since it would exist in a different site-packages directory and wouldn't conflict with existing CentOS/RHEL or EPEL packages.

3) Try to update qrcode in CentOS/RHEL. The most likely candidate would be to sync the CentOS/RHEL 9 package with the one from CentOS/RHEL 10, which is at version 7.4.2. That would satisfy the dependency of django-allauth[mfa] (at least version 7.0.0).

https://codeberg.org/allauth/django-allauth/src/tag/0.62.1/setup.cfg#L53

The only things that depends on it are ipaclient and ipalib, which are at version 4.12.2 in both CentOS/RHEL 9 and 10, so it may be a reasonable thing to approve (which is what I think Alexander was suggesting on the forwarded thread on CentOS devel). Then if approved, you can propose a more isolated incompat upgrade for just django-allauth.