devel

devel@lists.centos.org

15 participants
4613 discussions

ISA SIG status and ways to get involved?
by Neil Hanlon 29 May '25

29 May '25

Hi all, I’ve been trying to get in touch with the ISA SIG but haven’t been able to find much current information, particularly around where conversations are happening these days. I checked the ISA SIG documentation but couldn’t locate a Matrix channel matching the one described, and I haven’t seen any recent meetings in #centos-meeting on Libera or similar. I also noticed a few broken links on various SIG pages, and I know the SIG's original mission had finished, so I figured the best path was to ask here directly. Given the renewed focus on RISC-V, I would love to get involved or help out if there’s anything currently in motion. We (Rocky) are keenly interested in the initiatives mentioned in the recent blog post. Best, Neil Hanlon

3 2

SIGs build pipeline discussion about a change on cbs.centos.org (please read and comment)
by Fabian Arrotin 27 May '25

27 May '25

For a long time, cbs.centos.org had a inherited structure for build tags, and relying on buildsys${version}-release tag. That permitted us to have top-level macros set in all buildroots, that could be changed if needed : some macros like "dist" "rhel" "centos" etc It was all working fine (and still does to some extent) but recently we got a request from Hyperscale SIG to override %distprefix for some of their buildtags (RFE ticket being https://pagure.io/centos-infra/issue/1673) We then found out that it wasn't working as the macros from top-level couldn't be modified (and distprefix evaluated correctly, as it's also evaluated through centos-release-release (see https://gitlab.com/redhat/centos-stream/rpms/centos-stream-release/-/blob/c…) So we thought about just bumping buildsys-macros pkg to just remove duplicates, and it worked on a staging test. The interesting part (where we need your input/feedback) : as CentOS Stream just defines (for 10 but same logic applies on 9) " dist as el10, that means that your builds , even if built against/for CentOS stream would end up with disttags being eventually .el10 instead of .el10s (same thing for stream 9 of course) While it shouldn't be a problem for people only building for Stream, it would suddenly be an eventual problem for people building from same sources, with same NVR, and in parallel for Stream and RHEL, as koji wouldn't allow same built NVR (with same dist tags) Options : #1 : still defining these in the buildsys-macros file : same as usual but it can be an opt-in situation for people wiling to use something like distprefix : we can then "block" buildsys-macros from being populated in buildroots (the approach we took for hyperscale request above) : "less" work from infra/releng perspective but just documentation for these "opt-in" requests #2 : removing all from buildsys-macros and then just defining dist macros as el{9,10}s on koji build tags for SIGs building for both (and so still continuing to build as they do, transparently) #3 : (to be tested and in fact just thinking about it when typing this email) : no change, and we can just , for SIGs willing to use that distprefix/distsuffix macro, just do this : %%distcore .el%{major} %%dist %%{!?distprefix0:%%{?distprefix}}%%{expand:%%{lua:for i=0,9999 do print("%%{?distprefix" .. i .."}") end}}%%{distcore}%%{?distsuffix}%%{?with_bootstrap:%{__bootstrap}} Now that I'm typing that, I think that option 3 is probably the less intrusive and can just be something that SIGs willing to use can just ask for ? Waiting on opinions/feedback -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

4 5

Announcing EL10 buildroot support on cbs.centos.org
by Fabian Arrotin 27 May '25

27 May '25

Just to let you know that we recently got our first ticket asking for el10 buildroot support on cbs.centos.org (like we did for el9) and it's now available. It was confirmed to be working for Kmods SIG (https://pagure.io/centos-infra/issue/1669) Should you need/want to have it, feel free to ask through usual ticket tracker -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

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

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