devel

devel@lists.centos.org

3 participants
4613 discussions

CPE Weekly Update – Week of February 28th – March 3rd
by Michal Konecny 04 Mar '22

04 Mar '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/) 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-of-february-… # 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. Update ------ ### Fedora Infra * One new power9 online in iad2, second one needs hands on today. * Almost all bugzilla auth changes made, still need some changes to toddlers (ongoing) * Container builds broken again in an odd way ( https://pagure.io/releng/issue/10658) * Discussion on fedoraplanet.org on infrastructure list, please chime in if you have thoughts about it. ### CentOS Infra including CentOS CI * Migration of Pagure to new CentOS CI in progress * Openssl3 [late change](https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/78fb7… in EL9 impacting SIGs and gpg keys ### Release Engineering * Work on SCM request automation in progress - [PR](https://pagure.io/fedora-infra/toddlers/pull-request/93) * Container builds failing on armhfp * Bussiness as usual ## 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 ------- * Investigating compose QA improvements both in the t-functional suite and changes we may want to implement later in the project. * Developing sync2gitlab service for 8, 9 workflow alignment * Business as usual activities around CentOS Linux 7 * Work continuing on content resolvers maintainer pages also ## 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 ------- * Demo/Status call * Deployment to staging (ongoing) * Documentation (ongoing) * Expiring sessions (ongoing) ## Image builder for Fedora IoT Goal of this Initiative ----------------------- Integration of Image builder as a service with Fedora infra to allow Fedora IoT migrate their pipeline to Fedora infra. Updates ------- * No updates ## Bodhi Goal of this Initiative ----------------------- This initiative is to separate Bodhi into multiple sub packages, fix integration and unit tests in CI, fix dependency management and automate part of the release process. Read ARC team findings in detail at: https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html Updates ------- * No updates ## 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 2059 source packages (increase of 71 from last week) * EPEL9 buildroot has switched to a snapshot of the CentOS Stream 9 mirror, to avoid building against any 9.1 changes prior to the RHEL 9.0 GA * [EPEL Office Hours](https://communityblog.fedoraproject.org/epel-office-hours/) were yestarday at 1700 UTC * epel-release (and epel-next-release) now available in CentOS Stream 9 Extras repo Kindest regards, CPE Team

1 0

GPG check FAILED using CentOS Stream 9 Extras and other SIG Keys
by Brian Stinson 03 Mar '22

03 Mar '22

Hi Folks, OpenSSL in CentOS Stream and RHEL 9 intends to remove the sha1 algorithm, and recently a build landed that makes this change. When that build first went to testing we noticed that the CentOS SIG rpm signing keys (including the one enabled by default for Extras) contained a sha1 signature on one of the subkeys, which caused trouble validating rpms. We have begun to mitigate this by re-signing the offending subkey in the Extras signing key and are currently pushing a compose to the mirrors. If you've previously imported the Extras key (like if you've installed a SIG centos-release package on your system), you may notice messages during an rpm transaction like: `Key import failed (code 2)` followed by `Error: GPG check FAILED` To continue you will need to update to centos-gpg-keys-9.0-12.el9 (plus the corresponding centos-stream-release package) and perform a manual step: `rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras-SHA512` Since all of the SIG keys are affected as well, we are working on re-signing subkeys for those SIGs that are currently shipping content for CentOS Stream 9. We will post links to the updated pubkeys and SIG leaders will need to rebuild their centos-release packages to include these new keys. We expect references to those new keys to be published in the next couple of days. If there are any questions please find us in #centos-devel or #centos-stream in libera, or reply here. Cheers! --Brian References: https://bugzilla.redhat.com/show_bug.cgi?id=2059424

4 4

Introducing the Automotive Stream Distribution
by Pierre-Yves Chibon 02 Mar '22

02 Mar '22

Good Morning Everyone! The CentOS Automotive SIG is excited to announce the Automotive Stream Distribution. This is a binary distribution developed within the SIG that serves as a public, in-development preview of the upcoming Red Hat in-vehicle OS. More information can be found at: https://blog.centos.org/2022/03/centos-automotive-sig-announces-new-autosd-… Best regards, Pierre PS: I had sent this email 13 hours ago but from the wrong account... and I didn't get an error that my messages had been discarded so I didn't notice that it had not reached the list, my apologies for this :(

