devel May 2021

devel@lists.centos.org

44 participants
31 discussions

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

RFC: Stream Kernel SIG Proposal
by redbaronbrowser 19 May '21

19 May '21

There are four main goals of this SIG: First, break down changes in the Stream version 4.18.0 kernel into individual patches. When possible, document the source the patch is from and the purpose of the patch. Moving forward also document which Stream kernel package revision introduced the patch. Second, build CentOS Plus kernel for Stream. Third, package newer LTS kernels during the LTS lifespan. These would be available as alternative kernels for Stream similar to the CentOS Plus kernel. Fourth, work on tools for better delivery of live security patches to be applied via kpatch. The reasoning for this SIG is to improve the openness of kernels available through Stream. Normally a distribution upstream would have access to which patch or commit each addition to the kernel belongs to. The patch name or commit comment would also give information as to the purpose of the patch. Stream's kernel reports to be 4.18.0 but uses a tar that is 110% the size of a true 4.18.0 tar. A breakdown of the additional 10% is not provided. Hence Stream's kernel still functions similar to a downstream rather than providing what is expected for a successful upstream project. This SIG would help close the kernel openness gap by documenting the changes. Stream users would then be in a better position to track down individual patches that cause regressions or bugs. This SIG would also help smooth the adoption of Stream for users that depend on CentOS Plus kernel features. Next, this SIG should help improve feedback to the LTS kernel developers. Tracking LTS kernel changes may also help with documenting some changes in the primary Stream kernel. Lastly, this SIG should help improve kernel security by promoting methods to enable kernel security updates even when a reboot of the system is not possible.

12 42

[Artwork] CentOS Stream logo?
by Rich Bowen 18 May '21

18 May '21

Hi, Artwork/Design folks, I am getting asked several times a week, by various people, where they can get the CentOS Stream logo. Since there isn't such a thing, I generally say "we just have one logo." I wonder if it would be possible to get a CentOS Stream logo - presumably just the CentOS logo with "CentOS Stream" wordmark in the right font? There's a mockup of that at https://git.centos.org/centos/Artwork/issue/1 but having high-res/scalable versions would be nice. Is that a thing that someone is willing to do? --Rich

3 5

CentOS Stream 8 + EPEL?
by Mihai Moldovan 14 May '21

14 May '21

