May 2023 - 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

[Feedback request] CentOS website theme readability
by Alain Reguera Delgado 17 Aug '24

17 Aug '24

Hi, The website theme is being updated to improve content responsiveness and readability, on both large and small screen devices. Your feedback would be very helpful to detect usability issues and consolidate a design that works well for you. Here is an example page you can use for testing: https://www.dev.centos.org/about/governance/sigs/#functional-sig-responsibi… Is the content of this page readable for you? If possible, provide feedback from both large and small screen devices. Thanks! -- Alain Reguera Delgado <alain.reguera(a)gmail.com>

3 5

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

[REPORT] Quarterly Report - CentOS Automotive SIG
by Jeffrey Osier-Mixon 17 Aug '23

17 Aug '23

January 2023 Quarterly report submitted by: Jefro Osier-Mixon, Red Hat - chair _____________________________________ Membership update This SIG does not have a formal membership process. The mailing list currently has 106 subscribers representing at least 32 organizations, 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 Automotive SIG produces three types of artifacts: - AutoSD, a streaming distribution of CentOS designed for in-vehicle automotive use cases. - An Automotive SIG RPM repository that allows the community to expand the content of AutoSD or experiment with some of its parts. - Sample images, built using OSBuild, which provide examples of how to assemble production images based on AutoSD, customized for some hardware, including container images, based on CoreOS/ostree technologies. AutoSD, or Automotive Stream Distribution, is a streaming distribution for automotive in-vehicle software development based on CentOS Stream. It is transparently the upstream project for Red Hat's eventual in-vehicle OS product. AutoSD has been downloaded and used by many 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. In Q4 2022, we released a version of AutoSD compatible with the emerging SOAFEE specification. SOAFEE (https://soafee.io) is an initiative driven by Arm for the purpose of developing a reference specification for Arm-based software-defined vehicles (SDVs) consisting of an operating system, container orchestration strategy, and application layer. In addition, we introduced a very lightweight container runtime based on podman and systemd that does not include Kubernetes, as the latter represented a significant performance hit on all relevant hardware. We presented at the Arm Developer Summit in November on these topics. In the coming quarter, we plan to tighten up documentation, begin a process for accepting and supporting hardware enablement contributions, and continue to develop AutoSD toward the SOAFEE specification while also contributing to that specification within the SOAFEE community. _____________________________________ Health report and general activity narrative The SIG typically has 1 public meeting per month with 25-40 attendees, with visible participation from 7-10 separate organizations. We have largely given up on a separate office hours meeting due to attendance. This SIG is intended to be a community effort with contributions and shared benefits from all participants. All formal meetings are recorded and posted on this page: https://wiki.centos.org/SpecialInterestGroup/Automotive/Meetings Several Red Hat employees made the initial contributions to the project as well as the infrastructure required to build and test it. We occupy a gitlab repository in the CentOS namespace building software regularly using CI, with build instructions provided on the documentation page at https://sigs.centos.org/automotive/ . Sample images are present and downloadable along with customization and build instructions. _____________________________________ 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 1

Adding bootc images - part of Cloud SIG or separate?
by Colin Walters 29 Jun '23

29 Jun '23

