devel May 2022

devel@lists.centos.org

17 participants
17 discussions

Decommissioning of CentOS Stream 8 source-git branches
by Tomas Tomecek 13 May '22

13 May '22

Hello, we would like to announce our plan to decommission and remove the c8s branches of the CentOS Stream source-git repositories. This also means the removal of any repository from the gitlab.com/redhat/centos-stream/src namespace which is left without a branch. Stream 9 content will not be affected. As you might remember, these are the source-git repositories produced by unpacking the c8s branches from CentOS Stream 8 dist-git, and making the resulting content available at gitlab.com/redhat/centos-stream/src. We took a look at the utilization of this content during 2021, based on the GitLab data and found out that no one from the community has used these repositories to contribute to CentOS Stream 8. The only exception is the kernel repository [1], we will keep that one up. Please let us know if you find these repositories useful or are part of your routine. Our focus for the future is to deliver a consistent source-git workflow for Fedora and CentOS Stream under the umbrella of Fedora source-git SIG [2]. [1] https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8 [2] https://fedoraproject.org/wiki/SIGs/Source-git Tomas

1 2

[call for feedback/testers] : pagure upgrade on git.stg.centos.org (and future git.centos.org migration)
by Fabian Arrotin 09 May '22

09 May '22

Hi all, Some time ago, we created in our backlog this ticket (https://pagure.io/centos-infra/issue/456) to start investigating migrating to newer pagure version that would bring some features for SIGs, etc (see other tickets/RFEs linked on the ticket 456 for an overview) We finally had the time to work on the needed changes for our ansible role for pagure and so test migrating from pagure 5.8 on CentOS 7 to pagure 5.13 on RHEL8. We have just migrated today our staging instance, aka https://git.stg.centos.org. We don't know when we'll migrate git.centos.org (production instance) as we have first to validate with Red Hat team in charge of pushing all RHEL sources to git.centos.org that it still works fine for them on the staging instance (internal ticket) This mail is more about feedback from you, SIGs members, if you want to also verify that git.stg.centos.org is working fine. Some important things to consider though: - git.stg.centos.org is using stg authentication, so accounts.stg.centos.org, which is *not* in sync with production so different users/passwords, etc - ssh host keys changed and while we could have imported previous host keys, we considered it was better to just have the new ones, but still also worth knowing that they are still signed by our CA, so trusting it would make it work directly (https://github.com/CentOS/ansible-role-sshd/blob/master/defaults/main.yml#L…) - it's a RHEL8 host, so if you were still using ssh-dsa keys, they'd be refused (as it's the case on el8 hosts since the beginning) How to give feedback ? on this thread or on the mentioned ticket on centos-infra tracker. Once it will have been verified, we'll announce the migration for git.centos.org Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

[Cloud SIG] Cloud SIG chairs elections
by Alfredo Moralejo Alonso 09 May '22

09 May '22

Hi, The Cloud SiG has been active for the past year and it's time to hold elections for chair and co-chair again. Please reply to this email with your self-nominations and nominations for other members of the SiG. If you are nominated by another member of the SiG please re[;y to this mail as well with your acceptance (make sure amy(a)redhat.com is cc'ed). Nominations will conclude at the start of the May Meeting[0]. If we have a quorum, we will hold elections during this week's meeting. If a quorum is not met, we will ask for 1-2 volunteers and hold an election outside our regular meetings in the next week. Any questions please reach out to Amy Marrich (amy(a)redhat.com) 0 - https://www.centos.org/community/calendar/#cloud-sig

3 3

packaging DPDK 21.11 in RPM in CentOS 7 (elftools not found)
by Stefan Puiu 06 May '22

06 May '22

