devel

devel@lists.centos.org

11 participants
4618 discussions

glibc-2.34-37.el9 enables rseq by default
by Florian Weimer 09 Jun '22

09 Jun '22

We are going to enable rseq registration in glibc by default starting with glibc-2.34-37.el9 (already built in Koji). To facilitate integration with other rseq users, we have backported the GLIBC_2.35 symbol set for rseq integration. Such an ABI update during a major release is not entirely unprecedented for glibc, but hasn't happened in recent times. If an application links against the symbols, RPM will generate the appropriate dependencies, forcing an upgrade to a compatible glibc version. This is unlikely to happen soon because the interface is glibc-specific and has only been added in glibc 2.35, so applications would have to be written specifically for this interface. As a side effect, criu needs to be updated to criu-3.17-2.el9 to remain functional. The background is that rseq is required to implement a useful version of sched_getcpu on AArch64. Previously, a system call had to be used, and with rseq, execution can remain in userspace. The benefit is less on other architectures, but still there (e.g., on x86-64, an obscure LSL instruction is replaced with a memory load). And once glibc registers its rseq area, nothing else in the process can register it again, which is why we need some interface to rseq-using applications. Rather than coming up with our own interface, we decided to just use the upstream interface. Not entirely by accident, the GLIBC_2.35 symbol set for ld.so consists precisely of the rseq symbols, so RPM dependency management should interoperate well with this change. (Our RPM version requires backporting such symbol sets in their entirety, we do not have per-symbol package versioning information like Debian in our package builds.) Due to a kernel bug on the CentOS builders, sched_getcpu may return the wrong values during package builds. I requested a builder kernel update here: Please upgrade c9s builders to an 8.4 or later kernel <https://issues.redhat.com/browse/CS-1129> Downstream, we have plans for maintaining ABI compatibility with RHEL 9.0: backporting the symbol set there as well, without registering rseq by default. I don't know yet if we are going to backport further symbol sets to CentOS 9 Stream. The requirement to backport full symbol sets could be quite onerous. Historically, the main driver for such backports has been to enable running applications on CentOS that have been built on other distributions. I suspect the glibc incompatibility is simply the first problem people saw, and we don't know what problems would have come next after had we eliminated the glibc obstacle. Applications for CentOS should really be built and tested on CentOS. Thanks, Florian

2 2

kmods SIG workflow skips the -70 EL9 kernel - why?
by Anthony Alba 09 Jun '22

09 Jun '22

Hi - I am confused about the SIGs Stream 9 workflow: I would expect the -70 kernel to make it into kmods SIG as I see it in kojihub. Yet the artifacts (I look at kmod-btrfs as example) skip the -70 kernel. Rebuild for 5.14.0-73.el9 Rebuild for 5.14.0-69.el9 So what determines if a kernel release makes into kmods? Cheers, Anthony Alba

2 2

corosynclib rpm issues - ?
by lejeczek 08 Jun '22

08 Jun '22

Hi guys, anybody sees this/similar? -> $ dnf clean all -> $ dnf update Error: Problem: package corosync-3.1.5-3.el9.x86_64 requires corosynclib(x86-64) = 3.1.5-3.el9, but none of the providers can be installed - cannot install both corosynclib-3.1.5-4.el9.x86_64 and corosynclib-3.1.5-3.el9.x86_64 - cannot install both corosynclib-3.1.5-3.el9.x86_64 and corosynclib-3.1.5-4.el9.x86_64 - cannot install the best update candidate for package corosynclib-3.1.5-3.el9.x86_64 - problem with installed package corosync-3.1.5-3.el9.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) -> $ dnf update --allowerasing Dependencies resolved. =================================================================================================== Package Architecture Version Repository Size =================================================================================================== Upgrading: corosynclib x86_64 3.1.5-4.el9 appstream 55 k Removing dependent packages: corosync x86_64 3.1.5-3.el9 @highavailability 606 k glusterfs-ganesha x86_64 10.2-1.el9s @centos-gluster10 64 k pacemaker x86_64 2.1.2-4.el9 @highavailability 1.2 M pcs x86_64 0.11.1-10.el9 @highavailability 26 M many thanks, L.

1 1

