devel May 2022

devel@lists.centos.org

17 participants
17 discussions

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

CPE Weekly Update – Week 20 2022
by Michal Konecny 20 May '22

20 May '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: 16th May - 20th May 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-20-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-2022-05-18.pdf Update ------ ### Fedora Infra * Fedora Media Writer 5.0.1 is live/done for both windows and macos! * Email from @redhat.com users to @fedoraproject.org users who use gmail is broken due to SPF changes on rh side. [INC2210845 ](https://redhat.service-now.com/surl.do?n=INC2210845) * Switched to linux-system-roles.nbde_client (automatically unlocking encrypted devices via network) role from our home grown incomplete one after working thru a dracut bug in RHEL8.3+ * RHEL9 content synced and already switched epel9 to use it. * Mass update/reboot in progress, outage later today to finish. ### CentOS Infra including CentOS CI * CentOS Stream storage migration spike (Netapp for nfs/iscsi) (ongoing) * Duffy fixes and tests (ec2 provisioning working) * Git.centos.org pagure upgrade/migration (blocked, waiting on internal Red Hat Team) * 9 stream build targets on cbs/koji now consuming centos9s-buildroot repositories straight from upstream kojihub for Stream 9 (no latency) * Business as usual (mirrors, tags) ### Release Engineering * Archiving older releases * Updating the EOL release date will be part of the release schedule ### Any Other Bussiness * All the zuul jobs are now migrated to [centralized repository](https://pagure.io/fedora-infra/zuul) ## 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 ------- * Changes to the c8s module migration code to automatically filter to modules that are released. * Migration of packages to new c8s infrastructure is moving along. * Fixing the ELN Everything installer. ## 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 ------- * Deployment: apply database schema migrations * Test per tenant quotas and provisioning on EC2 ## Package Automation (Packit Service) Goal of this initiative ----------------------- Automate RPM packaging of infra apps/packages Updates ------- * Mostly business as usual, lots of dependencies * A fair amount of manual packaging needs to happen for most of our applications first * Reducing a lot of dependency pinning * Unfortunately packit [doesn’t support monorepos](https://github.com/packit/packit/issues/1543) at the moment so Bodhi and Datanommer will be blocked until they do. It’s on their roadmap. * scoady pto for ~2 weeks ## 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: -------- * Starting to [implement](https://github.com/fedora-infra/test-auth/blob/authlib_dev/test_… flask-oidc api using authlib. ## 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 2616 source packages (increase of 48 from last week). * Completed transition of epel9 from building against c9s snapshot to building against rhel9. * Retired multiple epel8 packages that were added in rhel8.6. * [Identified and reported](https://bugzilla.redhat.com/show_bug.cgi?id=2084131) version mismatch between c9s gcc and gcc-epel in epel9, working with maintainer to provide a compatible version in epel9-next. * [Ansible rebased to version 5 in epel8](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-67f52f0700) (major update) and [added to epel9](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73e215eb5c). Kindest regards, CPE Team

1 0

Issue with updating on altarch repos
by Lance Albertson 19 May '22

19 May '22