Hello, I'm a developer on Fedora/RHEL and OpenShift. Lately we've been landing a lot of "bootable container" changes in OpenShift core, and there's a lot more to come. However, as we've been doing about this...I've been saying to people that I wish I had a time machine to go back and do bootable containers from the start. There's a lot of things we're doing today that I think we should stop doing, e.g.: - Switching to kernel-rt by fiddling with each node; we should be simply pulling a pre-built bootable container image with that kernel (more on this below) - Getting away from injecting so much persistent state by default (both via Ignition and outside of it) And crucially, I think we should be developing tools and techniques that apply *outside* of Kubernetes/OpenShift and also work well with it. To be direct, I'd like to eventually productize some of what's happening here in RHEL, not in OpenShift. As part of this (potential) re-architecture of how we think of systems management, I created the https://github.com/containers/bootc project. To be direct: If successful, I think bootc will be the successor to (rpm-)ostree. It's also intended to much more closely align with the github.com/containers organization. A simple way to think of this is: One can (build and) run *application* containers with podman; and these containers can also be run in e.g. Kubernetes/OpenShift. One can build *bootable* containers using any tooling (including podman build), but *running* them is via bootc on the end machine. bootc understands kernels etc. But there's a lot to figure out here - and I want to have a space to figure out this stuff and experiment with it outside of a direct-to-product path. I think a CentOS SIG makes sense for this. So what I'd like to do is either: - Add a new effort to the Cloud SIG, which currently (IMO a bit confusingly) hosts OpenStack/RDO and OpenShift/OKD things which would be a 3rd thing. The bootc work would then be the "base OS" split for OKD/SCOS. But of course, nothing stops one from building bootable host images that are instead designed to be RDO/OpenStack hosts. - Or, create a new SIG Personally, I lean towards the latter because honestly I find the naming "Cloud" to be misleading - bootc is also intended to be useful for standalone, non-cloud-infrastructure settings (such as desktops and IoT). Specifically, I'd like to transfer the existing code that lives in https://github.com/cgwalters/bootc-demo-base-images (specifically https://github.com/cgwalters/bootc-demo-base-images/blob/main/c9s.yaml ) into something CentOS-affiliated and explicitly maintained by a team. (Though I'm not super excited to move it to pagure like at least some other SIG content, but let's not get distracted by git hosting too much here). Another way to say it is that I'd love to ship quay.io/centos/centos-boot:stream9 (notice the -boot). Or failing that, it'd be quay.io/centos-boot/centos-boot:stream9 or so. There's a *lot* to discuss in terms of what actually goes in these base images, and also ensuring it's equally ergonomic for users to build their own base images. So really it's very likely there wouldn't be just *one* base image. In fact, I recently introduced a -rt variant with the RT kernel: https://github.com/cgwalters/bootc-demo-base-images/commit/68afb072a5a1396c… - and this was specifically motivated by issues we hit in OCP. But again, I want to have a space where we try to do more of a "clean(er) slate" approach for a while, with notes "not for production use" - for a while. Everything done here though *is* made with that as an explicit goal though (e.g. it's a toplevel design goal too that existing ostree-based systems can be seamlessly switched to be container-based without reprovisioning). At the same time, bootc already introduces some quite new things that need design iteration; for example: https://github.com/containers/bootc#using-bootc-install - we ship tooling such that a container can install itself (without going through a raw disk image as is used by both OCP and Edge deployments today). And at the same time, I'd like to aim to get the Anaconda changes to install these bootable containers in https://github.com/rhinstaller/anaconda/pull/4561 OK this is already too long, so I'm just going to click send =) Thoughts?

7 10

Qemu VS GlusterFS - liburing rpm conlisions
by lejeczek 29 Jun '23

29 Jun '23

Hi guys. Just to let you know that with GlusterFS & latest qemu updates - on Centos 9 I'd image most will have these - there are conflicts which brake update: -> $ dnf update Error: Problem 1: package qemu-img-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1()(64bit), but none of the providers can be installed - package qemu-img-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-img-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.2)(64bit), but none of the providers can be installed - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from @System - cannot install the best update candidate for package qemu-img-17:8.0.0-2.el9.x86_64 - cannot install the best update candidate for package liburing-2.0-1.el9s.x86_64 Problem 2: package glusterfs-server-11.0-1.el9s.x86_64 from @System requires liburing.so.2()(64bit), but none of the providers can be installed - package glusterfs-server-11.0-1.el9s.x86_64 from @System requires liburing.so.2(LIBURING_2.0)(64bit), but none of the providers can be installed - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from @System - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11 - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11-test - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1()(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.2)(64bit), but none of the providers can be installed - cannot install the best update candidate for package qemu-kvm-core-17:8.0.0-2.el9.x86_64 - cannot install the best update candidate for package glusterfs-server-11.0-1.el9s.x86_64 Problem 3: problem with installed package liburing-2.0-1.el9s.x86_64 - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from @System - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11 - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11-test - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1()(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.2)(64bit), but none of the providers can be installed - problem with installed package qemu-kvm-core-17:8.0.0-2.el9.x86_64 - package qemu-kvm-core-17:8.0.0-2.el9.x86_64 from @System requires qemu-kvm-common = 17:8.0.0-2.el9, but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-2.el9.x86_64 from appstream requires qemu-kvm-common = 17:8.0.0-2.el9, but none of the providers can be installed - cannot install both qemu-kvm-common-17:8.0.0-4.el9.x86_64 from appstream and qemu-kvm-common-17:8.0.0-2.el9.x86_64 from @System - cannot install both qemu-kvm-common-17:8.0.0-4.el9.x86_64 from appstream and qemu-kvm-common-17:8.0.0-2.el9.x86_64 from appstream - cannot install the best update candidate for package qemu-kvm-common-17:8.0.0-2.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) many thanks, L.