CPE Weekly Update – Week 22 2022
by Lenka Segura 03 Jun '22

03 Jun '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: May 30st to June 3rd 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-22-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-06-01.pdf Update ------ ### Fedora Infra * Got to the bottom of an issue causing python38 modules to not be available in the epel8 buildroot * Bunch of reinstalling of openqa workers to help AdamW isolate a lockup issue. Still ongoing. * Moved some more ocp3->ocp4 apps. * Tracked down a https push segfault on src.fp.o to the new jq package in rhel 8.6 (downgraded and filed bug) * Got internetx02 (new donated hw replacement for 01) installed with rhel9. * New ipsilon release! Many thanks Abompard! (dedicated otp field, email or login works, and more) ### CentOS Infra including CentOS CI * Artifacts storage node replacement for CI (ready/deployed but to be announced in wider communication plan) https://pagure.io/centos-infra/issue/605 * CBS/koji proxy/settings tuning due to introduced change for gitlab (breaking some builds/tests) https://pagure.io/centos-infra/issue/782 * Roadmap for CentOS CI move to EC2 (working on communication plan) * Business as usual (mirrors proposals, tags) * Blocked: * Git.centos.org (waiting on EXD) * Stream storage migration (waiting on IT) ### Release Engineering * F34 is going EOL in one week * glibc update broke ostree updates in f36, more info https://pagure.io/releng/issue/10816 * Business as usual ## 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 ------- * Initial push of c8s packages to gitlab. * New Content Resolver feature: it's now showing repo per package in views. * Fedora ELN: Repositories are now closer to CentOS Stream, the Everything repository has been replaced with Extras which contains the packages not explicitly included in the other Variants. ## 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 ------- * Client CLI (almost there) * Migration Preparations ## Package Automation (Packit Service) Goal of this initiative ----------------------- Automate RPM packaging of infra apps/packages Updates ------- * Business as usual * Continued work on noggin-messages and datanommer-models ## 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 ------- * This week we have 5863 (+99) packages, from 2672 (+6) source packages * amavis installation from epel9 problem resolved by backporting upstream patch to switch dependency from libidn to libidn2 * Backported java_arches macro from Fedora to epel9 * Working on a method for enabling CRB repository when epel-release is installed * Deployed fix for some CRB module packages not showing up in the epel8 buildroot, but it caused too many non-default module packages to be included so it had to be rolled back. * Retired lmdb-epel since lmdb-devel was added to RHEL8/RHEL9. Later discovered that some users still depend on the lmdb subpackage (even though nothing in EPEL requires it), so the package was unretired to provided just that subpackage on epel8 only. Kindest regards, CPE Team

1 0

[NFV SIG] NFV SIG meeting minutes - 2020-06-01
by Alfredo Moralejo Alonso 01 Jun '22

01 Jun '22

============================================= #centos-meeting: NFV SIG meeting - 2020-06-01 ============================================= Meeting started by amoralej at 15:04:02 UTC. The full logs are available athttps://www.centos.org/minutes/2022/June/centos-meeting.2022-06-01-15.04.… . Meeting summary --------------- * FDP update (amoralej, 15:05:35) * new ovn versions have been released https://access.redhat.com/errata/RHBA-2022:4784 https://access.redhat.com/errata/RHBA-2022:4791 (amoralej, 15:06:41) * LINK: https://ftp.redhat.com/pub/redhat/linux/enterprise/8Base/en/Fast-Datapath/S… (amoralej, 15:08:56) * openvswitch2.17 has been included in last fdp release https://access.redhat.com/errata/RHBA-2022:4789 (amoralej, 15:11:18) * NFV SIG will rebuild it from srpm in ftp.redhat.com until we can get builds from pre-release (amoralej, 15:11:46) * Dominik Holler is leaving the SIG (amoralej, 15:31:10) * Thank dholler for your work on NFV SIG! (amoralej, 15:31:36) * Thanks for reviving the SIG, and to get good ovn and ovs builds to the community! Was a nice experience! (dholler, 15:32:30) Meeting ended at 15:41:13 UTC. Action Items ------------ People Present (lines said) --------------------------- * amoralej (63) * ykarel (15) * eraviv (7) * dholler (6)

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel