RPM packages explained

Perhaps the best known way the Fedora community pursues its mission of promoting free and open source software and content is by developing the Fedora software distribution. So it’s not a surprise at all that a very large proportion of our community resources are spent on this task. This post summarizes how this software is “packaged” and the underlying tools such as rpm that make it all possible.

RPM: the smallest unit of software

The editions and flavors (spins/labs/silverblue) that users get to choose from are all very similar. They’re all composed of various software that is mixed and matched to work well together. What differs between them is the exact list of tools that goes into each. That choice depends on the use case that they target. The basic unit of all of these is an RPM package file.

RPM files are archives that are similar to ZIP files or tarballs. In fact, they uses compression to reduce the size of the archive. However, along with files, RPM archives also contain metadata about the package. This can be queried using the rpm tool:

$ rpm -q fpaste

$ rpm -qi fpaste
Name        : fpaste
Version     :
Release     : 2.fc30
Architecture: noarch
Install Date: Tue 26 Mar 2019 08:49:10 GMT
Group       : Unspecified
Size        : 64144
License     : GPLv3+
Signature   : RSA/SHA256, Thu 07 Feb 2019 15:46:11 GMT, Key ID ef3c111fcfc659b9
Source RPM  : fpaste-
Build Date  : Thu 31 Jan 2019 20:06:01 GMT
Build Host  :
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         :
Bug URL     :
Summary     : A simple tool for pasting info onto sticky notes instances
Description :
It is often useful to be able to easily paste text to the Fedora
Pastebin at and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin

$ rpm -ql fpaste

When an RPM package is installed, the rpm tools know exactly what files were added to the system. So, removing a package also removes these files, and leaves the system in a consistent state. This is why installing software using rpm is preferred over installing software from source whenever possible.


Nowadays, it is quite rare for software to be completely self-contained. Even fpaste, a simple one file Python script, requires that the Python interpreter be installed. So, if the system does not have Python installed (highly unlikely, but possible), fpaste cannot be used. In packager jargon, we say that “Python is a run-time dependency of fpaste“.

When RPM packages are built (the process of building RPMs is not discussed in this post), the generated archive includes all of this metadata. That way, the tools interacting with the RPM package archive know what else must must be installed so that fpaste works correctly:

$ rpm -q --requires fpaste
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm -q --provides fpaste
fpaste =

$ rpm -qi python3
Name        : python3
Version     : 3.7.3
Release     : 3.fc30
Architecture: x86_64
Install Date: Thu 16 May 2019 18:51:41 BST
Group       : Unspecified
Size        : 46139
License     : Python
Signature   : RSA/SHA256, Sat 11 May 2019 17:02:44 BST, Key ID ef3c111fcfc659b9
Source RPM  : python3-3.7.3-3.fc30.src.rpm
Build Date  : Sat 11 May 2019 01:47:35 BST
Build Host  :
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         :
Bug URL     :
Summary     : Interpreter of the Python programming language
Description :
Python is an accessible, high-level, dynamically typed, interpreted programming
language, designed with an emphasis on code readability.
It includes an extensive standard library, and has a vast ecosystem of
third-party libraries.

The python3 package provides the "python3" executable: the reference
interpreter for the Python language, version 3.
The majority of its standard library is provided in the python3-libs package,
which should be installed automatically along with python3.
The remaining parts of the Python standard library are broken out into the
python3-tkinter and python3-test packages, which may need to be installed

Documentation for Python is provided in the python3-docs package.

Packages containing additional libraries for Python are generally named with
the "python3-" prefix.

$ rpm -q --provides python3
python(abi) = 3.7
python3 = 3.7.3-3.fc30
python3(x86-64) = 3.7.3-3.fc30
python3.7 = 3.7.3-3.fc30
python37 = 3.7.3-3.fc30

Resolving RPM dependencies

While rpm knows the required dependencies for each archive, it does not know where to find them. This is by design: rpm only works on local files and must be told exactly where they are. So, if you try to install a single RPM package, you get an error if rpm cannot find the package’s run-time dependencies. This example tries to install a package downloaded from the Fedora package set:

$ ls