1 0

CentOS Automotive SIG meeting this week
by Jeffrey Osier-Mixon 02 Mar '22

02 Mar '22

Hi all - just a quick reminder that the next SIG meeting is tomorrow, March 2, at 1500 UTC (10am EDT, 4pm CET). We will talk about the establishment of the AutoSD distro and how to use it. RSVP is not necessary, and everyone is welcome to join. The meeting will be held via Google Meet at this link: https://meet.google.com/hkx-btgd-dyc Please let me know if you would like to be added to the invitation going forward. best, Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive

3 3

CS8 repos / repomd.xml.asc
by Leon Fauster 02 Mar '22

02 Mar '22

Hey. It seems that the mirrors do not have the repomd.xml.asc file. Does the main repo provide it? -- Thanks Leon

5 8

Fw: [CentOS-announce] CESA-2022:0442 Important CentOS 7 log4j Security Update
by Kumar, Sanjeev 02 Mar '22

02 Mar '22

Hi John (Johnny Hughes), Is there a way to get this latest log4j 1.2.17 version be certified as a supported version in the Tenable Plugin Alert as seen below: https://www.tenable.com/plugins/nessus/156032 Since the fix is officially deployed in the mirrors, wouldn't that make the 1.2.17 version a supported version for the nessus plugin? Regards, Sanjeev ________________________________ From: CentOS-announce <centos-announce-bounces(a)centos.org> on behalf of Johnny Hughes <johnny(a)centos.org> Sent: Monday, February 7, 2022 11:47 AM To: centos-announce(a)centos.org <centos-announce(a)centos.org> Subject: [CentOS-announce] CESA-2022:0442 Important CentOS 7 log4j Security Update Warning: Replies to this message will go to centos-announce-bounces(a)centos.org. If you are unsure this is correct please contact the helpdesk. CentOS Errata and Security Advisory 2022:0442 Important Upstream details at : https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Faccess.r… The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 1b461b4e217ac5f51d8990aad583c7f189e73fd3220a54053124772b83c42eba log4j-1.2.17-18.el7_4.noarch.rpm e4950b148639895cb3ed78b8a00c0708abe4685bd380e0003ebeb947ea1edc42 log4j-javadoc-1.2.17-18.el7_4.noarch.rpm 7bbf77456d5e310210c4bd541fee70097c26568f34f44184c878e5874e2b57f1 log4j-manual-1.2.17-18.el7_4.noarch.rpm Source: c4224181672eede65a1b3d8f829c9ed475cade9b7234f58c03994f39459ca732 log4j-1.2.17-18.el7_4.src.rpm -- Johnny Hughes CentOS Project { https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.cento… } irc: hughesjr, #centos(a)libera.chat Twitter: @JohnnyCentOS _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.ce…

3 2

Building python38-createrepo_c in CentOS 8 Stream
by Ewoud Kohl van Wijngaarden 02 Mar '22

02 Mar '22

Hello everyone, I'm sending this on behalf of the packagers of the Pulp project. The Pulp project uses createrepo_c and in particular the Python bindings. The appstream repository does contain python3-createrepo_c but Pulp needs Python 3.8 so it uses the 3.8 module. There is no python38-createrepo_c so for now we're building it ourselves. The problem shows up when createrepo_c is bumped in CentOS Stream. From repoclosure: Depsolve Error occured: Problem: package python38-createrepo_c-0.17.7-3.2.el8.x86_64 requires createrepo_c-libs = 0.17.7-3.2.el8, but none of the providers can be installed - cannot install both createrepo_c-libs-0.17.7-4.el8.x86_64 and createrepo_c-libs-0.17.7-3.2.el8.x86_64 - cannot install both createrepo_c-libs-0.17.7-3.2.el8.x86_64 and createrepo_c-libs-0.17.7-4.el8.x86_64 - cannot install the best update candidate for package python38-createrepo_c-0.17.7-3.2.el8.x86_64 - cannot install the best update candidate for package createrepo_c-libs-0.17.7-3.2.el8.x86_64 It would be ideal if CentOS itself built python38-createrepo_c (and possibly also for other Python modules). Is this something that could be done? Regards, Ewoud

