devel

devel@lists.centos.org

18 participants
4604 discussions

Build for main CentOS Stream repos with subpackages in a SIG repo
by Sandro Bonazzola 04 Jul '23

04 Jul '23

Hi, is it possible to have a build from https://kojihub.stream.centos.org/koji/ having subpackages that are not going to be shipped in main CentOS Stream repos being somehow filtered to ship those subpackages into a SIG repo? I'm asking specifically about qemu-kvm sub packages we'd like to have in CentOS AutoSD SIG but that are not going to be shipped in main CentOS Stream repos as not relevant/supported in RHEL (qemu-kvm-ui-dbus, BZ# *2207940* <https://bugzilla.redhat.com/show_bug.cgi?id=2207940>). I would like to avoid having to rebuild the same qemu-kvm build within the SIG each time a new release lands in CentOS Stream just to get a subpackage. Is this possible? Thanks, -- 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.*

2 1

t_functional tests :: github checks broken, and the fix.
by Carlos Rodriguez-Fernandez 03 Jul '23

03 Jul '23

Hi Fabian Arrotin, I submitted a PR with a set of tests for libbpf-tools: https://github.com/CentOS/sig-core-t_functional/pull/88 The PR is failing because the python package duffy does not work with pydantic >= 2.0. I provided a commit in my PR that fixes that issue by pinpointing the version to the latest pydantic 1.x version (1.10.10 from 2023-06-30). That commit may need to be cherry picked first to then see if my PR passes the checks. Thank you, Carlos.

1 0

Scheduling the CentOS ISA SIG meeting
by Florian Weimer 30 Jun '23

30 Jun '23

I'd like to propose bi-weekly meetings for the ISA SIG. What about reusing the slot of the Fedora ELN SIG in alternating weeks? The first meeting would then be Friday, July 7th, 16:00 UTC. I proposed that here: Schedule initial sequence of ISA SIG meetings <https://github.com/CentOS/Calendar/pull/62> I'm aware of the holidays in Czechia and the United States next week, but it's just the first meeting, with more to follow. If that slot doesn't work in general and you want to participate in the meetings, please let me know (off-list if you prefer). Thanks, Florian

1 0

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

Where can I find updated CentOS artwork?
by Gordon Messmer 29 Jun '23

29 Jun '23

I don't want to reopen https://git.centos.org/centos/Artwork/issue/1 , but I'm not sure where to ask questions about the status of that work. The centos.org sites (www., wiki., and git.) use updated logos, but I can't find any updated artwork described at https://wiki.centos.org/ArtWork or any linked page. It's possible that I'm overlooking it. Any pointers?

4 4

ISA SIG rebuild status
by Florian Weimer 28 Jun '23

28 Jun '23

Last week, the ISA SIG concluded two rebuilds of a snapshot of CentOS 9 Stream with GCC 12, one with -march=x86-64-v2 (same as CentOS 9 Stream), and one with -march=x86-64-v3. The rebuilds are fairly complete. The following things are missing: * All modular content. * LibreOffice and OpenJDK. * Two Rust packages which require a rebase of their bundled rust-bindgen versions for Clang 16 compatibility. (Rust currently does not follow the subarchitecture in CFLAGS anyway.) I classifed most of the initial build failures, and here are some numbers: GCC 12 induced failures GCC 12 exposes latent undefined behavior 2 various issues (mostly -Werror) 18 GCC 12 C++ header inclusion changes 3 subtotal 23 x86-64-v3 test differences 7 general buildroot/time/policy changes 19 grand total 49 (We switch to GCC 12 for auto-vectorization at -O2 using the very-cheap cost model, something that cannot be model with GCC 11 compiler flags. Without that, a forward-looking comparison between -march=x86-64-v2 and -march=x86-64-v3 is not possible.) The x86-64-v3 test differences are mostly due to GCC's -ffp-contract=fast default, which does not match what some package test suites expect. We saw those on other architectures already, and with -march=x86-64-v3, GCC supports FMA, exposing them for the x86_64 architecture as well. Maybe upstream GCC can revisit the default there. The general failures are in some cases literally due to time because test certificates expired, or a hard-coded date in some test is no longer in the future. Disabling SHA-1 broke some tests as well. The rest is just general drift of build dependencies, introducing incompatibilities. FTBFS bugs have been filed in Red Hat Bugzilla as appropriate. We were able to eliminate a bunch of rebuild issues that are specific to the CBS Koji environment and do not show up in other environments. I should probably send out a separate note about that, in case other SIGs want to do mass rebuilds. We are still working out how to best deliver the rebuilt packages for testing. Until then, the packages are available from the Koji buildroot and can be (mostly) installed with “dnf distro-sync” from an existing CentOS 9 Stream system: <https://cbs.centos.org/kojifiles/repos/isa9s-packages-baseline-el9sbase-bui…> <https://cbs.centos.org/kojifiles/repos/isa9s-packages-optimized-el9sopt-bui…> I would like to thank Troy Dawson for shepherding the build process and reviewing and fixing issues, and Brian Stinson for resolving CBS Koji infrastructure issues. Florian