The recent update to grub2 seems to be causing a dependency issue on our systems using the centos-altarch repos (i.e. at least aarch64/ppc64le). The RPM file exists on our mirror and in the XML for repodata, but I don't think it's in the sqlite file. Perhaps a bad update happened when generating the repo data? I've tried re-syncing the mirror several times to make sure we have up to date content. Here's what we're seeing (which is also breaking new installations): Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package at.aarch64 0:3.1.13-24.el7 will be updated ---> Package at.aarch64 0:3.1.13-25.el7_9 will be an update ---> Package glibc.aarch64 0:2.17-325.el7_9 will be updated ---> Package glibc.aarch64 0:2.17-326.el7_9 will be an update ---> Package glibc-common.aarch64 0:2.17-325.el7_9 will be updated ---> Package glibc-common.aarch64 0:2.17-326.el7_9 will be an update ---> Package glibc-devel.aarch64 0:2.17-325.el7_9 will be updated ---> Package glibc-devel.aarch64 0:2.17-326.el7_9 will be an update ---> Package glibc-headers.aarch64 0:2.17-325.el7_9 will be updated ---> Package glibc-headers.aarch64 0:2.17-326.el7_9 will be an update ---> Package grub2.aarch64 1:2.02-0.87.el7.centos.7 will be updated ---> Package grub2.aarch64 1:2.02-0.87.el7.centos.9 will be an update ---> Package grub2-common.noarch 1:2.02-0.87.el7.centos.7 will be updated ---> Package grub2-common.noarch 1:2.02-0.87.el7.9 will be an update ---> Package grub2-efi-aa64.aarch64 1:2.02-0.87.el7.centos.7 will be updated ---> Package grub2-efi-aa64.aarch64 1:2.02-0.87.el7.centos.9 will be an update --> Processing Dependency: grub2-common = 1:2.02-0.87.el7.centos.9 for package: 1:grub2-efi-aa64-2.02-0.87.el7.centos.9 .aarch64 ---> Package grub2-tools.aarch64 1:2.02-0.87.el7.centos.7 will be updated ---> Package grub2-tools.aarch64 1:2.02-0.87.el7.centos.9 will be an update --> Processing Dependency: grub2-common = 1:2.02-0.87.el7.centos.9 for package: 1:grub2-tools-2.02-0.87.el7.centos.9.aa rch64 ---> Package grub2-tools-extra.aarch64 1:2.02-0.87.el7.centos.7 will be updated ---> Package grub2-tools-extra.aarch64 1:2.02-0.87.el7.centos.9 will be an update --> Processing Dependency: grub2-common = 1:2.02-0.87.el7.centos.9 for package: 1:grub2-tools-extra-2.02-0.87.el7.cento s.9.aarch64 ---> Package grub2-tools-minimal.aarch64 1:2.02-0.87.el7.centos.7 will be updated ---> Package grub2-tools-minimal.aarch64 1:2.02-0.87.el7.centos.9 will be an update --> Processing Dependency: grub2-common = 1:2.02-0.87.el7.centos.9 for package: 1:grub2-tools-minimal-2.02-0.87.el7.cen tos.9.aarch64 --> Finished Dependency Resolution --> Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies Error: Package: 1:grub2-tools-extra-2.02-0.87.el7.centos.9.aarch64 (updates) Requires: grub2-common = 1:2.02-0.87.el7.centos.9 Removing: 1:grub2-common-2.02-0.87.el7.centos.7.noarch (@updates) grub2-common = 1:2.02-0.87.el7.centos.7 Updated By: 1:grub2-common-2.02-0.87.el7.9.noarch (updates) grub2-common = 1:2.02-0.87.el7.9 Available: 1:grub2-common-2.02-0.86.el7.centos.noarch (base) grub2-common = 1:2.02-0.86.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.2.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.2 Available: 1:grub2-common-2.02-0.87.el7.centos.6.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.6 Error: Package: 1:grub2-tools-2.02-0.87.el7.centos.9.aarch64 (updates) Requires: grub2-common = 1:2.02-0.87.el7.centos.9 Removing: 1:grub2-common-2.02-0.87.el7.centos.7.noarch (@updates) grub2-common = 1:2.02-0.87.el7.centos.7 Updated By: 1:grub2-common-2.02-0.87.el7.9.noarch (updates) grub2-common = 1:2.02-0.87.el7.9 Available: 1:grub2-common-2.02-0.86.el7.centos.noarch (base) grub2-common = 1:2.02-0.86.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.2.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.2 Available: 1:grub2-common-2.02-0.87.el7.centos.6.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.6 Error: Package: 1:grub2-efi-aa64-2.02-0.87.el7.centos.9.aarch64 (updates) Requires: grub2-common = 1:2.02-0.87.el7.centos.9 Removing: 1:grub2-common-2.02-0.87.el7.centos.7.noarch (@updates) grub2-common = 1:2.02-0.87.el7.centos.7 Updated By: 1:grub2-common-2.02-0.87.el7.9.noarch (updates) grub2-common = 1:2.02-0.87.el7.9 Available: 1:grub2-common-2.02-0.86.el7.centos.noarch (base) grub2-common = 1:2.02-0.86.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.2.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.2 Available: 1:grub2-common-2.02-0.87.el7.centos.6.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.6 Error: Package: 1:grub2-tools-minimal-2.02-0.87.el7.centos.9.aarch64 (updates) Requires: grub2-common = 1:2.02-0.87.el7.centos.9 Removing: 1:grub2-common-2.02-0.87.el7.centos.7.noarch (@updates) grub2-common = 1:2.02-0.87.el7.centos.7 Updated By: 1:grub2-common-2.02-0.87.el7.9.noarch (updates) grub2-common = 1:2.02-0.87.el7.9 Available: 1:grub2-common-2.02-0.86.el7.centos.noarch (base) grub2-common = 1:2.02-0.86.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos Available: 1:grub2-common-2.02-0.87.el7.centos.2.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.2 Available: 1:grub2-common-2.02-0.87.el7.centos.6.noarch (updates) grub2-common = 1:2.02-0.87.el7.centos.6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -- Lance Albertson Director Oregon State University | Open Source Lab