$ rpm -qpi python3-elephant-0.6.2-3.fc30.noarch.rpm
Name        : python3-elephant
Version     : 0.6.2
Release     : 3.fc30
Architecture: noarch
Install Date: (not installed)
Group       : Unspecified
Size        : 2574456
License     : BSD
Signature   : (none)
Source RPM  : python-elephant-0.6.2-3.fc30.src.rpm
Build Date  : Fri 14 Jun 2019 17:23:48 BST
Build Host  :
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         :
Bug URL     :
Summary     : Elephant is a package for analysis of electrophysiology data in Python
Description :
Elephant - Electrophysiology Analysis Toolkit Elephant is a package for the
analysis of neurophysiology data, based on Neo.

$ rpm -qp --requires python3-elephant-0.6.2-3.fc30.noarch.rpm
python(abi) = 3.7
python3.7dist(neo) >= 0.7.1
python3.7dist(numpy) >= 1.8.2
python3.7dist(quantities) >= 0.10.1
python3.7dist(scipy) >= 0.14.0
python3.7dist(six) >= 1.10.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ sudo rpm -i ./python3-elephant-0.6.2-3.fc30.noarch.rpm
error: Failed dependencies:
        python3.7dist(neo) >= 0.7.1 is needed by python3-elephant-0.6.2-3.fc30.noarch
        python3.7dist(quantities) >= 0.10.1 is needed by python3-elephant-0.6.2-3.fc30.noarch

In theory, one could download all the packages that are required for python3-elephant, and tell rpm where they all are, but that isn’t convenient. What if python3-neo and python3-quantities have other run-time requirements and so on? Very quickly, the dependency chain can get quite complicated.


Luckily, dnf and friends exist to help with this issue. Unlike rpm, dnf is aware of repositories. Repositories are collections of packages, with metadata that tells dnf what these repositories contain. All Fedora systems come with the default Fedora repositories enabled by default:

$ sudo dnf repolist
repo id              repo name                             status
fedora               Fedora 30 - x86_64                    56,582
fedora-modular       Fedora Modular 30 - x86_64               135
updates              Fedora 30 - x86_64 - Updates           8,573
updates-modular      Fedora Modular 30 - x86_64 - Updates     138
updates-testing      Fedora 30 - x86_64 - Test Updates      8,458

There’s more information on these repositories, and how they can be managed on the Fedora quick docs.

dnf can be used to query repositories for information on the packages they contain. It can also search them for software, or install/uninstall/upgrade packages from them:

$ sudo dnf search elephant
Last metadata expiration check: 0:05:21 ago on Sun 23 Jun 2019 14:33:38 BST.
============================================================================== Name & Summary Matched: elephant ==============================================================================
python3-elephant.noarch : Elephant is a package for analysis of electrophysiology data in Python
python3-elephant.noarch : Elephant is a package for analysis of electrophysiology data in Python

$ sudo dnf list \*elephant\*
Last metadata expiration check: 0:05:26 ago on Sun 23 Jun 2019 14:33:38 BST.
Available Packages
python3-elephant.noarch      0.6.2-3.fc30      updates-testing
python3-elephant.noarch      0.6.2-3.fc30              updates

Installing dependencies

When installing the package using dnf now, it resolves all the required dependencies, then calls rpm to carry out the transaction:

$ sudo dnf install python3-elephant
Last metadata expiration check: 0:06:17 ago on Sun 23 Jun 2019 14:33:38 BST.
Dependencies resolved.
 Package                                      Architecture                     Version                                                        Repository                                 Size
 python3-elephant                             noarch                           0.6.2-3.fc30                                                   updates-testing                           456 k
Installing dependencies:
 python3-neo                                  noarch                           0.8.0-0.1.20190215git49b6041.fc30                              fedora                                    753 k
 python3-quantities                           noarch                           0.12.2-4.fc30                                                  fedora                                    163 k
Installing weak dependencies:
 python3-igor                                 noarch                           0.3-5.20150408git2c2a79d.fc30                                  fedora                                     63 k

Transaction Summary
Install  4 Packages

