May 2021 - devel - lists.centos.org

anaconda dependency calculation?
by Nicholas Byrne 04 Aug '25

04 Aug '25

Hi all, I'm trying to find a tool that calculates all dependencies for a specific package or group of packages for use with CentOS 5 (beta) with the intention of putting together a custom single CD build of CentOS 5. With CentOS 4 i used a python script that used the hdrlist module to find all dependencies which borrowed code from a number of sources. I've looked at yumdownloader and how it checks dependencies (using the --resolve option) but if i pass it the list of packages defined in say the Base and the Core yum groups which generally form an absolute minimal install i end up with about 200 packages. If i do a custom install (using beta 1 disks) and deselect everything i end up with over 300 packages. So i'm guessing anaconda calculates dependencies in a slightly different way, can anyone point me to files/code where i should be looking to find out? Thanks very much in advance for help Nick This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential. Any dissemination, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from Quadriga may be monitored. Quadriga cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

6 11

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

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 01 Jun '21

01 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

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

CentOS Stream 8 and `dnf downgrade`
by Carl George 07 May '21

07 May '21

I'm happy to announce that we've updated our CentOS Stream 8 repository pipeline to merge new composes rather than replacing the previous content. This will give users the ability to `dnf downgrade` packages easily. Most packages don't have multiple versions available yet, but going forward more package versions will be added. You can see if a package is downgradable by asking dnf to show the available duplicates. # dnf --quiet list --available --showduplicates openssh Available Packages openssh.x86_64 8.0p1-5.el8 baseos openssh.x86_64 8.0p1-7.el8 baseos openssh.x86_64 8.0p1-8.el8 baseos Due to space limitations we won't be able to keep all packages versions forever, but the intention is to have at least one downgrade version available for most packages. This will make it easier for users to identify if a recent update caused a regression and file a more detailed bug report. -- Carl George

5 4

Re: [CentOS-devel] Advanced Virtualiazion builds for ppc64le and aarch64 missing on Stream
by Sandro Bonazzola 06 May '21

06 May '21

Il giorno mer 14 apr 2021 alle ore 21:15 Eduardo Lima (Etrunko) < etrunko(a)redhat.com> ha scritto: > On 4/14/21 1:59 PM, Sandro Bonazzola wrote: > > Hi, > > while verifying https://gerrit.ovirt.org/#/c/ovirt-release/+/114299/ > > <https://gerrit.ovirt.org/#/c/ovirt-release/+/114299/> noticed we are > > missing Advanced Virtualization builds for aarch64 and ppc64le on CentOS > > Stream. > > I guess it's similar to what happened with ovirt 4.4 and tracked here: > > https://pagure.io/centos-infra/issue/254 > > <https://pagure.io/centos-infra/issue/254> > > Eduardo can you follow up on this and ensure we have ppc64le and aarch64 > > packages there? > > > > Thanks for the heads up. I will check what is going on. > Not sure about the investigations done so far, but in the meanwhile, opened https://pagure.io/centos-infra/issue/314. > > > -- > Eduardo de Barros Lima (Etrunko) > Software Engineer - Red Hat > etrunko(a)redhat.com > > -- 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. <https://mojo.redhat.com/docs/DOC-1199578>*

1 1

Re: [CentOS-devel] Documentation change propsal - "Contributing to CentOS Stream" web page
by Tomas Tomecek 06 May '21

06 May '21