4 5

9-stream repo file for centos-plus(containing thunderbird)?
by Anthony Alba 27 Jun '23

27 Jun '23

Hi list, Which repo file contains the metalink to centos-plus(containing thunderbird). Here is my current list of repo files but none seem to reference centos-plus. Cheers AA # current list of repo files etc/yum.repos.d/centos-addons.repo etc/yum.repos.d/CentOS-Ceph-Pacific.repo etc/yum.repos.d/CentOS-Ceph-Quincy.repo etc/yum.repos.d/CentOS-Gluster-10.repo etc/yum.repos.d/CentOS-Gluster-11.repo etc/yum.repos.d/CentOS-Gluster-9.repo etc/yum.repos.d/centos-kmods.repo etc/yum.repos.d/centos-kmods-userspace.repo etc/yum.repos.d/CentOS-Messaging-rabbitmq.repo etc/yum.repos.d/CentOS-NFS-Ganesha-4.repo etc/yum.repos.d/CentOS-NFS-Ganesha-5.repo etc/yum.repos.d/CentOS-NFV-OpenvSwitch.repo etc/yum.repos.d/CentOS-OKD-4.13.repo etc/yum.repos.d/CentOS-OKD-4.14.repo etc/yum.repos.d/CentOS-OpenStack-antelope.repo etc/yum.repos.d/CentOS-OpenStack-Client-xena.repo etc/yum.repos.d/CentOS-OpenStack-yoga.repo etc/yum.repos.d/CentOS-OpenStack-zed.repo etc/yum.repos.d/CentOS-OpsTools.repo etc/yum.repos.d/CentOS-oVirt-4.5.repo etc/yum.repos.d/CentOS-oVirt-4.5-testing.repo etc/yum.repos.d/centos.repo etc/yum.repos.d/CentOS-Samba-414.repo etc/yum.repos.d/CentOS-Samba-415.repo etc/yum.repos.d/CentOS-Samba-416.repo etc/yum.repos.d/CentOS-Samba-417.repo etc/yum.repos.d/CentOS-Samba-418.repo etc/yum.repos.d/CentOS-Storage-common.repo etc/yum.repos.d/CentOS-Stream-Hyperscale-Experimental.repo etc/yum.repos.d/CentOS-Stream-Hyperscale.repo etc/yum.repos.d/CentOS-Stream-Hyperscale-Spin.repo etc/yum.repos.d/epel-next.repo etc/yum.repos.d/epel-next-testing.repo etc/yum.repos.d/epel.repo etc/yum.repos.d/epel-testing.repo

2 2

Furthering the evolution of CentOS Stream
by Leon Fauster 26 Jun '23

26 Jun '23

Hi All, I wonder if someone is in the role/position to shed some more light on the topic as announced here https://www.redhat.com/en/blog/furthering-evolution-centos-stream Any deadlines? Does this target only EL10 or also any current release? Would be great if some discussion/communication could be happen. Thanks! -- Leon

7 20

How was the old centos git repo maintained?
by Gordon Messmer 22 Jun '23

22 Jun '23

I never paid much attention to the repos in the past, but after reading a comment about "exploded src.rpms" I picked one to review... (https://git.centos.org/rpms/bash/commits/c8) It looks like there was a process (or a person?) that would unpack released src.rpms into a git repo, delete Source0, and then commit whatever was left. Is that approximately correct?

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