devel May 2021

devel@lists.centos.org

44 participants
30 discussions

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

Can CentOS Stream 8 Devel repo be populated
by Troy Dawson 24 Jun '21

24 Jun '21

Back when the CentOS 8 Devel repo[1] was originally introduced, the CentOS Stream 8 Devel repo[2] was kept empty. Now that CentOS 8 is going away, and we are expected to develop on CentOS Stream 8, could we please get CentOS Stream 8 Devel populated with the same packages it once had. I know there is an initiative for all the missing -devel packages to appear somewhere at sometime. But here is my problem. I'm trying to get KDE rebuilt for CentOS Stream 8 due to the updated qt5 that is now in Stream. plasma-nm, a fairly important piece of KDE, requires mobile-broadband-provider-info-devel which is in the Devel repo. >From what I see, the fastest way to get mobile-broadband-provider-info-devel somewhere that I can consume it on Stream is via the Devel repo. Thus my question. Can we get CentOS Stream 8 Devel populated with whatever is in the regular Devel repo. Thanks Troy Dawson [1] - http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ [2] - http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/

10 21

repomd.xml.asc outdated?
by Leon Fauster 11 Jun '21

11 Jun '21

JFYI: LANG=C yum update --noplugins ... Error: Failed to download metadata for repo 'appstream': repomd.xml GPG signature verification error: Bad GPG signature http://mirror.centos.org/centos-8/8/AppStream/x86_64/os/repodata/ shows repomd.xml 2021-03-16 15:43 repomd.xml.asc 2021-03-03 00:29 -- Leon

5 6

RFC: kmods SIG Proposal
by Peter Georg 11 Jun '21

11 Jun '21

