devel

devel@lists.centos.org

3 participants
4613 discussions

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

CPE Weekly Update – Week 17 2022
by Michal Konecny 29 Apr '22

29 Apr '22

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/) Week: 25th April - 29th April 2022 If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update-week-17-2022/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I&R-27-04-2022.pdf Update ------ ### Fedora Infra * Issues sending email from fedoraproject.org -> redhat.com. Finally got tls connection reuse working so we didn’t hit their limits. * FCOS apps (almost) all moved from ocp3->ocp4 clusters * Cleaned up after a bodhi bug left rawhide updates in limbo. * Very close to having resultsdb in ocp4 stg working, just some url adjustments left hopefully. * Anitya and the-new-hotness messaging schemas were moved to separate repositories https://github.com/fedora-infra/the-new-hotness-messages https://github.com/fedora-infra/anitya-messages ### CentOS Infra including CentOS CI * Deploying RHEL (like Fedora Infra) in infra is [now supported](https://pagure.io/centos-infra/issue/739) * [Duffy testing/fixes](https://pagure.io/centos-infra/issue/712) still ongoing * Openshift upgrade (fixing jenkins image and [sync issue](https://pagure.io/centos-infra/issue/728)) * Bussiness As Usual (new tags/mirrors changes requests) ### Release Engineering * F36 RC composes 1.1 on friday 1.2 yesterday * Discussion about where container images live and potential move to quay.io ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Prototyping CI actions for Stream 9 using Duffy system, awaiting onboarding from infra * New compose released * Upcoming: Reviewing Stream container and image build processes * Improvements to the CVE checker have been rolled out * Fedora ELN is being used as a prototype for SHA-1 removal in Fedora ## CentOS Duffy CI Goal of this Initiative ----------------------- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates ------- * Parallelize running provisioning/deprovisioning playbooks * More testing and minor fixes ## Package Automation (Packit Service) Goal of this initiative ----------------------- Automate RPM packaging of infra apps/packages Updates ------- * backlog is stocked with plenty of our apps for the time being, more to be added as needed * Expect emails, lots of emails * fasjson-client, fedora-messaging and datagrepper currently being worked on * currently able to build in copr, minus some hiccups * we are currently looking at the best way to version. what are the teams thoughts on moving spec files upstream? it makes everything cleaner in packit. thoughts on a postcard please ## Flask-oidc: oauth2client replacement Goal of this initiative ----------------------- Flask-oidc is a library used across the Fedora infrastructure and is the client for ipsilon for its authentication. flask-oidc uses oauth2client. This library is now deprecated and no longer maintained. This will need to be replaced with authlib. Updates: -------- * Currently finding all instances of oauth2client code in the current flask-oidc code, mapping functionality to whats available in the authlib library. ## EPEL Goal of this initiative ----------------------- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates ------- * EPEL9 up to 2416 source packages (increase of 45 from last week) * qt5-5.15.3 update in CentOS Stream 8 and 9 has caused [update breakages for KDE users](https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedor… on those distros (EPEL8 and EPEL9). Updated packages are being built as we speak. * Unblocked python-aiosignal by adding python-pytest-asyncio to EPEL9. * Unblocked several openstack packages by adding python-ddt to EPEL9. * Resolved python-aiohttp installation issue by adding python-async-timeout to EPEL9. * Updated GitPython in EPEL7 to resolve issue with cloning large repositories. * Bump release of python-cheetah in EPEL7 to fix upgrade path from python-cheetah in CentOS 7 Extras. * Updated incompatible updates policy to reduce minimum time in testing from 2 weeks to 1 week to match regular updates policy. Kindest regards, CPE Team

1 0

New lookaside structure available
by Pierre-Yves Chibon 27 Apr '22

27 Apr '22

A while ago, we spoke about the structure of the lookaside cache used by Red Hat and SIGs [1]. We have made progress on this, there is now two ways SIGs can upload their tarball to the lookaside cache: - Using the current endpoint at: https://git.centos.org/sources/upload.cgi This works the way it always has, you can use `lookaside_upload` from [2] to interact with it, as before. In other words: nothing changes there. For the record, this uses the structure: `baseurl/pkgname/branch/hash`. Example: https://git.centos.org/sources/kernel/c8s/0c4e10577cfd4b4f8e3d83c0406da8ab0… - Using the new endpoint at: https://git.centos.org/sources/sig_upload.cgi This allows any SIG member to upload to the lookaside cache using the same structure as the one used in CentOS Stream and Fedora: `baseurl/pkgname/tarball/hashtype/hash/tarball`. Example: https://sources.stream.centos.org/sources/rpms/kernel/linux-5.14.0-62.el9.t… You can use the `lookaside_upload_sig` script from [3] to interact with it. So we can now either: - not change anything or - use the new endpoint to use the new lookaside structure What are the benefits of the new structure? - It allows to use a `sources` file similar to the one used in CentOS Stream and Fedora, which combined with the changes to support flat dist-git layout should make backporting from CentOS Stream or Fedora easier. - If two SIGs are using the same tarball, only one will be uploaded to the lookaside cache (so, it allows a little disk space saving on the server side). - It no longer ties sources uploaded to a specific git branch, which if you are using gitlab, means you no longer have to follow the branching structure that git.centos.org needs due to its dual purpose. Finally, the recent changes made to the infrastructure are all documented at: https://sigs.centos.org/guide/ More specifically, the changes for the lookaside and git repository structures can be found at: https://sigs.centos.org/guide/git/ The documentation on using gitlab is at: https://sigs.centos.org/guide/gitlab/ Happy hacking! Pierre [1] https://lists.centos.org/pipermail/centos-devel/2022-February/120226.html [2] https://git.centos.org/centos-git-common/blob/master/f/lookaside_upload [3] https://git.centos.org/centos-git-common/blob/master/f/lookaside_upload_sig

