devel

devel@lists.centos.org

4604 discussions

Dependent on PowerTools
by Mike Rochefort 16 Jul '21

16 Jul '21

Based on the office hour earlier this week, I spent some time performing scans of the PowerTools repo to see what packages from BaseOS, AppStream, and EPEL rely on it. The results of these scans can be found in a repo here: https://gitlab.com/omenos/crb-depends I was only able to do x86 based scans, and there will be some dupes of packages because i686 and x86_64 versions exist. Unfortunately this is a pretty basic check; I didn't differentiate between package types during cleanup, so there will be a lot of -devel packages showing up. Hopefully the data is accurate, I did this fairly late at night :) -- Mike Rochefort

2 4

Proper CentOS Stream value for ID_LIKE
by Mike Rochefort 15 Jul '21

15 Jul '21

When it comes to CentOS Stream, should the ID_LIKE parameter be changed to properly designate the upstream nature of CentOS in regards to RHEL? As of now, both Stream 8 and 9 are using the classic CentOS identifier of "rhel fedora". If the change of being upstream is strict enough, CentOS should be changed to "fedora", and RHEL should be altered to "centos fedora". However, I've got a feeling a lot of scripts and tooling may be looking to see if "rhel" is in the ID_LIKE parameter, which may end up preventing installations of software on Stream for limited reasons. I don't have any examples or numbers to back that up, just a hunch on how people use the os-release (and redhat/centos-release) file. Is this something that should be adjusted, or left as is for compatibility? -- Mike Rochefort

7 8

July board meeting, quick summary
by Rich Bowen 15 Jul '21

15 Jul '21

We had a *very* productive Board of Directors meeting yesterday. We'll be publishing the meeting minutes soon, but I wanted to summarize a couple of important items from yesterday's Board of Directors meeting. * The proposed Automotive SIG was approved: https://wiki.centos.org/SpecialInterestGroup/Automotive * We'll start planning for the third virtual Dojo of 2021 in the coming weeks. If you're interested in being part of that effort, please let me know, and subscribe to the centos-promo mailing lst. * Pursuant to the "Documenting the CentOS Linux 8 EOL process" thread on this list over the past week, the board came to agreement on several details around the CentOS 8 EOL in December, and we'll be drafting those in more detail over the coming days. * Pursuant to our commitment, in January, to continue being more transparent around the Board of Directors process, we'll be announcing a general public invite to future Board meetings. Details will be drafted over the coming days. * Over the past few months, I've been working on some updates to our governance docs, both to reflect the desire for greater transparency, as well as to promote a division between governance and technical direction. Over the next few weeks I'll be bringing drafts of those documents to this list for public commentary before we adopt them as our new guiding principles. So ... that's a *lot*, and some of it is going to take a while for us to get done. So, please do remind me if you don't see any progress on any of these items over the coming months. Many thanks to the Board of Directors for their hard work yesterday, and the work yet to come on the above items. --Rich, for Board of Directors

1 0

Community Platform Engineering Quarterly ~~Bragging Rights~~ Report Q2 2021
by Aoife Moloney 12 Jul '21

12 Jul '21

