devel

devel@lists.centos.org

8 participants
4623 discussions

CentOS Infra tracker moving to Gitlab.com (please read)
by Fabian Arrotin 15 Jul '25

15 Jul '25

As proposed/announced/requested by the CentOS Board (https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/NFNC…) projects are now encouraged to migrate to gitlab.com/CentOS namespace, instead of using git.centos.org (pagure). While we'll announce the git.centos.org migration to gitlab.com later (for all the rpms/* projects), we (Infra team) thought that it would be a good idea to move ourselves (and board will probably follow soon ...) our own tracker from pagure.io to gitlab.com/CentOS/infra. # What will happen The current https://pagure.io/centos-infra/issues tracker will be exported/imported in a new project under gitlab.com/CentOS/infra (to be announced when migrated). All metadata/history from open/closed tickets, and labels will be imported (thanks to the work done by Akashdeep on https://github.com/fedora-infra/pagure-exporter/ , the tool used to migrate from pagure to gitlab !) Worth knowing that only tickets and content will be migrated, but as we can't impersonate users at gitlab.com sides, tickets will appear to be created by our bot account used for the migration. You'll be able (and we plan on closing open tickets on pagure.io with a link to new ticket on gitlab.com side) to just "subscribe/watch" new ticket to follow status updates. For new tickets, normal workflow will resume as you'll be the real user creating the ticket[s] (with your gitlab.com account, linked to your ACO/FAS account - see https://docs.centos.org/centos-sig-guide/auth/#linking-your-centos-account-…) # When will that happen Migration is scheduled for July 15th, around 1:00pm UTC The way we'll proceed will be : - create new tracker project on gitlab.com/CentOS/infra - transfer tickets with metadata (that can take some time) - close all open tickets with link to new ticket (same number !) on gitlab.com - set the issue tracker to "read only" on pagure.io/centos-infra - update README.md on pagure.io with some explanations and link to gitlab (in case people aren't following devel mailing list) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 2

CentOS Showcase
by Shaun McCance 14 Jul '25

14 Jul '25

Hi folks, We're holding another CentOS Showcase on July 28. CentOS Showcase is our half-day virtual conference series that we're trying to do three times a year. The CFP is open until July 21. We'd love to hear what you've been working on. https://www.centos.org/events/showcase-2025-07/ All talks are short, just 20 minutes, including any time you want to leave for Q+A. We run the event from 17:00 to about 21:00 UTC. This time slot best accommodates NA Pacific to EU Central. Apologies to folks outside that range. Round planets are hard. CentOS Showcase is free, but we strongly recommend registering. It helps us a lot with planning. The registration link is on the event page. Thanks, Shaun

1 0

Secure boot for CentOS Stream 10 (and soon 9)
by Adam Samalik 10 Jul '25

10 Jul '25

Hi everyone, CentOS Stream 10 now has a working secure boot! This shim-15.8-5.el10 build enabled it earlier this week: https://kojihub.stream.centos.org/koji/buildinfo?buildID=79665 For that to work, the unsigned shim first had to go through a community review: https://github.com/rhboot/shim-review/issues/454 and after that get signed by Microsoft. The signed shim is now available on the mirrors. I'd like to thank Fabian Arrotin for pushing this through and testing, Marta Lewandowska for helping with the review and organization, Nicolas Frayer for all the packaging work, Peter Jones for handling the signing, and Brian Stinson for submitting the initial review. CentOS Stream 9 should have it in the following weeks as well. Cheers, Adam -- Adam Samalik --------------------------- Principal Software Engineer Red Hat

2 1

persistent mirror sync issues
by Colin Walters 09 Jul '25

09 Jul '25

Over the last few days it seems like many of the RPM mirrors are desync'd for some subsets of the repo. Many of my builds do `dnf builddep` and the `appstream|baseos-source` repos seem to have an especially high desync rate. $ podman run --rm -ti quay.io/centos/centos:stream10 bash # dnf --disablerepo='*' --enablerepo=appstream-source update CentOS Stream 10 - AppStream - Source 682 B/s | 3.0 kB 00:04 Errors during downloading metadata for repository 'appstream-source': - Downloading successful, but checksum doesn't match. Calculated: 09dc868bd85b58f482d2645fb823e5f7e835d219c515a72e8bca228dbe402387c72cab68273022a1ec9d76160ad513397549a4e336635ee1e22740ed3ec78ee0(sha512) Expected: 43068ade5bff34f3c74a58bc33e0e63d44de48586ba3ead6ee6b44ea7a506f069c5227a34ab64396b915432495c069f193586d2842208387758d54edb033a2e0(sha512) - Downloading successful, but checksum doesn't match. Calculated: 4fc5a6c4d27c34d0ca881b0ae0332448bc06917fd206bc1f1aab6fc9159c84598528e9c398a338fb67819488c6883239f48b3a37ba95ad887d51857aa396849d(sha512) Expected: 43068ade5bff34f3c74a58bc33e0e63d44de48586ba3ead6ee6b44ea7a506f069c5227a34ab64396b915432495c069f193586d2842208387758d54edb033a2e0(sha512) Error: Failed to download metadata for repo 'appstream-source': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Looking at the logs, mirrors like osuosl.org, ftpmirror.your.org, centos-stream-distro.1gservers.com are all out of sync, but are in the mirror list rotation.

2 2

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

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