4 13

Discussion: Open technical questions concerning SIG content for RHEL releases
by Peter Georg 09 Jun '23

09 Jun '23

Dear all, There has been an inquiry to the CentOS Board to clarify how long SIGs can expect to be able to build against RHEL build targets [1]. This is necessary to allow SIGs themselves to communicate expected lifecycle of their content to users. The outcome of this, in summary, is that SIGs should be able to build against RHEL until it reaches EOL (end of Maintenance Phase) + 30 days (no access to ELS content). This policy follows the one used by EPEL. Note: It is (obviously) still up to every single SIG to decide if and for how long they want to support a particular RHEL (or CentOS Stream) release. This inquiry also included respectively raised some technical questions. These technical questions are not to be decided by the CentOS Board. In [2] it has been recommended to discuss these on centos-devel. So let's do that. I want to start with two open questions which I do know of. In case there are other open question concerning this matter please raise them here. First open question is where to push content produced by SIGs for RHEL8 to. To better understand the issue, let me summarize the current situation, for which we first need to define the used format for tags in CBS: <sig><el>-<project>-<version>-{candidate,testing,release} where <el> can currently be 7,8,8s,9,9s Packages tagged for -testing are pushed to: https://buildlogs.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ Packages tagged for -released are push to: If el = 8 or 8s: debuginfo rpm packages: https://debuginfo.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ src.rpm packages: https://vault.centos.org/centos/<el>/<sig>/Source/<project>-<version>/ Everything else: http://mirror.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ If el = 9 or 9s: http://mirror.stream.centos.org/SIGs/<el>/<sig>/<arch>/<project>-<version>/ For src.rpm <arch> is source. Note: Although it is not relevant for the discussion, in fact on the mirrors the suffix "s" of <el> is replaced by "-stream". This currently is all fine. However it is planned that the infrastructure currently used for packages built for 8 or 8s will disappear once CentOS Stream 8 and CentOS Linux 7 are EOL (June 30th, 2024). So in case any SIG decides to produce content for RHEL 8 after that date packages can not be distributed properly anymore. Only using the -testing tag and thus https://buildlogs.centos.org is not really an option as it would probably produce too much load on these. My proposal: After CentOS Stream 8 went EOL (May 31st, 2024), which is the same date as the end of the Full support phase of RHEL 8, at least the -release tag of all RHEL 8 build targets is locked and SIGs have to opt-in in case they want to build content for RHEL 8 during its Maintenance Support phase (End: May 31st 2029) for a particular build target. For these, tagging for -release will then push content to http://mirror.stream.centos.org/SIGs/8/<sig>/<arch>/<project>-<version>/, i.e. the same location as used for 9 and 9s. This gives SIGs one month for all required changes before the currently infrastructure disappears. Of course this means additional work for SIGs and Infra. However at some point the location where to push content to has to be changed before the currently used infrastructure disappears. Choosing an earlier date would result in work for SIGs who do not want to continue providing any packages once RHEL 8 enters Maintenance Support phase anyway. The second open question concerns the centos-release-* packages provided by SIGs to allow users to easily consume SIGs' content. For 8s and 9s the CBS tags extras<el>-extras-common-{candidate,testing,release} are used to build these packages. This repository is added in CentOS Stream 8 and 9. For packages build for RHEL 8 and 9 there is currently no common way to provide any means of easing the process to consume SIGs' content. My proposal to fix this is by adding extras<el>-extras-common-{candidate,testing,release} for <el> = 8 and 9, i.e., using the same system as currently used for 8s and 9s. To further ease the process I propose to introduce a package named centos-release-extras which contains the repository config pointing to the content of the tags extras<el>-extras-common-{testing,release} (only -release enabled by default) and the CentOS-SIG-Extras GPG key. The centos-release-extras packages itself would be built in the extras<el>-extras-common-el<el> build target. Users of RHEL would then only need to install this single package to allow them to easily install any other centos-release-* packages. Obviously someone needs to maintain the centos-release-extras package. I volunteer to maintain this package. [1]: https://git.centos.org/centos/board/issue/82 [2]: https://pagure.io/centos-infra/issue/1002

