February 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

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

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

c8 container images - old - ?
by lejeczek 01 Mar '22

01 Mar '22

Hi guys I pulled one yesterday: -> $ podman pull registry.centos.org/centos:latest and it's old EOL centOS 8. Should not there be 'stream' in repos already and EOL ones be removed & gone? (or am I missing something) many thanks, L.

3 3

CentOS SIGs and lookaside cache
by Pierre-Yves Chibon 28 Feb '22

28 Feb '22

Good Morning Everyone, There are currently two lookaside caches in use around the CentOS project: * One used by CentOS-Stream: https://sources.stream.centos.org/sources it's not browsable, but it uses the structure: `baseurl/pkgname/tarball/hashtype/hash/tarball`. Example: https://sources.stream.centos.org/sources/rpms/kernel/linux-5.14.0-62.el9.t… * One used by CentOS-Linux, CentOS-Stream 8 and the SIGs: https://git.centos.org/sources/ this one is browsable and as you can see uses the structure: `baseurl/pkgname/branch/hash`. Example: https://git.centos.org/sources/kernel/c8s/0c4e10577cfd4b4f8e3d83c0406da8ab0… The rest of this email focuses on this second one. SIGs upload to it using the route: https://git.centos.org/sources/upload.cgi In an email last week [1] was proposed an idea for how SIGs could leverage the centos namespace in gitlab for those who wishes. One of the benefits of using gitlab would be increased flexibility for SIGs and a clear example for this would be the ability to drop the branch structures currently imposed on the git repositories. That structure is imposed because the git repositories are shared between CentOS-Linux, CentOS-Stream and (potentially multiple) SIGs, so that structure ensures groups are not stepping on each other's toes. By moving the SIGs out of these shared repositories, imposing that structure is no longer needed. However, since the lookaside cache relies on branch name, lifting that structure would break the lookaside cache. I have already brought this idea to a few folks to see if the idea was sane. The consensus that emerged is: * Introduce a new upload endpoint next to the existing one, something like: https://git.centos.org/sources/sig_upload.cgi * That new endpoint would upload the sources given using the same structure as the one used for CentOS-Stream, but ensuring that the person uploading is member of at least one SIG. The idea of using `sig_upload.cgi` instead of just replacing `upload.cgi` is the assumption that we want to preserve the current structure used for CentOS-Linux and CentOS-Stream, allowing to find more easily which sources are used where and not impacting the process Red Hat uses to push its releases. Since the structures used by the two upload scripts are different, they will not conflict. What we will end up seeing is something like: sources │ ├── pkg1 │ ├── c7 │ │ ├── hash1 │ │ └── hash2 │ ├── c8 │ │ ├── hash3 │ │ └── hash4 │ ├── tarball1 │ │ └── sha name │ │ └── hash5 │ │ └── tarball1 │ └── tarball2 │ └── sha name │ └── hash6 │ └── tarball2 │ └── pkg2 ├── c8 │ ├── hash7 │ └── hash8 ├── c8s │ ├── hash9 │ └── hash10 ├── tarball3 │ └── sha name │ └── hash11 │ └── tarball3 └── tarball4 └── sha name └── hash12 └── tarball4 and so on On CBS, the script that downloads the sources, will then need to be adjusted to try first the old structure before trying the new one. This may slow down a little bit the builds, but that should be most of the time, at most by a single http request. In this email I'm calling for feedback, do you like the idea? I'm happy to work on making it happen if there is consensus on this :) Looking forward for your thoughts, Pierre [1] https://lists.centos.org/pipermail/centos-devel/2022-February/120216.html

5 11

Using lookaside_upload in combination with the "flat" dist-git layout
by Daan De Meyer 25 Feb '22

25 Feb '22

Hi, Recently there was an announcement that the "flat" layout can now be used by SIGs that want to pull in changes from the Fedora RPM repos directly. I'm trying to switch the hyperscale branches for the systemd RPM to use the "flat" layout but I'm running into issues trying to upload the systemd tarball to the CentOS lookaside cache. I've successfully used the lookaside_upload script from centos-git-common to upload tarballs for use with the rpmbuild metadata layout before, but I'm struggling to get it to work with the "flat" layout. The main issue comes from the fact that in the "flat" layout, the sources file is used which contains a SHA512 hash that's used to find the corresponding tarball in the centos lookaside cache. However, the lookaside_upload script tries to upload tarballs to the lookaside cache using the sha1sum of the tarball as the identifier. This leads to CBS not finding the tarball when trying to do a build. I tried modifying the lookaside_upload script to use sha512sum instead of sha1sum but when doing this, I get a 500 HTTP internal error from the lookaside cache (https://paste.centos.org/view/5e7ef15c) Any other way to upload a tarball under the SHA512 identifier to the lookaside cache? Cheers, Daan De Meyer

1 1

[Storage-SIG] cephadm is not last version
by Luis Domingues 21 Feb '22

21 Feb '22

Hello, We are currently testing deploying clusters using CentOS Storage SIG. And while almost all packages are available on last version (16.2.7), we notice that cephadm was only on 16.2.5. Is any reason for that? Thanks, Luis Domingues Proton AG

4 4

Announcing possibility for SIGs to use "flat layout" on git.centos.org
by Fabian Arrotin 21 Feb '22

21 Feb '22

Recently, a thread (see https://lists.centos.org/pipermail/centos-devel/2022-January/120171.html) was started onn this list to discuss the possibility to let SIGs pushing to git in a "flat layout" style instead "rpmbuild layout" style on git.centos.org. As you know, since the beginning of git.centos.org, Red Hat pushed (as is still pushing, no change in sight for that part) in each /rpms/<package_name> git project in the "rpmbuild layout" style (so with SPECS/<pkg_name>.spec , eventually SOURCES/*) That's what SIGs have been using for years now, and it's how it's also documented in the SIG guide (see https://sigs.centos.org/guide/git/) Some SIGs wanted to bring "flat layout" style support so that they can just import existing branch from Fedora/Epel directly on git.centos.org without a need to change the dist-git layout, so get_sources.sh (from https://git.centos.org/centos-git-common) was recently modified to detect in which format the git repo is laid out and so how to retrieve sources from https://git.centos.org/sources. This request was all tracked in ticket https://pagure.io/centos-infra/issue/659 The needed new centpkg-minimal (https://cbs.centos.org/koji/packageinfo?packageID=8196) was built/pushed "live" today on cbs.centos.org , as some --scratch builds were tested with automotive SIG to confirm that it was working fine. We'll just add a simple note on the SIG Guide to mention that it's now possible to use the "flat layout" style (like Fedora/Epel) on git.centos.org for SIGs willing to use that layout. -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

Linux Engineering update
by Josh Boyer 16 Feb '22

16 Feb '22

Hi All, I wanted to take a moment to thank the CentOS Stream contributor community and give an update on where we're at from the Red Hat Linux Engineering side. The contributions coming in for CentOS Stream, particularly Stream 9, have been fantastic. This is the kind of feedback loop we are trying to build, and the willingness to jump in headfirst from the community even though we still have some bumpy spots in workflow and guidance is much appreciated. We've seen: - package rebases - compose adjustments - bug fixes - subpackage additions and more from the community. While not all of them were accepted into CentOS Stream, overall it's been great. As we march towards spring, the Linux Engineering team is going to be focusing on finishing up the releases of Red Hat Enterprise Linux 8.6 and 9.0. Thankfully, the continuous development model of CentOS Stream means that it won't stop and community contributions should keep on going. With that being said, what each Linux Eng team needs to do varies widely and it may result in some slower or intermittent responses to contributions for the next few months. If someone doesn't respond quickly or asks to defer a contribution, please have a little patience. We'll get to it eventually. Lastly, I wanted to give some forward-looking contribution advice. CentOS Stream 9 has seen quite a bit of flux since we made it available. This has been quite helpful to shape the Red Hat Enterprise Linux 9 Beta, and what will be the RHEL 9 GA. After RHEL 9 GA, things will solidify more into what one would normally expect from an Enterprise Linux operating system. Package versions will settle, rebases will be less common, and our Linux Eng maintainers will need to evaluate CentOS Stream 9 contributions fully against the standards we have for RHEL. For contributions that are just outside of those standards in some way, we have a variety of other avenues within the CentOS project. Several CentOS SIGs are active today, building additional content on top of CentOS Stream. We also have associated projects like EPEL. If you have a contribution and you're not quite sure if it's something CentOS Stream can accommodate, please reach out to the Feature Request SIG [1]. They're there to help you navigate the best place for a contribution, and to help shephard along where they can. Thank you so much for the success we've had to date. It's far from perfect, but building out a new project is fun in and of itself. josh [1] https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest

1 0

CentOS SIGs and gitlab
by Pierre-Yves Chibon 15 Feb '22

15 Feb '22

Good Morning Everyone, Some people have already noticed some asks being made to the CentOS infrastructure team and may be wondering what is the end goal of all of these. So this email is to try to share the end goal/vision of what I would to like to reach and open it up for comments/thoughts. I know of folks wanting to use gitlab for their workflow, this is for example the case of the automotive SIG folks. One reason for this is the automation that has been developed around the gitlab API in other contexes but that can be re-used for the SIG's benefits. So I have been looking at ways to make it possible for the Automotive SIG to use gitlab, but also keeping in mind that other SIGs may also be interested in re-using that model. First of all, a disclaimer: *all of the following only applies to SIGs who are interested. It is entirely opt-in. There is absolutely no desire to change what is working today for SIGs who do not wish to change*. So the way I envision things is the following: * SIGs who want they will be able to request a namespace at gitlab.com/centos/<sig_name> * The SIG chairs will be made owner of that namespace, giving them full power to organize it the way they wish * Guidance will be provided in the SIG's guide as to the different approaches possible (from the most simple to more complexes [1]). Those will be just that: guidance, SIGs can choose to follow them or ignore them * Gitlab groups will be mapped to groups in the CentOS accout system * Upon requests, groups can be created in the CentOS account system - This will allow SIG to fine-tune their access control if they so choose * SIGs will be able to use that gitlab namespace to host the git component of their dist-git * SIGs will be able to use either the flat dist-git layout or the exploded SRPM layout in their git repo, at their choosing, regardless of where they host their repositories * The lookaside cache used by the SIGs will be reworked to drop the requirement on branch name in the path. The end result will likely look like the Fedora or CentOS-Stream's lookaside cache. There are potentially a few ways to arrive to this, I have not started any conversation around this I have no ETA for most of these items, some are already work in progress (such as the possibility to use flat-layout in dist-git [2]), others are quite far down the line (cf the point about the lookaside cache). What do you all think of these ideas? Is that something that would be of interest? Did I miss something? If you would like more realtime discussion on this topic, it will be on the agenda of the infra SIG at 14 UTC on Monday the 21st in #centos-meeting. Looking forward to hear your thoughts! Pierre [1] for example: https://pagure.io/centos-infra/issue/645#comment-779917

2 1

Feedback on office hours
by Shaun McCance 15 Feb '22

15 Feb '22

Hi all, We have three sets of office hours that I'd like to gather feedback on. 1) CentOS Stream office hours are monthly on the second Wednesday, the same day as board meetings, at 17:00 UTC. This is a video meeting on meet.opensuse.org. It always has a few attendees. Sometimes productive stuff happens. Sometimes it's just a social hour, and that's ok. We should keep this one. I wouldn't mind a time shift or a shift in which week, because I happen to have another monthly meeting that conflicts. 2) CentOS office hours are monthly on the very next day on Thursday, at 10:00 UTC. This happens on IRC. Nobody attends, but we don't promote it at all. The time slot is awful for the US. It's a great time slot to bridge Europe and Asia. If we want to keep a time slot for Europe and Asia, we need to find attendees from those time zones, because I'm not awfully fond of waking up at 5am to look at a blank screen. 3) CentOS board office hours happen the week after the board meeting, so third week, Wednesday at 15:00 UTC. This is a video meeting on a Google Meet room I set up each month. The time slot is kind of early for US Pacific (7am). The purpose of this one is to ask the board questions about board stuff, so it's kind of important we have some board folks there. I'm open to rescheduling, canceling, consolidating, changing venues, or any level of bike shedding. Office hours can have value. They can also be a waste of time. Let's make sure we have something that adds value for our community. Thoughts? -- Shaun

