devel

devel@lists.centos.org

11 participants
4618 discussions

CentOS Stream MRs now get AI feedback from Log Detective
by Tomas Tomecek 27 May '25

27 May '25

We are thrilled to announce integration of AI feedback into CentOS Stream merge requests. Log Detective [1] [3] will now comment on merge requests for failed RPM builds, explaining the failure. We want to reduce your triage time, and allow for faster resolution of failed builds by eliminating the need for manual log examination. Please give 👍 to Log Detective’s comments if it is providing accurate information or 👎 if it is incorrect or too vague. The entire system is open source and we welcome your contributions. For more details please head over to the logdetective repository readme [2]. If you are curious how these comments will look like, thanks to Michal Hlavinka for being an early adopter, we can show you examples of both accurate and inaccurate comments: 1. good: https://gitlab.com/redhat/centos-stream/rpms/libtiff/-/merge_requests/26#no… 2. inaccurate: https://gitlab.com/redhat/centos-stream/rpms/libtiff/-/merge_requests/26#no… This system is actively developed and you can expect improvements in the coming weeks. In fact we already received a ton internally and are working through them. This integration was developed by the Log Detective team: Stephen Gallagher, Jakub Kadlcik, Maja Massarini, Jiri Podivin, Miroslav Suchy, Tomas Tomecek Shout out to our collaborators: Veronika Kabatova, Jiri Konecny, Jiri Kyjovsky, Pavel Raiskup Tomas, on behalf of the team [1] https://github.com/fedora-copr/logdetective [2] https://github.com/fedora-copr/logdetective?tab=readme-ov-file#contributing [3] https://logdetective.com/

1 0

NFV SIG active?
by Michał Nasiadka 20 May '25

20 May '25

Hello, I’ve been looking for a contact to current maintainers of OVS/OVN packages. There hasn’t been any update since Feb and there are some important OVN bug fixes. I’m happy to contribute to the SIG - I just need somebody to show me the path :-) Michał Nasiadka mnasiadka(a)gmail.com

1 0

Announcing kvm virt-host repo for CentOS Stream 10 ppc64le
by Fabian Arrotin 16 May '25

16 May '25