4 11

registry.centos.org is now decommissioned
by Bama Charan Kundu 07 Jun '23

07 Jun '23

Hi, We are announcing decommission of registry.centos.org infra. * registry.centos.org is removed from DNS entry * container-index repo[1] is no longer maintained and updated. For CentOS official builds please refer to https://www.centos.org/download/ Regards Bama Charan Kundu [1] https://github.com/CentOS/container-index

2 2

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

CentOS Connect at Flock
by Shaun McCance 25 May '23

25 May '23

https://blog.centos.org/2023/05/centos-connect-at-flock-2023/ The CentOS team is excited to announce that we will be hosting a CentOS Connect event at Flock to Fedora on August 2, 2023. CentOS Connect is a series of mini-conferences that showcase the latest developments across the Enterprise Linux ecosystem. These events are usually colocated with other open source conferences to help reach a broad audience. Flock is Fedora's flagship annual conference, bringing together Fedora contributors and community members to share ideas. Flock will take place August 2-4, 2023 in Cork, Ireland. CentOS Connect will be embedded in Flock as a dedicated track on August 2. Registration, CFP, and venue details will be available on the Flock website. This will be Fedora's first return to an in-person Flock since 2019, and we're very excited to partner with them to make this amazing conference happen again. The developments in Fedora over the following year will set the stage for CentOS Stream 10, so this is an ideal time for us to come together and collaborate. We hope you're able to join us in Cork to enjoy these two amazing events together. https://connect.centos.org/ https://flocktofedora.org/ -- Shaun McCance CentOS Community Architect

1 0

CentOS Stream image retention policies
by Troy Dawson 25 May '23

25 May '23

It was pointed out that we don't have CentOS Stream's image retention policies written down anywhere. We're in the process of getting those up into the docs section. But I figured an email would get them out quicker while we work on that. CentOS Stream Image Retention Policies: * Images on CentOS Cloud: https://cloud.centos.org/centos/8-stream/ https://cloud.centos.org/centos/9-stream/ ** Policy: All images are kept for a month. After that, we only keep one set of compose images per month, for up to a year. (I hope that makes sense) ** Images: container, ec2, qcow, vagrant Containers on Quay: https://quay.io/repository/centos/centos?tab=tags ** Policy: Only the latest images are kept. ** Images: container AMI's on AWS: ** Policy: Images are kept for 180 days ** Images: ec2 AMI's Questions and/or possible better wording is welcome. Troy

2 2

repo metadata refresh needed
by Sandro Bonazzola 23 May '23

23 May '23

Good morning. In oVirt CI we are seeing errors like: [MIRROR] ovn22.09-host-22.09.0-31.el9s.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 84909c4cb450c019b923f703efa9bddaa4bc070fa4866eea3551c5205ebe287f(sha256) Expected: 234e5bbdbde4426d8236c5f2d1373fb1379ca2d1149da84b5b831a5950a10c2b(sha256) Similar issue on el8 as well: [MIRROR] openvswitch-selinux-extra-policy-1.0-29.el8s.noarch.rpm: Downloading successful, but checksum doesn't match. Calculated: 3bde93c064d8e1142338e572e3731f733eb1c1e0a06523b9711adefcd6abb716(sha256) Expected: 960a0b5500729627959ecedb74f6e61a1075f082977fe177c7e855c402e81434(sha256) Perhaps packages got signed but repository metadata not refreshed? -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System 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.*

5 11

KDE on CentOS Stream 9
by Troy Dawson 22 May '23

22 May '23

