devel

devel@lists.centos.org

1 participants
4619 discussions

centos-stream-10 compilation fails on Fedora 42
by mkopelev＠redhat.com 02 Jul '25

02 Jul '25

Hi * I am having difficulties compiling locally centos-stream-10 kernel (https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10) on Fedora 42 x86 machine. I am trying to compile for x86 and aarch64 architectures. I am able to build on RHEL 10,without any difficulties. I am using : make dist-rpms make dist-all-rpms make dist-cross-aarch64-rpms Has anyone had a success in such a compilation?It seems to be impossible without making fixes to the build process

1 0

Reminder: Fedora Infra DC move (and impact[s]] on CentOS) next week
by Fabian Arrotin 29 Jun '25

29 Jun '25

As you're probably aware, Fedora announced some time ago (https://communityblog.fedoraproject.org/fedora-datacenter-move-later-this-y…) that they'd move to a new DC. CentOS will also migrate, but majority of our infra is located in a different DC, and so we'll just announce when we'll migrate our own infra there (this year but not this quarter). The updated blog post version (https://communityblog.fedoraproject.org/2025-fedora-datacenter-move-update/) was mentioning new Fedora plans and main ticket to track Fedora work is https://pagure.io/fedora-infrastructure/issue/12603 Fedora migration will happen next week, but let's list potential impacts on CentOS infra, the main one being probably/surely authentication. As you know, we use common authentication for Fedora and CentOS (so FAS accounts are also ACO accounts, same IPA cluster backend) # Authentication We have our own idp instance (https://id.centos.org) that is already running from new DC (migrated today) but we still expect some authentication issues next week when the whole Fedora infra will move from one DC to the other. That's true for things like : - https://accounts.centos.org (an app running in Fedora openshift cluster - that needs to be migrated, equivalent to https://accounts.fedoraproject.org ) => impact: users not able to sponsor/remove other from groups while maintenance is over - https://fasjson.fedoraproject.org (what permits to retrieve users/groups for some services and also TLS certs used to auth against CBS) => impact: services using fasjson endpoint to retrieve users/group membership will fail to sync (like cbs.centos.org, openshift, etc) All CentOS services will remain "up and running" but there will be some delays to reflect authentication changes. So if you'll encounter beginning of next week some small authentication issues, that can explain why (id.centos.org will be up and running but we depend on Fedora infra backend to be itself up and running). # mirrors and CentOS Stream / SIGs content Other potential impact for centos users : CentOS Stream is depending on Fedora mirrormanager to create needed metalinks used in .repo files. As mirrormanager main crawler will be down during the DC move, Fedora and CentOS users will just retrieve metalinks from "cached" information on Fedora proxies (outside of new DC). That means that operation involving dnf would sometimes fail to reflect new content being pushed out, as we don't know Fedora mirrormanager will be back online and with refreshed content set reflected by mirrors crawler. # CBS For SIGs using epel, we expect also issue while waiting for dl.fedoraproject.org to be up and running again. Other SIGs only building for/against CentOS Stream and RHEL will not be impacted -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 1

TOMOYO in Red Hat kernels
by Tetsuo Handa 18 Jun '25

18 Jun '25

Hello. I hope that some of Red Hat kernel team members are subscribed to this list. I want to use TOMOYO in RHEL kernels. In accordance with Fedora -> CentOS Stream -> RHEL flow, as a first step, I opened https://bugzilla.redhat.com/show_bug.cgi?id=2303689 and am waiting for response. Regards.

3 6

make dist-all-rpms fails with test_progs-no_alu32-extras Error
by Sebastian Hetze 18 Jun '25

18 Jun '25

Hi * I recently tried to compile a custom centos-stream-9 automotive SIG kernel and failed. Now I see the very same problem is present in the mainline centos-stream-9 kernel. When I clone the sources from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9 on a freshly installed centos-stream-9 host, the make dist-all-rpms target fails with make[3]: rsync: Argument list too long make[3]: *** [Makefile:768: test_progs-no_alu32-extras] Error 127 This is certainly not a problem with rsync and the ulimits are definitely sufficient to deal with this ~2000 char argument list. So what is going on here? This rsync call appears to come from the tools/testing/selftests/bpf/Makefile. The problem persists if I BUILDOPTS="-selftests" and I understand bpf to be a SKIP_TARGET by default, anyway. Does anyone have a hint? What is missing or what am I missing? Beste Grüße Sebastian Hetze -- Principal Software Engineer Red Hat GmbH. Niederlassung Berlin Leipziger Platz 16, 10117 Berlin Mobil: +49 173 8914205 E-Mail: she(a)redhat.com Registered seat: Werner von Siemens Ring 14, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

3 9

[Storage-SIG] need a newer libarrow for Ceph Reef
by Tobias Urdin - Binero 17 Jun '25

17 Jun '25

Hello, We’ve always been able to install Storage SIG built Ceph packages without using EPEL9 but when we are testing with the Reef release it looks like we need a newer libarrow that hasn’t been rebuild in Storage SIG since newer thrift 0.15 was introduced. We currently have parquet-libs-9.0.0-1.el9s in Storage SIG [1] but that has been built against thrift 0.14 so requires libthrift-0.14.0.so()(64bit) but we updated thrift to 0.15 a while ago [2] but newer rebuilt libarrow. The rebuild in EPEL9 happend way back in parquet-libs-9.0.0-9.el9 with [3], perhaps we can rebuild libarrow in Storage SIG against current thrift as well to fix this? @kkeithle: any chance you could start a new build for libarrow in Storage SIG? - package librgw2-2:18.2.7-1.el9s.x86_64 from cloud requires libparquet.so.900()(64bit), but none of the providers can be installed - cannot install the best candidate for the job - nothing provides libthrift-0.14.0.so()(64bit) needed by parquet-libs-9.0.0-1.el9s.x86_64 from cloud /Tobias [1] https://cbs.centos.org/koji/rpminfo?rpmID=387534 [2] https://cbs.centos.org/koji/buildinfo?buildID=50735 [3] https://src.fedoraproject.org/rpms/libarrow/c/e1d0139e9685b9ddf29a84a4ba802…

2 4

PostgreSQL ?
by lejeczek 16 Jun '25

16 Jun '25

Hi guys. Do we have 'postgresql-server' in some default repo? I see there is a module but it seems to be "empty". If not what method do you recommend for pgsql? many thanks, L.

2 1

Board Nominations Requested
by Shaun McCance 10 Jun '25

10 Jun '25

** Please read this entire email before responding with nominations. ** We have a process, and the process is important. Recently, Thomas Oulevey announced he would be stepping down from the CentOS Board: https://blog.centos.org/2025/06/reflecting-on-my-centos-journey-a-thank-you… We are asking you, the CentOS community, for nominations for who should fill Thomas's seat. Note that the vote on who will fill this seat is held by the Board itself, but nominations are open to the entire community. If you would like to nominate someone (or self-nominate), please use this Google form: https://forms.gle/B1SPgnxMSb1UDq467 Please DO NOT send nominations to this list. As this is not a public vote, we don't want to give the impression of a popularity contest with public nominations. We also want to avoid any shaming if someone is nominated and is not seated, or chooses not to accept. I will ensure that each nominee is willing and able to serve, and the board will consider them and select the next director from the list. I will also ask each candidate for a brief (100-150 words) blurb about why they would be a good fit for the Board. If you wish to nominate someone, you should consider the list of director requirements and recommendations listed at: https://www.centos.org/about/governance/director-requirements/ Nominations will be open until July 11. SPECIAL NOTE: I have some vacation coming up where I will have limited internet connectivity. For confidentiality reasons, this is one of the few things I do that I can't just delegate when I'm out. I will try to respond to email. I'll return on July 8, a few days before nominations end. If you're self-nominating, or if you know you've been nominated, you can help speed up the process by providing the 100-150 word blurb ahead of time. Thank you for your thoughtful consideration and participation in this process. -- Shaun, for the CentOS Board of Directors

2 1

2025-06-11 - CentOS Public Board Meeting
by Thomas Oulevey 10 Jun '25

10 Jun '25

Hi Everyone, Our next board meeting will take place at 20:00 UTC on Wednesday: `date -d "2025-06-11 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 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/Hk_DSMiMge 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. thanks, -- Thomas 'alphacc' Oulevey CentOS Board of Directors Secretary alphacc(a)centosproject.org

1 0

ISA SIG status and ways to get involved?
by Neil Hanlon 06 Jun '25

06 Jun '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

5 5

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

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