devel October 2024

devel@lists.centos.org

11 participants
14 discussions

anaconda dependency calculation?
by Nicholas Byrne 04 Aug '25

04 Aug '25

Hi all, I'm trying to find a tool that calculates all dependencies for a specific package or group of packages for use with CentOS 5 (beta) with the intention of putting together a custom single CD build of CentOS 5. With CentOS 4 i used a python script that used the hdrlist module to find all dependencies which borrowed code from a number of sources. I've looked at yumdownloader and how it checks dependencies (using the --resolve option) but if i pass it the list of packages defined in say the Base and the Core yum groups which generally form an absolute minimal install i end up with about 200 packages. If i do a custom install (using beta 1 disks) and deselect everything i end up with over 300 packages. So i'm guessing anaconda calculates dependencies in a slightly different way, can anyone point me to files/code where i should be looking to find out? Thanks very much in advance for help Nick This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential. Any dissemination, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from Quadriga may be monitored. Quadriga cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

6 11

TOMOYO in Red Hat kernels
by Tetsuo Handa 18 Jun '25

18 Jun '25

Hello. I hope that some of Red Hat kernel team members are subscribed to this list. I want to use TOMOYO in RHEL kernels. In accordance with Fedora -> CentOS Stream -> RHEL flow, as a first step, I opened https://bugzilla.redhat.com/show_bug.cgi?id=2303689 and am waiting for response. Regards.

3 6

AltImages SIG: Announcing new images
by Troy Dawson 14 Apr '25

14 Apr '25

The CentOS Alternative Images SIG[1] has updated their CentOS Stream 9 Live images this quarter. We also added 4 new Live desktop images.[2] We now have * CINNAMON * GNOME * KDE * MATE * XFCE * MAX MAX has all the desktops listed above, plus a few others like IceWM and Lumina. All of these live images can be installed on your system. If there are bugs that are specific to the live images (not just general CentOS Stream bugs) please file an issue in our spins bug tracker.[3] Troy [1] - https://sigs.centos.org/altimages/ [2] - https://mirror.stream.centos.org/SIGs/9-stream/altimages/images/live/ [3] - https://pagure.io/centos-sig-alt-images/spin-bugs/issues

3 2

Board Nominations Requested
by Shaun McCance 04 Nov '24

04 Nov '24

** Please read this entire email before responding with nominations. ** We have a process, and the process is important. Recently, Brian Exelbierd notified the CentOS board that he will be moving on from his role as Red Hat Liaison. The Red Hat Liaison role is special: it is the only board seat appointed by and speaking for Red Hat. All other board members are at-large and speak for themselves. Brian's role will be backfilled, but until it is, Josh Boyer will step in as the interim Red Hat Liaison. This means that Josh is stepping down from his position as an at-large board member. See Brian's and Josh's emails for more info: https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/QAG4… https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/BCWM… We are asking you, the CentOS community, for nominations for who should fill Josh's seat. Note that the vote on who will fill this seat is held by the board itself, but nominations are open to the entire community. If you would like to nominate someone (or self-nominate), please use this Google form: https://forms.gle/jqYF7v5AUVy6L1Fz6 Please DO NOT send nominations to this list. As this is not a public vote, we don't want to give the impression of a popularity contest with public nominations. We also want to avoid any shaming if someone is nominated and is not seated, or chooses not to accept. I will ensure that each nominee is willing and able to serve, and the board will consider them and select the next director from the list. If you wish to nominate someone, you should consider the list of director requirements and recommendations listed at: https://www.centos.org/about/governance/director-requirements/ Nominations will be open until September 23. Thank you for your thoughtful consideration and participation in this process. -- Shaun, for the CentOS Board of Directors

2 2

Introducing Community Linux Engineering (“CLE”)
by Brendan Conoboy 21 Oct '24

21 Oct '24

Hi everybody, The “CPE” name is a commonly used identifier in the Fedora and CentOS communities. Inside Red Hat, it meant a specific set of individuals and roles reporting into common management. We recently had a reorg that brought it and other community roles together. There is a new name for the whole group: Community Linux Engineering. To be clear, no one is changing roles as part of this; all the things Red Hatters did before the reorg and rename remain the same after. This change does bring a question with it: In our docs and conversations, should we just search and replace the CPE name with “CLE”? My answer is a resounding no! The external CPE branding unintentionally contributed to some common misconceptions: - “Red Hat teams are separate from the community.” Red Hatters can, and indeed many do, play key roles in the community Linux space, regardless of team affiliation. - “Community members can’t take part in the same Fedora activities that Red Hat employees can.” The reality is that most activities are or can be open to all. - “There is a ‘Fedora team’ or a ‘CentOS team’ solely responsible for All the Things.” This would be impossible – it’s way too much. We all are part of making these distributions and communities succeed and grow. As this name change takes effect, I hope we can embrace names which reflect what we are doing together, the myriad skills and interests and activities that come together to make something we can all use and enjoy. So while I’m pleased to announce CLE, I hope you’ll promptly forget about the name and instead focus on why you’re here in this community, and find yourself able to pursue your interests as we build amazing things together.