Hi all, As discussed recently in the CentOS Virt SIG list (https://lists.centos.org/hyperkitty/list/virt@lists.centos.org/thread/EPGFO…) , I'd like to officially announce that it's now possible to run kvm guests on top of CentOS Stream 10 ppc64le with the newly Virt SIG available repository (only covering ppc64le architecture, as qemu-kvm/libvirt and deps were available already for other architectures) Packages are available on https://mirror.stream.centos.org/SIGs/10-stream/virt/ppc64le/kvm-power/ For your convenience (common practice for stream users), corresponding centos-release package is available (only for ppc64le) so you can just issue these commands and you'll be able to then install what's needed : ``` dnf makecache ; dnf install centos-release-kvm-power ; dnf install qemu-kvm libvirt virt-install ``` I'd like to personally thank Lance Albertson (OSUOSL), Eduard Abdullin (Almalinux) for their patches, that were used for these Virt SIG builds. As always, you'll be able to find branched packages under https://gitlab.com/CentOS/virt/rpms On behalf of the CentOS Virt SIG, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

[Storage-SIG] centos-release-ceph-squid missing deps
by Sandro Bonazzola 14 May '25

14 May '25

Hi, looks like centos-release-ceph-squid is missing deps: ``` # dnf install centos-release-ceph-squid Last metadata expiration check: 0:09:29 ago on Wed Apr 9 09:40:18 2025. Error: Problem: cannot install the best candidate for the job - nothing provides centos-release-storage-common needed by centos-release-ceph-squid-1.0-2.el10s.noarch from extras-common ```

5 12

Extras-common repository status for s390x architecture
by Fabian Arrotin 13 May '25

13 May '25

Hi, Dusty created a ticket on infra tracker about empty s390x repo for extras-common : https://pagure.io/centos-infra/issue/1635 For visibility/awareness I'd like to discuss that here and then work on ticket eventually, as it would involve other SIGs. For a long time, we had no s390x arch support in CBS but it was finally available end of 2024 (https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/YW24…) So, now the interesting question : what to do about s390x ? It's easy to just add it to the extras-common build tag (https://cbs.centos.org/koji/taginfo?tagID=2914) and it would start pushing centos-release* noarch pkgs out , and so available for s390x users (are there a lot of these ? ) But while it would "solve" the issue mentioned by Dusty above, it would be giving impression that there are SIG content s(like ceph/gluster/else, so content built by SIGs) available for s390x, while only NFV/Infra (for our own needs)/OKD started to build for s390x. As a reminder, that extras-common repository is only used for SIGs to distribute their -release packages (containing .repo files and gpg pub key) so that it can be directly installed from a centos stream release (that's the only repo that is available by default, coming from CBS - community and so outside of stream repositories like BaseOS/AppStream/CRB/etc) I'd like to have your opinion/thoughs/feedback about this . -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

7 12

[Storage-SIG] new build for Ceph Reef 18.2.7 release
by Tobias Urdin - Binero 13 May '25

13 May '25

Hello o/ For CentOS Stream 9 the latest Ceph Reef build looks to be 18.2.5, this version and 18.2.6 contains critical bugs and those versions are not recommend due to that, they are fixed in 18.2.7 Can we please have a new build for Ceph Reef with 18.2.7 started? Thanks! /Tobias

1 0

AutoSD and Eclipse SDV
by Leonardo Rossetti 02 May '25

02 May '25

Hello, I would like to write a proposal to the Eclipse SDV community[0] about creating a project (i.e. a repository) to maintain an AutoSD[1] image to meet their needs while exposing our automotive platform to Eclipse SDV members. Eclipse SDV (Software Defined Vehicle) is a working group under the eclipse foundation organization that aims to act as an umbrella OSS organization for SDV related projects[2]. AutoSD does not provide “base images” as upstream CentOS Stream but it does provide sample manifest files[3] and tooling[4] to build AutoSD images using said manifest files as source; It’s important to note that those as “sample manifest files”, meaning that they serve as example for AutoSD users to create and maintain their own manifest files. The main reason why we do not provide a base image is because automotive use cases may vary significantly for each user and it’s tricky to provide a “base OS” that can be either extended or modified. That being said, the proposal to Eclipse SDV is about maintaining a project (repository) in their org. that would host manifest files to build an AutoSD image that fits Eclipse SDV use-cases while using our upstream tooling to build it, that repository will only host YAML files used to build an AutoSD image, such as this one[5]. It’s important to note that the image will still be using everything else from upstream CentOS, such as RPMs, container images and so on. We are not moving any packages or source code development to Eclipse SDV, just some manifest files that will be used to build an image. Any thoughts or concerns about doing so? [0] - https://sdv.eclipse.org/ [1] - https://sigs.centos.org/automotive/ [2] - https://sdv.eclipse.org/projects/ [3] - https://gitlab.com/CentOS/automotive/sample-images [4] - https://gitlab.com/CentOS/automotive/src/automotive-image-builder [5] - https://gitlab.com/CentOS/automotive/autosd-image-eclipse-sdv Regards, -- Leonardo Rossetti Principal Software Engineer, Red Hat <https://www.redhat.com> lrossett(a)redhat.com <https://www.redhat.com>

1 0

RDO Epoxy 2025.1 Release - Important Note at Bottom
by Amy Marrich 01 May '25

01 May '25

RDO Epoxy 2025.1 Release - Important Note at Bottom The RDO community is pleased to announce the general availability of RDO builds for OpenStack 2025.1 Epoxy for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public and hybrid clouds. Epoxy is the 31st release of the OpenStack project, backed by over 1,000 contributors worldwide. This release is already available on CentOS Stream 9 on the CentOS mirror network: https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ The RDO community project curates, packages, builds, tests, and maintains a complete set of OpenStack components for RHEL and CentOS Stream and is a member of the CentOS Cloud SIG. The Cloud SIG focuses on delivering a great user experience for CentOS users looking to build and maintain on-premise, public, or hybrid clouds. All work on RDO and its downstream release, Red Hat OpenStack Services on OpenShift, is 100% open source, with all code changes going into it's related upstream first. You can read the broader upstream OpenStack project highlights at https://releases.openstack.org/epoxy/highlights.html, but here are some highlights: - Notably, active/active support for Dell PowerStore, Dell PowerStore QoS support, NetApp adding support for active/active mode in ISCSI/FC drivers, HPE Nimble replication, and StorPool adding support for pool-to-pool cloning. - To address OSSN-0090 and OSSN-0065, support was added for a new add/get location API that replaces the image update (old location-add) mechanism for consumers such as cinder and nova. - Ironic includes multiple security improvements: - All supported mechanism drivers (ML2/OVS, ML2/OVN) can now use the WSGI API module, and the first phase of deprecation of the eventlet library is complete. - Instances with UEFI can now boot in stateless pending if the image has the hw_firmware_statelessproperty and the compute service has libvirt 8.6.0 or later. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) upgrades will only be supported from the Caracal 2024.1 release to the next SLURP release (phase Epoxy). RDO Epoxy 202 5.1 has been published by the CentOS Storage SIG in the official CentOS repository and has been built and tested with the latest released Ceph 18.2.0 Reef version ( https://docs.ceph.com/en/latest/releases/reef/) *Note:* Follow the instructions in the [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services on the same host. During Epoxy cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Epoxy 2025.1 release: - python-saharaclient (https://review.rdoproject.org/r/c/rdoinfo/+/54360) - puppet-corosync (https://review.rdoproject.org/r/c/rdoinfo/+/53127) - python-oauth2client (dependency https://review.rdoproject.org/r/c/rdoinfo/+/54115) During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: - During the Epoxy cycle, we saw the following new RDO contributors: - Ashish Gupta - Dmitriy Chubinidze - Francisco Seruca Salgado - Ivan Anfimov - Lilach Avraham - Manoj Katari - Saurabh Agarwal - Sofer Athlan-Guyot - Viji Candappa Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 51 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Alan Pevec - Alfredo Moralejo - Amy Marrich - Ananya Banerjee - Artom Lifshitz - Ashish Gupta - Bogdan Dobrelya - Chandan Kumar - Daniel Pawlik - Dmitriy Chubinidze - Douglas Viroel - Eduardo Olivares - Fiorella Yanac - Francesco Pantano - Francisco Seruca Salgado - Harald Jensås - Ivan Anfimov - Jakub Libosvar - Jaromír Wysoglad - Joan Francesc Gilabert - Joel Capitao - Karolina Kula - Lewis Denny - Lilach Avraham - Luigi Toscano - Manoj Katari - Maor Blaustein - Martin Kopec - Matthias Runge - Matthieu Huin - Miguel Garcia - Mikołaj Ciecierski - Pablo Rodríguez Nava - Pooja Jadhav - Rabi Mishra - Radomir Dopieralsk - iRodolfo Alonso - Ronelle Landy - Saurabh Agarwal - Sergii Golovatiuk - Shreshtha Joshi - Sławek Kapłoński - Sofer Athlan-Guyot - Takashi Kajinami - Tobias Urdin - Tony Breeds - Viji Candappa - Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Epoxy. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For those that do not have any hardware or physical resources, there is the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://www.rdoproject.org/community/mailing-lists/. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Join us in #rdo and on the OFTC IRC network. You can also find us on Facebook and YouTube. *Important Note!* We had a thriving, if small, group of community members maintaining packages prior to COVID and we need to return to those days of having folks participate in this effort. The OpenStack RPM packaging effort is in need of package maintainers in order to continue having RPMs. The current maintainers have moved on to new opportunities, so while we have folks continuing to contribute, we currently have no folks to build and maintain packages. Please check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Please reach out if you can help! *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz

1 0

[Infra] - Planned outage : cbs.centos.org - April 29th
by Fabian Arrotin 28 Apr '25

28 Apr '25

Due to a koji upgrade, we'll have to temporary shutdown CentOS Community Build System (aka https://cbs.centos.org) Migration is scheduled for """"Tuesday April 29th, 7:00 am UTC time"""". You can convert to local time with $(date -d '2025-04-29 07:00 UTC') The expected "downtime" is estimated to ~30 minutes , time needed to - disable kojid hosts (eventually a little bit before to ensure running jobs would be finished) - upgrade kojihub to version 1.35.2 (including DB schema changes) - upgrade and enable back koji builders For full details, see https://pagure.io/centos-infra/issue/1639 PS : worth knowing that koji 1.35 introduces a new "on demand" repo generation (https://docs.pagure.org/koji/repo_generation/) . For compatibility purposes, we'll just enable the repo.auto=True setting on existing build tags for el8/el9s/el9s/el10s build tags so that you don't have to wait for repo to be regenerated when submitting a new build) If you want to opt-out, feel free to ask us through infra ticket Thanks for your understanding and patience. on behalf of the Infra team, -- -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

Proposal to default to GitLab for SIG packaging
by Davide Cavalca 28 Apr '25

28 Apr '25

In the last Board meeting we discussed the future of git.centos.org, and whether it would make sense to encourage SIGs to move over to GitLab, as we already have a group at gitlab.com/centos and that's where CentOS Stream development is happening (under gitlab.com/redhat/centos-stream) GitLab also provides features (notably, CI integration via Pipelines and an improved code review flow) that some SIGs would like to use and would benefit from. To this end, I have filed https://git.centos.org/centos/board/issue/129 to summarize the discussion and decide the next steps. We'd welcome any comments and feedback on this. To be clear, there are no plans to sunset git.centos.org at this time. Cheers Davide

10 32

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