1 0

May board meeting recording and office hours
by Shaun McCance 16 May '22

16 May '22

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

1 0

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

[Cloud SIG][Meeting] CentOS Cloud SIG meeting minutes (2022-05-12)
by Joel Capitao 13 May '22

13 May '22

========================== #centos-meeting: cloud-sig ========================== Meeting started by spotz at 15:00:54 UTC. The full logs are available athttps://www.centos.org/minutes/2022/May/centos-meeting.2022-05-12-15.00.l… . Meeting summary --------------- * LINK: https://etherpad.opendev.org/p/centos-cloud-sig (spotz, 15:01:17) * Roll Call (spotz, 15:01:25) * Election (spotz, 15:03:34) * LINK: https://ci.centos.org/view/rdo/view/all/ (arrfab, 15:17:15) * Yoga release (jcapitao, 15:35:19) * CloudSIG/RDO Yoga was released a few weeks ago (jcapitao, 15:39:54) * SIG report due (jcapitao, 15:44:27) * Update CentOS Site (jcapitao, 15:53:48) * ACTION: jcapitao update meeting and wiki (jcapitao, 15:57:07) Meeting ended at 15:59:41 UTC. Action Items ------------ * jcapitao update meeting and wiki Action Items, by person ----------------------- * jcapitao * jcapitao update meeting and wiki * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jcapitao (53) * spotz (32) * arrfab (10) * centbot (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

CPE Weekly Update – Week 19 2022
by Michal Konecny 13 May '22

13 May '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: 09th May - 13th May 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-19-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-2022-05-11.pdf Update ------ ### Fedora Infra * F34/F35 container builds failing due to 32bit arm ( https://bugzilla.redhat.com/show_bug.cgi?id=2077680 ) * git -core change broke koji. Downgraded git and upstream koji already has a fix. * Got a FMW macos build fully signed and notarized! Unfortunately, now need to find out how to build it to be able to run on older macos. ;( * Fedora 36 release went pretty smoothly, we are now out of Freeze * Business as usual, misc tickets, etc. ### CentOS Infra including CentOS CI * CentOS Stream storage migration spike (Netapp for nfs/iscsi) * Duffy fixes and tests * Investigating hardware issue on CI pool * Investigating ci.centos.org decommission steps * Git.centos.org pagure upgrade/migration (blocked, waiting on internal Red Hat Team) * Updated sshd host key signing (sha1 issue for el9 ssh clients) * Bussiness as usual (mirrors, tags) ### Release Engineering * F36 is out * Firmware win binaries signed * Bussiness as usual - stalled epel packages, package unretirements ## 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 ------- * Finished the RPM import for c8s to Stream Koji * Business as usual otherwise ## 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 ------- * More deployment tests * Per tenant session lifetimes * Some bug fixes ## Package Automation (Packit Service) Goal of this initiative ----------------------- Automate RPM packaging of infra apps/packages Updates ------- * The team is hitting lots of dependency and sub dependency issues, working through them but its slow * fasjson-client is our first package to be fully automated * upstream release -> src.fp.o PR -> koji -> bodhi * Thanks to Nils, Aurelien and Kevin for their help/advice * fedora-messaging, datagrepper, fasjson currently being worked on (all have deps issues) * spec files will be staying downstream, packit has a way to facilitate this ## 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: -------- * Setup dev environment (Work In Progress!) * Starting to implement flask-oidc api using authlib. ## 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 2568 source packages (increase of 113 from last week). * Added rhel+epel-9 mock configs to mock-core-configs. * Updated slurm in epel7 and epel8 to fix CVE-2022-29500 and CVE-2022-29501. * Retired swtpm and libtpms from epel8 because they were added to RHEL8.6. * Added python-texttable to epel9 to allow c8s maintainers (Johnny) to run c9s as a workstation. * Added missing devel packages for cogl, clutter, and clutter-gtk to epel9 to unblock other epel9 requests. Kindest regards, CPE Team