Hi I've been looking at the current state of mock and noticed that EPEL 8 is supported when based off the CentOS 8 repositories, but there is no EPEL Stream 8 configuration or the like. Given that CentOS 8 is supposed to be EOL in half a year, what's the status on using CentOS Stream 8 with EPEL? (Yes, I'm aware of the usual disclaimer that EPEL is handled by the Fedora Project, but I figure that the overlap on this list is big enough.) Mihai

6 7

CentOS Dojo - Day two
by Rich Bowen 14 May '21

14 May '21

Thanks to everyone who attended yesterday's CentOS Dojo, and especially to the speakers. All of the video for yesterday, and most of the slides, are now available at https://wiki.centos.org/Events/Dojo/May2021 Today we have another day of content, including an AMA (Ask Me Anything) session with the Board of Directors to start. We hope to see more of you today. Registration is free, at the above URL.

1 0

Making EPEL available in CBS for SIG builds
by Davide Cavalca 13 May '21

13 May '21

Hello, Fabian suggested to post about https://pagure.io/centos-infra/issue/306 so we can have a wider discussion around it. That ticket is specifically for the Hyperscale SIG, but I think this is something that could be generally useful. Within Hyperscale, we have a need to build a few packages that have dependencies coming from EPEL. While we could rebuild those dependencies within the SIG, that seems both wasteful and undesirable, as it would lead to needless deviation and potentially discourage folks from maintaining stuff in EPEL (where it has a chance to benefit the most people). So, our conclusion was that it would be great to just depend directly on EPEL and have it added to our build targets in CBS so we can build against it. One concern with doing this is that EPEL is kind of a moving target. This doesn't really apply to Hyperscale (as we track CentOS Stream), but it could be relevant for SIGs tracking CentOS Linux. Still, this would just be a non-default option for a SIG to add to their build tags, so I don't think this will be much of a problem in practice. From my chat with Fabian I understand this was raised in the past and there had been policy concerns around it. I'd love to get more context around this and see if we can get them addressed. Alternatively, if there are no concerns I'd be happy to entertain suggestions on how to actually do this :) Thanks! Cheers Davide

13 32

mbox koji is unavailable
by Davide Cavalca 12 May '21

12 May '21

Heads up, it looks like there's an outage affecting https://koji.mbox.centos.org and https://mbs.mbox.centos.org . The ticket at https://pagure.io/centos-infra/issue/322 has some details. Cheers Davide

1 0

Wallaby RDO Release Announcement
by Amy Marrich 12 May '21

12 May '21

If you're having trouble with the formatting, this release announcement is available online at https://blogs.rdoproject.org/2021/05/rdo-wallaby-released/ --- *RDO Wallaby Released* The RDO community is pleased to announce the general availability of the RDO build for OpenStack Wallaby for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Wallaby is the 23rd 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 at http://mirror.centos.org/centos/8 <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/> -stream <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/> /cloud/x86_64/openstack- <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/> wallaby <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/>/ <http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-wallaby/>. 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. PLEASE NOTE: RDO Wallaby provides packages for CentOS Stream 8 and Python 3 only. Please use the Victoria release for CentOS8. For CentOS7 and python 2.7, please use the Train release. *Interesting things in the Wallaby release include:* - RBAC supported added in multiple projects including Designate, Glance, Horizon, Ironic, and Octavia - Glance added support for distributed image import - Ironic added deployment and cleaning enhancements including UEFI Partition Image handling, NVMe Secure Erase, per-instance deployment driver interface overrides, deploy time “deploy_steps”, and file injection. - Kuryr added nested mode with node VMs running in multiple subnets is now available. To use that functionality a new option [pod_vif_nested]worker_nodes_subnets is introduced accepting multiple Subnet IDs. - Manila added the ability for Operators to now set maximum and minimum share sizes as extra specifications on share types. - Neutron added a new subnet type network:routed is now available. IPs of this subnet type can be advertised with BGP over a provider network. - TripleO moved network and network port creation out of the Heat stack and into the baremetal provisioning workflow. Other highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/wallaby/highlights.html *Contributors* - During the Wallaby cycle, we saw the following new RDO contributors: - Adriano Petrich - Ananya Banerjee - Artom Lifshitz - Attila Fazekas - Brian Haley - David J Peacock - Jason Joyce - Jeremy Freudberg - Jiri Podivin - Martin Kopec - Waleed Mousa 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 58 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: - Adriano Petrich - Alex Schultz - Alfredo Moralejo - Amol Kahat - Amy Marrich - Ananya Banerjee - Artom Lifshitz - Arx Cruz - Attila Fazekas - Bhagyashri Shewale - Brian Haley - Cédric Jeanneret - Chandan Kumar - Daniel Pawlik - David J Peacock - Dmitry Tantsur - Emilien Macchi - Eric Harney - Fabien Boucher - frenzyfriday - Gabriele Cerami - Gael Chamoulaud - Grzegorz Grasza - Harald Jensas - Jason Joyce - Javier Pena - Jeremy Freudberg - Jiri Podivin - Joel Capitao - Kevin Carter - Luigi Toscano - Marc Dequenes - Marios Andreou - Martin Kopec - Mathieu Bultel - Matthias Runge - Mike Turek - Nicolas Hicher - Pete Zaitcev - Pooja Jadhav - Rabi Mishra - Riccardo Pittau - Roman Gorshunov - Ronelle Landy - Sagi Shnaidman - Sandeep Yadav - Slawek Kaplonski - Sorin Sbarnea - Steve Baker - Takashi Kajinami - Tristan Cacqueray - Waleed Mousa - Wes Hayutin - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Xena. *Get Started* There are three ways to get started with RDO. 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. For a production deployment of RDO, use TripleO and you’ll be running a production cloud in short order. 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 our 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 Freenode 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, and #tripleo on irc.freenode.net), 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 Freenode 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

SIG feedback
by Rich Bowen 12 May '21

12 May '21

If you have been involved in any of our SIGs, now or in the past - or, indeed, if you'd like to be in the future - I'd like to hear from you. I was going to do a formal survey, but I find I need a baseline - I don't even know what questions to ask. I'd like to hear what you love and what you hate about the SIG process. What you would like to see done differently. What features/services you'd like to see added, and which we could drop. Feel free to respond here, but if there are things you'd like to say that you don't feel comfortable saying publicly, you can send them directly to me, and I will anonymize before sharing the results. This is certainly not a promise that we can or will implement any of your requests, but as we work through more clearly documenting our governance, we want, along the way, to fix whatever's broken. And for that, we need to hear from you.

6 6

Missing build dependencies in CentOS 8 repositories
by František Šumšal 07 May '21

07 May '21

Hello! I'm not sure if this has been already answered somewhere on this list, but I'm curious why the CentOS 8 repositories are missing certain build dependencies (although they're present in RHEL's internal repositories). This makes rebuilding some of the CentOS 8 packages a bit painful. For example, let's try to rebuild util-linux: ``` $ podman run -it --rm centos:8 # rm -f /etc/yum.repos.d/CentOS-Linux-Media.repo # dnf -y install dnf-plugins-core ... # dnf --refresh --enablerepo \* -y builddep util-linux Failed to set locale, defaulting to C.UTF-8 CentOS Linux 8 - AppStream 10 kB/s | 4.3 kB 00:00 CentOS Linux 8 - BaseOS 23 kB/s | 3.9 kB 00:00 CentOS Linux 8 - ContinuousRelease 5.3 kB/s | 3.0 kB 00:00 CentOS Linux 8 - Debuginfo 1.6 MB/s | 27 MB 00:16 CentOS Linux 8 - Devel WARNING! FOR BUILDROOT USE ONLY! 18 kB/s | 13 kB 00:00 CentOS Linux 8 - Extras 8.2 kB/s | 1.5 kB 00:00 CentOS Linux 8 - FastTrack 933 B/s | 257 B 00:00 CentOS Linux 8 - HighAvailability 741 kB/s | 504 kB 00:00 CentOS Linux 8 - Plus 807 kB/s | 596 kB 00:00 CentOS Linux 8 - PowerTools 2.1 MB/s | 2.0 MB 00:00 CentOS Linux 8 - BaseOS - Source 120 kB/s | 384 kB 00:03 CentOS Linux 8 - AppStream - Source 271 kB/s | 991 kB 00:03 CentOS Linux 8 - Extras - Source 2.2 kB/s | 7.8 kB 00:03 CentOS Linux 8 - Plus - Source 1.7 kB/s | 5.0 kB 00:03 Package systemd-239-41.el8_3.x86_64 is already installed. No matching package to install: 'libuser-devel' Not all dependencies satisfied Error: Some packages could not be found. ``` Oh well, looks like we have to rebuild libuser as well: ``` # dnf --enablerepo \* -y builddep libuser Failed to set locale, defaulting to C.UTF-8 Last metadata expiration check: 0:02:14 ago on Tue Apr 13 10:36:39 2021. No matching package to install: 'openldap-servers' Not all dependencies satisfied Error: Some packages could not be found. ``` And apparently openldap, too. I noticed that Davide from FB already come across this issue and filed it in RHBZ[0], where it was confirmed that the dependency is indeed present only in the internal RHEL buildroot repository - and after a quick test they still are: # dnf --enablerepo rhel-buildroot search libuser-devel ... libuser-devel.i686 : Files needed for developing applications which use libuser libuser-devel.x86_64 : Files needed for developing applications which use libuser Is there any reason why they aren't shipped in some CentOS repository or was there any progress to make them available? Thank you! Frantisek [0] https://bugzilla.redhat.com/show_bug.cgi?id=1868430 -- Frantisek Sumsal GPG key ID: 0xFB738CE27B634E4B

15 23

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2021