Total download size: 1.4 M
Installed size: 7.0 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch.rpm                                                                                                  222 kB/s |  63 kB     00:00
(2/4): python3-elephant-0.6.2-3.fc30.noarch.rpm                                                                                                               681 kB/s | 456 kB     00:00
(3/4): python3-quantities-0.12.2-4.fc30.noarch.rpm                                                                                                            421 kB/s | 163 kB     00:00
(4/4): python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch.rpm                                                                                               840 kB/s | 753 kB     00:00
Total                                                                                                                                                         884 kB/s | 1.4 MB     00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                      1/1
  Installing       : python3-quantities-0.12.2-4.fc30.noarch                                                                                                                              1/4
  Installing       : python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch                                                                                                                    2/4
  Installing       : python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch                                                                                                                 3/4
  Installing       : python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 4/4
  Running scriptlet: python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 4/4
  Verifying        : python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 1/4
  Verifying        : python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch                                                                                                                    2/4
  Verifying        : python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch                                                                                                                 3/4
  Verifying        : python3-quantities-0.12.2-4.fc30.noarch                                                                                                                              4/4

  python3-elephant-0.6.2-3.fc30.noarch   python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch   python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch   python3-quantities-0.12.2-4.fc30.noarch


Notice how dnf even installed python3-igor, which isn’t a direct dependency of python3-elephant.

DnfDragora: a graphical interface to DNF

While technical users may find dnf straightforward to use, it isn’t for everyone. Dnfdragora addresses this issue by providing a graphical front end to dnf.

dnfdragora (version 1.1.1-2 on Fedora 30) listing all the packages installed on a system.

From a quick look, dnfdragora appears to provide all of dnf‘s main functions.

There are other tools in Fedora that also manage packages. GNOME Software, and Discover are two examples. GNOME Software is focused on graphical applications only. You can’t use the graphical front end to install command line or terminal tools such as htop or weechat. However, GNOME Software does support the installation of Flatpaks and Snap applications which dnf does not. So, they are different tools with different target audiences, and so provide different functions.

This post only touches the tip of the iceberg that is the life cycle of software in Fedora. This article explained what RPM packages are, and the main differences between using rpm and using dnf.

In future posts, we’ll speak more about:

  • The processes that are needed to create these packages
  • How the community tests them to ensure that they are built correctly
  • The infrastructure that the community uses to get them to community users in future posts.

Using i3 with multiple monitors

Are you using multiple monitors with your Linux workstation? Seeing many things at once might be beneficial. But there are often much more windows in our workflows than physical monitors — and that’s a good thing, because seeing too many things at once might be distracting. So being able to switch what we see on individual monitors seems crucial.

Let’s talk about i3 — a popular tiling window manager that works great with multiple monitors. And there is one handy feature that many other window managers don’t have — the ability to switch workspaces on individual monitors independently.

Quick introduction to i3

The Fedora Magazine has already covered i3 about three years ago. And it was one of the most popular articles ever published! Even though that’s not always the case, i3 is pretty stable and that article is still very accurate today. So — not to repeat ourselves too much — this article only covers the very minimum to get i3 up and running, and you’re welcome to go ahead and read it if you’re new to i3 and want to learn more about the basics.

To install i3 on your system, run the following command:

$ sudo dnf install i3

When that’s done, log out, and on the log in screen choose i3 as your window manager and log back in again.

When you run i3 for the first time, you’ll be asked if you wish to proceed with automatic configuration — answer yes here. After that, you’ll be asked to choose a “mod key”. If you’re not sure here, just accept the default which sets you Windows/Super key as the mod key. You’ll use this key for mostly all the shortcuts within the window manager.

At this point, you should see a little bar at the bottom and an empty screen. Let’s have a look at some of the basic shortcuts.

Open a terminal using:

$mod + enter

Switch to a second workspace using:

$mod + 2

Open firefox in two steps, first by:

$mod + d

… and then by typing “firefox” and pressing enter.

Move it to the first workspace by:

$mod + shift + 1

… and switch to the first workspace by:

$mod + 1

At this point, you’ll see a terminal and a firefox window side by side. To close a window, press:

$mod + shift + q

There are more shortcuts, but these should give you the minimum to get started with i3.

Ah! And to exit i3 (to log out) press:

$mod + shift + e

… and then confirm using your mouse at the top-right corner.

Getting multiple screens to work

Now that we have i3 up and running, let’s put all those screens to work!

To do that, we’ll need to use the command line as i3 is very lightweight and doesn’t have gui to manage additional screens. But don’t worry if that sounds difficult — it’s actually quite starighforward!

The command we’ll use is called xrandr. If you don’t have xrandr on your system, install it by running:

$ sudo dnf install xrandr

When that’s installed, let’s just go ahead and run it:

$ xrandr

The output lists all the available outputs, and also indicated which have a screen attached to them (a monitor connedted with a cable) by showing supported resolutions. Good news is that we don’t need to really care about the specific resolutions to make the them work.

This specific example shows a primary screen of a laptop (named eDP1), and a second monitor connected to the HDMI-2 output, physically positionned right of the laptop. To turn it on, run the following command:

$ xrandr --output HDMI-2 --auto --right-of eDP1

And that’s it! Your screen is now active.

Second screen active. The commands shown on this screenshot are slightly different than in the article, as they set a smaller resolution to make the screenshots more readable.

Managing workspaces on multiple screens

Switching workspaces and creating new ones on multiple screens is very similar to having just one screen. New workspaces get created on the screen that’s currently active — the one that has your mouse cursor on it.

So, to switch to a specific workspace (or to create a new one in case it doesn’t exist), press:

$mod + NUMBER

And you can switch workspaces on individual monitors independently!

Workspace 2 on the left screen, workspace 4 on the right screen.
Left screen switched to workspace 3, right screen still showing workspace 4.
Right screen switched to workspace 4, left screen still showing workspace 3.

Moving workspaces between monitors

The same way we can move windows to differnet workspaces by the following command:

$mod + shift + NUMBER

… we can move workspaces to different screens as well. However, there is no default shortcut for this action — so we have to create it first.

To create a custom shortcut, you’ll need to open the configuration file in a text editor of your choice (this article uses vim):

$ vim ~/.config/i3/config

And add the following lines to the very bottom of the configuration file:

# Moving workspaces between screens 
bindsym $mod+p move workspace to output right

Save, close, and to reload and apply the configuration, press:

$mod + shift + r

Now you’ll be able to move your active workspace to the second monitor by:

$mod + p
Workspace 2 with Firefox on the left screen
Workspace 2 with Firefox moved to the second screen

And that’s it! Enjoy your new multi-monitor experience, and to learn more about i3, you’re welcome to read the previous article about i3 on the Fedora Magazine, or consult the official i3 documentation.


Making Fedora 30

What does it take to make a Linux distribution like Fedora 30? As you might expect, it’s not a simple process.

Changes in Fedora 30

Although Fedora 29 released on October 30, 2018, work on Fedora 30 began long before that. The first change proposal was submitted in late August. By my count, contributors made nine separate change proposals for Fedora 30 before Fedora 29 shipped.

Some of these proposals come early because they have a big impact, like mass removal of Python 2 packages. By the time the proposal deadline arrived in early January, the community had submitted 50 change proposals.

Of course, not all change proposals make it into the shipped release. Some of them are more focused on how we build the release instead of what we release. Others don’t get done in time. System-wide changes must have a contingency plan. These changes are generally evaluated at one of three points in the schedule: when packages branch from Rawhide, at the beginning of the Beta freeze, and at the beginning of the Final freeze. For Fedora 30, 45 Change proposals were still active for the release.

Fedora has a calendar-based release schedule, but that doesn’t mean we ship whatever exists on a given date. We have a set of release criteria that we test against, and we don’t put out a release until all the blockers are resolved. This sometimes means a release is delayed, but it’s important that we ship reliable software.

For the Fedora 30 development cycle, we accepted 22 proposed blocker bugs and rejected 6. We also granted 33 freeze exceptions — bugs that can be fixed during the freeze because they impact the released artifacts or are otherwise important enough to include in the release.

Other contributions

Of course, there’s more to making a release than writing or packaging the code, testing it, and building the images. As with every release, the Fedora Design team created a new desktop background along with several supplemental wallpapers. The Fedora Marketing team wrote release announcements and put together talking points for the Ambassadors and Advocates to use when talking to the broader community.

If you’ve looked at our new website, that was the work of the Websites team in preparation for the Fedora 30 release:

The Documentation Team wrote Release Notes and updated other documentation. Translators provided translations to dozens of languages.

Many other people made contributions to the release of Fedora 30 in some way. It’s not easy to count everyone who has a hand in producing a Linux distribution, but we appreciate every one of our contributors. If you would like to join the Fedora Community but aren’t sure where to start, check out What Can I Do For Fedora?

Photo by Robin Sommer on Unsplash.

Critical Firefox vulnerability fixed in 67.0.3

On Friday, Mozilla issued a security advisory for Firefox, the default web browser in Fedora. This advisory concerns a CVE for a vulnerability based on type confusion that can happen when JavaScript objects are being manipulated. It can be used to crash your browser. There are apparently already attacks in the wild that exploit the issue. Read on for more information, and how to protect your system against this flaw.

At the same time the security vulnerability was issued, Mozilla also released Firefox 67.0.3 (and ESR 60.7.1) to fix the issue.

Updating Firefox in Fedora

Firefox 67.0.3 (with the security fixes) has already been pushed to the stable Fedora repositories. The security fix will be applied to your system with your next update. You can also update the firefox package only by running the following command:

$ sudo dnf update firefox

This command requires you to have sudo setup. Note that not every Fedora mirrors syncs at the same rate. Community sites graciously donate space and bandwidth these mirrors to carry Fedora content. You may need to try again later if your selected mirror is still awaiting the latest update.

Get the latest Ansible 2.8 in Fedora

Ansible is one of the most popular automation engines in the world. It lets you automate virtually anything, from setup of a local system to huge groups of platforms and apps. It’s cross platform, so you can use it with all sorts of operating systems. Read on for more information on how to get the latest Ansible in Fedora, some of its changes and improvements, and how to put it to use.

Releases and features

Ansible 2.8 was recently released with many fixes, features, and enhancements. It was available in Fedora mere days afterward as an official update in Fedora 29 and 30, as well as EPEL. The follow-on version 2.8.1 released two weeks ago. Again, the new release was available within a few days in Fedora.

Installation is, of course, easy to do from the official Fedora repositories using sudo:

$ sudo dnf -y install ansible

The 2.8 release has a long list of changes, and you can read them in the Porting Guide for 2.8. But they include some goodies, such as Python interpreter discovery. Ansible 2.8 now tries to figure out which Python is preferred by the platform it runs on. In cases where that fails, Ansible uses a fallback list. However, you can still use a variable ansible_python_interpreter to set the Python interpreter.

Another change makes Ansible more consistent across platforms. Since sudo is more exclusive to UNIX/Linux, and other platforms don’t have it, become is now used in more places. This includes command line switches. For example, –ask-sudo-pass has become –ask-become-pass, and the prompt is now BECOME password: instead.

There are many more features in the 2.8 and 2.8.1 releases. Do check out the official changelog on GitHub for all the details.

Using Ansible

Maybe you’re not sure if Ansible is something you could really use. Don’t worry, you might not be alone in thinking that, because it’s so powerful. But it turns out that it’s not hard to use it even for simple or individual setups like a home with a couple computers (or even just one!).

We covered this topic earlier in the Fedora magazine as well:

Give Ansible a try and see what you think. The great part about it is that Fedora stays quite up to date with the latest releases. Happy automating!


Personal assistant with Mycroft and Fedora

Looking for an open source personal assistant ? Mycroft is allowing you to run an open source service which gives you better control of your data.

Install Mycroft on Fedora

Mycroft is currently not available in the official package collection, but it can be easily installed from the project source. The first step is to download the source from Mycroft’s GitHub repository.

$ git clone

Mycroft is a Python application and the project provides a script that takes care of creating a virtual environment before installing Mycroft and its dependencies.

$ cd mycroft-core
$ ./

The installation script prompts the user to help him with the installation process. It is recommended to run the stable version and get automatic updates.

When prompted to install locally the Mimic text-to-speech engine, answer No. Since as described in the installation process this can take a long time and Mimic is available as an rpm package in Fedora so it can be installed using dnf.

$ sudo dnf install mimic

Starting Mycroft

After the installation is complete, the Mycroft services can be started using the following script.

$ ./ all

In order to start using Mycroft the device running the service needs to be registered. To do that an account is needed and can be created at

Once the account created, it is possible to add a new device at the following address Adding a new device requires a pairing code that will be spoken to you by your device after starting all the services.

The device is now ready to be used.

Using Mycroft

Mycroft provides a set of skills that are enabled by default or can be downloaded from the Marketplace. To start you can simply ask Mycroft how is doing, or what the weather is.

Hey Mycroft, how are you ?

Hey Mycroft, what's the weather like ?

If you are interested in how things works, the script provides a cli option that lets you interact with the services using the command line. It is also displaying logs which is really useful for debugging.

Mycroft is always trying to learn new skills, and there are many way to help by contributing the Mycroft community.

Photo by Przemyslaw Marczynski on Unsplash

Installing alternative versions of RPMs in Fedora

Modularity enables Fedora to provide alternative versions of RPM packages in the repositories. Several different applications, language runtimes, and tools are available in multiple versions, build natively for each Fedora release. 

The Fedora Magazine has already covered Modularity in Fedora 28 Server Edition about a year ago. Back then, it was just an optional repository with additional content, and as the title hints, only available to the Server Edition. A lot has changed since then, and now Modularity is a core part of the Fedora distribution. And some packages have moved to modules completely. At the time of writing — out of the 49,464 binary RPM packages in Fedora 30 — 1,119 (2.26%) come from a module (more about the numbers).

Modularity basics

Because having too many packages in multiple versions could feel overwhelming (and hard to manage), packages are grouped into modules that represent an application, a language runtime, or any other sensible group.

Modules often come in multiple streams — usually representing a major version of the software. Available in parallel, but only one stream of each module can be installed on a given system.

And not to overwhelm users with too many choices, each Fedora release comes with a set of defaults — so decisions only need to be made when desired.

Finally, to simplify installation, modules can be optionally installed using pre-defined profiles based on a use case. A database module, for example, could be installed as a client, a server, or both.

Modularity in practice

When you install an RPM package on your Fedora system, chances are it comes from a module stream. The reason why you might not have noticed is one of the core principles of Modularity — remaining invisible until there is a reason to know about it.

Let’s compare the following two situations. First, installing the popular i3 tiling window manager, and second, installing the minimalist dwm window manager:

$ sudo dnf install i3

As expected, the above command installs the i3 package and its dependencies on the system. Nothing else happened here. But what about the other one?

$ sudo dnf install dwm
Enabling module streams:
dwm 6.1

It feels the same, but something happened in the background — the default dwm module stream (6.1) got enabled, and the dwm package from the module got installed.

To be transparent, there is a message about the module auto-enablement in the output. But other than that, the user doesn’t need to know anything about Modularity in order to use their system the way they always did.

But what if they do? Let’s see how a different version of dwm could have been installed instead.

Use the following command to see what module streams are available:

$ sudo dnf module list
dwm latest ...
dwm 6.0 ...
dwm 6.1 [d] ...
dwm 6.2 ...
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

The output shows there are four streams of the dwm module, 6.1 being the default.

To install the dwm package in a different version — from the 6.2 stream for example — enable the stream and then install the package by using the two following commands:

$ sudo dnf module enable dwm:6.2
Enabling module streams:
dwm 6.2
$ sudo dnf install dwm

Finally, let’s have a look at profiles, with PostgreSQL as an example.

$ sudo dnf module list
postgresql 9.6 client, server ...
postgresql 10 client, server ...
postgresql 11 client, server ...

To install PostgreSQL 11 as a server, use the following command:

$ sudo dnf module install postgresql:11/server

Note that — apart from enabling — modules can be installed with a single command when a profile is specified.

It is possible to install multiple profiles at once. To add the client tools, use the following command:

$ sudo dnf module install postgresql:11/client

There are many other modules with multiple streams available to choose from. At the time of writing, there were 83 module streams in Fedora 30. That includes two versions of MariaDB, three versions of Node.js, two versions of Ruby, and many more.

Please refer to the official user documentation for Modularity for a complete set of commands including switching from one stream to another.


Applications for writing Markdown

Markdown is a lightweight markup language that is useful for adding formatting while still maintaining readability when viewing as plain text. Markdown (and Markdown derivatives) are used extensively as the priumary form of markup of documents on services like GitHub and pagure. By design, Markdown is easily created and edited in a text editor, however, there are a multitude of editors available that provide a formatted preview of Markdown markup, and / or provide a text editor that highlights the markdown syntax.

This article covers 3 desktop applications for Fedora Workstation that help out when editing Markdown.


UberWriter is a minimal Markdown editor and previewer that allows you to edit in text, and preview the rendered document.

The editor itself has inline previews built in, so text marked up as bold is displayed bold. The editor also provides inline previews for images, formulas, footnotes, and more. Ctrl-clicking one of these items in the markup provides an instant preview of that element to appear.

In addition to the editor features, UberWriter also features a full screen mode and a focus mode to help minimise distractions. Focus mode greys out all but the current paragraph to help you focus on that element in your document

Install UberWriter on Fedora from the 3rd-party Flathub repositories. It can be installed directly from the Software application after setting up your system to install from Flathub


Marker is a Markdown editor that provides a simple text editor to write Markdown in, and provides a live preview of the rendered document. The interface is designed with a split screen layout with the editor on the left, and the live preview on the right.

Additionally, Marker allows you to export you document in a range of different formats, including HTML, PDF, and the Open Document Format (ODF).

Install Marker on Fedora from the 3rd-party Flathub repositories. It can be installed directly from the Software application after setting up your system to install from Flathub


Where the previous editors are more focussed on a minimal user experice, Ghostwriter provides many more features and options to play with. Ghostwriter provides a text editor that is partially styled as you write in Markdown format. Bold text is bold, and headings are in a larger font to assist in writing the markup.

It also provides a split screen with a live updating preview of the rendered document.

Ghostwriter also includes a range of other features, including the ability to choose the Markdown flavour that the preview is rendered in, as well as the stylesheet used to render the preview too.

Additionally, it provides a format menu (and keyboard shortcuts) to insert some of the frequent markdown ‘tags’ like bold, bullets, and italics.

Install Ghostwriter on Fedora from the 3rd-party Flathub repositories. It can be installed directly from the Software application after setting up your system to install from Flathub


Contribute to Fedora Magazine

Do you want to share a piece of Fedora news for the general public? Have a good idea for how to do something using Fedora? Do you or someone you know use Fedora in an interesting way?

We’re always looking for new contributors to write awesome, relevant content. The Magazine is run by the Fedora community — and that’s all of us. You can help too! It’s really easy.Read on to find out how.


What content do we need?

Glad you asked. We often feature material for desktop users, since there are many of them out there! But that’s not all we publish. We want the Magazine to feature lots of different content for the general public.

Sysadmins and power users

We love to publish articles for system administrators and power users who dive under the hood. Here are some recent examples:


We don’t forget about developers, either. We want to help people use Fedora to build and make incredible things. Here are some recent articles focusing on developers:

Interviews, projects, and links

We also feature interviews with people using Fedora in interesting ways. We even link to other useful content about Fedora. We’ve run interviews recently with people using Fedora to increase security, administer infrastructure, or give back to the community. You can help here, too — it’s as simple as exchanging some email and working with our helpful staff.

How do I get started?

It’s easy to start writing for Fedora Magazine! You just need to have decent skill in written English, since that’s the language in which we publish. Our editors can help polish your work for maximum impact.

Follow this easy process to get involved.

The Magazine team will guide you through getting started. The team also hangs out on #fedora-mktg on Freenode. Drop by, and we can help you get started.

Image courtesy Dustin Lee – originally posted to Unsplash as Untitled


Tweaking the look of Fedora Workstation with themes

Changing the theme of a desktop environment is a common way to customize your daily experience with Fedora Workstation. This article discusses the 4 different types of visual themes you can change and how to change to a new theme. Additionally, this article will cover how to install new themes from both the Fedora repositories and 3rd party theme sources.

Theme Types

When changing the theme of Fedora Workstation, there are 4 different themes that can be changed independently of each other. This allows a user to mix and match the theme types to customize their desktop in a multitude of combinations. The 4 theme types are the Application (GTK) theme, the shell theme, the icon theme, and the cursor theme.