There is a new qt5 update in CentOS Stream 9. This update will be going out when RHEL 9.3 is released six months from now. Again, that is RHEL 9.3, NOT 9.2. I am currently rebuilding KDE for CentOS Stream 9. This will take some time to rebuild and make it through testing. I am suspecting it will not be in stable until May 18. It is a known issue that is being resolved. No need for further bugs. If you have already created a bug, please cc me (tdawson(a)redhat.com) on it, because most of the bugs do not get assigned to me. Thank You Troy

1 3

[Virt SIG] Virtualization SIG meeting minutes - 2023-05-17
by Sandro Bonazzola 18 May '23

18 May '23

=================================== #centos-meeting: Virtualization SIG =================================== Meeting started by sbonazzo at 16:00:41 UTC. The full logs are available at https://www.centos.org/minutes/2023/May/centos-meeting.2023-05-17-16.00.log… . Meeting summary --------------- * Automotive SIG collaboration (sbonazzo, 16:03:25) * working with qemu upstream adding virtio-multitouch and enable GTK3 to use it (patch version 4) (sbonazzo, 16:03:36) * LINK: https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg02098.html (sbonazzo, 16:03:43) * working with qemu upstream adding virtio shared dma-buf (sbonazzo, 16:03:54) * LINK: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg00598.html (sbonazzo, 16:04:04) * Pipewire audio backend for QEMU now included in QEMU 8.1 source tree (sbonazzo, 16:04:12) * LINK: https://wiki.qemu.org/ChangeLog/8.1#Audio_2 (sbonazzo, 16:04:20) * Automotive SIG Digital Cockpit team wants to move away from the qemu GTK ui backend and instead use the dbus ui backend + libmks (sbonazzo, 16:04:31) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2207940 (sbonazzo, 16:04:38) Meeting ended at 16:10:24 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * sbonazzo (15) * centguard (3) -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System 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

CentOS x86-64 SIG naming
by Florian Weimer 15 May '23

15 May '23

During the board meeting, the naming issue was re-raised; “x86 SIG” just isn't that great. So I'd like to propose “x86-64 SIG” instead, with a hyphen. We use “x86_64” in the RPM architecture name and configure triplets, but only because we must, as “-” is consindered a separator in these contexts. The official vendor-neutral architecture name is x86-64. During the meeting, I was under the impression that the board was leaning towards a narrow scope, but that is not quite what the posted minutes reflect. Per Fabian's announcement, we have at least a bit of wiggle room for non-x86 ISA experiments in CBS (ThunderX2 has LSE atomics support). Personally, I'm not interested in such experiments at this time, though. But we could call the SIG “ISA SIG” to keep open the possibility for non-x86 work, if that's what people want. Thoughts? Thanks, Florian

6 7

May board meeting and office hours
by Shaun McCance 15 May '23

15 May '23

The board had its monthly meeting last week. The recording, minutes, and recap are all available. Recording: https://youtu.be/Tmr1MI7bY74 Minutes: https://hackmd.io/@centosboard/SkDqdm_En Recap: https://blog.centos.org/2023/05/centos-board-meeting-recap-may-2023/ We'll have the followup office hours this Thursday, May 18, at 14:00 UTC. Everybody is welcome to join and talk to the baord. https://us06web.zoom.us/j/85621888235?pwd=UmVzdy9jU1VKVU81MENVTU5nNXYxdz09 Hightlights of the recap: * The board discussed work left to be done around the ISA SIG (Issue 115) and the mission statement (Issue 85). * We had a lengthy conversation about defining success and developing project goals. * We discussed some issues around trademarks, including trademark use for mirrors (Issue 113 and Issue 114). * We had brief updates on secureboot (Issue 67) and Azure images (Issue 3). * Due to the cancellation of DevConf.US, we're working on moving CentOS Connect to Flock in August.

1 0

SIGs rpm packages in testing repositories will be signed starting from next week
by Fabian Arrotin 15 May '23

15 May '23