1 0

CentOS Stream 10 availability for CI tenants (aka duffy.ci.centos.org)
by Fabian Arrotin 21 Oct '24

21 Oct '24

As discussed back and forth with CI tenants using duffy.ci.centos.org (see https://sigs.centos.org/guide/ci/#duffy-ephemeral-bare-metalvirtual-machine…) , there was a request to start testing against/for Stream 10 (as it was available already for SIGs building against/for it on https://cbs.centos.org) I had time to work on this ticket (https://pagure.io/centos-infra/issue/1519) so I'm happy to share that you can now request through same duffy api calls CentOS Stream 10 machines that you'll be able to use for your CI tests. Please just keep in mind that Stream 10 packages set is still subject to major changes, but at least this gives you an opportunity to test things in advance. Happy testing ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

CentOS Showcase CFP Reminder
by Shaun McCance 17 Oct '24

17 Oct '24

Hi all, As a reminder, we'll be hosting a CentOS Showcase on November 4. This is a half-day virtual event with short talks that showcase the work being done around the project. The CFP is open until this coming Monday, October 21. https://cfp.fedoraproject.org/centos-showcase-2024-11/ Please submit talks about the work you're doing. We'd especially like to hear updates from our SIGs. Remember that these are short talks, just 20 minutes, so there's no need to prepare a technical deep dive. Also, if you haven't already, please register to attend: https://pretix.eu/centos/showcase-2024-11/ Thanks, Shaun

1 0

installing packages after CentOS Stream 9 EOL
by Ken Dreyer 17 Oct '24

17 Oct '24

Hi folks. We use CentOS Stream for Ceph's CI along with other distributions. When CentOS Stream 8 went EOL, we could no longer "yum install" packages for it. As a result, Ceph's build and testing infrastructure broke in important ways that were difficult to debug. Engineers spent a lot of unplanned time fixing things. For example, in Ceph we test many upgrade paths against very old versions, because we want confidence in our upgrade processes. Several of these old environments are EOL, but these tests are important to our users. When Ceph upgrades are stable, our users have confidence to get onto non-EOL releases. The security risk of using EOL bits in our test lab is acceptable because our environment is a secured network where we reimage regularly. The Ceph project was not alone with broken CI recently. Other projects that experienced similar trouble when we could not install packages on EOL CentOS. When I "podman pull ubuntu:trusty", I can "apt update" and still install packages. That went EOL in 2019. When I "podman pull" end-of-life fedoras, like fedora:31, I can "dnf install" packages too. When CentOS Stream 9 goes EOL, would you please update MirrorManager so that package installs continue to work?

3 2

RDO Dalmatian 2024.2 Released
by Amy Marrich 15 Oct '24

15 Oct '24

The RDO community is pleased to announce the general availability of the RDO build for OpenStack 2024.2 Dalmatian for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Dalmatian is the 30th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available for CentOS Stream 9 on the CentOS mirror network in: http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-dalmat… The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud SIG. The Cloud SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/dalmatian/highlights.html but here are some highlights: - New Cinder driver features were added, notably, Dell PowerStore active-active support, Dell PowerStore QoS support, NetApp added support to active/active mode in ISCSI/FC drivers, HPE Nimble replication, and StorPool added support clone-across-pools capability. - Added Glance support of new add/get location APIs which replaces the image-update (old location-add) mechanism for consumers like cinder and nova to address OSSN-0090 and OSSN-0065. - Ironic has enhanced multiple security aspects, for example it now requires rescue passwords to be hashed, it has reduced the logged nodes information during the cleaning phase to avoid showing sensitive data, and it has hardened the communication between the ironic services and the ironic agent requiring an HTTPS url by default. - All Neutron supported mechanism drivers (ML2/OVS, ML2/OVN) can now use the WSGI API module, completing the first phase of eventlet library deprecation. - Nova Instances with UEFI firmware can now be launched with stateless firmware if their image has the hw_firmware_statelessproperty and if the compute services have libvirt 8.6.0 or later. OpenStack Dalmatian is not marked as Skip Level Upgrade Release Process or SLURP. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) this means that upgrades will only be supported from the Caracal 2024.1 release. RDO Dalmatian 2024.2 has been built and tested with the recently released Ceph 18.2.0 Reef version (https://docs.ceph.com/en/latest/releases/reef/) which has been published by the CentOS Storage SIG in the official CentOS repositories. *Note:* Follow the instructions in [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services in the same host. During the Dalmatian cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Dalmatian 2024.2 release: - python-saharaclient (https://review.rdoproject.org/r/c/rdoinfo/+/54360) - puppet-corosync (https://review.rdoproject.org/r/c/rdoinfo/+/53127) During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: During the Dalmatian cycle, we saw the following new RDO contributors: - Roman Safronov - Archana Singh - pkomarov komarov - Sergii Golovatiuk - Milana Levy - Liron Kuchlani - Jaromír Wysoglad - Arnau Verdaguer - Andre Aranha Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 51 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Alfredo Moralejo Alonso - Amy Marrich - Ananya Banerjee - Andre Aranha - Archana Singh - Arnau Verdaguer - Artom Lifshitz - Arx Cruz - Bhagyashri Shewale - Bohdan Dobrelia - Cédric Jeanneret - Chandan Kumar - Daniel Pawlik - Douglas Viroel - Fabien Boucher - Fiorella Yanac - Francesco Pantano - Goutham Pacha Ravi - Gregory Thiemonge - Grzegorz Grasza - Harald Jensås - Jaromír Wysoglad - Joan Francesc Gilabert - Joel Capitao - Jon Schlueter - Karolina Kula - Karthik Sundaravel - Lewis Denny - Liron Kuchlani - Lon Hohberger - Luigi Toscano - Maor Blaustein - Marihan Girgis - Marios Andreou - Martin Kopec - Martin Magr - Michael Johnson - Milana Levy - Nicolas Hicher - Pini Komarov - Roman Safronov - Ronelle Landy - Sergii Golovatiuk - Shreshtha Joshi - Soniya Vyas - Steve Baker - Takashi Kajinami - Tobias Urdin - Tristan De Cacqueray - Yadnesh Kulkarni - Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Epoxy. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For those that do not have any hardware or physical resources, there is the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://www.rdoproject.org/community/mailing-lists/. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube. *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

Announcing s390x architecture availability for cbs.centos.org/SIGs
by Fabian Arrotin 09 Oct '24

09 Oct '24

As discussed last week (https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/S3X3… ) I reached out to openmainframeproject to see if there would be a possibility to remotely use at least one s390x VM for SIGs. I'm proud to announce that such infra is ready to be used within CBS build infra (https://cbs.centos.org/koji/hostinfo?hostID=22) # What does that mean ? If your SIG wants to start building against/for s390x architecture, please just open a infra ticket on https://pagure.io/centos-infra/issues (usual way) and for which SIG/tags you'd like to see the s390x arch being added. As usual, SIGs can build against rhel8/rhel9/CentOS Stream 9 and CentOS Stream 10, including for s390x (internal mirror is now ready too) # How to proceed There are basically multiple ways to add the s390x architecture : - when you'll create new tag, you can ask for s390x arch to be included by default for your new build tag - for existing tags, you can also ask for the s390x arch to be added, but that also means that builds you'll submit as usual will have to find all build dependencies, including for s390x. It can be that you have yourself built some BuildRequires: dependencies for your RPM packages in your tags, but so probably just for x86_64, aarch64 and eventually ppc64le. How can that specific problem be solved : - either bump nvr for your build chain/order, rebuild in order to include from now on s390x, and then it will be BAU (Business as Usual) once s390x will be at same level for all pkgs. - other possibility (what I just used for the infra tags) : it's possible to just resubmit scratch builds for same package NVR (which koji would refuse you to do as "normal" build) : cbs build --scratch --arch-override s390x <target> <src.rpm/dist-git url> After each successfully scratch build, you can use the build id and then communicate (either through ticket or irc) us the build id, so that we can use a specific (admin right required, reason why SIGs can do that themselves) koji api call, to "merge" the newly s390x build with the existing one (with same pkg NVR, so nothing to do at the src.rpm/git level at all) - other option (if you have plenty of packages in the build chain, and don't want to block other builds for your existing -release tags) : we can create a specific "bootstrap" tag, with only s390x, in which we can just do the scratch+merge dance, until it's all resolved/equal to other tag, and only then, add the s390x arch to your existing tags (that will then automatically find the s390x packages, as existing in koji) One example : I had to rebuild cvs (one of many pkgs I rebuilt), itself a dep for koji-builder (needed to bootstrap the new infra) : - scratch build : https://cbs.centos.org/koji/taskinfo?taskID=4235422 - promoted to existing build : https://cbs.centos.org/koji/buildinfo?buildID=43020 (see s390x artifacts now part of a previous build ID) # Worth knowing We'd like to thank again openmainframeproject for the VM, but also worth knowing that because it's a remote (and locked down) VM, all koji/mirror traffic goes through an encrypted tunnel , and so that has a small impact on the needed time to init a buildroot. Based on my tests, it's still pretty fast to build, but just a little bit slower to init the buildroot, when downloading all needed packages Happy building and let us know which SIG wants to be next SIG (Infra SIG started to rebuild packages for our own usage already) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel October 2024