Hi, I've already asked this on the dpdk-users list (https://mails.dpdk.org/archives/users/2022-April/006395.html) without getting any answer, so I thought maybe I'd also try centos-devel, since this is a CentOS and dpdk question. We're using a CentOS 7 based distro that is obviously RPM-based, and we package the DPDK with it, in order to run on some of our x86-64 hardware boards. Now, we currently have DPDK 20.11 in our image and are looking to upgrade to 21.11, and I'm hitting a build error about elftools not being found: Program python3 found: YES (/usr/bin/python3) ../buildtools/meson.build:49:8: ERROR: Problem encountered: missing python module: elftools The fix seems to be to install pyelftools from pip: pip3 install pyelftools But that only works for building directly with meson / ninja. That doesn't work when building through rpmbuild. I've struggled to understand this, until I found this RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1937494. It seems Fedora changed the python3 search path so that /usr/local/lib/python is not taken into account if RPM_BUILD_ROOT is defined (see https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe); so basically, when building with rpmbuild, pip-installed packages are ignored. I think I can understand the rationale of the Fedora change when you want to ensure that dependencies are properly set: packages installed using pip are not recorded as RPM dependencies, and the package might break at runtime. However, as far as I can tell, pyelftools seems to be a *build-time dependency*; removing the elftools check in the meson script leads to a build failure. There's no pyelftools RPM for CentOS 7 that I could find, so I don't see another option than installing the package from pip. Also, the python change in Fedora doesn't seem to allow for any workaround. The only thing that I can think of is ugly as hell: symlink everything under /usr/local/python in /usr/lib/python for the DPDK build. I'm not even sure we need pyelftools at runtime; in our build of DPDK-20.11, dpdk-pmdinfo.py doesn't even run (because of missing pyelftools :) ). Are there any other people struggling with this? Is there any more elegant approach that I haven't thought of? Thanks, Stefan.

2 3

CentOS Summer Dojo, June 17
by Shaun McCance 05 May '22

05 May '22

We will be hosting another online CentOS Dojo on Friday, June 17. This will run roughly from 14:00 to 19:00 UTC, but the schedule is not yet determined, and the exact hours will depend on presentations. https://wiki.centos.org/Events/Dojo/Summer2022 We are seeking presentations about anything of interest to the CentOS community. This includes CentOS Stream, CentOS SIGs, EPEL or other related projects, RHEL, and the various RHEL rebuilds. Submit a proposal: https://forms.gle/B5Wo8FBfi2bAJ7d58 As always, this Dojo is free. However, registration is required to join the event on Hopin. A registration link is on the wiki page above. -- Shaun

1 0

CS9 status of secure boot
by Leon Fauster 04 May '22

04 May '22

Hey all, I wonder what the current status of UEFI Secure Boot in CS9 is? I installed CentOS-Stream-9-20220328.0-x86_64-dvd1 on a workstation. # rpm -qa|egrep -i '^efi|kernel-5|^grub2'|sort efibootmgr-16-12.el9.x86_64 efi-filesystem-4-9.el9.noarch efivar-libs-38-2.el9.x86_64 grub2-common-2.06-25.el9.noarch grub2-efi-x64-2.06-25.el9.x86_64 grub2-tools-2.06-25.el9.x86_64 grub2-tools-minimal-2.06-25.el9.x86_64 kernel-5.14.0-75.el9.x86_64 and can't boot with "secure boot" enabled. Grub shows something like ~shim signature bad~. Any updated informations out there? -- Thanks Leon

4 5

Re: [CentOS-devel] [EPEL-devel] Re: Qt update and packages rebuild
by Alex Iribarren 02 May '22

02 May '22

Hi, On 4/29/22 21:17, Stephen John Smoogen wrote: > > > On Fri, 29 Apr 2022 at 14:28, Germano Massullo > <germano.massullo(a)gmail.com <mailto:germano.massullo@gmail.com>> wrote: > > Recent CentOS Stream Qt update broke some EPEL packages like keepassxc > that needed a rebuild against the new Qt version. > Can we talk about a way to prevent this from happening again? > > > This is the current situation of events for dealing with CentOS Stream > and EPEL > 0. Packages get put into stream at the rate of internal developers doing > things and getting stuff put into GIT. There is no communication to know > when this will happen so knowing what packages to build before this > drops isn't happening. > 1. The QT packages in Stream have taken a week to be fixed due to > various issues found in them. [Mostly they were built in the wrong order > and linked against each other poorly.] So how could we stop this from happening in the future? The 50_test_comps[0] test caught some of the problems, but not all because not all qt5 packages seem to be listed in a comps group. `dnf install qt5-*` is unlikely to work, though I haven't tried. How could we test that all qt5 packages have been correctly rebuilt? If that's done right, the following steps will be a lot less painful. Cheers, Alex > 2. This means rebuilding packages have to wait until that is fixed as > some people found when they jumped on it sooner. Either they could not > rebuild anything or when they rebuilt it they needed to do it again when > the updated packages with the right library links came out. > 3. Packages in EPEL are maintained by a lot of people who may not know > that centos-stream have updated rapidly and do not have the spare > capacity to update sooner than the weekend spare time they had allotted > to do it. > > What are ways that this could be improved? > > -- > Stephen J Smoogen. > Let us be kind to one another, for most of us are fighting a hard > battle. -- Ian MacClaren [0] https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/…

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2022