Dear all, I'd like to propose a SIG for CentOS Stream. Please see the proposal below. Note: In case anyone has a better suggestion for a name, please let me know. I'm really terrible at naming things. And sorry in advance for any spelling or grammar mistakes (I'm not a native english speaker). For everyone following the previously posted "RFC: Stream Kernel SIG Proposal": The goal of the "kmods" SIG proposed here has previously been proposed to be added to a potential "Stream Kernel SIG" as a fifth goal. However it seems to make sense to split the various different goals into seperate SIGs. Disclaimer: I used the Hyperscale SIG description (https://wiki.centos.org/SpecialInterestGroup/Hyperscale) as a template. I hope that's OK. Best, Peter Proposal: = kmods SIG = == Goals == The kmods SIG will focus on providing kernel modules currently not available in CentOS Stream. == Status == Proposed: RFC and looking for a sponsoring Governing Board member == What's in scope == This SIG is a good place for any kernel module that is beneficial to CentOS Stream, but cannot be directly contributed to any of the involved upstream projects. These kernel modules may be divided in three categories: === Restore support for deprecated devices === The CentOS Stream kernel includes several kernel modules for which the list of supported devices has been limited by Red Hat. This SIG aims to provide versions of these kernel modules with restored support for as many deprecated and removed devices as possible. A close collaboration with the kernel-plus developers is desired for these kernel modules. === In-kernel modules not enabled for CentOS Stream === Many in-kernel modules are simply disabled for the CentOS Stream kernel. This may either be due to drivers being deprecated and removed compared to older CentOS major releases or never being enabled in the first place. This SIG aims to provide these in-kernel drivers as external kernel modules to enable CentOS Stream running on a broader range of available hardware and provide other beneficial functionality. A close collaboration with the kernel-plus developers is desired for these kernel modules. In addition it is desired to work with upstream to get any valuable kernel modules directly into the CentOS Stream kernel. === Third-party external kernel modules === This SIG also aims to provide third-party kernel modules for CentOS Stream not (yet) available in upstream kernel. == What's not in scope == Anything that can be contributed directly to any of the involved upstream projects is not in scope. This includes, but is not limited to: * New user space packages: These should be submitted to Fedora/EPEL * Support for new architectures currently not supported by CentOS Stream * Third-party kernel modules with non compatible license == Roadmap == * Provide packages for in-kernel modules with restored support for deprecated devices * Provide packages for in-kernel modules that have been supported in older CentOS major releases * Provide packages for further beneficial kernel modules requested by the community == Resources == TBD == Communication == The SIG uses the [[https://lists.centos.org/mailman/listinfo/centos-devel|centos-devel]] mailing list for coordination and communication. TBD: Add note about regular meetings once established. == Membership == The current set of members is: ##begin-members * ... ##end-members The SIG is co-chaired by ... and .... Everybody is welcome to join and contribute to the SIG. Membership can be requested by asking on the [[https://lists.centos.org/mailman/listinfo/centos-devel|centos-devel]] mailing list. Any current member can raise objections and request a simple majority vote on membership applications. SIG members are expected to actively contribute or otherwise remain engaged with the project. Stale members may be removed by a simple majority vote after six months of inactivity. The SIG is co-chaired by two equal chairpersons elected by SIG members for one year. Each chairperson is elected individually using a plurality vote.

14 56

Stream ISO retention
by Lance Albertson 02 Jun '21

02 Jun '21

What is the current policy for Stream ISO's? It seems that it's currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability. Would it be possible to do one of the following? 1. Offer a filename symlink to the "current" build? 2. Offer an ISO that exists longer than a week? 3. Host archived ISOs on vault (or somewhere else) with some saner retention Thanks- -- Lance Albertson Director Oregon State University | Open Source Lab

3 10

[Cloud SiG] RDO IRC Information
by Amy Marrich 26 May '21

26 May '21

Dear Cloud SiG and CentOS Community Members, As many of you know, there have been changes in Freenode which affect the RDO channel, OpenInfra channels, and the channels of many other communities we work closely with. After careful consideration, the OpenDev team has chosen to move the Open Infrastructure Foundation IRC related infrastructure to OFTC[0]. As of Monday, May 31st, OFTC will become the primary home of RDO (#rdo) including where we host our meeting. The Fedora and CentOS Communities have chosen to move to Libera[1] and due to our close relationship with these projects RDO will have a presence on this system as well also in #rdo. Our channel is already created on both systems and are ready for you to join them and it is recommended you register your Nick[2][3] on both these systems. While not a total solution, we would like to mention Matrix[4] which we hope in the future will be able to bridge OFTC and Libera.chat into one location. Thanks, Amy Marrich (spotz) 0 - https://www.oftc.net/ 1 - https://libera.chat/ 2 - https://www.oftc.net/Services/#register-your-account 3 - https://libera.chat/guides/registration 4 - https://matrix.org *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/>

3 2

Enabling PowerTools by default? (and proof-of-concept alternative)
by Michel Alexandre Salim 26 May '21

26 May '21

At the Hyperscale SIG, one of the repos we ship (centos-release- hyperscale-hotfixes, which we use to override modular content we need to fix as MBS is not available to SIGs) depends on EPEL (because the packages there, for example libvirt, needs dependencies in EPEL). EPEL's Quickstart recommends enabling codeready-builder on RHEL8, and the corresponding powertools repo on CentOS 8: https://fedoraproject.org/wiki/EPEL#Quickstart Could we possibly just enable powertools by default? CRB is on by default in RHEL8 UBI containers (but weirdly not in the related CentOS Stream containers!). There are multiple unactionable bugs in Bugzilla for EPEL about uninstallable packages, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1890414 that ends up with the maintainer telling the reporter to just enable powertools. A proof-of-concept we tested in Hyperscale is to just enable PowerTools in %posttrans: https://git.centos.org/rpms/centos-release-hyperscale/c/03b6fd490be2571efa6… That way we can make sure that Powertools is already enabled for future transactions installing packages from our repos, but not potentially break the transaction itself by changing the set of packages available. (note: not shipped yet) But we'd rather not have to do this, and just have Powertools enabled to begin with. Failing that, have this kludge in epel-release so we get it for free for our packages that depend on EPEL. Looking at PowerTools, there's a lot of packages there, esp. in the Python stack, that I could imagine many Python library or application shipped in EPEL would be uninstallable if the repo is disabled. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name

8 11

Infra SIG Bi-Weekly Meeting Cancellation Today
by Aoife Moloney 24 May '21

24 May '21

Hi Everyone, Between a mix of people having some time off today, people (me!) not having moved their account to Libera.chat yet, and no agenda to discuss today, please note the Infra SIG bi-weeklyt meeting is cancelled. It will resume as normal on the #centos-meeting channel on libera.chat, at 1500 UTC +1 on Monday 7th June. Issues can be filed and found here https://pagure.io/centos-infra/issues Have a lovely week everyone! Aoife, on behalf of the Infra SIG. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA <https://www.redhat.com> Communications House Cork Road Waterford <https://www.redhat.com>

1 0

SIG feedback - Summary and actions
by Rich Bowen 21 May '21

21 May '21

Two weeks ago I asked this list for feedback on Special Interest Groups. I got a *LOT* of feedback, both on-list, and off-list. There were, of course, some common themes, and you've seem some of that in the on-list replies. I have summarized all of the feedback here - https://blog.centos.org/2021/05/sig-experience-feeback/ - because there was so much of it. In the coming weeks, I'll be working on the SIG Guide, and related documentation, to address the comments regarding lack of information and clarity of instructions. I'm also taking the process complaints/suggestions to the board and to the Infra team to see if, and how, we can address those complaints. Note that some of them have already been answered/addressed, and I'll be documenting those items. This will all be a public process, so that I can get your continued feedback on proposed changes and clarifications, so that I don't show up with something rewritten that doesn't actually address everyone's needs. Thank you to everyone who responded. This was very helpful. I want to specifically call out Fabian Arrotin, since several people mentioned that without Fabian, they would never have figured out how to do what they were supposed to do around SIG setup.

1 0

CentOS IRC channels moving to irc.libera.chat
by Rich Bowen 20 May '21

20 May '21

TL;DR: #centos and #centos-* are moving to libera.chat Over the past few days, there has been some upheaval on the Frenode IRC network, resulting in a number of the staff members quitting and starting a new IRC network. I wont attempt to explain all the details here, but you can read more at https://kline.sh which also links to other sources. The various ops have discussed the situation, and we intend to migrate all of the various #centos-* channels from Freenode over to irc.libera.chat over the coming days. This will take time, since libera is still spinning up, and some servers are moving from one network to the other. As libera is still in the early stages of setup, you may have significantly more timeouts/disconnects, netsplits and other issues for now. Until the new network is fully stable, we'll all continue to be present in the Freenode chanels. Please bring further questions to the IRC channels (on either network).

8 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2021