devel

devel@lists.centos.org

9 participants
4687 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

2026-03-11 CentOS Public Board Meeting
by Amy Marrich 11 Mar '26

11 Mar '26

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

1 0

[Messaging SIG] Stepping down as SIG chair
by Matthias Runge 10 Mar '26

10 Mar '26

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

2 1

Update on RDO: A Shift to Containers
by Amy Marrich 04 Mar '26

04 Mar '26

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

1 0

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel