March 2022 - 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

Few questions on cloud images
by Pino Toscano 06 Jun '23

06 Jun '23

Hello, I have few questions related to the cloud images provides for c8s and c9s, i.e.: - https://cloud.centos.org/centos/8-stream/x86_64/images/ - https://cloud.centos.org/centos/9-stream/x86_64/images/ 1) I see the c9s images are regularly updated, while the c8s images not; is this wanted, or simply a mistake/miss somewhere? If so, will they be kept up-to-date just like the c9s images? 2) are the Vagrant images there officially supported? Let's say you use one, and find a bug; then check on a "classic" installation (baremetal/VM), and the bug isn't there; can users report problems in those cases? 3) would it be possible to have either unversioned or "-latest" symlinks for the latest versions of all the files (i.e. images, checksums, etc)? This way, it will be much easier for users to fetch the latest versions with no need to change URLs frequently. Of course, the assumption is that users of this are always willing to use the latest version. Thanks! -- Pino Toscano

7 14

Proposal: CentOS Public Board Meetings
by Rich Bowen 07 Jan '23

07 Jan '23

In January of 2021, the CentOS Board of Directors opened our monthly meetings to all SIG chairs, in a first step towards more transparent governance. We wanted to see how the larger audience changed the meeting dynamics, if at all, as well as welcoming a broader pool of voices. We are now ready for the second part of this process. Starting in the August meeting, we will be inviting the entire CentOS community to attend these meetings. Due to the nature of the Internet, we won’t be simply publishing the meeting URL, as this often leads to disruptive behavior in meetings, as I am sure many of you have experienced. Rather, in the week before the meeting, we’ll send, to this list, a way to request an invitation to the meeting. In this way, we hope to limit the incidence of such disruptions, while also making the meeting available to anyone who wishes to attend. We will be working on the rules of engagement for these meetings, but they will be, at minimum: * Wait to be recognized by the Chair before speaking * Respect the Chair when told your time to speak is over - this will allow us to remain on agenda, and complete the meetings in the allotted time * In the event that there are Board-confidential topics, these will be put at the end of the meeting, in Executive Session, and guests will be asked to leave. We hope to minimize these items, but they do sometimes happen. The most common scenarios in which this may happen are personnel issues, or information that Red Hat wishes to share with the Board, but is not yet public. * Muting of participants, or, in extreme situations, ejection from the meeting, is at the sole discretion of the Chair. * Meetings will be recorded, and published to YouTube (possibly with edits/redactions, as approved by the Directors). Thus, by joining the meeting you consent to have your presence at the meeting, and anything you say during the meeting, made public. Because there will seldom be time for Q&A during the meeting itself, we plan to add a post-meeting IRC office hours session for followup questions. This will probably be scheduled for a week after the board meeting, to allow time to publish meeting minutes We welcome your comments about the above proposal, and thank you all for your patience as we implement these changes to our governance process.

8 27

RHEL moving to issues.redhat.com only long term
by Josh Boyer 20 May '22

20 May '22

Hi Fedora, CentOS, and EPEL Communities! As part of our continued 3 year major Red Hat Enterprise Linux release cadence, RHEL 9 development is starting to wrap up with the spring 2022 release coming soon. That means planning for the next release will start in earnest in the very near future. As some of you may know, Red Hat has been using both Bugzilla and Jira via issues.redhat.com for RHEL development for several years. Our intention is to move to using issues.redhat.com only for the major RHEL releases after RHEL 9. What does this mean for Fedora and CentOS? This discussion is in part to figure that out. Based on some very brief analysis, the following should hold: - RHEL customers should continue to file support cases through the Red Hat Customer portal, which will remain consistent regardless of the backend tooling used. - There is no imminent retirement of the Red Hat Bugzilla instance being planned at this time. RHEL 7, 8, and 9 will continue to use bugzilla in some form and RHEL 9 has a very long lifecycle. - Fedora Linux and EPEL have their own Bugzilla product families and are not directly impacted in their own workflows by the choice to use only issues.redhat.com for RHEL. - There will be impacts on existing documentation that provide guidance on requesting things from RHEL in various places like EPEL. We will be happy to help adjust these. - CentOS Stream contribution and bug reporting workflows will be adjusted to use issues.redhat.com instead of bugzilla in the relevant places. This should apply to all versions of CentOS Stream for a unified contributor workflow. This will happen gradually as we discover the best workflow to use. If there are other impacts that you can think of, please raise them on this thread. We’d like to ensure we’re covering as much as possible as this rolls out. josh

7 14

Decommissioning of CentOS Stream 8 source-git branches
by Tomas Tomecek 13 May '22

13 May '22

Hello, we would like to announce our plan to decommission and remove the c8s branches of the CentOS Stream source-git repositories. This also means the removal of any repository from the gitlab.com/redhat/centos-stream/src namespace which is left without a branch. Stream 9 content will not be affected. As you might remember, these are the source-git repositories produced by unpacking the c8s branches from CentOS Stream 8 dist-git, and making the resulting content available at gitlab.com/redhat/centos-stream/src. We took a look at the utilization of this content during 2021, based on the GitLab data and found out that no one from the community has used these repositories to contribute to CentOS Stream 8. The only exception is the kernel repository [1], we will keep that one up. Please let us know if you find these repositories useful or are part of your routine. Our focus for the future is to deliver a consistent source-git workflow for Fedora and CentOS Stream under the umbrella of Fedora source-git SIG [2]. [1] https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8 [2] https://fedoraproject.org/wiki/SIGs/Source-git Tomas

1 2

Experimentation with the centos namespace on gitlab
by Brian Stinson 07 Apr '22

07 Apr '22

Hi Folks! We had a thread a few weeks ago about the usage of the “centos” namespace on gitlab: https://lists.centos.org/pipermail/centos-devel/2022-February/120216.html The authentication angle is progressing up to the point that we would like to open up the opportunity for a couple of SIGs to onboard with gitlab and help us round the edges. The idea being to open this up to all the SIGs interested in a few weeks once we have clearer documentations and guidelines around the usage of GitLab. We are currently working on that set of best-practices that SIGs which would like to use the centos namespace on gitlab will need to agree and follow. If you are interested, please let us know (just not everyone at once!) :) Thanks, Brian

6 5

repomd.xml.asc outdated for extras
by Leon Fauster 30 Mar '22

30 Mar '22

In some kind related to https://pagure.io/centos-infra/issue/550 repomd.xml and repomd.xml.asc out of "sync" for http://mirror.centos.org/centos/8-stream/extras/x86_64/os/repodata/ [TXT] repomd.xml 2022-03-28 13:52 2.9K [TXT] repomd.xml.asc 2022-03-24 00:40 811 I believe that a repo sync would sync the entire directory. So, the origin is already providing a signed file that is outdated, thought ... -- Leon

2 2

announcing "extras-common" repo for Stream 8 , managed by SIGs
by Fabian Arrotin 30 Mar '22

30 Mar '22

Following what was already implement for CentOS Stream 9 (see the https://lists.centos.org/pipermail/centos-devel/2021-November/098666.html thread), we have also created new tags on cbs.centos.org to let SIG build/push their centos-release-* pkg (containing their public gpg key, and .repo files for dnf/yum) for CentOS Stream 8. While the extras8s-extras-common-{candidate,testing,release} tags were all created some time ago (and some SIGs already tried this for -testing tag, with pkgs landing on https://buildlogs.centos.org/centos/8-stream/extras/) the -release tag itself was still locked, until the same mechanism that was implemented for Stream 9 would be working for Stream 8. Now that newer centos-gpg-keys-8-6.el8.noarch and centos-stream-repos- 8-6.el8.noarch packages are available in CentOS Stream 8 BaseOS, that means that we have now unlocked the extras8s-extras-common-release tag and so SIGs can from now on just build and tag their centos-release* packages directly through cbs and not having to ask a CentOS Stream core member to just rebuild it through distro koji (aka https://koji.mbox.centos.org) PS : as you can see the /8-stream/extras/<basearch>/os/ repo is still there,and still available on every installed CentOS 8s, but is also "frozen" from now on. The new extras-common will be populated with new builds coming from cbs.centos.org koji exclusively (as it's the case for CentOS Stream 9) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

Announcement: livesys-scripts v0.1.0
by Neal Gompa 28 Mar '22

28 Mar '22

Hello all, Over the past few months, I've been working on building new image build descriptions for the CentOS Hyperscale SIG and Fedora Cloud WG so we can migrate away from Oz/ImageFactory[0]. One detour that I took as part of doing this is an attempt to simplify the creation of live media. The tool I'm using for the Hyperscale SIG live media for CentOS Stream 9 is called kiwi[1] and it notably does not support the same script merging+inheritance model that Lorax[2] and livecd-tools[3] support that we rely on for correctly assembling the livesys init script (!!!) used to bootstrap the live environment correctly. I took a day to analyze the scripts across all the live media we have right now and made an initial attempt to convert them into more regular scripts that are invoked from systemd services. The result is livesys-scripts, which just landed in Fedora and EPEL 8/9. The project sources for livesys-scripts is here: https://pagure.io/livesys-scripts The livesys-scripts package should be agnostic to the image build tool. If you're previously relying on assembling the init script (e.g. fedora-kickstarts), the way to switch over is: 1. Delete the init script assembly logic from your kickstarts 2. Add livesys-scripts to %packages section 3. Enable livesys.service and livesys-late.service in services stanza 4. If your live ISO has a desktop environment in it, set livesys_session in /etc/sysconfig/livesys to load the correct subscript in %post. (The choices currently are: gnome, kde, cinnamon, mate, xfce, lxqt, lxde, soas, i3) If more desktops need to be supported, contribution via pull request is welcome! :) The intent of this is to make it easier to support building Fedora(ish) live media across a wider range of tools and also to synchronize what it does with improvements in dracut over time. The livesys-scripts are old and much of its functionality belongs in dracut itself. This is something that will hopefully be corrected in the near future... So, give it a try and let me know how it goes! :) [0]: https://imgfac.org/ [1]: http://osinside.github.io/kiwi/ [2]: https://weldr.io/lorax/ [3]: https://github.com/livecd-tools/livecd-tools -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

CPE Weekly Update – Week of March 21st – 25th
by Michal Konecny 25 Mar '22

25 Mar '22

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/) If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-march-21s… # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I&R-23-03-2022.pdf Update ------ ### Fedora Infra * Fixed cert generation in ipa staging (needed upgrade run) * Found problem with proxies that stopped processing, was an apache bug. Downgraded back to previous stable version. * Good progress on testing ansible upgrade. Successfully run playbooks with python3.8/ansible-core-2.12.3. * Usual business. ### CentOS Infra including CentOS CI * Kicked off work for the ansible [2.9.x => 5.x](https://pagure.io/centos-infra/issue/496) (good progress so far) * WIP : new lookaside structure and [building from gitlab](https://pagure.io/centos-infra/issue/645) (working but need now just last steps like centpkg-minimal) * Last [centos-repos](https://pagure.io/centos-infra/issue/698) should enable the extras-common repo for SIGs (autonomous from koji.mbox.centos.org koji builds) * Multiple 1:1 with phsmoura for infra onboarding * Working on [image-build issue](https://pagure.io/centos-infra/issue/708) as first ticket * Bussiness as usual: new koji tags , projects on git.centos.org/rpms ### Release Engineering * F36 Beta 1.4 * Work on SCM request automation should be finished this week - [PR](https://pagure.io/fedora-infra/toddlers/pull-request/93) ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Troubleshooting CCCC service issues * Build & pushing Extras repos for CentOS Stream 8, once built, tags will be available * Content resolver can now differentiate between warnings (when a workload lists packages that don't exist) and failures (actual dependency problems). * DC move went well, all systems operational again ## CentOS Duffy CI Goal of this Initiative ----------------------- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates ------- * Focusing on documentation this week https://github.com/CentOS/duffy/issues/253 ## Bodhi Goal of this Initiative ----------------------- This initiative is to separate Bodhi into multiple sub packages, fix integration and unit tests in CI, fix dependency management and automate part of the release process. Read ARC team findings in detail at: https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html Updates ------- * Got rid of the DeclEnumType warning with SQLAlchemy 1.4+ * Use namespace packages in accordance with current recommendations (avoiding needless .pth files) * Copy severity when obsoleting a security update * Updated Vagrant docs * Dependency management (ongoing) * Added procedure for pushing the snapshots to staging ## EPEL Goal of this initiative ----------------------- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates ------- * EPEL9 up to 2187 source packages (increase of 39 from last week) * Notable EPEL9 packages now available: * [KDE Plasma](https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedo… * openvpn and NetworkManager-openvpn * Several ansible collections (general, mysql, rabbitmq, podman) Kindest regards, CPE Team

1 0

KDE ready for testing in RHEL9Beta / CentOS Stream 9
by Troy Dawson 22 Mar '22

22 Mar '22

For those of you who want to use KDE on RHEL9 Beta, or CentOS Stream 9, it is available via EPEL. It is currently plasma 5.23.5, kf5 5.90.0, qt5 5.15.2. There might be an update before RHEL 9.0 is released. There is currently a critical selinux bug[1] that prevents KDE from starting. That is the reason I have not sent this out earlier. When that get's fixed, I'll update these instructions. Note: All these steps should be done as sudo or root. Step 0 - Manually fix selinux bug setsebool -P selinuxuser_execmod 1 Step 1 - Enable CRB and Install epel-release [2] # RHEL 9 Beta subscription-manager repos --enable codeready-builder-beta-for-rhel-9-$(arch)-rpms dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm # CentOS Stream 9 dnf config-manager --set-enabled crb dnf install epel-release epel-next-release Step 2 - Install KDE dnf group install "KDE Plasma Workspaces" or dnf group install kde-desktop Step 2.a - (Optional) Install other kde groups dnf group install kde-media dnf group install kde-apps dnf install okular Step 2.b - (Optional) Set sddm as desktop manager dnf install sddm\* -y systemctl enable sddm -f Step 3 - Ensure you boot into graphical mode systemctl set-default graphical.target Step 4 - Reboot and enjoy It is recommended that you log into the Plasma (X11) vs Plasma (Wayland). There are several non-critical wayland bugs. These bugs are being addressed but aren't expected to be fixed until the RHEL 9.1 timeframe. Troy Dawson [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2058657 [2] - https://docs.fedoraproject.org/en-US/epel/#_el9

3 3

CentOS Stream 9 Build environment outage today
by Brian Stinson 21 Mar '22

21 Mar '22

Hi Folks, We have a migration in progress for the CentOS Stream 9 environment today. This will affect access to kojihub.stream.centos.org while we work on this. I'll post a note here when our outage is clear. Mirror content will remain available, composes.stream.centos.org may be affected periodically throughout the day. --Brian

1 0

Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term
by Josh Boyer 15 Mar '22

15 Mar '22

On Mon, Mar 14, 2022 at 2:59 PM Dan Čermák <dan.cermak(a)cgc-instruments.com> wrote: > > Hi Adam, > > Adam Williamson <adamwill(a)fedoraproject.org> writes: > > > snip > > > That could obviously have pretty significant consequences for Fedora. > > Bugzilla isn't only an issue tracker for Fedora; we run some > > significant processes through it, notably the Change process, the > > blocker/FE bug process, and the prioritized bug process. In A World > > Without Bugzilla all of those would need adapting (and their > > documentation updating). There's fairly tight integration between Bodhi > > and Bugzilla, which would need to be redesigned. Those are just things > > I can think of off the top of my head. There are also a couple of > > decades worth of internet links to Fedora issues on RH Bugzilla, of > > course. > > > > I guess the two big choices for Fedora if RH said "we're not > > maintaining Bugzilla any more" would be 1) take over maintaining > > Bugzilla or 2) switch to something else. 1) would probably be the path > > of least resistance, I guess. > > Short term it is the path of the least resistance, but at least what > I've heard from $dayjob, maintaining a Bugzilla instance is no easy > task, as they are often customized (via non-upstream patches) and this > all needs to be maintained. I cannot speak for our infra team, but I > really don't know if they'd like yet another huge service, because this > effectively means they'd have to take over maintenance of > bugzilla.redhat.com... > > > > > This does also kinda lead to a larger question for me, trying to wear > > both Red Hat and Fedora hats at the same time[0]. I wonder if we're > > kind of lacking a...mechanism, for want of a better word, to handle the > > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora > > project" first started. At that point Fedora and Red Hat shared a lot > > of tooling and infrastructure, and this was useful to both sides in > > many ways; it saves on development costs and it makes it easy for > > people to work in both worlds. With my Red Hat on, I think I'm allowed > > to say that internally we often talk about this being desirable - > > having consistency between how X is done in Fedora and how it's done > > for RHEL - and it obviously has benefits to Fedora too (it means we > > don't have to find the resources to do that same work at Fedora level). > > > > However, situations like this make me wonder if we might have an issue > > with keeping shared infra/tooling where it's desirable. It seems like > > this is a decision/conversation that's been happening within RH, about > > what makes sense for RH in terms of RHEL development. AFAIK this is the > > first time it's been formally talked about in a Fedora context, and the > > messaging is "RH has already decided to stop using Bugzilla for RHEL > > after 9". In other words, RH has decided on its own to move away from > > something that is part of the shared RH/Fedora "heritage way of doing > > things". > > > > I'm not saying that's wrong, but as I said it does make me wonder > > whether, if both sides do find shared tooling/approaches beneficial, we > > might want to approach this kind of potential change differently in > > future. Otherwise it does seem like we could sort of gradually drift > > apart, with no explicit intention to do so, and lose the benefits of > > shared tooling and process. Unless the ultimate outcome of this is > > "Fedora adopts issues.redhat.com for bug tracking" - which would be a > > possibility, but doesn't seem like a certainty - the result will be > > that we go from having a shared bug tracker, with the benefits of > > shared maintenance and being able to easily clone or reference bugs > > between Fedora and RHEL, to each maintaining our own bug tracker and > > not having those benefits. > > > > Of course, there would be sensitivities in developing such a process - > > it could look a lot like Red Hat telling Fedora how to do stuff, which > > I think isn't exactly the relationship we want to have. But at the same > > time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop > > using this thing they'd previously both used" is always the best choice > > either. > > No, certainly not. I think it would have been nice if the tooling > discussion happened before RH decided to drop Bugzilla so that we can > all use a common tooling. However, I also know that in a business RHEL is choosing not to use Bugzilla for future versions of RHEL. I need to be clear in wording there, because Red Hat is a company, RHEL is one of its products, and we're only talking about newer versions of that product. I am not aware of any plans for Red Hat to drop Bugzilla. I am aware of plans for newer versions of RHEL to no longer use Bugzilla. > sometimes reaching such a consensus is everything but easy. It would > have been nice if someone at least tried though. Tried what, to be precise? If you mean try to find common tooling between Fedora and RHEL, well we have off and on for years. Several things work. Many didn't. If you mean try to use bugzilla, we've been trying for the last 5 years internally to make it work in conjunction with issues.redhat.com. It's not working and it's time to consolidate to a single tool. That decision has no direct bearing on Fedora though. If you mean try having a conversation with the community before something goes into effect... that's what this thread is. Depending on how you count, at least a year in advance if not 3. If you meant something else, I've missed it. josh

1 0

Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term
by Josh Boyer 15 Mar '22

15 Mar '22

On Mon, Mar 14, 2022 at 11:12 AM Adam Williamson <adamwill(a)fedoraproject.org> wrote: > > On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > > > What does this mean for Fedora and CentOS? This discussion is in part > > to figure that out. Based on some very brief analysis, the following > > should hold: > > > > - RHEL customers should continue to file support cases through the Red > > Hat Customer portal, which will remain consistent regardless of the > > backend tooling used. > > > > - There is no imminent retirement of the Red Hat Bugzilla instance > > being planned at this time. RHEL 7, 8, and 9 will continue to use > > bugzilla in some form and RHEL 9 has a very long lifecycle. > > > > - Fedora Linux and EPEL have their own Bugzilla product families and > > are not directly impacted in their own workflows by the choice to use > > only issues.redhat.com for RHEL. > > - There will be impacts on existing documentation that provide > > guidance on requesting things from RHEL in various places like EPEL. > > We will be happy to help adjust these. > > > > - CentOS Stream contribution and bug reporting workflows will be > > adjusted to use issues.redhat.com instead of bugzilla in the relevant > > places. This should apply to all versions of CentOS Stream for a > > unified contributor workflow. This will happen gradually as we > > discover the best workflow to use. > > > > If there are other impacts that you can think of, please raise them on > > this thread. We’d like to ensure we’re covering as much as possible > > as this rolls out. > > So if I'm understanding this correctly, the ultimate consequence here > is "Red Hat Bugzilla might go away, or stop being maintained, at > whatever point it's no longer needed for RHEL 9", right? I have no idea, to be honest. There's a lot of assumption in that statement and it certainly could be an outcome, but I'm not aware of any plans towards that directly. > That could obviously have pretty significant consequences for Fedora. > Bugzilla isn't only an issue tracker for Fedora; we run some > significant processes through it, notably the Change process, the > blocker/FE bug process, and the prioritized bug process. In A World > Without Bugzilla all of those would need adapting (and their > documentation updating). There's fairly tight integration between Bodhi > and Bugzilla, which would need to be redesigned. Those are just things > I can think of off the top of my head. There are also a couple of > decades worth of internet links to Fedora issues on RH Bugzilla, of > course. Those all sound like the things I'm familiar with. > I guess the two big choices for Fedora if RH said "we're not > maintaining Bugzilla any more" would be 1) take over maintaining > Bugzilla or 2) switch to something else. 1) would probably be the path > of least resistance, I guess. > > This does also kinda lead to a larger question for me, trying to wear > both Red Hat and Fedora hats at the same time[0]. I wonder if we're > kind of lacking a...mechanism, for want of a better word, to handle the > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora > project" first started. At that point Fedora and Red Hat shared a lot > of tooling and infrastructure, and this was useful to both sides in > many ways; it saves on development costs and it makes it easy for > people to work in both worlds. With my Red Hat on, I think I'm allowed > to say that internally we often talk about this being desirable - > having consistency between how X is done in Fedora and how it's done > for RHEL - and it obviously has benefits to Fedora too (it means we > don't have to find the resources to do that same work at Fedora level). Fedora and RHEL process and tooling has deviated significantly over the years. So much so that by the time I joined the RHEL team, it was already very different. That was almost 5 years ago, which means the individual decisions that led to it were even earlier. I don't really want to revisit those decisions because I wasn't around and can't speak to why they were made, but the connection between Fedora and RHEL via bugzilla is minimal at best. The commonality that brings the most shared benefit is the activities of our communities, the quality and rigor they bring into Fedora, and the sources we share. Tooling and process are orthogonal to those. Important, because they certainly lend themselves to aiding that quality and rigor, but orthogonal. > However, situations like this make me wonder if we might have an issue > with keeping shared infra/tooling where it's desirable. It seems like > this is a decision/conversation that's been happening within RH, about > what makes sense for RH in terms of RHEL development. AFAIK this is the > first time it's been formally talked about in a Fedora context, and the > messaging is "RH has already decided to stop using Bugzilla for RHEL > after 9". In other words, RH has decided on its own to move away from > something that is part of the shared RH/Fedora "heritage way of doing > things". I don't think this is the first instance of those kinds of decisions. It is perhaps one of the few instances where we've been up-front about it well in advance. > I'm not saying that's wrong, but as I said it does make me wonder > whether, if both sides do find shared tooling/approaches beneficial, we I think we do in some cases, and not in others. I don't find bugzilla to be one of those. Even the clone function is questionable. > might want to approach this kind of potential change differently in > future. Otherwise it does seem like we could sort of gradually drift > apart, with no explicit intention to do so, and lose the benefits of > shared tooling and process. Unless the ultimate outcome of this is >From my perspective, we minimally share tooling. Process is common in concepts, but RHEL process is far more additive and heavy-weight than anything Fedora does. > "Fedora adopts issues.redhat.com for bug tracking" - which would be a > possibility, but doesn't seem like a certainty - the result will be To be clear, it is not an explicit goal for Fedora to adopt issues.redhat.com. That's up to the Fedora project, much as adoption of gitlab was. > that we go from having a shared bug tracker, with the benefits of > shared maintenance and being able to easily clone or reference bugs > between Fedora and RHEL, to each maintaining our own bug tracker and > not having those benefits. Personally, I don't think we're taking advantage of perceived benefits at all. They are effectively separate. > Of course, there would be sensitivities in developing such a process - > it could look a lot like Red Hat telling Fedora how to do stuff, which > I think isn't exactly the relationship we want to have. But at the same > time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop > using this thing they'd previously both used" is always the best choice > either. The Fedora decision is up to Fedora. RHEL is driven by product constraints and will evaluate based on those needs. Where we can align, we should. For a recent example of a decision to align more, look at the CKI project. Both Fedora and RHEL benefit greatly from maintaining the kernel in the CKI manner, and this is the closest the Fedora and RHEL kernels have ever been. josh

1 0

NFV SIG - AVC denials with openvswitch
by Sandro Bonazzola 14 Mar '22

14 Mar '22

Hi, while testing oVirt for 4.5 alpha I noticed on the ovirt-engine side: # ausearch -m avc|grep den type=AVC msg=audit(1646758341.539:780): avc: denied { search } for pid=38783 comm="modprobe" name="events" dev="tracefs" ino=45 scontext=system_u:system_r:openvswitch_load_module_t:s0 tcontext=system_u:object_r:tracefs_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1646758341.539:780): avc: denied { search } for pid=38783 comm="modprobe" name="events" dev="tracefs" ino=45 scontext=system_u:system_r:openvswitch_load_module_t:s0 tcontext=system_u:object_r:tracefs_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1646881861.570:998): avc: denied { write } for pid=97466 comm="ovs-appctl" name="ovnnb_db.ctl" dev="tmpfs" ino=195196 scontext=system_u:system_r:openvswitch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1646881861.573:999): avc: denied { write } for pid=97467 comm="ovs-appctl" name="ovn-northd.38883.ctl" dev="tmpfs" ino=195260 scontext=system_u:system_r:openvswitch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1646881861.575:1000): avc: denied { write } for pid=97468 comm="ovs-appctl" name="ovnsb_db.ctl" dev="tmpfs" ino=198897 scontext=system_u:system_r:openvswitch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1646969461.086:1037): avc: denied { write } for pid=122222 comm="ovs-appctl" name="ovnnb_db.ctl" dev="tmpfs" ino=195196 scontext=system_u:system_r:openvswitch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1646969461.089:1038): avc: denied { write } for pid=122223 comm="ovs-appctl" name="ovn-northd.38883.ctl" dev="tmpfs" ino=195260 scontext=system_u:system_r:openvswitch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1646969461.091:1039): avc: denied { write } for pid=122224 comm="ovs-appctl" name="ovnsb_db.ctl" dev="tmpfs" ino=198897 scontext=system_u:system_r:openvswitch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1647265858.456:54): avc: denied { search } for pid=1245 comm="modprobe" name="events" dev="tracefs" ino=45 scontext=system_u:system_r:openvswitch_load_module_t:s0 tcontext=system_u:object_r:tracefs_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1647265858.456:54): avc: denied { search } for pid=1245 comm="modprobe" name="events" dev="tracefs" ino=45 scontext=system_u:system_r:openvswitch_load_module_t:s0 tcontext=system_u:object_r:tracefs_t:s0 tclass=dir permissive=0 Involved packages are: dnf list installed "*openvswitch*" Installed Packages centos-release-nfv-openvswitch.noarch 1-3.el8 @extras openvswitch-selinux-extra-policy.noarch 1.0-28.el8 @centos-nfv-openvswitch openvswitch2.15.x86_64 2.15.0-81.el8s @centos-nfv-openvswitch ovirt-openvswitch.noarch 2.15-3.el8 @centos-ovirt45-testing ovirt-openvswitch-ovn.noarch 2.15-3.el8 @centos-ovirt45-testing ovirt-openvswitch-ovn-central.noarch 2.15-3.el8 @centos-ovirt45-testing ovirt-openvswitch-ovn-common.noarch 2.15-3.el8 @centos-ovirt45-testing ovirt-python-openvswitch.noarch 2.15-3.el8 @centos-ovirt45-testing python3-openvswitch2.15.x86_64 2.15.0-81.el8s @centos-nfv-openvswitch As the openvswitch packages are coming from centos-release-nfv-openvswitch reporting to centos devel (no more specific location mentioned on https://wiki.centos.org/ReportBugs ) -- 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.*

1 1

Board office hours, March 16
by Shaun McCance 09 Mar '22

09 Mar '22

Hi all, First, I want to apologize if any guests were unable to join the board meeting today. We had technical issues and had to switch to a different room, and we might not have gotten the new URL to everybody. Minutes and recording will be posted shortly. We will have our monthly board office hours next week, so if you have questions, you can bring them there. Join us Wednesday, March 16 at 15:00 UTC. **NOTE** Some people will start daylight savings this weekend. The meeting time is in UTC. Double-check your local time. Local time: `date -d "2022-03-16 15:00 UTC"` Video call link: https://meet.google.com/wtn-zwwz-dca If you need dial-in details instead, just email me off-list. Thanks, Shaun

1 0

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

04 Mar '22

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/) If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-february-… # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Update ------ ### Fedora Infra * One new power9 online in iad2, second one needs hands on today. * Almost all bugzilla auth changes made, still need some changes to toddlers (ongoing) * Container builds broken again in an odd way ( https://pagure.io/releng/issue/10658) * Discussion on fedoraplanet.org on infrastructure list, please chime in if you have thoughts about it. ### CentOS Infra including CentOS CI * Migration of Pagure to new CentOS CI in progress * Openssl3 [late change](https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/78fb7… in EL9 impacting SIGs and gpg keys ### Release Engineering * Work on SCM request automation in progress - [PR](https://pagure.io/fedora-infra/toddlers/pull-request/93) * Container builds failing on armhfp * Bussiness as usual ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Investigating compose QA improvements both in the t-functional suite and changes we may want to implement later in the project. * Developing sync2gitlab service for 8, 9 workflow alignment * Business as usual activities around CentOS Linux 7 * Work continuing on content resolvers maintainer pages also ## CentOS Duffy CI Goal of this Initiative ----------------------- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates ------- * Demo/Status call * Deployment to staging (ongoing) * Documentation (ongoing) * Expiring sessions (ongoing) ## Image builder for Fedora IoT Goal of this Initiative ----------------------- Integration of Image builder as a service with Fedora infra to allow Fedora IoT migrate their pipeline to Fedora infra. Updates ------- * No updates ## Bodhi Goal of this Initiative ----------------------- This initiative is to separate Bodhi into multiple sub packages, fix integration and unit tests in CI, fix dependency management and automate part of the release process. Read ARC team findings in detail at: https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html Updates ------- * No updates ## EPEL Goal of this initiative ----------------------- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates ------- * EPEL9 up to 2059 source packages (increase of 71 from last week) * EPEL9 buildroot has switched to a snapshot of the CentOS Stream 9 mirror, to avoid building against any 9.1 changes prior to the RHEL 9.0 GA * [EPEL Office Hours](https://communityblog.fedoraproject.org/epel-office-hours/) were yestarday at 1700 UTC * epel-release (and epel-next-release) now available in CentOS Stream 9 Extras repo Kindest regards, CPE Team

1 0

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

03 Mar '22

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

4 4

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

02 Mar '22

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

1 0

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

02 Mar '22

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

3 3

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

02 Mar '22

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

5 8

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

02 Mar '22

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

3 2

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

02 Mar '22

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

2 3

vault outage
by BC 01 Mar '22

01 Mar '22

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel March 2022