Tag: CentOS

Posted on by — Leave a comment

rpmdistro-repoquery: a cross-distribution repoquery tool

This article showcases rpmdistro-repoquery, and describes how to use it to simplify doing RPM-based package operations across multiple distributions. This does not require using SSH to log into another host or starting a container or VM.

Introduction

Whether you’re a packager, system administrator, or a user of Fedora Linux, CentOS Stream, or their derivatives (RHEL, AlmaLinux, Rocky Linux etc.), you might already be familiar with dnf repoquery. This tool allows you to query the repositories configured on the system for information about available packages, whether or not they are currently installed on the local machine.

This is great, within limits. For instance, on Fedora Linux, you can query packages built for stable and branched Fedora Linux releases and, if you install fedora-repos-rawhide, packages in the development branch. Sufficient care is required to make sure you don’t enable repos meant for different Fedora Linux releases by default and thus accidentally upgrade the running system.

Enter rpmdistro-repoquery: it comes with a set of repo definitions for different RPM-based distributions, but instead of putting them in /etc/yum.repos.d with the repositories meant for actual use, put them in /usr/share/rpmdistro-repoquery (or, if you so choose, you can clone the repository and use definitions that come in the checkout). DNF is then invoked with a custom configuration file and a custom cache location that points at one of the repos for one of the distributions rather than the default location.

The various supported distributions come with the relevant repositories enabled by default. Some have additional repositories that need to be enabled explicitly. For example, source repos are off by default. Also, CentOS Stream configurations come with additional repos for SIG packages that are off by default.

This opens up a lot of use cases. I highlight some of them below.

Note: The primary author of this tool, Neal Gompa, works on a lot of RPM-based Linux distributions. I became involved using it in ebranch.

Real-life rpmdistro-repoquery use cases

Quickly seeing if a CentOS Stream update has made it to the mirrors

In Fedora’s build system, updates go through Bodhi, and once they are marked testing or stable that means there is a compose containing those updates, and they tend to hit mirrors shortly after.

In CentOS Stream, the situation is more complicated, as the QA process is not visible to the public. Take clang for example: given a commit, and a matching Koji build on January 27th, can we be sure this is pushed out to the mirrors?

It turns out, as of February 9th, it’s not in the mirrors yet:

$ rpmdistro-repoquery centos-stream 9 clang 2>/dev/null
clang-0:14.0.0-1.el9.i686
clang-0:14.0.0-1.el9.x86_64
clang-0:14.0.5-1.el9.i686
clang-0:14.0.5-1.el9.x86_64
clang-0:14.0.6-1.el9.i686
clang-0:14.0.6-1.el9.x86_64
clang-0:15.0.1-2.el9.i686
clang-0:15.0.1-2.el9.x86_64
clang-0:15.0.7-2.el9.i686
clang-0:15.0.7-2.el9.x86_64

Comparing what is packaged in different distributions

Scenario: you use / manage a heterogeneous fleet of different distributions. You want to find out if all the packages you need are available (because you might need to package what’s missing).

Let’s see if myrepos is available on openSUSE Tumbleweed (the rolling distribution):

$ rpm -q myrepos
myrepos-1.20180726-14.fc37.noarch $ rpmdistro-repoquery opensuse-tumbleweed 0 myrepos $ rpmdistro-repoquery opensuse-tumbleweed 0 /usr/bin/mr
mr-0:1.20180726-1.9.noarch

Searching by the Fedora Linux package name yields nothing, but in this case, searching by the binary shows a match (since those are in the RPM metadata): myrepos is available, but you’ll need a different package name in your configuration management.

ebranch

This is a special case of the former. ebranch is a tool for branching Fedora Linux packages for EPEL.

Given that CentOS Stream (and its downstreams, such as Red Hat Enterprise Linux, AlmaLinux and Rocky Linux) only carries the subset of Fedora Linux packages that Red Hat is committed to supporting, EPEL provides a way for the community to maintain additional packages built against RHEL (or CentOS Stream).

A major problem here is dealing with dependency hell: a missing package might have several missing dependencies, which in turn have more missing dependencies… Getting retsnoop in EPEL 9 involves branching 189 packages in total!

ebranch utilizes rpmdistro-repoquery to compare what is available in Rawhide (rpmdistro-repoquery fedora rawhide) with what is available in CentOS Stream + EPEL (rpmdistro-repoquery centos-stream-legacy 8 and rpmdistro-repoquery centos-stream 9) to build up a transitive closure of missing dependencies and report on any dependency loops. ebranch also computes a chain build order for the missing dependencies, grouping packages that can be built in parallel.