Hi Everyone, Below you will find a report of the work the Community Platform Engineering (CPE) team was involved in over the last three months. If you would like to view this in a 'toggle-able' view, I would suggest you visit this hackmd link https://hackmd.io/@Ap8CkTlpSfmjb44UGV-kWA/BJlrOsBpu ## Intro The Community Platform Engineering team is a group of people who work on infrastructure, release engineering, documentation, development and just about anything else you can think of that supports both the CentOS and Fedora projects. In an effort to try work even more effectively and improve on our work planning, we have been scheduling some of our work on a quarterly basis for the last 15-18 months. And its been working pretty well...once we got the hang of it :) This in a nutshell, just means that there is work the CPE team *will commit* to delivering every quarter that relates to both distros, while also still providing support to the projects infrastructure that come in as bugs, tickets, etc. Quarter two 2021, or April, May and June to give them their government names, has been a particularly good quarter for our team with a lot of work getting completed. Below is a breakdown of what our team delivered over the quarter per project. A note, that is a given but should never go without saying - is that the CPE team work in the Fedora and CentOS communities, and rely on community member feedback and discussion while working. Without your continued support and engagement with our team - be it when we are announcing something available and need input on how it works or an idea we have had and we want more discussion on a proposal before we start developing - the work we deliver at the end of each quarter would not be possible. So on behalf of the CPE team, thank you for your involvement in our quarterly work! This is as much your bragging rights as it is ours :) ## Fedora ### RPMautospec This project was originally prototyped early last year and presented at Nest with Fedora last August. It was a body of work that would relieve packagers from the burden of manually updating the Release field and %changelog section in RPM spec files. Some of the highlights of this project that the team delivered was: * Implemented a simplified release enumeration algorithm (from the discussion on the devel list and with FESCo) * Reflect flags to %autorelease in generated changelog entries * `fedpkg local`, `fedpkg mockbuild` (possibly `fedpkg srpm`) supports rpmautospec features, i.e. prepare the SRPM on the fly as Koji would do it before building. * Allows for uncommitted changes in local builds with fedpkg, i.e. bump the release number by one and generate a boilerplate “- uncommitted changes” RPM changelog entry. * Up-to-date and more complete documentation :) You can read more detailed information on this project from the repo https://pagure.io/docs/fedora-infra/rpmautospec/ and from the fedora mailing list https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… ### Infrastructure & Release Engineering * F34 was released! https://fedoramagazine.org/announcing-fedora-34/ * New Status Page released! https://www.fedorastatus.org/ * Fedora Accounts got new features in staging that will be deployed to production soon: * Noggin (upstream project name) now supports Matrix IDs as well as IRC nicknames https://github.com/fedora-infra/noggin/pull/668 * Integrated the Spammish app into Noggin https://github.com/fedora-infra/noggin/pull/672 * FPCA status displayed on Noggin’s user page * https://fedoraloveskde.org site was deployed in staging and production * A *lot* of builder fixing and module cleanup * Behind-the-scenes work: * updates to services and applications, eg Bodhi * Upgraded machines to F34 * Fedocal now runnning on Openshift rather than VMs * Mass update/reboot to systems ## CentOS ### CentOS Stream 9 * Development composes are available https://composes.stream.centos.org/ * Container Images are available https://quay.io/repository/centos/centos?tag=stream9-development&tab=tags * Quickstart Contribution Guide available https://docs.centos.org/en-US/stream-contrib/quickstart/ * New SIG approved: Feature Request SIG for CentOS Stream https://lists.centos.org/pipermail/centos-devel/2021-April/076716.html * Centpkg development and release * CentOS Stream 9 build system is publicly viewable https://kojihub.stream.centos.org/koji/ * CentOS Stream 9 package sources are publicly available in GitLab https://gitlab.com/redhat/centos-stream/rpms ### CentOS Stream 8 * CentOS Stream 8 repository pipeline upgraded to merge new composes rather than replacing the previous content giving users the ability to `dnf downgrade` packages easily. More info https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html * Centos8-stream buildroot available for missing -devel pkgs https://pagure.io/centos-infra/issue/316 ### CentOS Linux * CentOS Linux 8 had a new release derived from Red Hat Enterprise Linux 8.4 Source Code! Read more here https://lists.centos.org/pipermail/centos-devel/2021-June/077021.html ### Infrastructure & Release Engineering * EPEL repositories (plain rpms, no module content) can be enabled on demand on CBS for: * epel 7 (x86_64, ppc64le, aarch64) * epel 8 Everything (x86_64, ppc64le, aarch64) * epel Next 8 Everything (x86_64, ppc64le, aarch64) * Auth system switch completed in April bringing both CentOS and Fedora backend system under one stack and allowing contributors to both projects use one email for both projects! More info: https://lists.centos.org/pipermail/centos-devel/2021-April/076694.html * Deployed some instances for Artwork SIG to test centos visual theme for www/blog/mirror/mailman https://pagure.io/centos-infra/issue/366 This report is really only a snapshot of the volume of work the people on the Community Platform Engineering do, and also at a more high level overview, but even still there are *a lot* of very noteworthy successes in there that we are very proud of delivering this quarter, and we hope the communities we are part of and serve find value in the work we do too. Have a lovely weekend everyone, and I will be back with our plans for July, August and September with links to the projects work trackers and their respective goals that we are going to shoot for in Q3 very soon (like, next week) :) Kindest regards, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