1 0

[Cloud] RDO Yoga Released
by Amy Marrich 27 Apr '22

27 Apr '22

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Yoga for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Yoga is the 25th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network: - For CentOS Stream 8 http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-yoga - For CentOS Stream 9 http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-yoga/ The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. Interesting things in the Yoga release include: - RDO Yoga is the first RDO version built and tested for CentOS Stream 9. - In order to ease transition from CentOS Stream 8, RDO Yoga is also built and tested for CentOS Stream 8. Note that next release of RDO will be available only for CentOS Stream 9. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/yoga/highlights.html TripleO in the RDO Yoga release: Since the Xena development cycle, TripleO follows the Independent release model <https://specs.openstack.org/openstack/tripleo-specs/specs/xena/tripleo-inde…> and will only maintain branches for selected OpenStack releases. In the case of Yoga, TripleO will not support the Yoga release. For TripleO users in RDO, this means that: - RDO Yoga will include packages for TripleO tested at OpenStack Yoga GA time. - Those packages will not be updated during the entire Yoga maintenance cycle. - RDO will not be able to included patches required to fix bugs in TripleO on RDO Yoga. - The lifecycle for the non-TripleO packages will follow the code merged and tested in upstream stable/yoga branches. - There will not be any TripleO Yoga container images built/pushed, so interested users will have to do their own container builds when deploying Yoga. You can find details about this on the RDO Webpage <https://www.rdoproject.org/documentation/tripleo-in-xena/> *Contributors* During the Yoga cycle, we saw the following new RDO contributors: - Adriano Vieira Petrich - Andrea Bolognani - Dariusz Smigiel - David Vallee Delisle - Douglas Viroel - Jakob Meng - Lucas Alvares Gomes - Luis Tomas Bolivar - T. Nichole Williams - Karolina Kula Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 40 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: - Adriano Vieira Petrich - Alan Bishop - Alan Pevec - Alex Schultz - Alfredo Moralejo - Amy Marrich (spotz) - Andrea Bolognani - Chandan Kumar - Daniel Alvarez Sanchez - Dariusz Smigiel - David Vallee Delisle - Douglas Viroel - Emma Foley - Gaël Chamoulaud - Gregory Thiemonge - Harald - Jakob Meng - James Slagle - Jiri Podivin - Joel Capitao - Jon Schlueter - Julia Kreger - Kashyap Chamarthy - Lee Yarwood - Lon Hohberger - Lucas Alvares Gomes - Luigi Toscano - Luis Tomas Bolivar - Martin Kopec - mathieu bultel - Matthias Runge - Riccardo Pittau - Sergey - Stephen Finucane - Steve Baker - Takashi Kajinami - T. Nichole Williams - Tobias Urdin - Karolina Kula - User otherwiseguy - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Zed. *Get Started* To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project has the users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC. IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel in Libera Chat network, and #tripleo on OFTC), however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube. *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz <https://www.redhat.com/>

1 0

httpd CVEs in CentOS 8 Stream
by Ken Dreyer 24 Apr '22

24 Apr '22

RHEL 8.5 has the following fixes in the httpd package over the past couple of months: 2022-03-21 Luboš Uhliarik <luhliari(a)redhat.com> - 2.4.37-43.3 - Resolves: #2065247 - CVE-2022-22720 httpd:2.4/httpd: HTTP request smuggling vulnerability in Apache HTTP Server 2.4.52 and earlier 2022-02-25 Luboš Uhliarik <luhliari(a)redhat.com> - 2.4.37-43.2 - Resolves: #2059256 - CVE-2021-34798 httpd:2.4/httpd: NULL pointer dereference via malformed requests - Resolves: #2059257 - CVE-2021-39275 httpd:2.4/httpd: out-of-bounds write in ap_escape_quotes() via malicious input 2022-01-10 Luboš Uhliarik <luhliari(a)redhat.com> - 2.4.37-43.1 - Resolves: #2035062 - CVE-2021-44790 httpd:2.4/httpd: mod_lua: possible buffer overflow when parsing multipart content I don't see builds that correspond to this in https://koji.mbox.centos.org/koji/packageinfo?packageID=583 , and this URL hangs in my browser: https://git.centos.org/rpms/httpd When should I expect these CVE fixes in CentOS 8 Stream? - Ken

6 7

oVirt 4.5.0 Release Announcement
by Sandro Bonazzola 20 Apr '22

20 Apr '22

The CentOS Virtualization SIG on behalf of the oVirt Project Community is pleased to announce the general availability of the oVirt 4.5.0 build for CentOS Stream, Red Hat Enterprise Linux and derivatives. The release is already available on the CentOS mirror network. Read more on the announcement blog post at https://blogs.ovirt.org/2022/04/ovirt-4-5-0-is-now-generally-available/ Many thanks to the other CentOS Special Interest Groups involved in this release. Questions about the release? Please join the discussion on https://lists.ovirt.org/archives/list/users@ovirt.org/ Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV 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.*

1 0

Board meeting recording and office hours
by Shaun McCance 19 Apr '22

19 Apr '22

Hi folks, I've uplaoded the recording of last week's board meeting: https://youtu.be/ubv6tOWGyzE If you'd like to discuss any issues with the board, we'll have an open board office hours this Thursday, April 21, at 14:00 UTC. https://meet.google.com/dax-yfpm-zxh Email me directly if you need dial-in info instead. Thanks, Shaun

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