devel February 2026

devel@lists.centos.org

9 participants
8 discussions

Fwd: [EPEL-devel] EPEL 9 incompatible upgrade request for python-django-allauth; also surfacing a qrcode dependency issue with python3-ipalib
by Michel Lind 13 Mar '26

13 Mar '26

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

4 3

mock & shadow-utils issues?
by lejeczek 02 Mar '26

02 Mar '26

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.

2 1

Re: [EPEL-devel] EPEL 9 incompatible upgrade request for python-django-allauth; also surfacing a qrcode dependency issue with python3-ipalib
by Carl George 27 Feb '26

27 Feb '26

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

1 0

Announcing new features for cbs.centos.org (draft builds and sidetags)
by Fabian Arrotin 27 Feb '26

27 Feb '26

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]

1 0

2026-02-11 CentOS Public Board Meeting - Canceled
by Amy Marrich 10 Feb '26

10 Feb '26

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

1 0

How to use gcc toolset in c10?
by lejeczek 10 Feb '26

10 Feb '26

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.

1 0

devel rpms
by lejeczek 03 Feb '26

03 Feb '26

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.

2 1

c9 to c10 migration - anybody did recently?
by lejeczek 02 Feb '26

02 Feb '26

Hi guys. An in-place migration, bit clunky but works - what did not work when I did it, in very early days of c10 was: networkmanager configuration, specifically: network connections were all lost. Anybody did it such "migration" recently - perhaps "recently" NM whole stash remains a ok? many thanks, L.

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel February 2026