2 3

vault outage
by BC 01 Mar '22

01 Mar '22

I have been unable to connect to vaul since yesterday. Is this a known issue? I can ping in from multiple regions.

2 1

c8 container images - old - ?
by lejeczek 01 Mar '22

01 Mar '22

Hi guys I pulled one yesterday: -> $ podman pull registry.centos.org/centos:latest and it's old EOL centOS 8. Should not there be 'stream' in repos already and EOL ones be removed & gone? (or am I missing something) many thanks, L.

3 3

CentOS SIGs and lookaside cache
by Pierre-Yves Chibon 28 Feb '22

28 Feb '22

Good Morning Everyone, There are currently two lookaside caches in use around the CentOS project: * One used by CentOS-Stream: https://sources.stream.centos.org/sources it's not browsable, but it uses the structure: `baseurl/pkgname/tarball/hashtype/hash/tarball`. Example: https://sources.stream.centos.org/sources/rpms/kernel/linux-5.14.0-62.el9.t… * One used by CentOS-Linux, CentOS-Stream 8 and the SIGs: https://git.centos.org/sources/ this one is browsable and as you can see uses the structure: `baseurl/pkgname/branch/hash`. Example: https://git.centos.org/sources/kernel/c8s/0c4e10577cfd4b4f8e3d83c0406da8ab0… The rest of this email focuses on this second one. SIGs upload to it using the route: https://git.centos.org/sources/upload.cgi In an email last week [1] was proposed an idea for how SIGs could leverage the centos namespace in gitlab for those who wishes. One of the benefits of using gitlab would be increased flexibility for SIGs and a clear example for this would be the ability to drop the branch structures currently imposed on the git repositories. That structure is imposed because the git repositories are shared between CentOS-Linux, CentOS-Stream and (potentially multiple) SIGs, so that structure ensures groups are not stepping on each other's toes. By moving the SIGs out of these shared repositories, imposing that structure is no longer needed. However, since the lookaside cache relies on branch name, lifting that structure would break the lookaside cache. I have already brought this idea to a few folks to see if the idea was sane. The consensus that emerged is: * Introduce a new upload endpoint next to the existing one, something like: https://git.centos.org/sources/sig_upload.cgi * That new endpoint would upload the sources given using the same structure as the one used for CentOS-Stream, but ensuring that the person uploading is member of at least one SIG. The idea of using `sig_upload.cgi` instead of just replacing `upload.cgi` is the assumption that we want to preserve the current structure used for CentOS-Linux and CentOS-Stream, allowing to find more easily which sources are used where and not impacting the process Red Hat uses to push its releases. Since the structures used by the two upload scripts are different, they will not conflict. What we will end up seeing is something like: sources │ ├── pkg1 │ ├── c7 │ │ ├── hash1 │ │ └── hash2 │ ├── c8 │ │ ├── hash3 │ │ └── hash4 │ ├── tarball1 │ │ └── sha name │ │ └── hash5 │ │ └── tarball1 │ └── tarball2 │ └── sha name │ └── hash6 │ └── tarball2 │ └── pkg2 ├── c8 │ ├── hash7 │ └── hash8 ├── c8s │ ├── hash9 │ └── hash10 ├── tarball3 │ └── sha name │ └── hash11 │ └── tarball3 └── tarball4 └── sha name └── hash12 └── tarball4 and so on On CBS, the script that downloads the sources, will then need to be adjusted to try first the old structure before trying the new one. This may slow down a little bit the builds, but that should be most of the time, at most by a single http request. In this email I'm calling for feedback, do you like the idea? I'm happy to work on making it happen if there is consensus on this :) Looking forward for your thoughts, Pierre [1] https://lists.centos.org/pipermail/centos-devel/2022-February/120216.html

5 11

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