Automotive SIG in CentOS
by Jeffrey Osier-Mixon 09 Jul '21

09 Jul '21

Hello all - there is now a proposed Automotive SIG in CentOS. It has been requested for consideration at next week's board meeting. https://wiki.centos.org/SpecialInterestGroup/Automotive The goal for this SIG is to enable code as well as active collaboration on ideas for automotive operating systems, with the eventual goal to create an in-vehicle automotive CentOS variant/spin. This SIG is open to all and we value active participation. If approved, we will host our first (virtual) meeting in August. best regards, Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive

1 0

Two directories for 8.4.2105 and 8-stream in the centos mirrors
by Burn Alting 08 Jul '21

08 Jul '21

Recently, it appears that two directories for 8.4 and 8-stream are being distributed in the Centos mirrors. You can't see it if you view the mirrors, but if one downloads the filelist.gz file and grep for '^\.\/\.' one will see the directories, with content, .8.4.2105 and .8-stream. Can this be explained? An error or a new distribution concept?? If the latter, then this may have an impact on those who have off-line repos which they manually rebuild. Rgds

4 5

[CloudSIG] CentOS Cloud SIG meeting minutes (2021-07-08)
by Alfredo Moralejo Alonso 08 Jul '21

08 Jul '21

====================================================== #centos-meeting: CentOS Cloud SIG meeting (2021-07-08) ====================================================== Meeting started by amoralej at 15:10:26 UTC. The full logs are available athttps://www.centos.org/minutes/2021/July/centos-meeting.2021-07-08-15.10.… . Meeting summary --------------- * roll call (amoralej, 15:10:39) * for CentOS Stream 9 (amoralej, 15:11:38) * LINK: https://blog.centos.org/2021/07/centos-community-newsletter-july-2021/ (amoralej, 15:11:56) * Cloud images are coming in the next month or so (amoralej, 15:12:46) * Signed packages are coming in the next month or so (amoralej, 15:13:16) * Publishing to the mirrors will happen later this quarter (amoralej, 15:13:41) * LINK: https://releases.openstack.org/xena/schedule.html (amoralej, 15:14:47) * LINK: https://github.com/openstack/governance/blob/master/reference/runtimes/xena… (amoralej, 15:17:54) * ACTION: amoralej to send mail to centos-devel about CBS availability of CS9 buildroots (amoralej, 15:24:19) * ACTION: amoralej to send a mail to openstack-discuss and rdo lists with our plans (amoralej, 15:24:58) * open floor (amoralej, 15:31:55) * meeting cadence (amoralej, 15:32:42) * AGREED: to change meeting cadence to first week of each month at this same time (amoralej, 15:36:50) * ACTION: spotz update calendar and documentation for monthly (first week) (spotz, 15:39:33) Meeting ended at 15:59:32 UTC. Action Items ------------ * amoralej to send mail to centos-devel about CBS availability of CS9 buildroots * amoralej to send a mail to openstack-discuss and rdo lists with our plans * spotz update calendar and documentation for monthly (first week) Action Items, by person ----------------------- * amoralej * amoralej to send mail to centos-devel about CBS availability of CS9 buildroots * amoralej to send a mail to openstack-discuss and rdo lists with our plans * spotz * spotz update calendar and documentation for monthly (first week) * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * amoralej (96) * spotz (21) * jcapitao (19) * centbot (5) * jpena (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[Cloud] Cloud SiG Meeting today at 15:00 UTC
by Amy Marrich 08 Jul '21

08 Jul '21

Just a reminder and an invitation to join us today at the Cloud SiG meeting on Libera in the centos-meeting room. On the agenda[0] for today is how the CCcentOS Stream 9 schedule will affect the timing of the RDO Xena release of OpenStack. Thanks, Aamy (spotz) 0 - https://etherpad.opendev.org/p/centos-cloud-sig *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

Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9
by Florian Weimer 07 Jul '21

07 Jul '21

TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library creates problems, so we are removing it. There may be some hickups. Full updates with “dnf update” are recommended. We expect that we will soon be able to import glibc upstream snapshots regularly into Fedora 35 and CentOS Stream 9. We did such regular imports for the past couple of Fedora rawhide releases, but the situation will be slightly different, as explained below. The snapshots will also land in CentOS Stream 9, after a delay as the result of a different testing pipeline. glibc 2.33 and earlier accidentally provided an very generic ROP gadget in the statically linked startup code that is present in every program (even dynamically linked ones). We have removed the ROP gadget and moved that particular initialization code into the dynamically linked part, but that means that the interface between the startup code and the dynamically loaded glibc parts had to change. As a result, any program linked against glibc 2.34 will not run with glibc 2.33 or any earlier version. (Some of you may remember the memcpy(a)GLIBC_2.14 issue, it was similar.) This version requirement will be properly reflected in RPM dependencies. glibc 2.34 removes libpthread as a separate library. This is based on the observation that most processes load libpthread anyway. (On this system, I count 141 out of 159 processes that load libpthread.) One particularly thorny issue is that certain NSS modules depend on libpthread, and if the main program is not linked (indirectly) against libpthread, loading such NSS modules effectively loads libpthread via dlopen, which is something that glibc has never supported well. Furthermore, the availability of some pthread_* functions without -lpthread has been a source of confusion to developers, resulting in both overlinking and underlinking. We started the libpthread transition in glibc 2.33 when we added the __libc_single_threaded variable as a replacement for the weak symbol hacks that some libraries use to detect single-threaded processes. (For example, libstdc++ used to do this to avoid using atomic instructions in std::shared_ptr.) Backwards compatibility for dynamically linked binaries should be preserved (as usual), but we know of one issue on ppc64le, where the weak symbol hacks resulted in slightly corrupt binaries. Upstream glibc did not accept the proposed backwards compatibility enhancement so far. Instead, we will rebuild affected distribution binaries with a binutils version which handles weak symbols slightly differently, avoiding the corruption. As we plan to perform these rebuilds before the new glibc lands in the buildroot, the requirement to upgrade to the new binaries before or at the same time of the upgrade to the glibc upstream snapshot will NOT be reflected in RPM dependencies. A full upgrade using “dnf update” will work, however. In addition to the removal of libpthread, I also hope to remove libdl and librt. This means that new GLIBC_2.34 symbols will be added to libc.so.6 (e.g., timer_create(a)GLIBC_2.34) The librt removal in particular will probably not land with the first imported snapshot. This is unfortunate because RPM does not have a way to express this: there's just a blanket Provides: libc.so.6(GLIBC_2.34), which will already be included in the first snapshot that adds the symbol __lib_start_main@@GLIBC_2.34 (whether or not the RPM package includes timer_create(a)GLIBC_2.34 as well). Some tools in the fedpkg/centpkg/mock sphere try to install builds from the Koji buildroot into installations from composes, without upgrading everything to the current buildroot, so it's possible that glibc won't be upgraded to match the requirements of RPMs directly imported from the buildroot. Developers encountered similar issues with glibc snapshot imports (e.g., around the symbol pthread_getattr_np). Our RPM infrastructure does not have per-symbol dependencies, so there isn't much we can do about it at the packaging level. It's a transitory issue during rawhide/CentOS Stream 9 development; the finished release will add all GLIBC_2.34 symbols in one upgrade, so end users won't see it in a Fedora 34 to Fedora 35 upgrade or a CentOS Stream 8 to CentOS Stream 9 upgrade. We think there is value in providing access to these snapshots early, and will try to make the transitions as smooth as possible, within the constraints outlined above. Thanks, Florian

1 1

Case study: libxml2 CVE fixes in the Red Hat ecosystem
by Carl George 02 Jul '21

02 Jul '21

Since the announcement of the CentOS Linux 8 EOL date in December, I've noticed there has been confusion about how CVE fixes work in CentOS Stream 8. Recently there have been some CVE fixes for the libxml2 package, and I took the opportunity to examine how these fixes flowed through the Red Hat ecosystem. Here are the relevant CVE identifiers and their CVSS v3 scores. CVE-2021-3516 - 7.8 [0] CVE-2021-3517 - 8.6 [1] CVE-2021-3518 - 8.6 [2] CVE-2021-3537 - 7.5 [3] CVE-2021-3541 - 6.5 [4] Here is a timeline of notable events. 2021-05-07 * libxml2-2.9.10-12.fc34 [5] was submitted for Fedora 34, which included fixes for the first four CVEs. 2021-05-10 * libxml2-2.9.10-12.fc34 [5] was released for Fedora 34, fixing the first four CVEs. 2021-05-13 * All five CVE fixes were released upstream as part of version 2.9.11 [6]. * libxml2-2.9.12-1.fc34 [7] was submitted for Fedora 34, which included the fix for the fifth CVE. 2021-05-21 * libxml2-2.9.12-2.fc34 [7] was submitted for Fedora 34, which fixed an unrelated upstream regression [8], but also reset the pending update. * libxml2-2.9.7-11.el8 [9] was released for CentOS Stream 8, fixing all five CVEs. This was a backport update that was unaffected by the upstream regression in 2.9.12. 2021-05-24 * libxml2-2.9.12-2.fc34 [7] was released for Fedora 34, fixing the fifth CVE. 2021-06-29 * libxml2-2.9.7-9.el8_4.2 [10] was released for RHEL 8, fixing all five CVEs. Later that day it was rebuilt [11] and released for CentOS Linux 8. This was a backport update that was unaffected by the upstream regression in 2.9.12. It's important to note that these CVE fixes were not part of a security embargo [12]. That is why CentOS Stream 8 was able to provide them before RHEL 8. If these fixes had been part of an embargo, they would have been released for RHEL 8 first (once the embargo was lifted), then CentOS Stream 8 and CentOS Linux 8 immediately after. Another thing I want to point out is that libxml2-2.9.7-11.el8 and libxml2-2.9.7-9.el8_4.2 are effectively identical. They contain the exact same backported CVE fixes. The only difference is the release field. This can be verified in the exported SRPM commits [13][14]. No additional changes were made to the package source between being released for CentOS Stream 8 and being released for RHEL 8. I hope you enjoyed this deep dive into the lifecycle of these CVE fixes. The key takeaway is that CentOS Stream 8 does get security fixes, and usually gets them much sooner than CentOS Linux 8. [0] https://access.redhat.com/security/cve/CVE-2021-3516 [1] https://access.redhat.com/security/cve/CVE-2021-3517 [2] https://access.redhat.com/security/cve/CVE-2021-3518 [3] https://access.redhat.com/security/cve/CVE-2021-3537 [4] https://access.redhat.com/security/cve/CVE-2021-3541 [5] https://bodhi.fedoraproject.org/updates/FEDORA-2021-e3ed1ba38b [6] https://mail.gnome.org/archives/xml/2021-May/msg00000.html [7] https://bodhi.fedoraproject.org/updates/FEDORA-2021-e8b7e177a4 [8] https://gitlab.gnome.org/GNOME/libxml2/-/issues/255 [9] https://koji.mbox.centos.org/koji/buildinfo?buildID=17568 [10] https://access.redhat.com/errata/RHSA-2021:2569 [11] https://koji.mbox.centos.org/koji/buildinfo?buildID=18244 [12] https://www.redhat.com/en/blog/security-embargoes-red-hat [13] https://git.centos.org/rpms/libxml2/c/6ce3da4b1430e975a40a538aa250775e101e5… [14] https://git.centos.org/rpms/libxml2/c/bc5a009a460cda9e2392f75fff8bf6edae43e… -- Carl George

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