2 1

Announcing Fedora-messaging notifications for cbs.centos.org
by Fabian Arrotin 14 Feb '22

14 Feb '22

We recently received this request from the Automotive SIG to enable fedora-messaging notification on the cbs.centos.org koji instance. (see https://pagure.io/centos-infra/issue/650) After some tests in dev/stg environment (thanks Pingou !), we pushed live the change earlier today and that means that if you're already using fedora-messaging, you'll be able to track activities from cbs.centos.org on fedora-messaging, or through datagrepper. For example, you'll be able to use https://apps.fedoraproject.org/datagrepper/v2/search?category=cbs to see recent activity on cbs.centos.org More information about fedora-messaging on https://fedora-messaging.readthedocs.io/ and https://apps.fedoraproject.org/datagrepper/ -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

Board office hours, Feb 16
by Shaun McCance 11 Feb '22

11 Feb '22

This week was a board meeting, so next week we'll have board office hours. Join the board Wednesday, February 16, at 15:00 UTC. Video call link: https://meet.google.com/qud-kgjn-tfg If you need dial-in details instead, just email me off-list. Thanks, Shaun

1 0

CPE Weekly Update – Week of February 7th – 11th
by Michal Konecny 10 Feb '22

10 Feb '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 * Got koji issues sorted and things back on track * Worked with Fedora CoreOS folks on bringing up a ppc64le builder, which exposed a virt issue we have. Will be installing a power9 box with Fedora 35 to test if it fixes it. * Got more ocp4 workers added, upgraded clusters a few times without incident * First live prod app on ocp4 ([blockerbugs](https://qa.fedoraproject.org/blockerbugs/)) * Outage Friday caused by disk space issue on proxies. ;( * 2 10TB iscsi volumes setup on fedora iad2 netapp for CentOS folks. * Fedimg is broken apparently, caused ci issues. Still need to find a fix to it. ( https://pagure.io/fedora-infrastructure/issue/10532 ) ### CentOS Infra including CentOS CI * Still storage/hardware issues to work on * [Dell server](https://pagure.io/centos-infra/issue/649) for iscsi/netapp usage * CentOS [backup server](https://pagure.io/centos-infra/issue/618) * https://debuginfod.centos.org should be [live/announced](https://lists.centos.org/pipermail/centos-devel/2022-Februa… (content for CentOS Stream 8 and 9 and SIGs packages) * Bussiness as usual ### Release Engineering * Branching of F36 * Rawhide nightlies are enabled again * F37 builds are being signed with F37 key * We have a Fedora 36 branched compose done already * Started work on [automation of scm requests](https://pagure.io/releng/issue/9274) ## 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 ------- * February planning done * Adding centpkg to EPEL * Continuing aligning c8s + c9s workflows with an optimum delivery date now agreed * Content Resolver upgrades continuing with maintainer page being added ## 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 ------- * Legacy API meta client merged * Provisioning/Deprovisioning implemented (in review) * Outstanding: integration tests & loose ends ## 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 ------- * local dev environment successfully deployed * koji in containers, mocked oidc auth, builder in containers, and osbuild-compose running as a service * We can run a full koji build using the image-builder plugins to make a successful compose ## 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 ------- * Move Bodhi from python-openid to OIDC (ongoing) * Automate staging process for RPM building in Koji (ongoing) * Dependency management via Poetry and dependabot (ongoing) ## 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 1775 source packages (increase of 127 from last week) * [RDO considering shipping openstack client packages in EPEL](https://meetings.opendev.org/meetings/rdo_meeting___2022_02_09/2022/r… * EPEL talks at CentOS Dojo * [State of EPEL on CentOS](https://youtu.be/JqnENGdvG88) * [Bootstrapping new EPEL releases with ebranch](https://youtu.be/VjPZmq_h2Rk) * [EPEL Packaging Hackfest](https://youtu.be/vZ-CX5XJV2Q) Kindest regards, CPE Team

1 0

bind rpm conflicts - centOS 8
by lejeczek 10 Feb '22

10 Feb '22

Hi guys, I did not rush with this but now after a week and some - does anybody else sees it to? Last metadata expiration check: 0:03:21 ago on Fri 04 Feb 2022 08:57:59 GMT. Error: Problem 1: package bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires libdns.so.1112()(64bit), but none of the providers can be installed - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-6.el8.x86_64 - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-3.el8.x86_64 - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-4.el8_4.x86_64 - cannot install the best update candidate for package bind-libs-lite-32:9.11.26-6.el8.x86_64 - cannot install the best update candidate for package bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 Problem 2: problem with installed package bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 - package bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires libdns.so.1112()(64bit), but none of the providers can be installed - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-6.el8.x86_64 - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-3.el8.x86_64 - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-4.el8_4.x86_64 - package bind-32:9.11.36-2.el8.x86_64 requires libdns.so.1115()(64bit), but none of the providers can be installed - package bind-32:9.11.36-2.el8.x86_64 requires bind-libs-lite(x86-64) = 32:9.11.36-2.el8, but none of the providers can be installed - cannot install the best update candidate for package bind-32:9.11.26-6.el8.x86_64 Problem 3: package ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch requires bind-dyndb-ldap >= 11.2-2, but none of the providers can be installed - package bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires libdns.so.1112()(64bit), but none of the providers can be installed - package bind-dyndb-ldap-11.6-2.module_el8.4.0+639+a88aab78.x86_64 requires libdns.so.1112()(64bit), but none of the providers can be installed - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-6.el8.x86_64 - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-3.el8.x86_64 - cannot install both bind-libs-lite-32:9.11.36-2.el8.x86_64 and bind-libs-lite-32:9.11.26-4.el8_4.x86_64 - package bind-libs-32:9.11.36-2.el8.x86_64 requires libdns.so.1115()(64bit), but none of the providers can be installed - package bind-libs-32:9.11.36-2.el8.x86_64 requires bind-libs-lite(x86-64) = 32:9.11.36-2.el8, but none of the providers can be installed - cannot install the best update candidate for package ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch - cannot install the best update candidate for package bind-libs-32:9.11.26-6.el8.x86_64 Problem 4: problem with installed package ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch - package ipa-server-dns-4.9.8-2.module_el8.6.0+1053+0ac05726.noarch requires bind-dyndb-ldap >= 11.2-2, but none of the providers can be installed - package bind-dyndb-ldap-11.6-2.module_el8.5.0+750+c59b186b.x86_64 requires libdns.so.1112()(64bit), but none of the providers can be installed - package bind-dyndb-ldap-11.6-2.module_el8.4.0+639+a88aab78.x86_64 requires libdns.so.1112()(64bit), but none of the providers can be installed - package bind-libs-lite-32:9.11.26-6.el8.x86_64 requires bind-license = 32:9.11.26-6.el8, but none of the providers can be installed - package bind-libs-lite-32:9.11.26-3.el8.x86_64 requires bind-license = 32:9.11.26-3.el8, but none of the providers can be installed - package bind-libs-lite-32:9.11.26-4.el8_4.x86_64 requires bind-license = 32:9.11.26-4.el8_4, but none of the providers can be installed - cannot install both bind-license-32:9.11.36-2.el8.noarch and bind-license-32:9.11.26-6.el8.noarch - cannot install both bind-license-32:9.11.36-2.el8.noarch and bind-license-32:9.11.26-3.el8.noarch - cannot install both bind-license-32:9.11.36-2.el8.noarch and bind-license-32:9.11.26-4.el8_4.noarch - cannot install the best update candidate for package bind-license-32:9.11.26-6.el8.noarch many thanks, L

5 9

Announcing https://debuginfod.centos.org service
by Fabian Arrotin 09 Feb '22

09 Feb '22

Some time ago, we got a request to provide a debuginfod service for CentOS 8-stream and 9-stream. (see ticket https://pagure.io/centos-infra/issue/500 for details) Service / infra is now live and available directly at https://debuginfod.centos.org That means that people who want to consume transparently debuginfo pkgs can use that service instead of manually fetching the debuginfo corresponding pkgs (matching NVR, etc) Thanks to the collaboration with Frank Eigler (initial requester), the service was tested and is now operational. For more info about debuginfod, you can read https://fedoraproject.org/wiki/Debuginfod (linked from https://debuginfod.centos.org/) Worth knowing that there is a manual step for now but Frank already opened a bugzilla ticket to transparently enable that new feature (you can track ticket https://bugzilla.redhat.com/show_bug.cgi?id=2052574) Last but not least : this public debuginfod service is tracking/indexing *all* pkgs built for 8-stream and 9-stream, including SIGs packages, and so should be available quickly once the matching other packages are landing on public mirror network. Thanks a lot to Frank for the received advice on setting this service up. Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

Resigning from Kmods SIG
by Jonathan Billings 08 Feb '22

08 Feb '22

Hello, I am resigning my role as co-chair of the Kmods SIG. Please let me know if I need to change my account settings in git or other centos systems. -- Jonathan Billings

3 2

resilientstorage - resource-agents-paf
by lejeczek 07 Feb '22

07 Feb '22

Hi guys. Anybody gets this?: -> $ dnf update Last metadata expiration check: 0:13:07 ago on Mon 07 Feb 2022 08:47:24 GMT. Error: Problem: package resource-agents-paf-4.9.0-7.el8.x86_64 requires resource-agents = 4.9.0-7.el8, but none of the providers can be installed - cannot install both resource-agents-4.9.0-13.el8.x86_64 and resource-agents-4.9.0-7.el8.x86_64 - cannot install both resource-agents-4.9.0-7.el8.x86_64 and resource-agents-4.9.0-13.el8.x86_64 - cannot install the best update candidate for package resource-agents-paf-4.9.0-7.el8.x86_64 - cannot install the best update candidate for package resource-agents-4.9.0-7.el8.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) many thanks, L

1 0

CentOS Stream 9 security patches: Where is polkit?
by Steven Rosenberg 03 Feb '22

03 Feb '22

I have been looking for the polkit patch for CentOS Stream 9, and I have not seen a new package in the repo. Am I missing something?

6 10

CentOS 8 stream Messaging SIG rabbitmq mirrorlist url
by Daniel Nilsson 01 Feb '22

01 Feb '22

Hi Not sure if there is work already going on or if it has not been brought to anyones attention. The mirrorlist url supplied by centos-release-rabbitmq-38 rpm in the Extras repo still uses the now removed "mirrorlist.centos.org/8" address. Are there any plans to release a new version of the package that use/supply the working "8-stream" address? Best regards Daniel Nilsson Daniel Nilsson Software Integrations Engineer dnilsson(a)itrsgroup.com www.itrsgroup.com ITRS Group Första Långgatan 19 413 27 Gothenburg Sweden Tel.+46 31-352 56 00 Internet communications are not secure and therefore the ITRS Group does not accept legal responsibility for the contents of this message. Any view or opinions presented are solely those of the author and do not necessarily represent those of the ITRS Group unless otherwise specifically stated. [itrs.email.signature] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel February 2022