April 2022 - devel - lists.centos.org

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

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

Few questions on cloud images
by Pino Toscano 06 Jun '23

06 Jun '23

Hello, I have few questions related to the cloud images provides for c8s and c9s, i.e.: - https://cloud.centos.org/centos/8-stream/x86_64/images/ - https://cloud.centos.org/centos/9-stream/x86_64/images/ 1) I see the c9s images are regularly updated, while the c8s images not; is this wanted, or simply a mistake/miss somewhere? If so, will they be kept up-to-date just like the c9s images? 2) are the Vagrant images there officially supported? Let's say you use one, and find a bug; then check on a "classic" installation (baremetal/VM), and the bug isn't there; can users report problems in those cases? 3) would it be possible to have either unversioned or "-latest" symlinks for the latest versions of all the files (i.e. images, checksums, etc)? This way, it will be much easier for users to fetch the latest versions with no need to change URLs frequently. Of course, the assumption is that users of this are always willing to use the latest version. Thanks! -- Pino Toscano

7 14

Proposal: CentOS Public Board Meetings
by Rich Bowen 07 Jan '23

07 Jan '23

In January of 2021, the CentOS Board of Directors opened our monthly meetings to all SIG chairs, in a first step towards more transparent governance. We wanted to see how the larger audience changed the meeting dynamics, if at all, as well as welcoming a broader pool of voices. We are now ready for the second part of this process. Starting in the August meeting, we will be inviting the entire CentOS community to attend these meetings. Due to the nature of the Internet, we won’t be simply publishing the meeting URL, as this often leads to disruptive behavior in meetings, as I am sure many of you have experienced. Rather, in the week before the meeting, we’ll send, to this list, a way to request an invitation to the meeting. In this way, we hope to limit the incidence of such disruptions, while also making the meeting available to anyone who wishes to attend. We will be working on the rules of engagement for these meetings, but they will be, at minimum: * 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/redactions, 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. Because there will seldom be time for Q&A during the meeting itself, we plan to add a post-meeting IRC office hours session for followup questions. This will probably be scheduled for a week after the board meeting, to allow time to publish meeting minutes We welcome your comments about the above proposal, and thank you all for your patience as we implement these changes to our governance process.

8 27

RHEL moving to issues.redhat.com only long term
by Josh Boyer 20 May '22

20 May '22

Hi Fedora, CentOS, and EPEL Communities! As part of our continued 3 year major Red Hat Enterprise Linux release cadence, RHEL 9 development is starting to wrap up with the spring 2022 release coming soon. That means planning for the next release will start in earnest in the very near future. As some of you may know, Red Hat has been using both Bugzilla and Jira via issues.redhat.com for RHEL development for several years. Our intention is to move to using issues.redhat.com only for the major RHEL releases after RHEL 9. What does this mean for Fedora and CentOS? This discussion is in part to figure that out. Based on some very brief analysis, the following should hold: - RHEL customers should continue to file support cases through the Red Hat Customer portal, which will remain consistent regardless of the backend tooling used. - There is no imminent retirement of the Red Hat Bugzilla instance being planned at this time. RHEL 7, 8, and 9 will continue to use bugzilla in some form and RHEL 9 has a very long lifecycle. - Fedora Linux and EPEL have their own Bugzilla product families and are not directly impacted in their own workflows by the choice to use only issues.redhat.com for RHEL. - There will be impacts on existing documentation that provide guidance on requesting things from RHEL in various places like EPEL. We will be happy to help adjust these. - CentOS Stream contribution and bug reporting workflows will be adjusted to use issues.redhat.com instead of bugzilla in the relevant places. This should apply to all versions of CentOS Stream for a unified contributor workflow. This will happen gradually as we discover the best workflow to use. If there are other impacts that you can think of, please raise them on this thread. We’d like to ensure we’re covering as much as possible as this rolls out. josh

7 14

CentOS Stream 8 and 9 - KDE un-updateable for a week
by Troy Dawson 13 May '22

13 May '22

