FYI - since this will get used by the CentOS mailing list
infrastructure
Best regards,
-------- Forwarded Message --------
From: Michel Lind <salimma(a)fedoraproject.org>
Reply-To: EPEL Development List <epel-devel(a)lists.fedoraproject.org>
To: EPEL Development List <epel-devel(a)lists.fedoraproject.org>
Cc: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>, freeipa-maintainers(a)fedoraproject.org,
Fabian Arrotin <arrfab(a)centos.org>, Greg Sutcliffe
<fedora(a)emeraldreverie.org>, devel(a)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?re…
- 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
--
 _o) Michel Lind
_( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
README: https://fedoraproject.org/wiki/User:Salimma#README
Apologies for the late notification and for those of you with a calendar
invite we are working on getting it updated. We will be meeting 1 hour
earlier than the invite shows may show on your calendar at 4:00 EST/3:00
CST/ 1:00 PST/ 20:00 UTC.
Our next board meeting will take place at 20:00 UTC on Wednesday:
`date -d "2026-03-11 20:00 UTC"`
If you would like to attend please send me an email to
amy(a)redhat.com ( please do not reply to @centos-devel or use
another email address) and you will receive a link to a meeting
room with a passcode, 1 hour before the meeting takes place.
The agenda can be checked at (work in progress) :
https://hackmd.io/iNymiiUGRC6Ne5WFU0y47w
As a reminder we will enforce few rules :
* Wait to be recognized by the Chair before speaking
* Respect the Chair when told your time to speak is over - this will
allow us to remain on agenda, and complete the meetings in the
allotted time
* In the event that there are Board-confidential topics, these will be
put at the end of the meeting, in Executive Session, and guests will be
asked to leave. We hope to minimize these items, but they do sometimes
happen. The most common scenarios in which this may happen are personnel
issues, or information that Red Hat wishes to share with the Board, but
is not yet public.
* Muting of participants, or, in extreme situations, ejection from the
meeting, is at the sole discretion of the Chair.
* Meetings will be recorded, and published to YouTube (possibly with
edits/redaction, as approved by the Directors). Thus, by joining the
meeting you consent to have your presence at the meeting, and anything
you say during the meeting, made public.
I hope some of you can join.
thanks,
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc <https://www.redhat.com/>
amy(a)redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
Hi there,
due to other time commitments I will not be able to continue supporting
the SIG. Fortunately Peter Lemenkov stepped up to take over[1].
Best,
Matthias
[1] https://gitlab.com/CentOS/infra/tracker/-/issues/1874
Dear RDO Community/Stakeholders,
This email provides an important update regarding the RDO project and its
future direction which marks a significant change in how RDO content will
be delivered.
End of RDO RPM Builds
Historically, RDO provided RPM-based rebuilds of upstream OpenStack
packages. Due to insufficient contributors, the continuous RDO rpm builds
that were released through the CentOS Cloud SIG have been officially
discontinued as of the Epoxy release.
Introducing the New RDO: Container Focus
The future of RDO will be focused entirely on containers. This is a pivot
from our traditional RPM delivery, as RDO did not previously focus on
containers.
RDO will be transitioning to Source-to-Image (S2I) builds for service
containers. This work will be starting shortly within the
github.com/openstack-k8s-operators organization, and these new container
builds will essentially be the "new RDO".
Timeline and Usage:
-
This transition work has not yet begun. The timeline is not committed,
but the work is currently expected to be available for the Hibiscus release
in late 2026. The final delivery location of those images is still to be
determined.
-
These containers are primarily intended to be consumed via the operators
provided in the openstack-k8s-operators GitHub organization.
-
While nothing explicitly prevents these containers from being used
elsewhere, this is not currently part of the plan. Community involvement
and feedback for broader usage are welcome including within OKD and the
okderators.
-
Please note that the operators in this organization are currently only
developed and tested on Red Hat OpenShift Container Platform.
Thank you for your understanding and continued support as we make this
important shift. We look forward to engaging with the community on this new
path forward.
Sincerely,
Amy
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc <https://www.redhat.com/>
amy(a)redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
Hi guys.
Is this an old problem's - from what I could find - new
occurrence?
-> $ mock something centos-stream-10 ....
...
ERROR: Command failed:
 # useradd mockbuild -o -u 1000 -g 135 -N -d /builddir
--prefix /devs/var/mock
past mentions are about incompatible/broken/different
shadow-utils
Anybody sees this/similar?
many thanks, L.
On Tue, Feb 24, 2026 at 5:46 AM Michel Lind <salimma(a)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?re…
> - 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(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)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.fedoraprojec…
> 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.
--
Carl George
We recently received (from two different SIGs) "feature requests" on our
infra tracker:
- https://gitlab.com/CentOS/infra/tracker/-/issues/1853 (Draft builds)
- https://gitlab.com/CentOS/infra/tracker/-/issues/1860 (sidetag)
# Draft Builds
The first one (requested by Hyperscale SIG) was to enable the "draft
build" feature from koji (https://docs.pagure.org/koji/draft_builds/)
If you're interested in such feature, it's now deployed and available on
cbs.centos.org.
So far, SIGs were building and we had something in mind before draft
builds were a possibility, so as a reminder, your builds are being
tagged to -candidate first.
You can then iterate, and when happy, you can "promote" to -testing
(pgks are signed and pushed to testing mirrors) and then promote once
again to -release (pkgs are already signed but repodata files are also
signed and it goes to whole mirror network)
That's the concept explained in the SIG Guide
(https://docs.centos.org/centos-sig-guide/delivery/)
Draft builds are another way to work around that, by allowing multiple
builds of the *same* pkg NVR (you can read the whole logic on upstream
koji doc website above, but the idea is to just add an extra suffix in
the NVR), and then promote *one* of these builds as the real build (NVR
without any suffix)
You can (optional) work with draft builds if you consider that it's it
might be useful but just keep in mind that draft builds aren't scratch
builds !
We have cleanup of scratch builds, but draft builds are there to stay in
db/filesystem so don't abuse that (if you think you need but for cbs
usage , my personal take is that it's not needed)
We'll keep an eye on disk usage and if SIGs are using it or not
# Sidetag
The other request came from Automotive SIG, about a need to build
"aside" some specific packages (in an isolated buildroot).
That is possible with the sidetag plugin
(https://docs.pagure.org/koji/plugins/#sidetag)
In short, it lets you (packagers/SIGs members) request a specific "side"
build tag/target, inheriting your existing build tag, to let you build
inside that tag and then tag multiple packages back into your
-candidate,-testing,-release tags (BAU)
The "advantage" of such sidetag[s] is that you only have to request it
through koji api, and not through infra ticket
As these tags are also created "on the fly", let me though add that
these are "transient" build environments, and so they'll be
automatically cleaned up on regular intervals (defined through our
ansible role), but let's start with a delay of 30 days (after that, it's
all deleted, but you have time to build what you want and then tag all
the built packages in your real tag)
I'll update the sig guide to reflect these new options in case other
SIGs would find these useful in their workflow
Kind Regards,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
Due to recent travel to Connect and FOSDEM we are cancelling tomorrow's
meeting while we catch up on things, recover from the FOSDEM flu, and get
over jet lag.
There just wasn't enough for the agenda to be worth taking up folk's time.
Thanks
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc <https://www.redhat.com/>
amy(a)redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
Hi guys.
In c9 if I want to use gcc-toolset-15 non-interactively I do:
source /opt/rh/gcc-toolset-15/enable
export X_SCLS=gcc-toolset-15
I'm fiddling with things in c10 but I fail to get this set
to work - how is it done, do you know?
many thanks, L.
Hi.
I'm missing something or some packages are really absent -
do you guys get, eg.: teamd-devel libndp-devel - these I
cannot get for c9 nor for c10 - if some devel rpms are
absent, is it on purpose?
thanks, L.