Hi SIGs folks (and testing community) ! Just to inform you that next Monday (May 15th) , we'll migrate our sign-and-push process to a different infra/machine, but you shouldn't see any service disruption. We'll also implement signing for the packages tagged to -testing, and so landing on https://buildlogs.centos.org. It's a request that came through the Infra tracker (https://pagure.io/centos-infra/issue/1131) and that was approved by the CentOS Project board (all details in that ticket) There is nothing to do at your side (it's not an opt-in scenario, it will be implemented for all SIGs), as it will be transparently processed next time you'll (un)tag-build a package (or more) to your -testing tags. (We can also manually process existing -testing repositories on demand , should there be a need/request) You can though bump your 'release' pkg (that contains the .repo files) to reflect gpgcheck=1 and point to same key as for repositories going to the mirror network, but that's optional (SIG's choice) I'll also update the SIG Guide (https://sigs.centos.org/guide/delivery/) to reflect that change. Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 1

RFC (Request for Comments) : future of lists.centos.org (aka centos mailing-lists)
by Fabian Arrotin 14 May '23

14 May '23

Let's chat about centos mailing lists ! https://lists.centos.org is powered by mailman package, available in CentOS 7 , itself going EOL next year. There is no packaged (yet) mailman3 stack (more components than simple mailman 2 stack). Options : # use mailman2 package from RHEL8 That means (in theory) that we can just reinstall the machine with RHEL8, and use the package that is available in AppStream repository: mailman.x86_64 3:2.1.29-12.module+el8.5.0+13466+327eb9f3.2 Normally that should be more or less (to be tested though) transparent migration, but as that module is still relying on python2 itself, we don't know when it will itself go EOL in RHEL8 (BaseOS should be 10y but apps in AppStream can have a shorter TTL) # migrate to mailman3 Clearly much more work to do including see if the mailman3 stack maintainer can branch to epel9 and then we can reuse it. Also time to investigate how to import previous archives from mailman2 to mailman3 but should be doable (needs time to investigate and a PoC) # something else ? All comments, opinions are welcome and let's discuss it in advance and not wait next year when machine will be powered off Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

11 20

Kernel vulnerabilities patched in CentOS Stream 9
by Steven Rosenberg 12 May '23

12 May '23

Thanks to Carl George for pointing out these three CVEs being fixed in the CentOS Stream 9 kernel: https://fosstodon.org/@carlwgeorge/110323344174577155 https://gitlab.com/search?project_id=24152864&scope=merge_requests&search=C… For context, here is the original article that Carl is responding to: https://bugs.chromium.org/p/project-zero/issues/detail?id=2439

1 0

CentOS Cloud SIG meeting minutes (2023-05-11)
by Joel Capitao 11 May '23

11 May '23

====================================================== #centos-meeting: CentOS Cloud SIG meeting (2023-05-11) ====================================================== Meeting started by jcapitao[m] at 15:01:03 UTC. The full logs are available athttps://www.centos.org/minutes/2023/May/centos-meeting.2023-05-11-15.01.l… . Meeting summary --------------- * roll call (jcapitao[m], 15:01:22) * OKD/SCOS update (jcapitao[m], 15:08:25) * the 3-weekly release schedule is all green (jcapitao[m], 15:09:25) * LINK: https://github.com/okd-project/okd-scos/releases (jcapitao[m], 15:09:30) * SCOS builds now push notifications to https://matrix.to/#/#okd:fedoraproject.org (lorbus, 15:10:31) * interest from MicroShift devs to build on OKD/SCOS, WIP (lorbus, 15:11:35) * RDO/OpenStack Update (jcapitao[m], 15:20:50) * RDO Antelope was released on Apr 18th (jcapitao[m], 15:21:01) * LINK: https://lists.centos.org/pipermail/centos-devel/2023-April/142884.html (jcapitao[m], 15:21:30) * LINK: https://github.com/openstack/oslo.middleware/blob/master/requirements.txt#L6 (amoralej, 15:41:00) * Open Floor (jcapitao[m], 15:54:30) Meeting ended at 15:58:49 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * amoralej (58) * jcapitao[m] (42) * spotz_ (11) * lorbus (9) * centguard (4) * karolinku12 (1) * karolinku (0) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

RFC (Request for Comments) : future of bugs.centos.org
by Fabian Arrotin 10 May '23

10 May '23

Let's discuss https://bugs.centos.org ! For a long time, we used to only have one public tracker , powered by MantisBT (https://mantisbt.org/) , and it was https://bugs.centos.org Due to various changes in the CentOS ecosystem in the last years, some categories were removed/migrated elsewhere : - CentOS infra tracker : https://pagure.io/centos-infra/issues - CentOS Stream : https://bugzilla.redhat.com Some other SIGs also started to have (and document) their own tracker (see https://wiki.centos.org/ReportBugs) So the question is : while we can easily migrate bugs.centos.org to el9, should we ? All comments/remarks are welcome, and let's have a plan about what to do Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 4

2023-05-10 - CentOS Public Board Meeting
by Thomas Oulevey 09 May '23

09 May '23

Hi Everyone, Our next board meeting will take place at 20:00 UTC tomorrow: `date -d "2023-05-10 20:00 UTC"` If you would like to attend please send me an email to alphacc(a)centosproject.org ( please do not reply to @centos-devel or use another email address) and you will receive a link to a Zoom meeting room with a passcode, 1 hour before the meeting takes place. The agenda can be checked at (work in progress) : https://hackmd.io/@centosboard/SkDqdm_En As a reminder we will enforce few rules : * Wait to be recognized by the Chair before speaking * Respect the Chair when told your time to speak is over - this will allow us to remain on agenda, and complete the meetings in the allotted time * In the event that there are Board-confidential topics, these will be put at the end of the meeting, in Executive Session, and guests will be asked to leave. We hope to minimize these items, but they do sometimes happen. The most common scenarios in which this may happen are personnel issues, or information that Red Hat wishes to share with the Board, but is not yet public. * Muting of participants, or, in extreme situations, ejection from the meeting, is at the sole discretion of the Chair. * Meetings will be recorded, and published to YouTube (possibly with edits/redaction, as approved by the Directors). Thus, by joining the meeting you consent to have your presence at the meeting, and anything you say during the meeting, made public. I hope some of you can join. Sorry for the late announcement. thanks, -- Thomas 'alphacc' Oulevey CentOS Board of Directors Secretary alphacc(a)centosproject.org

1 0

End dates for CentOS Stream 8 and CentOS Linux 7
by Shaun McCance 04 May '23

04 May '23

CentOS Stream 8 and CentOS Linux 7 will both come to an end in about a year. CentOS Stream 8 will reach end of builds on May 31, 2024. CentOS Linux 7 will reach end of life on June 30, 2024. More information is available on the CentOS blog: https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-an… Please help us spread the word by linking to the blog post. Nobody likes getting caught off guard on these things. Thanks, Shaun McCance CentOS Community Architect Red Hat Open Source Program Office

1 0

[Virt SIG] Virtualization SIG meeting minutes - 2023-05-03
by Sandro Bonazzola 03 May '23

03 May '23

=================================== #centos-meeting: Virtualization SIG =================================== Meeting started by sbonazzo at 16:02:28 UTC. The full logs are available athttps://www.centos.org/minutes/2023/May/centos-meeting.2023-05-03-16.02.l… . Meeting summary --------------- * kata-containers (sbonazzo, 16:03:22) * no updates this week (sbonazzo, 16:03:29) * oVirt updates (sbonazzo, 16:04:30) * upstream developers are suggesting users to swithch to nightly builds as there are no regular releases planned (sbonazzo, 16:04:42) * LINK: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/DMCC5QCHL6ECXN… (sbonazzo, 16:04:49) * Automotive SIG collaboration (sbonazzo, 16:05:55) * working with qemu upstream adding virtio-multitouch and enable GTK3 to use it (sbonazzo, 16:06:06) * LINK: https://lists.nongnu.org/archive/html/qemu-devel/2023-04/msg01961.html (sbonazzo, 16:06:14) * working with qemu upstream adding virtio shared dma-buf (sbonazzo, 16:06:34) * LINK: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg00598.html (sbonazzo, 16:06:44) * working with qemu upstream adding Pipewire audio backend for QEMU (sbonazzo, 16:06:55) * LINK: https://lists.nongnu.org/archive/html/qemu-devel/2023-04/msg02287.html (sbonazzo, 16:07:03) Meeting ended at 16:11:06 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * sbonazzo (23) * centguard (4) * etrunko (4) -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2023