During the past week qt5 was updated on CentOS Stream 8 and 9 to version 5.15.3. This caused updates to break for KDE users running CentOS Stream 8 and 9. The epel 8 and 9 packages affected are being rebuilt at this time. We expect everything rebuilt and through testing next week. Question: Does this affect my RHEL/Alma/Rocky 8/9 install? Answer: Not at this time. This qt5 update isn't going to be released until RHEL 8.7 and 9.1. Question: What is being rebuilt? Answer: epel8 - We believe about 30 packages. That includes all of the qt5 packages in epel8, as well as several plasma and kf5 packages that have tight version dependencies on qt5. epel9 - The entire KDE Plasma Desktop stack. (about 380 packages). There recently has been an update to wayland-protocols in Stream 9. It didn't break anything, but it had been an update that was needed to update to the latest kf5 and plasma releases. Since we knew that the qt5 update was coming, we held off rebuilding everything until qt5 came out. Now that it is out, we are updating everything. Troy Dawson

2 4

Decommissioning of CentOS Stream 8 source-git branches
by Tomas Tomecek 13 May '22

13 May '22

Hello, we would like to announce our plan to decommission and remove the c8s branches of the CentOS Stream source-git repositories. This also means the removal of any repository from the gitlab.com/redhat/centos-stream/src namespace which is left without a branch. Stream 9 content will not be affected. As you might remember, these are the source-git repositories produced by unpacking the c8s branches from CentOS Stream 8 dist-git, and making the resulting content available at gitlab.com/redhat/centos-stream/src. We took a look at the utilization of this content during 2021, based on the GitLab data and found out that no one from the community has used these repositories to contribute to CentOS Stream 8. The only exception is the kernel repository [1], we will keep that one up. Please let us know if you find these repositories useful or are part of your routine. Our focus for the future is to deliver a consistent source-git workflow for Fedora and CentOS Stream under the umbrella of Fedora source-git SIG [2]. [1] https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8 [2] https://fedoraproject.org/wiki/SIGs/Source-git Tomas

1 2

[Cloud SIG] Cloud SIG chairs elections
by Alfredo Moralejo Alonso 09 May '22

09 May '22

Hi, The Cloud SiG has been active for the past year and it's time to hold elections for chair and co-chair again. Please reply to this email with your self-nominations and nominations for other members of the SiG. If you are nominated by another member of the SiG please re[;y to this mail as well with your acceptance (make sure amy(a)redhat.com is cc'ed). Nominations will conclude at the start of the May Meeting[0]. If we have a quorum, we will hold elections during this week's meeting. If a quorum is not met, we will ask for 1-2 volunteers and hold an election outside our regular meetings in the next week. Any questions please reach out to Amy Marrich (amy(a)redhat.com) 0 - https://www.centos.org/community/calendar/#cloud-sig

3 3

packaging DPDK 21.11 in RPM in CentOS 7 (elftools not found)
by Stefan Puiu 06 May '22

06 May '22

Hi, I've already asked this on the dpdk-users list (https://mails.dpdk.org/archives/users/2022-April/006395.html) without getting any answer, so I thought maybe I'd also try centos-devel, since this is a CentOS and dpdk question. We're using a CentOS 7 based distro that is obviously RPM-based, and we package the DPDK with it, in order to run on some of our x86-64 hardware boards. Now, we currently have DPDK 20.11 in our image and are looking to upgrade to 21.11, and I'm hitting a build error about elftools not being found: Program python3 found: YES (/usr/bin/python3) ../buildtools/meson.build:49:8: ERROR: Problem encountered: missing python module: elftools The fix seems to be to install pyelftools from pip: pip3 install pyelftools But that only works for building directly with meson / ninja. That doesn't work when building through rpmbuild. I've struggled to understand this, until I found this RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1937494. It seems Fedora changed the python3 search path so that /usr/local/lib/python is not taken into account if RPM_BUILD_ROOT is defined (see https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe) so basically, when building with rpmbuild, pip-installed packages are ignored. I think I can understand the rationale of the Fedora change when you want to ensure that dependencies are properly set: packages installed using pip are not recorded as RPM dependencies, and the package might break at runtime. However, as far as I can tell, pyelftools seems to be a *build-time dependency*; removing the elftools check in the meson script leads to a build failure. There's no pyelftools RPM for CentOS 7 that I could find, so I don't see another option than installing the package from pip. Also, the python change in Fedora doesn't seem to allow for any workaround. The only thing that I can think of is ugly as hell: symlink everything under /usr/local/python in /usr/lib/python for the DPDK build. I'm not even sure we need pyelftools at runtime; in our build of DPDK-20.11, dpdk-pmdinfo.py doesn't even run (because of missing pyelftools :) ). Are there any other people struggling with this? Is there any more elegant approach that I haven't thought of? Thanks, Stefan.

2 3

CS9 status of secure boot
by Leon Fauster 04 May '22

04 May '22

Hey all, I wonder what the current status of UEFI Secure Boot in CS9 is? I installed CentOS-Stream-9-20220328.0-x86_64-dvd1 on a workstation. # rpm -qa|egrep -i '^efi|kernel-5|^grub2'|sort efibootmgr-16-12.el9.x86_64 efi-filesystem-4-9.el9.noarch efivar-libs-38-2.el9.x86_64 grub2-common-2.06-25.el9.noarch grub2-efi-x64-2.06-25.el9.x86_64 grub2-tools-2.06-25.el9.x86_64 grub2-tools-minimal-2.06-25.el9.x86_64 kernel-5.14.0-75.el9.x86_64 and can't boot with "secure boot" enabled. Grub shows something like ~shim signature bad~. Any updated informations out there? -- Thanks Leon

4 5

CPE Weekly Update – Week 17 2022
by Michal Konecny 29 Apr '22

29 Apr '22

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/) Week: 25th April - 29th April 2022 If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update-week-17-2022/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I&R-27-04-2022.pdf Update ------ ### Fedora Infra * Issues sending email from fedoraproject.org -> redhat.com. Finally got tls connection reuse working so we didn’t hit their limits. * FCOS apps (almost) all moved from ocp3->ocp4 clusters * Cleaned up after a bodhi bug left rawhide updates in limbo. * Very close to having resultsdb in ocp4 stg working, just some url adjustments left hopefully. * Anitya and the-new-hotness messaging schemas were moved to separate repositories https://github.com/fedora-infra/the-new-hotness-messages https://github.com/fedora-infra/anitya-messages ### CentOS Infra including CentOS CI * Deploying RHEL (like Fedora Infra) in infra is [now supported](https://pagure.io/centos-infra/issue/739) * [Duffy testing/fixes](https://pagure.io/centos-infra/issue/712) still ongoing * Openshift upgrade (fixing jenkins image and [sync issue](https://pagure.io/centos-infra/issue/728)) * Bussiness As Usual (new tags/mirrors changes requests) ### Release Engineering * F36 RC composes 1.1 on friday 1.2 yesterday * Discussion about where container images live and potential move to quay.io ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Prototyping CI actions for Stream 9 using Duffy system, awaiting onboarding from infra * New compose released * Upcoming: Reviewing Stream container and image build processes * Improvements to the CVE checker have been rolled out * Fedora ELN is being used as a prototype for SHA-1 removal in Fedora ## CentOS Duffy CI Goal of this Initiative ----------------------- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates ------- * Parallelize running provisioning/deprovisioning playbooks * More testing and minor fixes ## Package Automation (Packit Service) Goal of this initiative ----------------------- Automate RPM packaging of infra apps/packages Updates ------- * backlog is stocked with plenty of our apps for the time being, more to be added as needed * Expect emails, lots of emails * fasjson-client, fedora-messaging and datagrepper currently being worked on * currently able to build in copr, minus some hiccups * we are currently looking at the best way to version. what are the teams thoughts on moving spec files upstream? it makes everything cleaner in packit. thoughts on a postcard please ## Flask-oidc: oauth2client replacement Goal of this initiative ----------------------- Flask-oidc is a library used across the Fedora infrastructure and is the client for ipsilon for its authentication. flask-oidc uses oauth2client. This library is now deprecated and no longer maintained. This will need to be replaced with authlib. Updates: -------- * Currently finding all instances of oauth2client code in the current flask-oidc code, mapping functionality to whats available in the authlib library. ## EPEL Goal of this initiative ----------------------- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates ------- * EPEL9 up to 2416 source packages (increase of 45 from last week) * qt5-5.15.3 update in CentOS Stream 8 and 9 has caused [update breakages for KDE users](https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedor… on those distros (EPEL8 and EPEL9). Updated packages are being built as we speak. * Unblocked python-aiosignal by adding python-pytest-asyncio to EPEL9. * Unblocked several openstack packages by adding python-ddt to EPEL9. * Resolved python-aiohttp installation issue by adding python-async-timeout to EPEL9. * Updated GitPython in EPEL7 to resolve issue with cloning large repositories. * Bump release of python-cheetah in EPEL7 to fix upgrade path from python-cheetah in CentOS 7 Extras. * Updated incompatible updates policy to reduce minimum time in testing from 2 weeks to 1 week to match regular updates policy. Kindest regards, CPE Team

1 0

New lookaside structure available
by Pierre-Yves Chibon 27 Apr '22

27 Apr '22

A while ago, we spoke about the structure of the lookaside cache used by Red Hat and SIGs [1]. We have made progress on this, there is now two ways SIGs can upload their tarball to the lookaside cache: - Using the current endpoint at: https://git.centos.org/sources/upload.cgi This works the way it always has, you can use `lookaside_upload` from [2] to interact with it, as before. In other words: nothing changes there. For the record, this uses the structure: `baseurl/pkgname/branch/hash`. Example: https://git.centos.org/sources/kernel/c8s/0c4e10577cfd4b4f8e3d83c0406da8ab0… - Using the new endpoint at: https://git.centos.org/sources/sig_upload.cgi This allows any SIG member to upload to the lookaside cache using the same structure as the one used in CentOS Stream and Fedora: `baseurl/pkgname/tarball/hashtype/hash/tarball`. Example: https://sources.stream.centos.org/sources/rpms/kernel/linux-5.14.0-62.el9.t… You can use the `lookaside_upload_sig` script from [3] to interact with it. So we can now either: - not change anything or - use the new endpoint to use the new lookaside structure What are the benefits of the new structure? - It allows to use a `sources` file similar to the one used in CentOS Stream and Fedora, which combined with the changes to support flat dist-git layout should make backporting from CentOS Stream or Fedora easier. - If two SIGs are using the same tarball, only one will be uploaded to the lookaside cache (so, it allows a little disk space saving on the server side). - It no longer ties sources uploaded to a specific git branch, which if you are using gitlab, means you no longer have to follow the branching structure that git.centos.org needs due to its dual purpose. Finally, the recent changes made to the infrastructure are all documented at: https://sigs.centos.org/guide/ More specifically, the changes for the lookaside and git repository structures can be found at: https://sigs.centos.org/guide/git/ The documentation on using gitlab is at: https://sigs.centos.org/guide/gitlab/ Happy hacking! Pierre [1] https://lists.centos.org/pipermail/centos-devel/2022-February/120226.html [2] https://git.centos.org/centos-git-common/blob/master/f/lookaside_upload [3] https://git.centos.org/centos-git-common/blob/master/f/lookaside_upload_sig

1 0

[Cloud] RDO Yoga Released
by Amy Marrich 27 Apr '22

27 Apr '22

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Yoga for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Yoga is the 25th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network: - For CentOS Stream 8 http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-yoga - For CentOS Stream 9 http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-yoga/ 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 Infrastructure SIG. The Cloud Infrastructure 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. Interesting things in the Yoga release include: - RDO Yoga is the first RDO version built and tested for CentOS Stream 9. - In order to ease transition from CentOS Stream 8, RDO Yoga is also built and tested for CentOS Stream 8. Note that next release of RDO will be available only for CentOS Stream 9. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/yoga/highlights.html TripleO in the RDO Yoga release: Since the Xena development cycle, TripleO follows the Independent release model <https://specs.openstack.org/openstack/tripleo-specs/specs/xena/tripleo-inde…> and will only maintain branches for selected OpenStack releases. In the case of Yoga, TripleO will not support the Yoga release. For TripleO users in RDO, this means that: - RDO Yoga will include packages for TripleO tested at OpenStack Yoga GA time. - Those packages will not be updated during the entire Yoga maintenance cycle. - RDO will not be able to included patches required to fix bugs in TripleO on RDO Yoga. - The lifecycle for the non-TripleO packages will follow the code merged and tested in upstream stable/yoga branches. - There will not be any TripleO Yoga container images built/pushed, so interested users will have to do their own container builds when deploying Yoga. You can find details about this on the RDO Webpage <https://www.rdoproject.org/documentation/tripleo-in-xena/> *Contributors* During the Yoga cycle, we saw the following new RDO contributors: - Adriano Vieira Petrich - Andrea Bolognani - Dariusz Smigiel - David Vallee Delisle - Douglas Viroel - Jakob Meng - Lucas Alvares Gomes - Luis Tomas Bolivar - T. Nichole Williams - Karolina Kula 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 40 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: - Adriano Vieira Petrich - Alan Bishop - Alan Pevec - Alex Schultz - Alfredo Moralejo - Amy Marrich (spotz) - Andrea Bolognani - Chandan Kumar - Daniel Alvarez Sanchez - Dariusz Smigiel - David Vallee Delisle - Douglas Viroel - Emma Foley - Gaël Chamoulaud - Gregory Thiemonge - Harald - Jakob Meng - James Slagle - Jiri Podivin - Joel Capitao - Jon Schlueter - Julia Kreger - Kashyap Chamarthy - Lee Yarwood - Lon Hohberger - Lucas Alvares Gomes - Luigi Toscano - Luis Tomas Bolivar - Martin Kopec - mathieu bultel - Matthias Runge - Riccardo Pittau - Sergey - Stephen Finucane - Steve Baker - Takashi Kajinami - T. Nichole Williams - Tobias Urdin - Karolina Kula - User otherwiseguy - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Zed. *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. Finally, for those that don’t have any hardware or physical resources, there’s 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 the 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://mail.rdoproject.org. 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 and TripleO IRC channels (#centos, #centos-devel in Libera Chat network, and #tripleo on OFTC), 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 #tripleo 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 <https://www.redhat.com/>

1 0

httpd CVEs in CentOS 8 Stream
by Ken Dreyer 24 Apr '22

24 Apr '22

RHEL 8.5 has the following fixes in the httpd package over the past couple of months: 2022-03-21 Luboš Uhliarik <luhliari(a)redhat.com> - 2.4.37-43.3 - Resolves: #2065247 - CVE-2022-22720 httpd:2.4/httpd: HTTP request smuggling vulnerability in Apache HTTP Server 2.4.52 and earlier 2022-02-25 Luboš Uhliarik <luhliari(a)redhat.com> - 2.4.37-43.2 - Resolves: #2059256 - CVE-2021-34798 httpd:2.4/httpd: NULL pointer dereference via malformed requests - Resolves: #2059257 - CVE-2021-39275 httpd:2.4/httpd: out-of-bounds write in ap_escape_quotes() via malicious input 2022-01-10 Luboš Uhliarik <luhliari(a)redhat.com> - 2.4.37-43.1 - Resolves: #2035062 - CVE-2021-44790 httpd:2.4/httpd: mod_lua: possible buffer overflow when parsing multipart content I don't see builds that correspond to this in https://koji.mbox.centos.org/koji/packageinfo?packageID=583 , and this URL hangs in my browser: https://git.centos.org/rpms/httpd When should I expect these CVE fixes in CentOS 8 Stream? - Ken

6 7

oVirt 4.5.0 Release Announcement
by Sandro Bonazzola 20 Apr '22

20 Apr '22

The CentOS Virtualization SIG on behalf of the oVirt Project Community is pleased to announce the general availability of the oVirt 4.5.0 build for CentOS Stream, Red Hat Enterprise Linux and derivatives. The release is already available on the CentOS mirror network. Read more on the announcement blog post at https://blogs.ovirt.org/2022/04/ovirt-4-5-0-is-now-generally-available/ Many thanks to the other CentOS Special Interest Groups involved in this release. Questions about the release? Please join the discussion on https://lists.ovirt.org/archives/list/users@ovirt.org/ Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Board meeting recording and office hours
by Shaun McCance 19 Apr '22

19 Apr '22

Hi folks, I've uplaoded the recording of last week's board meeting: https://youtu.be/ubv6tOWGyzE If you'd like to discuss any issues with the board, we'll have an open board office hours this Thursday, April 21, at 14:00 UTC. https://meet.google.com/dax-yfpm-zxh Email me directly if you need dial-in info instead. Thanks, Shaun

1 0

How to compile modular SRPMs for CentOS 8?
by Nico Kadel-Garcia 15 Apr '22

15 Apr '22

I admit to disliking "modularity" for RPMs, especially because there are various modularity RPMs I'd like to compile for python 3.9 compatibility. ansible-core requires at least python 3.8, but there are a stack of dependencies for ansible-core which have never been provided for python 3.9, such as python39-sphinx and python39-pytest.. Can anyone offer me suggestions or guidance on how to build those? The SRPMs for python3-pytest and others seem to support modularity, but I'd like to use "mock" locally to test them out.

6 11

Kernel topics at the 13-Apr CentOS Stream office Hours
by Brian Stinson 14 Apr '22

14 Apr '22

Hi Folks, For this month's office hours we're going to have some folks from the Kernel team at Red Hat to chat about kernel maintainer workflows, contributing to the kernel, and cover questions you may have about using or building against the kernel in your SIG. Office Hours are on Wednesday, 13-Apr at 17UTC https://centos.org/community/calendar/#centos-stream-office-hours-meetopens… See you there! --Brian

3 2

[REPORT] Automotive SIG
by Jeffrey Osier-Mixon 13 Apr '22

13 Apr '22

January 2022 Quarterly report submitted by: Jefro Osier-Mixon, Red Hat - acting chair _____________________________________ Membership update This SIG does not have a formal membership process. The mailing list currently has 89 subscribers representing at least 12 companies, though not all subscribers use corporate emails and some are participating as individuals. _____________________________________ Releases in the most recent quarter (or most recent release, if none in that quarter) The SIG now provides a new distribution: Automotive Stream Distribution (AutoSD), a CentOS Stream derivative designed specifically around the needs of an automotive OS, and transparently the upstream project for Red Hat's eventual in-vehicle OS product. AutoSD has been downloaded and used by several organizations who have commented or asked for help, so we know it is getting some traction though of course we don't have exact metrics on usage. _____________________________________ Health report and general activity narrative. The SIG has had two public meetings per month, one formal and one informal "office hours", each with 25-40 attendees, with visible participation from 7-10 separate organizations. This SIG is intended to be a community effort with contributions and shared benefits from all participants. Several Red Hat employees made the first contributions to the project as well as the infrastructure required to build and test it. We now occupy a gitlab repository building software regularly using CI, with build instructions provided. Sample images are present and downloadable along with customization and build instructions. This is a high-level summary of current activity: - The work is migrating to a CentOS namespace within GitLab in order to cement our intention as a community project: https://gitlab.com/centos/automotive - CI/CD infrastructure is in place - Downloadable images are available: https://autosd.sig.centos.org/ - Documentation has been greatly expanded with both community and corporate contributions: https://sigs.centos.org/automotive/ - Documentation now includes detailed contribution guidelines: https://sigs.centos.org/automotive/contributing/contributing-to-auto-sig-re… - Ongoing discussions within the meetings have centered around supported hardware and expectations for documentation - A new meetings page contains recordings of all meetings: https://wiki.centos.org/SpecialInterestGroup/Automotive/Meetings - Synchronous communications have moved from IRC to Matrix thanks to some help from Fedora: https://app.element.io/#/room/#centos-automotive-sig:fedoraproject.org _____________________________________ Issues for the board to address, if any None, keep up the excellent work :) Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive

1 0

Please update images on VagrantCloud
by Mike DePaulo 08 Apr '22

08 Apr '22

Hi, Could you please update/add the images on VagrantCloud? Your project has already built and uploaded the images, but to cloud.centos.org rather than VagrantCloud. Vagrant has an issue if we try to use cloud.centos.org manual URLs instead of VagrantCloud. VagrantCloud (https://app.vagrantup.com/centos) has: - 8 Stream from 2021-02-10, but the latest manual URL image is 2022-01-25 - 8 from 2020-12-04, but the latest manual URL image is 2021-06-03 - 9 Stream isn't on VagrantCloud at all, but the latest manual URL image is 2022-03-30 The latest images available via for manual URLs: - https://cloud.centos.org/centos/8-stream/x86_64/images/ - https://cloud.centos.org/centos/8/x86_64/images/ - https://cloud.centos.org/centos/9-stream/x86_64/images/ - Mike -- Mike DePaulo He / Him / His Service Reliability Engineer, Pulp Red Hat <https://www.redhat.com/> IM: mikedep333 GPG: 51745404 <https://www.redhat.com/>

1 0

[Openssl]incorrect CVE mentioned in openssl changelog
by Akshar Kanak 08 Apr '22

08 Apr '22

Dear team in latest openssl openssl-1.0.2k-25.el7_9.x86_64 , looks like there is an issue with change logs . rpm -qi --changelog openssl-1.0.2k-25.el7_9.x86_64 shows me " * Wed Mar 23 2022 Dmitry Belyavskiy <dbelyavs(a)redhat.com> - 1:1.0.2k-25 - Fixes CVE-2022-2078 Infinite loop in BN_mod_sqrt() reachable when parsing certificates - Related: rhbz#2067160 " The CVE number should be CVE-2022-0778 . Right ? reference : https://bugzilla.redhat.com/show_bug.cgi?id=2062202 Thanks and regards Akshar

2 1

CPE Weekly Update – Week of April 4th – 8th
by Michal Konecny 08 Apr '22

08 Apr '22

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/) If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update-4th-8th/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I&R-06-04-2022.pdf Update ------ ### Fedora Infra * Started F36 final freeze * Completed mass update/reboot last week before freeze * Hit fun koji bug that made it write our signed with mode 600 so it didn’t sync. Found and fixed all files and patched koji. * Had issue with s390x z/vm instances, but they are now back online (many thanks dhorak!) * Internal mail MX changed, blocking emails from fedoraproject.org -> redhat.com. Updated to new one and slowly caught up. * Completed ansible upgrade. Only thing left to fix is fedora-messaging callback. ### CentOS Infra including CentOS CI * Issues with Jenkins openshift sync plugins * Duffy onboarding with Nils and Pedro * Bussiness as usual, mirror tickets and koji tag requests .. ### Release Engineering * F36 releng final freeze * Retirement of FTI (Fails To Install) packages in F36 * Lots of stalled epel package requests * F37 changes are landing in our tracker ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Planning completed yesterday, focusing on: * 8 + 9 workflow parity * Build imports from c8s koji to c9s koji * Deploying sync2gitlab service * CVE checker service deployment * Testing making github actions running in test suite ## CentOS Duffy CI Goal of this Initiative ----------------------- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates ------- * Tests and fixes for cicoclient * Deployment preparation with Fabian, Pedro and Mark * Work on the Ansible role for Duffy * Meetings, meetings(, meetings!) ## Bodhi Goal of this Initiative ----------------------- This initiative is to separate Bodhi into multiple sub packages, fix integration and unit tests in CI, fix dependency management and automate part of the release process. Read ARC team findings in detail at: https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html Updates ------- * Bodhi 6.0 will be deployed to production a couple of weeks after the Fedora release * E-mail about what’s new in Bodhi 6.0 sent to devel-announce * Wrapping up dependency management ## EPEL Goal of this initiative ----------------------- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates ------- * EPEL9 up to 2247 source packages (increase of 33 from last week) * Rebuilt hwinfo epel8 package to be compatible with unannounced libx86emu soname bump * qt6 on its way to epel9 testing, which will allow more applications * Other notable new epel9 packages: * uwsgi * akmods * Notable mailing list discussions: * [Slowing down the stalled request process](https://lists.fedoraproject.org/archives/list/epel-devel@lists.fed… * [Dependency policy for packages in less common RHEL channels (HighAvailability, ResilientStorage, etc.)](https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedor…) * [EPEL8 packages needing care and feeding](https://lists.fedoraproject.org/archives/list/epel-devel@lists.fed… Kindest regards, CPE Team

1 0

Experimentation with the centos namespace on gitlab
by Brian Stinson 07 Apr '22

07 Apr '22

Hi Folks! We had a thread a few weeks ago about the usage of the “centos” namespace on gitlab: https://lists.centos.org/pipermail/centos-devel/2022-February/120216.html The authentication angle is progressing up to the point that we would like to open up the opportunity for a couple of SIGs to onboard with gitlab and help us round the edges. The idea being to open this up to all the SIGs interested in a few weeks once we have clearer documentations and guidelines around the usage of GitLab. We are currently working on that set of best-practices that SIGs which would like to use the centos namespace on gitlab will need to agree and follow. If you are interested, please let us know (just not everyone at once!) :) Thanks, Brian

6 5

Re: [CentOS-devel] [CentOS] ansible upgrade
by Leon Fauster 06 Apr '22

06 Apr '22