Checking the impact of a soname bump

Fedora’s updates policy for stable releases and EPEL’s incompatible upgrades policy both discourage ABI-breaking updates, but sometimes they are necessary, as in the case of libkdumpfile in EPEL.

With rpmdistro-repoquery, finding the delta between any two distribution releases that it supports is trivial:

$ comm <(rpmdistro-repoquery fedora rawhide \ --provides libkdumpfile >/dev/null) \ <(rpmdistro-repoquery centos-stream 9 \ --provides libkdumpfile >/dev/null) libaddrxlat.so.2()(64bit) libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
libaddrxlat.so.3
libaddrxlat.so.3()(64bit)
libaddrxlat.so.3(LIBADDRXLAT_0)
libaddrxlat.so.3(LIBADDRXLAT_0)(64bit) libkdumpfile = 0.4.1-5.el9
libkdumpfile = 0.5.0-3.fc38
libkdumpfile(x86-32) = 0.5.0-3.fc38 libkdumpfile(x86-64) = 0.4.1-5.el9
libkdumpfile(x86-64) = 0.5.0-3.fc38
libkdumpfile.so.10
libkdumpfile.so.10()(64bit)
libkdumpfile.so.10(LIBKDUMPFILE_0)
libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit) libkdumpfile.so.9()(64bit) libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)

And likewise, finding the blast radius of said update:

$ rpmdistro-repoquery centos-stream 9 \ --whatrequires "libaddrxlat.so.2()(64bit)"
libkdumpfile-devel-0:0.4.1-5.el9.x86_64
libkdumpfile-util-0:0.4.1-5.el9.x86_64
python3-libkdumpfile-0:0.4.1-5.el9.x86_64 $ rpmdistro-repoquery centos-stream 9 \ --whatrequires "libkdumpfile.so.9()(64bit)"
drgn-0:0.0.22-1.el9.x86_64
libkdumpfile-devel-0:0.4.1-5.el9.x86_64
libkdumpfile-util-0:0.4.1-5.el9.x86_64
python3-libkdumpfile-0:0.4.1-5.el9.x86_64 $ rpmdistro-repoquery centos-stream-legacy 8 \ --whatrequires "libaddrxlat.so.2()(64bit)"
libkdumpfile-devel-0:0.4.1-5.el8.x86_64
libkdumpfile-util-0:0.4.1-5.el8.x86_64
python3-libkdumpfile-0:0.4.1-5.el8.x86_64 $ rpmdistro-repoquery centos-stream-legacy 8 \ --whatrequires "libkdumpfile.so.9()(64bit)"
drgn-0:0.0.22-1.el8.x86_64
libkdumpfile-devel-0:0.4.1-5.el8.x86_64
libkdumpfile-util-0:0.4.1-5.el8.x86_64
python3-libkdumpfile-0:0.4.1-5.el8.x86_64

Building OS images

mkosi is a tool for generating OS images; currently it contains the logic for different distributions (e.g. Fedora, CentOS), but this makes it hard to, for example, build an image for CentOS SIGs such as Hyperscale.

With Daan De Meyer’s refactor rpmdistro-repoquery’s repo files can now be reused by mkosi so in the future, tailoring what repositories are used to build an OS image should be much easier.

Conclusion

The contributors for this tool have found it very useful in our Linux distribution work, and we hope this article can help introduce it to others who likewise find it useful.

Please try it yourself — on Fedora Linux, and on any CentOS Stream or derivatives with EPEL enabled, simply do:

$ sudo dnf install rpmdistro-repoquery

If the distro you want to work with is not supported, pull requests are welcome! Likewise with suggestions or requests. If you want to package rpmdistro-repoquery in a different distribution, feel free to use the Fedora packaging as reference.

Posted on by — Leave a comment

Fedora pastebin and fpaste updates

Fedora and EPEL users who use fpaste to paste and share snippets of text might have noticed some changes recently. Recently, an update went out which sends pastes made by fpaste to the CentOS Pastebin instead of the Modern Paste instance that Fedora was running. Don’t fear — this was an intentional change, and is part of the effort to lower the workload within the Fedora Infrastructure and Community Platform Engineering teams. Keep reading to learn more about what’s happening with pastebin and your pastes.

About the service

A pastebin lets you save text on a website for a length of time. This helps you exchange data easily with other users. For example, you can post error messages for help with a bug or other issue.

The CentOS Pastebin is a community-maintained service that keeps pastes around for up to 24 hours. It also offers syntax highlighting for a large number of programming and markup languages.

As before, you can paste files:

$ fpaste sql/010.add_owner_ip_index.sql Uploading (0.1KiB)...
https://paste.centos.org/view/6ee941cc

…or command output…

$ rpm -ql python3 | fpaste
Uploading (0.7KiB)...
https://paste.centos.org/view/44945a99

…or system information:

$ fpaste --sysinfo Gathering system info .............Uploading (8.1KiB)...
https://paste.centos.org/view/8d5bb827

What to expect from Pastebin

On December 1st, 2019, Fedora Infrastructure will turn off its Modern Paste servers. It will then redirect fpaste.org, www.fpaste.org, and paste.fedoraproject.org to paste.centos.org.

If you notice any issues with fpaste, first try updating your fpaste package. On Fedora use this command:

$ dnf update fpaste

Or, on machines that use the EPEL repository, use this command:

$ yum update fpaste

If you still run into issues, please file a bug on the fpaste issue tracker, and please be as detailed as possible. Happy pasting!

Photo by Kelly Sikkema on Unsplash.

Posted on by — Leave a comment

Fedora and CentOS Stream

From the desk of the Fedora Project Leader:

Hi everyone! You may have seen the announcement about changes over at the CentOS Project. (If not, please go ahead and take a few minutes and read it — I’ll wait!) And now you may be wondering: if CentOS is now upstream of RHEL, what happens to Fedora? Isn’t that Fedora’s role in the Red Hat ecosystem?

First, don’t worry. There are changes to the big picture, but they’re all for the better.

If you’ve been following the conference talks from Red Hat Enterprise Linux leadership about the relationship between Fedora, CentOS, and RHEL, you have heard about “the Penrose Triangle”. That’s a shape like something from an M. C. Escher drawing: it’s impossible in real life!

We’ve been thinking for a while that maybe impossible geometry is not actually the best model. 

For one thing, the imagined flow where contributions at the end would flow back into Fedora and grow in a “virtuous cycle” never actually worked that way. That’s a shame, because there’s a huge, awesome CentOS community and many great people working on it — and there’s a lot of overlap with the Fedora community too. We’re missing out.

But that gap isn’t the only one: there’s not really been a consistent flow between the projects and product at all. So far, the process has gone like this: 

  1. Some time after the previous RHEL release, Red Hat would suddenly turn more attention to Fedora than usual.
  2. A few months later, Red Hat would split off a new RHEL version, developed internally.
  3. After some months, that’d be put into the world, including all of the source — from which CentOS is built. 
  4. Source drops continue for updates, and sometimes those updates include patches that were in Fedora — but there’s no visible connection.

Each step here has its problems: intermittent attention, closed-door development, blind drops, and little ongoing transparency. But now Red Hat and CentOS Project are fixing that, and that’s good news for Fedora, too.

Fedora will remain the first upstream of RHEL. It’s where every RHEL came from, and is where RHEL 9 will come from, too. But after RHEL branches off, CentOS will be upstream for ongoing work on those RHEL versions. I like to call it “the midstream”, but the marketing folks somehow don’t, so that’s going to be called “CentOS Stream”.

We — Fedora, CentOS, and Red Hat — still need to work out all of the technical details, but the idea is that these branches will live in the same package source repository. (The current plan is to make a “src.centos.org” with a  parallel view of the same data as src.fedoraproject.org). This change gives public visibility into ongoing work on released RHEL, and a place for developers and Red Hat’s partners to collaborate at that level.

CentOS SIGs — the special interest groups for virtualization, storage, config management and so on — will do their work in shared space right next to Fedora branches. This will allow much easier collaboration and sharing between the projects, and I’m hoping we’ll even be able to merge some of our similar SIGs to work together directly. Fixes from Fedora packages can be cherry-picked into the CentOS “midstream” ones — and where useful, vice versa.

Ultimately, Fedora, CentOS, and RHEL are part of the same big project family. This new, more natural flow opens possibilities for collaboration which were locked behind artificial (and extra-dimensional!) barriers. I’m very excited for what we can now do together!

— Matthew Miller, Fedora Project Leader