1 0

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

[call for feedback/testers] : pagure upgrade on git.stg.centos.org (and future git.centos.org migration)
by Fabian Arrotin 09 May '22

09 May '22

Hi all, Some time ago, we created in our backlog this ticket (https://pagure.io/centos-infra/issue/456) to start investigating migrating to newer pagure version that would bring some features for SIGs, etc (see other tickets/RFEs linked on the ticket 456 for an overview) We finally had the time to work on the needed changes for our ansible role for pagure and so test migrating from pagure 5.8 on CentOS 7 to pagure 5.13 on RHEL8. We have just migrated today our staging instance, aka https://git.stg.centos.org. We don't know when we'll migrate git.centos.org (production instance) as we have first to validate with Red Hat team in charge of pushing all RHEL sources to git.centos.org that it still works fine for them on the staging instance (internal ticket) This mail is more about feedback from you, SIGs members, if you want to also verify that git.stg.centos.org is working fine. Some important things to consider though: - git.stg.centos.org is using stg authentication, so accounts.stg.centos.org, which is *not* in sync with production so different users/passwords, etc - ssh host keys changed and while we could have imported previous host keys, we considered it was better to just have the new ones, but still also worth knowing that they are still signed by our CA, so trusting it would make it work directly (https://github.com/CentOS/ansible-role-sshd/blob/master/defaults/main.yml#L…) - it's a RHEL8 host, so if you were still using ssh-dsa keys, they'd be refused (as it's the case on el8 hosts since the beginning) How to give feedback ? on this thread or on the mentioned ticket on centos-infra tracker. Once it will have been verified, we'll announce the migration for git.centos.org Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

[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

CentOS Summer Dojo, June 17
by Shaun McCance 05 May '22

05 May '22

We will be hosting another online CentOS Dojo on Friday, June 17. This will run roughly from 14:00 to 19:00 UTC, but the schedule is not yet determined, and the exact hours will depend on presentations. https://wiki.centos.org/Events/Dojo/Summer2022 We are seeking presentations about anything of interest to the CentOS community. This includes CentOS Stream, CentOS SIGs, EPEL or other related projects, RHEL, and the various RHEL rebuilds. Submit a proposal: https://forms.gle/B5Wo8FBfi2bAJ7d58 As always, this Dojo is free. However, registration is required to join the event on Hopin. A registration link is on the wiki page above. -- Shaun

1 0

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

Re: [CentOS-devel] [EPEL-devel] Re: Qt update and packages rebuild
by Alex Iribarren 02 May '22

02 May '22

Hi, On 4/29/22 21:17, Stephen John Smoogen wrote: > > > On Fri, 29 Apr 2022 at 14:28, Germano Massullo > <germano.massullo(a)gmail.com <mailto:germano.massullo@gmail.com>> wrote: > > Recent CentOS Stream Qt update broke some EPEL packages like keepassxc > that needed a rebuild against the new Qt version. > Can we talk about a way to prevent this from happening again? > > > This is the current situation of events for dealing with CentOS Stream > and EPEL > 0. Packages get put into stream at the rate of internal developers doing > things and getting stuff put into GIT. There is no communication to know > when this will happen so knowing what packages to build before this > drops isn't happening. > 1. The QT packages in Stream have taken a week to be fixed due to > various issues found in them. [Mostly they were built in the wrong order > and linked against each other poorly.] So how could we stop this from happening in the future? The 50_test_comps[0] test caught some of the problems, but not all because not all qt5 packages seem to be listed in a comps group. `dnf install qt5-*` is unlikely to work, though I haven't tried. How could we test that all qt5 packages have been correctly rebuilt? If that's done right, the following steps will be a lot less painful. Cheers, Alex > 2. This means rebuilding packages have to wait until that is fixed as > some people found when they jumped on it sooner. Either they could not > rebuild anything or when they rebuilt it they needed to do it again when > the updated packages with the right library links came out. > 3. Packages in EPEL are maintained by a lot of people who may not know > that centos-stream have updated rapidly and do not have the spare > capacity to update sooner than the weekend spare time they had allotted > to do it. > > What are ways that this could be improved? > > -- > Stephen J Smoogen. > Let us be kind to one another, for most of us are fighting a hard > battle. -- Ian MacClaren [0] https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/…

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2022