Application (GTK) themes

As the name suggests, Application themes change the styling of the applications that are displayed on a user’s desktop. Application themes control the style of the window borders and the window titlebar. Additionally, they also control the style of the widgets in the windows — like dropdowns, text inputs, and buttons. One point to note is that an application theme does not change the icons that are displayed in an application — this is achieved using the icon theme.

Two application windows with two different application themes. The default Adwaita theme on the left, the Adapta theme on the right.

Application themes are also known as GTK themes, as GTK (GIMP Toolkit) is the underlying technology that is used to render the windows and user interface widgets in those windows on Fedora Workstation.

Shell Themes

Shell themes change the appearance of the GNOME Shell. The GNOME Shell is the technology that displays the top bar (and the associated widgets like drop downs), as well as the overview screen and the applications list it contains.

Comparison of two Shell themes, with the Fedora Workstation default on top, and the Adapta shell theme on the bottom.

Icon Themes

As the name suggests, icon themes change the icons used in the desktop. Changing the icon theme will change the icons displayed both in the Shell, and in applications.

Comparison of two icon themes, with the Fedora 30 Workstation default Adwaita on the left, and the Yaru icon theme on the right

One important item to note with icon themes is that all icon themes will not have customized icons for all application icons. Consequently, changing the icon theme will not change all the icons in the applications list in the overview.

Comparison of two icon themes, with the Fedora 30 Workstation default Adwaita on the top, and the Yaru icon theme on the bottom

Cursor Theme

The cursor theme allows a user to change how the mouse pointer is displayed. Most cursor themes change all the common cursors, including the pointer, drag handles and the loading cursor.

Comparison of multiple cursors of two different cursor themes. Fedora 30 default is on the left, the Breeze Snow theme on the right.

Changing the themes

Changing themes on Fedora Workstation is a simple process. To change all 4 types of themes, use the Tweaks application. Tweaks is a tool used to change a range of different options in Fedora Workstation. It is not installed by default, and is installed using the Software application:

Alternatively, install Tweaks from the command line with the command:

sudo dnf install gnome-tweak-tool

In addition to Tweaks, to change the Shell theme, the User Themes GNOME Shell Extension needs to be installed and enabled. Check out this post for more details on installing extensions.

Next, launch Tweaks, and switch to the Appearance pane. The Themes section in the Appearance pane allows the changing of the multiple theme types. Simply choose the theme from the dropdown, and the new theme will apply automatically.

Installing themes

Armed with the knowledge of the types of themes, and how to change themes, it is time to install some themes. Broadly speaking, there are two ways to install new themes to your Fedora Workstation — installing theme packages from the Fedora repositories, or manually installing a theme. One point to note when installing themes, is that you may need to close and re-open the Tweaks application to make a newly installed theme appear in the dropdowns.

Installing from the Fedora repositories

The Fedora repositories contain a small selection of additional themes that once installed are available to we chosen in Tweaks. Theme packages are not available in the Software application, and have to be searched for and installed via the command line. Most theme packages have a consistent naming structure, so listing available themes is pretty easy.

To find Application (GTK) themes use the command:

dnf search gtk | grep theme

To find Shell themes:

dnf search shell-theme

Icon themes:

dnf search icon-theme

Cursor themes:

dnf search cursor-theme

Once you have found a theme to install, install the theme using dnf. For example:

sudo dnf install numix-gtk-theme

Installing themes manually

For a wider range of themes, there are a plethora of places on the internet to find new themes to use on Fedora Workstation. Two popular places to find themes are OpenDesktop and GNOMELook.

Typically when downloading themes from these sites, the themes are encapsulated in an archive like a tar.gz or zip file. In most cases, to install these themes, simply extract the contents into the correct directory, and the theme will appear in Tweaks. Note too, that themes can be installed either globally (must be done using sudo) so all users on the system can use them, or can be installed just for the current user.

For Application (GTK) themes, and GNOME Shell themes, extract the archive to the .themes/ directory in your home directory. To install for all users, extract to /usr/share/themes/

For Icon and Cursor themes, extract the archive to the .icons/ directory in your home directory. To install for all users, extract to /usr/share/icons/