Am 23.02.22 um 13:47 schrieb Fabian Arrotin: > On 22/02/2022 22:37, Leon Fauster via CentOS wrote: >> Am 21.02.22 um 16:24 schrieb Fabian Arrotin: >>> On 21/02/2022 15:49, Leon Fauster via CentOS wrote: >>>> Hey all, back from vacation and seeing ansible 2.12 in the repos now. >>>> Anything to be aware of when upgrading from 2.9 to 2.12 in CS8? >>>> >>> >>> You'd be lucky if it works directly , as there were some semantic >>> changes in ansible, so you'll probably have to review all the >>> changes, and if ansible-core just has the modules (it's a stripped >>> down version of ansible, as you're supposed to download the >>> collections yourself) , and use FQCN (Fully Qualified Collection >>> Names) for modules ... >>> >>> FWIW, CentOS Infra still on ansible 2.9.27 from our own configuration >>> management SIG and ansible-core excluded in yum/dnf to ensure that >>> our automation still runs fine (until we have time to test/convert >>> all our roles/tasks/playbooks to run on ansible 5 - aka ansible-core >>> 2.12.x) >>> >> >> Thanks Fabian for the insights. I was planning such tests for May but >> that seems to be to late now. >> >> I remember that someone wanted to provide a meta package that pull >> additional ansible collections to give a similar experience like 2.9? >> Maybe more an EPEL question ... >> >> -- >> Leon > > There is indeed a an effort to have an ansible meta-package that would > pull both ansible-core and would contain collections (see > https://fedoraproject.org/wiki/Changes/Ansible5) > > I already had a look myself to see how to rebuild/provide it through > configmanagement SIG eventually, as we now have ansible-core availble > Some packages for ansible 5.x are already built on > koji.fedoraproject.org (see > https://koji.fedoraproject.org/koji/packageinfo?packageID=13842) but not > yet available for epel8, due to lack of ansible-core in RHEL 8 (for now, > but coming as it's in 8-stream, so in advance) > > Other introduced problem with ansible-core is the dep on python 3.8, > meaning that while we had ara (Ansible Records Ansible dashboard) > available in configmanagement SIG, it needs to be using same python > interpreter version for the callback, and previous one was built > against/for python 3.6 (like ansible 2.9.x) , so quite some changes ... > Moved this from #centos to #centos-devel: I am using an "ansible community package" (5.5.0) for testing internally now and noticed following behaviour: "yum update" obsoletes "ansible-2.9.27-1.el8.noarch" and installs ansible-core-2.12.2-2.el8.x86_64. A second "yum update" updates to ansible-core-2.12.3-1.el8.x86_64. We have the "ansible community package" as "ansible" in the repos. When doing a "yum install ansible" then dnf downgrades ansible-core to 2.12.2-2.el8. That is caused by the "Obsoletes: ansible" statement in that version but it is changed now to a "Conflicts: ansible < 2.10.0" in the newer version of ansible-core "2.12.3-1.el8.x86_64". IMO - the cs8 compose should remove the intermediate package ansible-core-2.12.2-2.el8.x86_64 to allow installing newer "ansible community package" rpms ... if it comes from the internal or in the future from the EPEL repo is irrelevant. test # rpm -q ansible-core ansible-core-2.12.3-1.el8.x86_64 test # yum install ansible Last metadata expiration check: 0:27:35 ago on Mon Apr 4 16:54:41 2022. Dependencies resolved. ================================================================================================================== Package Architecture Version Repository Size ================================================================================================================== Downgrading: ansible-core x86_64 2.12.2-2.el8 appstream 2.4 M Transaction Summary ================================================================================================================== Downgrade 1 Package Total download size: 2.4 M Is this ok [y/N]: ^COperation aborted. test # yum --exclude ansible-core-2.12.2-2.el8.x86_64 install ansible Last metadata expiration check: 0:27:49 ago on Mon Apr 4 16:54:41 2022. Dependencies resolved. ================================================================================================================== Package Architecture Version Repository Size ================================================================================================================== Installing: ansible noarch 5.5.0-1.el8 is-ws-tools 42 M Transaction Summary ================================================================================================================== Install 1 Package Total download size: 42 M Installed size: 305 M Is this ok [y/N]: Operation aborted. -- Leon

2 1

CentOS Hyperscale SIG Quarterly Report for 2022Q1
by Davide Cavalca 05 Apr '22

05 Apr '22

Hello, I've published our quarterly update for the Hyperscale SIG activities on the CentOS Blog: https://blog.centos.org/2022/04/centos-hyperscale-sig-quarterly-report-for-… Cheers Davide

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel April 2022