On Fri, Apr 30, 2021 at 6:18 PM Michal Schorm <mschorm(a)redhat.com> wrote: > > On Fri, Apr 30, 2021 at 11:48 AM Tomas Tomecek <ttomecek(a)redhat.com> wrote: > > This is where I'm stopping my replies because your language is just > > way too offensive and I am not interested in this kind of discussion. > > Right, this was a tremendously frustrating week for me and it was > wrong to pour the frustration to you too, as it helps nothing. > I'll try my best to approach it calmly. I understand - so many changes taking place it's easy to get lost and be frustrated. I'm really happy that you didn't fall for the despair fully and that you are now active in improving the workflow, documenting the process, and helping others with questions and problems - that's exactly the collaborative spirit we all should nurture. Keep on the great work! One tip which helps me personally when I feel frustrated, angry, desperate, or just tired: stand up, leave my computer, dress up and take a walk in the fresh air - works all the time for me. > On Fri, Apr 30, 2021 at 11:48 AM Tomas Tomecek <ttomecek(a)redhat.com> wrote: > > On Thu, Apr 29, 2021 at 5:14 PM Michal Schorm <mschorm(a)redhat.com> wrote: > > > The "Contributing to CentOS Stream" webpage: > > > https://wiki.centos.org/Contribute/CentOSStream > > > is very confusing (at least to me) and lacks a lot of details. > > > > It's true the documentation is not finished yet - the CentOS Stream > > team is planning to provide comprehensive contributor's documentation, > > the wiki is really just an intro. > > I'm glad to hear that ! > It's not clear to me from your sentence - the "comprehensive > contributor's documentation" will be a wiki too or some different > platform ? > Just curious; wiki is IMO fine as long as it accommodates all the needed info. Brian Stinson reached out to me that the team is already working on the documentation over here: https://github.com/CentOS/docs-contributors-guide In the coming weeks, I'd love to migrate the wiki page and all of its subpages to the docs-contributors-guide repository and just link to the rendered version: https://docs.centos.org/en-US/docs/ (tracking jira ticket: https://issues.redhat.com/browse/PACKIT-1362 ) once we start working on the migration, Michal, we'll go through your feedback in this thread and incorporate it into the guide, hope that works for you thank you again for your thorough feedback! > > > (2) > > > Section 1 > > > Text: "You should always open a bugzilla first" > > > > > > "Should" ? > > > The process *requires* package maintainers to have the ACKed BZ > > > referenced in the commit message, otherwise it will be impossible to > > > merge it. > > > I haven't heard of any other way, so this should be changed to " *MUST* ". > > > > The reason I wrote "should" there is that it may already be a bugzilla > > opened for the MR. I can see that Rich already changed it to "must" so > > let's keep it that way because that would incentivize potential > > contributors to discuss changes first, which is what we really want. > > > > > Also, the GitLab offers features such as "Issues" and so on. Will > > > those be globally disabled to discourage the contributors to file > > > tickets in the wrong place ? > > > > Yes, issues are disabled. Bugzilla is still the official tracker. > > My confusion originates from the step(s) in the workflow that wasn't > clear to me. > As I understand it *now*, the outside contributors are not supposed to > be responsible for the commits to workflow parts (getting BZ; > referencing it in the commit msg). > > If that's the case, it might be beneficial to mention that the > maintainer will have to deal with that in order for the commit to be > able to be merged; > but the "MUST" seems to be too strong. > However another sentence encouraging to discuss the issue first might > be also nice. > > > > (3) > > > Section 1 > > > Text: "As with any open source projects, in the end it's up to > > > maintainers to decide which changes they want to accept and maintain, > > > so Red Hat maintainers can decline contributions for any reason." > > > > > > This sentence is heavily suggesting that only "Red Hat maintainers" > > > have the power to decide the fate of the contributions. > > > > Correct. > > > > > Does that mean that there can be no CentOS stream maintainer that is > > > not a RH employee at the same time ? > > > If yes, why don't make this clear and say it explicitly ? > > > > I'd say it's explicitly stated there already. Please suggest a better > > wording if you have one in your mind already. > > Yes, I would love to have it stated more explicitly. > > What about: > "As with any open source projects, in the end it's up to maintainers > to decide which changes they want to accept and maintain. Since the > CentOS Stream serves as a direct upstream for the RHEL, the > maintainers of the CentOS stream are Red Hat employees and they can > decline contributions for any reason." > > I also tried to stress the likely main reason for MR decline - that it > won't fit RHEL at the end. > > > > > Also if yes, why can't I login to CentOS project using Red Hat > > > credentials or SSO ? > > > > Because the CentOS identity provider is not utilizing Red Hat's SSO - > > I'd suggest starting a new thread for such a request because that's a > > big one. Though you can log in to GitLab via https://red.ht/GitLabSSO > > I will be happy to start the thread. > But first I would like to clarify, what for ate the CentOS FAS > accounts needed, in the case of the very CentOS Stream. > > If the only benefit for the Red Hat employees would be the ability to > update some wiki pages or similar "stuff around", > It would seem perfectly OK to me that anyone who wants to do that can > get that account on their own. > > On the other hand, if there are common tasks expected to be done, > maybe even repeatedly, by Red Hat employees, which would require the > CentOS FAS account, I would want the accounts to be managed > automatically. (e.g. via RH SSO) > > No point in granting privileges to do stuff in the CentOS project to > hundreds of accounts of RH employees, when the vast majority of them > won't ever need them. > > > > (4) > > > Section 1 > > > Text: "It's also great to have it in Fedora Linux first as well." > > > > > > AFAIK, the OS you are mentioning is named "Fedora" or you can use > > > "Fedora Operating System" (to distinguish from the Fedora Project that > > > has a broader portfolio than just the OS). I think the "Fedora Linux" > > > is not correct. > > > Correct me if I'm wrong > > > > https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-… > > As already pointed out by Miro Hrončok. > Thanks for showing me. > > Would you please correct the other occurrences of the "Fedora" to > "Fedora Linux" ? > > > > > Also, shouldn't be the "It's also great to have it in ..." statement > > > which is "nice-to-have" like, rather something more stressing the fact > > > that Fedora serves as an upstream for RHEL an in order to avoid future > > > regressions, it is very important to have the change accepted in the > > > Fedora first - if possible && if it makes sense. > > > The Red Hat package maintainers have to do it (the upstreaming of > > > relevant code to Fedora) anyway as a part of their job. > > > Also, how would it need to be a part of the upstream project and not > > > to be in Fedora at the same time ? I mean Fedora (at least Rawhide) > > > aims to provide the latest upstream versions possible. > > That's why I mentioned "if possible && if it makes sense". > > > This is really hard because you have plenty of software that is being > > built and configured differently for all the distributions: kernel, > > qemu-kvm, *-release, subscription-manager... > > > > I'll reword that statement and will make it more clear. My assumption > > is there would be a dialogue between the maintainer and the > > contributor on how to handle specific contributions: I'd say it's > > perfectly reasonable to ask the contributor to propose the patch > > upstream or to Fedora Linux first. > > Right, that makes sense to me. > The fact is that the maintainers would most likely maintain the same > package in Fedora too, so they will know the best, whether it is > reasonable to ask to duplicate (or move) the request to Fedora Linux. > > > > > (5) > > > Section 2 > > > Text: "If you want to contribute to CentOS Stream, you need to have an > > > account in CentOS FAS." > > > > > > Same issue as (3), same questions I ask. > > > > > > How comes it that I do not have the account and still I can contribute ? > > > The statement is most likely false. > > > > I agree this piece is slightly outdated because the sources are now > > placed on two locations: git.centos.org and > > gitlab.com/redhat/centos-stream > > > > I'll update it. > > I've got a feeling the account might not be really needed (or even > useful?) for the contributor who contributes solely to the "CentOS > Stream". > But I might be wrong. > As I wrote regarding the SSO. > > > > > (6) > > > Section 3 > > > Text: "Once your account is set up, you can proceed to clone the > > > respective package repository locally." > > > > > > You can't clone the package repository locally without any account at all? > > > That would be weird for a public Git repos ... > > > > > > I'd reformulate the sentence such as "The next step you like to do is > > > to clone ... " > > > Also, the actual goal is not to clone the repo, but fork it, so let's > > > state that fact right away: > > > "The next step you like to do is to clone a package (project) from one > > > of the following repositories and fork it" > > > > That's a good point, I simplified the section. > > Again, it feels like that only applies to the other than "CentOS > Stream" projects. > Is that so ? > As I am continually discussing those - and many similar - subjects > around, there was a good suggestion to strongly separate information > relevant for the "CentOS Stream", just as the "CentOS Stream" itself > is strongly separated from the rest from the CentOS projects. > > > > > (8) > > > Section 3.1 > > > Text: "You'll be able to see 3 types of branches: > > > > > > Not all projects have all 3 types of the branches. > > > It would be better to say something like "The repository will contain > > > some of these types of branches:'' > > > followed by a bullet point list > > " > > To me, it already says that. Would this wording work? "Branches in the > > repositories follow this naming pattern:" > > Yeah, sound's good to me > > > > (9) > > > Section 3.1 > > > > > > Also, what about showing some instructions on how to do it? > > > Do the contributors from the general public know about the "centpkg" > > > tool or should they work with bare "git" ? > > > > I'll mention centpkg though it doesn't have comprehensive > > documentation out there yet. > > I understood at the very beginning, the new documentation is on the > way - which is great. > The whole page felt very ... bare, thin, lacking much information. > > Now I get why the details are not there - they weren't supposed to be > there in the first place! > So mention of a centpkg is a main tool would be great, but I no longer > expect any usage details on this page. > > > > There is: https://git.centos.org/rpms/systemd/tree/c8s > > > > The main problem with this wiki page is that it was written as > > contributor's docs for CentOS Stream 8 while it was hosted on > > git.centos.org and it was never fully updated for Stream 9 and gitlab, > > hence the confusion. And also as you can see, Stream 8 and Stream 9 > > dist-git repos look differently. > > Copying of the documentation of the old behaviour, and leaving it > there until something better comes around is IMO a bit unfortunate. > A simple message that the docs were copied that way and the docs > writing / shaping is still in progress would significantly lessen my > expectancy for this page to currently up-to-date bearing the info and > face we are trying to present to the world with CentOS stream. > > -- > > Most of the rest of my points are something I would expect to be moved > to the more detailed documentation. > > However I'd like to continue in the discussion together, if possible. > Your answers threw a brand new light on the state of the document and > it's expected future. > > > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > > On Fri, Apr 30, 2021 at 11:48 AM Tomas Tomecek <ttomecek(a)redhat.com> wrote: > > > > Hi Michal, thanks for your thorough feedback! More comments inline. > > > > On Thu, Apr 29, 2021 at 5:14 PM Michal Schorm <mschorm(a)redhat.com> wrote: > > > > > > Hello, > > > > > > The "Contributing to CentOS Stream" webpage: > > > https://wiki.centos.org/Contribute/CentOSStream > > > is very confusing (at least to me) and lacks a lot of details. > > > > It's true the documentation is not finished yet - the CentOS Stream > > team is planning to provide comprehensive contributor's documentation, > > the wiki is really just an intro. > > > > > Here is my proposal to update / fix / enhance / clarify at least some > > > of the sections. > > > > > > -- > > > > > > (1) > > > Section 1 > > > Text: "You should always open a bugzilla first" > > > > > > The link leads to the most general selection in Bugzilla. > > > Even in the "All" category, there is no "CentOS" or "CentOS Stream" product. > > > Let's clarify that the product selected should be "Red Hat Enterprise > > > Linux *" and provide more accurate link: > > > https://bugzilla.redhat.com/enter_bug.cgi?classification=Red%20Hat > > > > Oh yeah, this is gonna be really handy! I just updated it to point to > > RHEL 8 and picked CentOS Stream as the version. > > > > > (2) > > > Section 1 > > > Text: "You should always open a bugzilla first" > > > > > > "Should" ? > > > The process *requires* package maintainers to have the ACKed BZ > > > referenced in the commit message, otherwise it will be impossible to > > > merge it. > > > I haven't heard of any other way, so this should be changed to " *MUST* ". > > > > The reason I wrote "should" there is that it may already be a bugzilla > > opened for the MR. I can see that Rich already changed it to "must" so > > let's keep it that way because that would incentivize potential > > contributors to discuss changes first, which is what we really want. > > > > > Also, the GitLab offers features such as "Issues" and so on. Will > > > those be globally disabled to discourage the contributors to file > > > tickets in the wrong place ? > > > > Yes, issues are disabled. Bugzilla is still the official tracker. > > > > > (3) > > > Section 1 > > > Text: "As with any open source projects, in the end it's up to > > > maintainers to decide which changes they want to accept and maintain, > > > so Red Hat maintainers can decline contributions for any reason." > > > > > > This sentence is heavily suggesting that only "Red Hat maintainers" > > > have the power to decide the fate of the contributions. > > > > Correct. > > > > > Does that mean that there can be no CentOS stream maintainer that is > > > not a RH employee at the same time ? > > > If yes, why don't make this clear and say it explicitly ? > > > > I'd say it's explicitly stated there already. Please suggest a better > > wording if you have one in your mind already. > > > > > Also if yes, why can't I login to CentOS project using Red Hat > > > credentials or SSO ? > > > > Because the CentOS identity provider is not utilizing Red Hat's SSO - > > I'd suggest starting a new thread for such a request because that's a > > big one. Though you can log in to GitLab via https://red.ht/GitLabSSO > > > > > If not, the sentence doesn't make much sense. > > > > > > (4) > > > Section 1 > > > Text: "It's also great to have it in Fedora Linux first as well." > > > > > > AFAIK, the OS you are mentioning is named "Fedora" or you can use > > > "Fedora Operating System" (to distinguish from the Fedora Project that > > > has a broader portfolio than just the OS). I think the "Fedora Linux" > > > is not correct. > > > Correct me if I'm wrong > > > > https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-… > > > > > Also, shouldn't be the "It's also great to have it in ..." statement > > > which is "nice-to-have" like, rather something more stressing the fact > > > that Fedora serves as an upstream for RHEL an in order to avoid future > > > regressions, it is very important to have the change accepted in the > > > Fedora first - if possible && if it makes sense. > > > The Red Hat package maintainers have to do it (the upstreaming of > > > relevant code to Fedora) anyway as a part of their job. > > > Also, how would it need to be a part of the upstream project and not > > > to be in Fedora at the same time ? I mean Fedora (at least Rawhide) > > > aims to provide the latest upstream versions possible. > > > > This is really hard because you have plenty of software that is being > > built and configured differently for all the distributions: kernel, > > qemu-kvm, *-release, subscription-manager... > > > > I'll reword that statement and will make it more clear. My assumption > > is there would be a dialogue between the maintainer and the > > contributor on how to handle specific contributions: I'd say it's > > perfectly reasonable to ask the contributor to propose the patch > > upstream or to Fedora Linux first. > > > > > (5) > > > Section 2 > > > Text: "If you want to contribute to CentOS Stream, you need to have an > > > account in CentOS FAS." > > > > > > Same issue as (3), same questions I ask. > > > > > > How comes it that I do not have the account and still I can contribute ? > > > The statement is most likely false. > > > > I agree this piece is slightly outdated because the sources are now > > placed on two locations: git.centos.org and > > gitlab.com/redhat/centos-stream > > > > I'll update it. > > > > > (6) > > > Section 3 > > > Text: "Once your account is set up, you can proceed to clone the > > > respective package repository locally." > > > > > > You can't clone the package repository locally without any account at all? > > > That would be weird for a public Git repos ... > > > > > > I'd reformulate the sentence such as "The next step you like to do is > > > to clone ... " > > > Also, the actual goal is not to clone the repo, but fork it, so let's > > > state that fact right away: > > > "The next step you like to do is to clone a package (project) from one > > > of the following repositories and fork it" > > > > That's a good point, I simplified the section. > > > > > (7) > > > Section 3 > > > Text: "The package repositories are right now located in two places:" > > > > > > Two places, but four list items? :) > > > > will update > > > > > (8) > > > Section 3.1 > > > Text: "You'll be able to see 3 types of branches: > > > > > > Not all projects have all 3 types of the branches. > > > It would be better to say something like "The repository will contain > > > some of these types of branches:'' > > > followed by a bullet point list > > " > > To me, it already says that. Would this wording work? "Branches in the > > repositories follow this naming pattern:" > > > > > (9) > > > Section 3.1 > > > > > > Also, what about showing some instructions on how to do it? > > > Do the contributors from the general public know about the "centpkg" > > > tool or should they work with bare "git" ? > > > > I'll mention centpkg though it doesn't have comprehensive > > documentation out there yet. > > > > > If they should know (or even are encouraged to use) "centpkg", provide > > > the damn instructions. > > > > I don't think such language is necessary. > > > > > Otherwise, describe if the forking in the web UI is the only way and > > > how to do it. > > > > > > (10) > > > Section 4.1 > > > > > > I bet this is a confusing section, at least for new contributors. > > > > > > 1/ Let's begin with the fact that you need the fork in the first place. > > > 2/ Inside of the fork, you should create a new branch - based on the > > > branch they want to contribute to, ideally (but necessarily? ... we > > > might make a "best practice" though) named "bz12345" referencing the > > > submitted BZ ticket for easy recognition > > > 3/ commit the changes. > > > note: each commit must contain an ACKed BZ ticket in order to be > > > able to be merged to the target branch. > > > note: there will be different ACK requirements for different > > > branches in the future (e.g. Y-stream v s Z-stream) > > > 4/ Push the branch to your fork > > > 5/ create MR > > > note: when using "centpkg" as I asked above, the MR URL will be > > > created during the push > > > > > > (11) > > > Section 4.2 > > > Text: "you need to execute %prep phase to see it." > > > > > > To "see it"? More like to "retrieve it from the cache". > > > > > > (12) > > > Section 4.4 > > > > > > What the hell is this about? > > > We should be talking about a dist-git layout & workflow in this > > > section, not a RPMbuild layout (which is completely irrelevant here). > > > There are no "SOURCES" and "SPECS" directories in dist-git. that is > > > completely wrong, the whole section. > > > > There is: https://git.centos.org/rpms/systemd/tree/c8s > > > > The main problem with this wiki page is that it was written as > > contributor's docs for CentOS Stream 8 while it was hosted on > > git.centos.org and it was never fully updated for Stream 9 and gitlab, > > hence the confusion. And also as you can see, Stream 8 and Stream 9 > > dist-git repos look differently. > > > > This is where I'm stopping my replies because your language is just > > way too offensive and I am not interested in this kind of discussion. > > > > > 1/ If you want to make just a packaging change, you *likely* only need > > > to modify just the SPECfile. > > > 2/ If you want to make justa patch change, you need to add the patch > > > AND modify the SPECfile too. > > > > > > At the end, you add all the modified files, commit them, add the BZ > > > ticket to the commit message and create MR. > > > > > > (13) > > > Section 4.5 > > > Text: "4.5. After a pull request is created" > > > > > > For a reason I don't know, some people call it "pull requests" (e.g. > > > in Fedora), some people "merge requests" (e.g. in GitLab). > > > Anyway, we are working with GitLab, so use it's naming. > > > > > > So: "4.5. After a merge request is created" > > > > > > Please find all 3 occurrences of the word "pull" on the page and fix them. > > > > > > (14) > > > Section 4.5 > > > Text: "When you submit a pull request for source-git, automation will > > > pick up the change and build it " > > > > > > Does it not work for the dist-git too? > > > Why ? > > > What about mentioning the scratch-build then? ... aww hell, we are > > > back to the "centpkg" again :) > > > > > > (15) > > > Section 4.5 > > > Text: "Once your change is accepted, it will be marked with the label > > > "accepted". Our automation will create a corresponding bugzilla with > > > the patch attached and then it’s up to the RHEL maintainer to pick it > > > up, commit and build internally so that it can land back into CentOS > > > Stream" > > > > > > This is most confusing. > > > > > > Why won't a maintainer merge it into CentOS first? > > > Why would he first apply it in the most downstream place? What about > > > the "upstream first" rule? > > > > > > How can a package maintainer mark the MR as "accepted"? > > > I haven't found such an option anywhere. > > > > > > "Our automation will create a corresponding bugzilla with the patch attached" > > > So ... another BZ ? This time to ... what product ? > > > Again see (1). > > > > > > I personally actually created a MR, but none BZ has been created: > > > https://gitlab.com/redhat/centos-stream/rpms/mariadb-connector-c/-/merge_re… > > > > > > "RHEL maintainer to pick it up, commit and build internally so that it > > > can land back into CentOS Stream" > > > That sentence suggests that the RHEL is the upstream for CentOS > > > stream, but at the same time we are pushing CentOS stream to be > > > upstream for RHEL. > > > Get this straight. > > > > > > BTW on a webpage: > > > https://wiki.centos.org/Contribute#CentOS_Stream > > > the re is a clear statement: > > > "CentOS Stream is a continuously delivered distribution which is > > > upstream to the next minor version of Red Hat Enterprise Linux" > > > > > > (16) > > > Section 5 > > > Text: "it needs to be reviewed and approved by the RHEL maintainer for > > > the particular component." > > > > > > Again - so only RH employees will be able to maintain ? > > > Why don't have a CentOS FAS access already created ? > > > Why would anyone else need a CentOS FAS ? > > > > > > "maintainer for the particular component" > > > Also, I believe this is a false statement too. > > > The current permissions AFAIK allow for any RH employee with the > > > GitLab account with the "devel" role over gitlab.com/redhat space to > > > merge the MR. > > > > > > (17) > > > Section 5 > > > Text: "We are making sure behind the scenes they see your patch." > > > > > > Who is making sure? > > > the RH employees ? > > > Who are "they" > > > *the same* RH employees ? :D > > > > > > (18) > > > Section 6 > > > > > > Might help to add instructions on how to do it. > > > > > > (101) > > > > > > Is there not a single documentarist as a part of the CentOS project > > > who would read through the webpages ? > > > > > > > > > -- > > > > > > Michal Schorm > > > Software Engineer > > > Core Services - Databases Team > > > Red Hat > > > > > > -- > > > > > >

1 0

CentOS Stream 8 boot ISO works now
by Carl George 05 May '21

05 May '21

During the lifecycle of CentOS Stream 8 we've had a number of anaconda issues that have manifested the same way. When using the boot ISO, the user should have an option to use "closest mirror" as the installation source once the network is enabled. Up until now, that feature has not worked correctly, requiring users to manually type in a mirror URL, or switch to the larger DVD ISO. We've managed to resolve all the issues and now have a functional boot ISO. This would not have been possible without lots of help from the upstream anaconda team and from users who filed bugs. -- Carl George

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2021