Fedora People

SSL: How It Works and Why It Matters

Posted by Farhaan Bukhsh on May 23, 2024 02:46 PM

How did it start?

I have been curious about what an SSL Certificate is and how it works. This is a newbie's log on the path to understanding a thing or two about how it works.

We casually talk about security and how SSL certificates should be used to make your website more secure. In this blog, I am documenting my learnings, and the end goal for me here is to see if I can enable an SSL certificate (sshh... it's called a TLS Certificate since SSL is long deprecated) on a server locally. Why?

This end goal will help me with a few problems that I face day to day and help me dive deeper to understand the magic.

The Need ...

Why do we need an SSL certificate and what does it certify? The obvious answer found all over the internet is that obtaining an SSL certificate guarantees that any connection made to the website is secure.

Okay! But how?

This is the most interesting part. A superficial answer is that a website or application with an SSL certificate means that any data transfer between the client and server will happen over HTTPS (HTTP over SSL/TLS), so the data will be encrypted, making the transfer more secure.

This explanation raises more questions.

Where is the encryption happening? How is the encryption happening? Is encryption the sole reason we are using HTTPS?

How is this working?

To investigate the working I started banking on what I know with my experience with SSL certificates. I have used Let's Encrypt to obtain and use SSL certificates hence I started working backwards.

An SSL certificate also shows the public that you are who you say you are. To achieve this, we need a Certificate Authority (CA) that has verified the entity and is publicly trusted.

When we install certbot and try to obtain a certificate it:

  1. Generate a private key.

  2. Generate a public key.

  3. Generate a CSR(Certificate Signing Request) and send the CSR to the Certificate Authority(CA).

On receiving the CSR the CA will verify the user, domain etc. and if all goes well it will issue a certificate to the user/domain.

Now, let's try to understand what exactly a certificate is.

A certificate is a file or document that contains the issuer's information, the issuer's public key, and a signature.

The signature is a crucial part of the document because it is used by entities to verify the authenticity of the certificate.

A signature is the checksum of the certificate, calculated using the provided algorithm and then encrypted by the issuer's private key.

Note: For messages, the public key is used to encrypt and the private key is used to decrypt. For signatures, it works the opposite way.

Now that we have obtained a certificate, our CA authenticates the connection by checking the signature.

The question that puzzled me was: how does my machine trust any of these connections, and will there be a lot of back-and-forth to establish a single HTTPS connection?

This brought me to an understanding that each operating system and browser does ship a bunch of public keys for Root Certificate Authority. The Root CA certifies the intermediate CA's like Let's Encrypt and there is a chain of trust that gets verified on each connection.

Root CA and Intermediate CA comparison

Hence, the chain of trust is followed and then Root CA Signature gets verified using the public key that is shipped with the Operating System or browser. On Ubuntu, the certificates can be found in /etc/ssl/certs.


Now, that we have an understanding of how security is promised(Not guaranteed) on an HTTPS connection, we can reverse-engineer a few concepts to generate a certificate and force OS/browser to support the certificate.

Generating a Local (Self Signed) Certificate

Various resources will help you generate a self-signed certificate, the ones that I can vouch for are this GitHub gist and the article from Lets Encrypt.

First, we need to generate Root Certificate, Root Primary key and Public Key.

openssl req -x509 -nodes -new -sha256 -days 1024 -newkey rsa:2048 -keyout RootCA.key -out RootCA.pem -subj "/C=US/CN=Farhaan-Root-CA"

After this you should have 3 files in your directory:

Root CA Files

Now we need to have an ext file which has all information about the domain I want the certificate for i.e SAN information:

authorityKeyIdentifier=keyid,issuerbasicConstraints=CA:FALSEkeyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEnciphermentsubjectAltName = @alt_names[alt_names]DNS.1 = localhostDNS.2 = farhaan.localDNS.3 = farhaan.bukhsh.local

I created a file called farhaan.ext to achieve the same.

Now I need to file a CSR for the domain and generate the private-public key and then sign it with a Root CA.

openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=IN/ST=YourState/L=YourCity/O=Example-Certificates/CN=farhaan.local"

The above command will give me a private key for the localhost and a Certificate Signing Request file which we can use to generate an SSL Certificate.

and then we run

openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile farhaan.ext -out localhost.crt

This gives us the localhost.crt file which is the SSL certificate.


Let's Serve


You can see I am serving the local file on a HTTPS connection. There are a few things that needs to be done, I had a simple pyhton 3 server written and borrowed from here.

from http.server import HTTPServer, SimpleHTTPRequestHandlerimport sslfrom pathlib import Pathport = 4443httpd = HTTPServer(("localhost", port), SimpleHTTPRequestHandler)ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)ssl_context.load_cert_chain(Path(__file__).parent / "server.pem")httpd.socket = ssl_context.wrap_socket(    httpd.socket,    server_side=True,)print(f"Serving on https://localhost:{port}")httpd.serve_forever()

after that I need to modify my /etc/hosts file on Ubuntu to support farhaan.local .


This is so that farhaan.local redirects to localhost and done. After this we need to make sure Firefox recognizes this so we need to go under `about:preferences` > Privacy & Security > Certificates > View Certificate > import. Here import the RootCA.crt. Now we can visit https://farhaan.local:4443.

We can see that this is an HTTPS connection.


Here is the certificate:



I got to learn about a bunch of things about SSL, Security, etc. while writing this blog. Let me know if you have any clarification or any improvements. Thanks for reading and happy hacking!

Live Migration: setup

Posted by pjp on May 23, 2024 12:12 PM

While debugging a QEMU live migration related issue, I learned a setup to live migrate a virtual machine (VM) across two host machines. Migration here means to move a VM from one host machine to another. And live migration is, while a VM is running on the source machine, its state is copied to the destination machine, and once this copying is done, VM stops on the source machine and starts running on the destination machine. Applications running inside the VM are suppose to run as before, as if nothing changed.

Migrating a VM from one machine to another would entail moving its disk image and xml files as well. But copying (rsync(1)) files across machines could take long time, depending on file size and network bandwidth.

f39vm.qcow2  107.39G  100%  334.82MB/s  0:05:05
r91vm.qcow2   42.96G  100%  111.88MB/s  0:06:06
r93vm.qcow2   21.48G  100%  242.79MB/s  0:01:24

It is not feasible to stall a VM for such long times during migration. So migration requires that the source and destination machines are connected by a reliable high bandwidth network channel and the VM disk files are accessed on both machines via shared storage system. Accordingly, the source host machine is turned into a NFS server and destination machine is made NFS client:

source)# dnf install nfs-utils
source)# systemctl enable nfs-server
source)# systemctl enable rpcbind
source)# echo '/home/images 10.x.x.0/24(rw)' > /etc/exports
source)# mount -t nfs source.host.machine.com:/home/images/ /mnt/images/

destin)# dnf install nfs-utils
destin)# systemctl enable nfs-server
destin)# systemctl enable rpcbind
destin)# virsh pool-create-as --name=migrate \
--type=netfs --source-host=source.host.machine.com \
--source-path='/home/images' --source-format=nfs \

The VM xml configuration file should access the disk image via /mnt/images path as

<disk type='file' device='disk'>
  <source file='/mnt/images/r93vm.qcow2' index='1'/>

If the NFS setup is incorrect, migrate command may throw errors like these:

error: Unsafe migration: Migration without shared storage is unsafe

Once NFS server & client setup is done, try to start the VM on both machines to confirm that it is working, before trying the migration.

source)# virsh start --console r93vm

When VM runs on both machines, we can try the migration between two machines with

# cat migrate-test.sh 

if [ $# -lt 2 ]; then
    echo "Usage: $0 <guest> <destination-host>"
    exit 1;

while true;
    ds=$(virsh domstate $GUEST | sed -ne '1p')
    if [ "$ds" == "running" ]; then
        id=$(virsh domid $GUEST | sed -ne '1p')
        echo -n "migrate $GUEST.........$id"
        sleep 3s
        /bin/virsh migrate --verbose --persistent \
            --timeout 3 --timeout-postcopy \
            --live --postcopy  \
            $GUEST  qemu+ssh://$DHOST/system
    sleep 3s
exit 0;

This script live migrates a VM between source and destination machines in an infinite loop using the postcopy method of migration. Next we’ll see more about these migration methods.

New badge: DevConf.cz 2025 Attendee !

Posted by Fedora Badges on May 23, 2024 07:17 AM
DevConf.cz 2025 AttendeeYou attended the 2025 iteration of DevConf.cz, a yearly open source conference in Czechia!

New badge: DevConf.cz 2024 Attendee !

Posted by Fedora Badges on May 23, 2024 07:15 AM
DevConf.cz 2024 AttendeeYou attended the 2024 iteration of DevConf.cz, a yearly open source conference in Czechia!

New badge: Let's have a party (Fedora 40) !

Posted by Fedora Badges on May 23, 2024 07:09 AM
LetYou attended the F40 Online Release Party!

Introducing the WebKit Container SDK

Posted by Patrick Griffis on May 23, 2024 04:00 AM

Developing WebKitGTK and WPE has always had challenges such as the amount of dependencies or it’s fairly complex C++ codebase which not all compiler versions handle well. To help with this we’ve made a new SDK to make it easier.

Current Solutions

There have always been multiple ways to build WebKit and its dependencies on your host however this was never a great developer experience. Only very specific hosts could be “supported”, you often had to build a large number of dependencies, and the end result wasn’t very reproducable for others.

The current solution used by default is a Flatpak based one. This was a big improvement for ease of use and excellent for reproducablity but it introduced many challenges doing development work. As it has a strict sandbox and provides read-only runtimes it was difficult to use complex tooling/IDEs or develop third party libraries in it.

The new SDK tries to take a middle ground between those two alternatives, isolating itself from the host to be somewhat reproducable, yet being a mutable environment to be flexible enough for a wide range of tools and workflows.

The WebKit Container SDK

At the core it is an Ubuntu OCI image with all of the dependencies and tooling needed to work on WebKit. On top of this we added some scripts to run/manage these containers with podman and aid in developing inside of the container. It’s intention is to be as simple as possible and not change traditional development workflows.

You can find the SDK and follow the quickstart guide on our GitHub: https://github.com/Igalia/webkit-container-sdk

The main requirements is that this only works on Linux with podman 4.0+ installed. For example Ubuntu 23.10+.

In the most simple case, once you clone https://github.com/Igalia/webkit-container-sdk.git, using the SDK can be a few commands:

source /your/path/to/webkit-container-sdk/register-sdk-on-host.sh
wkdev-create --create-home

From there you can use WebKit’s build scripts (./Tools/Scripts/build-webkit --gtk) or CMake. As mentioned before it is an Ubuntu installation so you can easily install your favorite tools directly like VSCode. We even provide a wkdev-setup-vscode script to automate that.

Advanced Usage


A workflow that some developers may not be familiar with is making use of entirely disposable development environments. Since these are isolated containers you can easily make two. This allows you to do work in parallel that would interfere with eachother while not worrying about it as well as being able to get back to a known good state easily:

wkdev-create --name=playground1
wkdev-create --name=playground2

podman rm playground1 # You would stop first if running.
wkdev-enter --name=playground2

Working on Dependencies

An important part of WebKit development is working on the dependencies of WebKit rather than itself, either for debugging or for new features. This can be difficult or error-prone with previous solutions. In order to make this easier we use a project called JHBuild which isn’t new but works well with containers and is a simple solution to work on our core dependencies.

Here is an example workflow working on GLib:

wkdev-create --name=glib
wkdev-enter --name=glib

# This will clone glib main, build, and install it for us. 
jhbuild build glib

# At this point you could simply test if a bug was fixed in a different versin of glib.
# We can also modify and debug glib directly. All of the projects are cloned into ~/checkout.
cd ~/checkout/glib

# Modify the source however you wish then install your new version.
jhbuild make

Remember that containers are isoated from each other so you can even have two terminals open with different builds of glib. This can also be used to test projects like Epiphany against your build of WebKit if you install it into the JHBUILD_PREFIX.

To Be Continued

In the next blog post I’ll document how to use VSCode inside of the SDK for debugging and development.

Quectel EM05-G (LTE module) with ThinkPad T14 Gen4 on Fedora 39 and 40

Posted by Andreas Haerter on May 23, 2024 01:46 AM

We recently bought a bunch of Lenovo ThinkPad T14 Gen4 Model 21HDCTO1WW. They were shipped with a Quectel EM05-G WWAN module. To our surprise, ModemManager did not activate the module right away even though the Fedora Linux support for the hardware is known to be good. It turned out that our hardware revision reports with a different USB device ID 2c7c:0313 than previous versions which used 2c7c:030a:

Bus 003 Device 002: ID 2c7c:0313 Quectel Wireless Solutions Co., Ltd. Quectel EM05-G

Therefore, the necessary FCC unlock procedure does not get triggered automatically even though an unlock script for the Quectel EM05-G was already added by Leah Oswald. However, the modem works perfectly fine if you unlock it manually after each reboot:

mmcli -L
sudo mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on

We have opened an upstream issue to fix the problem. If you don’t want to wait so long until a new ModemManager version including the fix arrives on your computer, you can help yourself as follows:

sudo mkdir -p "/etc/ModemManager/fcc-unlock.d/"
sudo chown root:root -R "/etc/ModemManager/"
sudo find "/etc/ModemManager/" -type d -exec chmod 0755 {} +
sudo find "/etc/ModemManager/" -type f -exec chmod 0644 {} +
sudo ln -s -f "/usr/share/ModemManager/fcc-unlock.available.d/2c7c" "/etc/ModemManager/fcc-unlock.d/2c7c:0313"

This creates a symlink to the working FCC unlock script 2c7c for the new USB device ID 2c7c:0313 in your local configuration. Hope that helps.

Please use GPLv3 “or-later” instead of “only”

Posted by Andreas Haerter on May 23, 2024 12:25 AM

It makes sense to prefer copyleft licenses. The most popular copyleft license is probably the GNU General Public License (GPL), with Version 3 from 2007 being the latest one. When you use the GPLv3, you have to decide if you go for “GPL v3.0 or later” or “GPL v3.0 only”. This is because of Clause 14 “Revised Versions of this License” of the GPLv3.1

The clause addresses how future versions of the license will be handled and state that the Free Software Foundation (FSF) may publish new versions of the GPL, which will be similar in spirit to the current version but may include changes to address new legal and technological issues. This also ensures the protection of Free Software from potential missteps by the Free Software Foundation (FSF) itself as, for example, no one could state a valid GPLv4 without copyleft. Some argue that the GPLv3 is fundamentally different from the GPLv2, but a detailed examination shows this is not the case–it is indeed similar in spirit. Just read it for yourself. For our part, we therefore strongly recommend choosing the “or later” option for our own projects.

Learn from past mistakes

Using GPL-2.0-only in the past created significant compatibility issues with other licenses, hindering the integration and distribution of combined works. For example, software licensed under GPL-2.0-only is incompatible with the Apache-2.0 license, preventing the combination of many codebases even today. And some projects had to spend a lot of time and work to change licensing to achieve better license compatibility and reduce integration barriers. These issues can lead to fragmentation and reduced flexibility in the open-source ecosystem.

GPLv2 showed that this adaptability might be necessary, as sticking to GPL-2.0-only did not provide any significant benefit and led to compatibility problems. Therefore, it makes sense to adopt the “or later” option whenever possible. This approach not only preserves the spirit of the license but also provides a safeguard against potential future challenges, much like a well-prepared contingency plan.


The “or later” clause of GPL-3.0-or-later is crucial as it allows the evolution of the license to keep up with changing circumstances, ensuring ongoing protection and freedom for software users and developers. This clause is like a safety net that allows us to adapt to future changes in the legal and technological landscape and to enable cooperation from various parties in the future. Use it.

  1. It is the same with Clause 9 of GPLv2↩︎

mostly unknown keepalived feature

Posted by Jens Kuehnel on May 22, 2024 08:15 PM

There are lot of introduction to keepalived. Like Setting up a Linux cluster with Keepalived: Basic configuration | Enable Sysadmin (redhat.com) or Keepalived and high availability: Advanced topics | Enable Sysadmin (redhat.com)

But I recently learned that keepalived has a cool feature that makes writing keepalived much easier (Thanks Spindy). Almost all documentation found on the net shows you that you need two different configuration files. But this is not the case. There is an extension that allows you to rollout the same configuration for all nodes.

When you compare this example from the first links. They use this two configurations:

server1# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
        state MASTER
        interface eth0
        virtual_router_id 51
        priority 255
        advert_int 1
        authentication {
              auth_type PASS
              auth_pass 12345
        virtual_ipaddress {
server2# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        virtual_router_id 51
        priority 254
        advert_int 1
        authentication {
              auth_type PASS
              auth_pass 12345
        virtual_ipaddress {

When you look at it its almost the same file – only 2 lines are different, state and priority. Here comes the @format into play. You can rollout this file on both side and it will work the same way as above:

# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
        @server1 state MASTER
        @server2 state BACKUP
        interface eth0
        virtual_router_id 51
        @server1 priority 255
        @server2 priority 254
        advert_int 1
        authentication {
              auth_type PASS
              auth_pass 12345
        virtual_ipaddress {

So you can configure lines that are only valid for certain hosts by adding a @HOSTNAME in front. More possibilities are explained in the man page keepalived.conf(5) in the section “Conditional configuration and configuration id”

syslog-ng Prometheus exporter

Posted by Peter Czanik on May 22, 2024 11:08 AM

Prometheus is an open-source monitoring system that collects metrics from your hosts and applications, allowing you to visualize and alert on them. The syslog-ng Prometheus exporter allows you to export syslog-ng statistics, so that Prometheus can collect it.

While an implementation in Go has been available for years on GitHub (for more information, see this blog entry), that solution uses the old syslog-ng statistics interface. And while that Go-based implementation still works, syslog-ng 4.1 introduced a new interface that provides not just more information than the previous statistics interface, but does so in a Prometheus-friendly format. The information available through the new interface has been growing ever since.

The syslog-ng Prometheus exporter is implemented in Python. It also uses the new statistics interface, making new fields automatically available when added.

Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-prometheus-exporter


syslog-ng logo

</figcaption> </figure>

Upgrade of Copr servers

Posted by Fedora Infrastructure Status on May 22, 2024 09:00 AM

We're updating copr packages to the new versions which will bring new features and bugfixes.

This outage impacts the copr-frontend and the copr-backend.

Contribute at the Podman 5.1 and Kernel 6.9 Test Week

Posted by Fedora Magazine on May 21, 2024 05:06 PM

Fedora test days are events where anyone can help make certain that changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. This is a perfect way to start contributing to Fedora, if you haven’t in the past.

There are two upcoming test periods in the next two weeks covering two topics:

  • Thursday 23 May, is to test the Podman 5.1
  • Sunday 26 May through Monday 03 June, is to test Kernel 6.9

Podman 5.1 Test Day

Podman is a daemon-less, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCIContainers and Container Images. It provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine. As part of a recent discussion, the Rawhide Test Day efforts, and Podman Container Engine Team’s collaborative efforts, we will hold a test day for a minor Podman Release.

During this test day, on Thursday 23 May, the focus will be on testing the changes that will be coming in Fedora 41 (Rawhide) as we move ahead with Podman 5.1. This test day is an opportunity for anyone to learn and interact with the Podman Community and container tools in general.

The wiki page helps the testers know and understand the scope of the test day. The Test day app helps the testers submit the results once they have tried the test cases.

Kernel 6.9 Test Week

The kernel team is working on final integration for Linux kernel 6.9. This recently released kernel version will arrive soon in Fedora Linux. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday, May 26, 2024 to Monday, June 03, 2024.

The wiki page contains links to the test images you’ll need to participate. The results can be submitted in the test day app.

How do test days work?

A test day/week is an event where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about all the test days is available on the wiki pages mentioned above. If you’re available on or around the days of the events, please do some testing and report your results. All the test day pages receive some final touches which complete about 24 hrs before the test day begins. We urge you to be patient about resources that are, in most cases, uploaded hours before the test day starts.

Come and test with us to make the upcoming Fedora Linux 41 even better

Fedora Linux 38 s'en va

Posted by Charles-Antoine Couret on May 20, 2024 10:00 PM

C'est en ce mardi 21 mai 2024 que la maintenance de Fedora Linux 38 prend fin.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora Linux 40, la version n-2 (donc Fedora Linux 38) n'est plus maintenue.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora Linux 38 et antérieurs d'effectuer la mise à niveau vers Fedora Linux 40 ou 39.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora Linux 40 ou 39. N'hésitez pas à lancer la mise à niveau par ce biais.

Kiwi TCMS 13.3

Posted by Kiwi TCMS on May 20, 2024 01:15 PM

We're happy to announce Kiwi TCMS version 13.3!

IMPORTANT: This is a small release which contains several improvements, bug fixes, internal refactoring and updated translations!

Recommended upgrade path:

13.2 -> 13.3

You can explore everything at https://public.tenant.kiwitcms.org!


Upstream container images (x86_64):

kiwitcms/kiwi   latest  c43a47e388ab    675MB

IMPORTANT: version tagged and multi-arch container images are available only to subscribers!

Changes since Kiwi TCMS 13.2


  • Update Django from 4.2.11 to 4.2.12
  • Update psycopg from 3.1.18 to 3.1.19
  • Update PyGithub from 1.58.2 to 2.3.0
  • Update pygments from 2.17.2 to 2.18.0
  • Update python-gitlab from 4.4.0 to 4.5.0
  • Replace more inline style= HTML attributes with CSS classes

Bug fixes

  • Truncate TestCase.text length for Jira 1-click bug reports to avoid 400, 414 and/or 500 errors! Text will be truncated to 30k chars for automated POST requests and 6k chars for fallback GET requests to fit inside Jira limitations

Refactoring and testing

  • Remove double slash in Jira fallback URL
  • Stop using the Github(login_or_token) argument b/c it is deprecated
  • Update selenium from 4.20.0 to 4.21.0

Kiwi TCMS Enterprise v13.3-mt

  • Based on Kiwi TCMS v13.3
  • Update kiwitcms-github-app from 1.6.0 to 1.7.0
  • Update sentry-sdk from 2.0.1 to 2.2.0
  • Preserve /static/ca.crt file inside the container

Private container images

quay.io/kiwitcms/version            13.3 (aarch64)          0f9f70835859    20 May 2024     686MB
quay.io/kiwitcms/version            13.3 (x86_64)           c43a47e388ab    20 May 2024     675MB
quay.io/kiwitcms/enterprise         13.3-mt (aarch64)       40d0769bc640    20 May 2024     1.05GB
quay.io/kiwitcms/enterprise         13.3-mt (x86_64)        ea3d8e8999f4    20 May 2024     1.03GB

IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!

How to upgrade

Backup first! Then follow the Upgrading instructions from our documentation.

Happy testing!


If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!

Fedora 40 Release Party in Prague

Posted by Jiri Eischmann on May 20, 2024 11:08 AM

Last Friday I organized a Fedora 40 release party in Prague. A month ago I got a message from Karel Ziegler of Etnetera Core if we could do a Fedora release party in Prague again. Etnetera Core is a mid-sized company that does custom software development and uses Red Hat technologies. They have a really cool office in Prague which we used as a venue for release parties several times in pre-covid times.

We got a bit unlucky with the date this time. It was really terrible weather in Prague on Friday. It was pouring outside. Moreover the Ice Hockey World Championship is taking place in Prague now and the Czech team played against Austria at the time of the release party. These two things contributed to the less than expected attendance. But in the end roughly 15 people showed up.

<figure class="wp-block-image aligncenter size-large">A round table with Fedora swag.<figcaption class="wp-element-caption">Fedora swag for party attendees.</figcaption></figure>

The talk part was really interesting. In the end it took almost 4 hours because there was a lot of discussion. The first talk was mine, traditionally on Fedora Workstation that switched to a long discussion about Distrobox vs Toolbx. As a result of that Luboš Kocman of SUSE got interested in Ptyxis saying that it’s something they may actually adopt, too.

<figure class="wp-block-image size-large">Lukáš Kotek on stage.<figcaption class="wp-element-caption">Lukáš Kotek talking about his legacy computing machine.</figcaption></figure>

The second talk was delivered by Lukáš Kotek who talked about building a retro-gaming machine based on Fedora and Atomic Pi. Several people asked us to provide his slides online, so here they are:

<object aria-label="Embed of kotek-fedora-legacy-computing." class="wp-block-file__embed" data="https://enblog.eischmann.cz/wp-content/uploads/2024/05/kotek-fedora-legacy-computing.pdf" data-wp-bind--hidden="!state.hasPdfPreview" style="width:100%;height:600px" type="application/pdf"></object>kotek-fedora-legacy-computingDownload

The third talk was delivered by Karel Ziegler who spoke on the new release of his favorite desktop environment – Plasma 6. The last talk was supposed to be delivered by Ondřej Kolín, but at the beginning of the party we were not sure if he’d make it because he was travelling from Berlin and was stuck in Friday traffic. The first three talks took so long due to interesting discussions that Ondřej arrived just on time for his talk.

He spoke about his experience building a simple app and distributing it on Flathub. This again started an interesting discussion about new and traditional models of Linux app distribution.

In the middle of the party we were joined by Andre Klapper, a long-time GNOME contributor living in Prague, and Keywan Tonekaboni, a German open source journalist who is currently on his holidays travelling on trains around the Czech Republic. We found out that we were taking the same train to Brno next day, so on Saturday we had another two hours for Linux software topics. 🙂

I’d like to thank the Fedora Project for sponsoring my travel to Prague to organize the event and also big thanks to Etnetera Core for providing just perfect venue for the party and sponsoring refreshment (They even had a beer tap!) and the party cake.

<figure class="wp-block-image aligncenter size-medium">Fedora 40 cake<figcaption class="wp-element-caption">Fedora 40 cake.</figcaption></figure>

Week 20 update

Posted by Ankur Sinha "FranciscoD" on May 20, 2024 10:47 AM

Open Source Brain

Open Source Brain (OSB) is a web platform for neuroscientists. Version 1 was focussed on the sharing and archival of biophysically detailed models, standardised in NeuroML. There are a number of published models on the platform that one can visualise and study there already:

A screenshot of Open Source Brain version 1.

A screenshot of Open Source Brain version 1.

The newer version, version 2 takes it a step further. Its goal is to be a cloud based integrated research environment where people can store their data and their code in "workspaces", and work in the cloud, requesting as many resources as they need. This means that people no longer have to set up their own computers/lab servers---the platform will provide the computing infrastructure and the required tools in a web browser. OSBv2 also indexes a number of data sources to make it easier for researchers to find data and models, such as:

A screenshot of Open Source Brain version 2.

A screenshot of Open Source Brain version 2.

OSBv2 also integrates a number of web applications for users:

We're working on integrating biosimulations.org as another data source now. This requires adding an adapter to the back end that understands the biosimulations.org API so that it can use it to pull information from there to index. An initial version has already been implemented. We now need to test it.

OSBv2: dev environment

Since OSBv2 is cloud based (currently deployed on Google Cloud), it makes use of containers and Kubernetes (our software partners, MetaCell manage our infrastructure and a majority of the development/maintenance of OSB). The complete platform is also broken down into a number of services. To test changes and develop, therefore, one has to run a local deployment. We've documented the steps in our readme, and I've got a script to automate the various steps.

Of course, it's never that simple. While my script had worked the last time I had tinkered with OSBv2, it didn't work last week and I spent hours trying to figure out why. I need to continue with that this week too.

Software Working Group

The Software Working Group is an open community working group about all things software. It's shared by the International Neuroinformatics Co-ordinating Facility and the Organization for Computational Neuroscience. The idea is simply to have a community for exchange of ideas related to research/neuroscience software development. The working group is based on GitHub, and open to anyone at all.

Last week, we had a session on SpikeInterface where Pierre Yger presented the tool to the community. It was recorded, and the recordings should be on the INCF YouTube channel soon.


I worked on a few Neuro SIG packages--updates, Fails to Build From Source (FTBFS) issues, and so on. Not much to report in detail here.

Launch Fedora 40 in Microsoft Azure

Posted by Fedora Magazine on May 20, 2024 08:00 AM

In Fedora 40, Cloud images for Microsoft Azure are directly available in Azure via its new Community Gallery feature. This article will describe how to use these.


Starting in Fedora 39, the Fedora Project began producing Cloud images for Microsoft Azure which could be manually uploaded to an Azure tenant. In Fedora 40, these images are available directly in Azure via its new Community Gallery feature.

To use Microsoft Azure, you will need a Microsoft account. New users get 12 months of several services free, including virtual machines, so you can try everything covered in this article without needing to pay for anything. These virtual machines have 1-2 vCPUs and 1 GiB of RAM, which is enough for development or testing, low traffic web servers, small databases, etc.

Using the web portal

To get started, go to the Community images service in the Azure Portal. Add a filter on Public gallery names and select Fedora’s public gallery name, Fedora-5e266ba4-2250-406d-adad-5d73860d958f.

<figure class="wp-block-image size-large"></figure>

Select a Fedora 40 x64 image in a location near you, then click Create VM.

<figure class="wp-block-image size-large"></figure>

Alternatively, you can go to the The Fedora Project’s Cloud section, click Launch in public cloud, and select the Azure region to jump directly to the Create VM blade.

Configure the VM

Click Create new under the Resource group field. Resource groups are buckets of arbitrary resources (virtual machines, storage accounts, public IP addresses, etc.) which are related. Next, give your virtual machine a name. The name you choose becomes the host name as well as the virtual machine resource name in Azure. After that, you should set the virtual machine size. Click See all sizes and type “B2ats_v2” into the search bar, click on the only result, and click Select at the bottom of your screen.

<figure class="wp-block-image size-large"></figure>

Finally, click Review + create at the bottom of your screen, and then click Create.

Download the SSH key it generates for you. Afterwards, you will be taken to a page where you can see your resources being created. Once they’ve all completed, click on Go to resource. This will take you to the overview page for your new virtual machine running Fedora 40. Under Essentials you’ll find the public IP address assigned to your instance which you can use to SSH to the virtual machine.

<figure class="wp-block-image size-large"></figure>

Open a terminal, ensure the SSH key you downloaded has proper permissions, and log in to your new machine:

chmod 600 ~/Downloads/<key name>
ssh -i ~/Downloads/<key name> azureuser@<pubic IP address>
<figure class="wp-block-image size-large"></figure>

Finally, if you decide you don’t need the machine anymore, you can clean everything up by deleting the resource group. From the virtual machine overview page, click on the resource group name you created under Essentials, then click Delete resource group and confirm you want to delete it. Everything you created in the resource group is destroyed with it.

Launch a virtual machine via azure-cli

You may prefer to manage your resources from the command line. The downside of the CLI is it doesn’t guide you through all the options available. The upside is that, if you know what you want, it’s much quicker than clicking through all the options available. This section covers using the CLI to create the exact same virtual machine as the first section.


Install the Azure command-line interface and log in:

sudo dnf install azure-cli
az login

Find the Image ID

We need the Fedora 40 image ID in Microsoft Azure to launch the virtual machine from the CLI. Each Fedora release has an image definition for each hardware architecture. Each image definition contains one or more image versions. We add new image versions with the latest updates on a regular basis.

First, list all available image definitions in Fedora’s public gallery:

az sig image-definition list-community --public-gallery-name Fedora-5e266ba4-2250-406d-adad-5d73860d958f --location eastus --query '[].name'

Optionally, you can list the versions available using an image definition’s name:

az sig image-version list-community --public-gallery-name Fedora-5e266ba4-2250-406d-adad-5d73860d958f --gallery-image-definition "Fedora-Cloud-40-x64" --location eastus --query '[?!excludeFromLatest].uniqueId'

Typically, you should use the latest available version of an image definition, which you can reference by replacing the version number in the image version’s uniqueId with latest. For example, the image ID for the latest x86_64 Fedora 40 image is /CommunityGalleries/Fedora-5e266ba4-2250-406d-adad-5d73860d958f/Images/Fedora-Cloud-40-x64/Versions/latest.

Create the VM

Begin by creating the resource group:

az group create --location eastus --resource-group fedora-in-azure

Next, create the virtual machine using the image ID we found:

az vm create --location eastus --name fedora40 --resource-group fedora-in-azure --image /CommunityGalleries/Fedora-5e266ba4-2250-406d-adad-5d73860d958f/Images/Fedora-Cloud-40-x64/Versions/latest --size Standard_B2ats_v2 --security-type TrustedLaunch --generate-ssh-keys

Finally, you can delete everything with:

az group delete --resource-group fedora-in-azure


We have covered the basics for creating Fedora virtual machines in Microsoft Azure. For more in-depth coverage of virtual machine features you can refer to the virtual machine documentation for Azure. The Azure CLI documentation is also available online.

Next Open NeuroFedora meeting: 20 May 1300 UTC

Posted by The NeuroFedora Blog on May 20, 2024 07:26 AM
Photo by William White on Unsplash

Photo by William White on Unsplash.

Please join us at the next regular Open NeuroFedora team meeting on Monday 20 May at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us in the Fedora meeting channel on chat.fedoraproject.org (our Matrix instance). Note that you can also access this channel from other Matrix home severs, so you do not have to create a Fedora account just to attend the meeting.

You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:

$ date -d 'Monday, May 20, 2024 13:00 UTC'

The meeting will be chaired by @ankursinha. The agenda for the meeting is:

We hope to see you there!

Week 20 in Packit

Posted by Weekly status of Packit Team on May 20, 2024 12:00 AM

Week 20 (May 14th – May 20th)

  • When running dist-git init command from CLI, you can pass a command to specify the git URL of the project. (packit#2308)
  • We have fixed the incorrect displaying of the time it took for the jobs to run on dashboard. (dashboard#408)

Episode 429 – The autonomy of open source developers

Posted by Josh Bressers on May 20, 2024 12:00 AM

Josh and Kurt talk about open source and autonomy. This is even related to some recent return to office news. The conversation weaves between a few threads, but fundamentally there’s some questions about why do people do what they do, especially in the world of open source. This also is a problem we see in security, security people love to tell developers what to do. Developers don’t like being told what to do.

<audio class="wp-audio-shortcode" controls="controls" id="audio-3388-1" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_429_The_autonomy_of_open_source_developers.mp3?_=1" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_429_The_autonomy_of_open_source_developers.mp3</audio>

Show Notes

Elections Voting is now Open!

Posted by Fedora Community Blog on May 19, 2024 11:01 PM

The voting period has now opened for the Fedora Linux 40 elections cycle. Please read the candidate interviews and cast your votes in our Elections App. Visit our Voting Guide to learn how our voting system works, and voting closes at 23:59:59 UTC on May 30th.

Fedora Mindshare Committee

Fedora Mindshare has one seat open. Below is the candidate that will be elected at the end of the voting period.

Fedora Council

The Fedora Council has two seats open. Below are the candidates eligible for election.

Fedora Engineering Steering Committee (FESCo)

The Fedora Engineering Steering Committee (FESCo) has four seats open. Below are the candidates eligible for election.

EPEL Steering Committee

The EPEL Steering Committee has four seats open. Below are the candidates eligible for election.

The post Elections Voting is now Open! appeared first on Fedora Community Blog.

EPEL Steering Committee Election: Troy Dawson (tdawson)

Posted by Fedora Community Blog on May 19, 2024 10:56 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Troy Dawson

  • FAS ID: tdawson


What is your background in EPEL? What have you worked on and what are you doing now?

I started contributing to EPEL 11 years ago with some nodejs packages for OpenShift. I later added rubygems and golang packages as OpenShift changed languages. Later, RHEL 8 did not have KDE, so I added KDE to epel8, and have been maintaining KDE in epel ever since. I have picked up many other packages during the years, but I think my KDE contributions are what I am most known for.

I’ve been the EPEL Steering Committee chair since 2020, taking over from Stephen Smoogen. A lot of changes have happened since then, most of them for the better. I’m not responsible for all the changes, but it’s been wonderful being part of the committee as these changes have come through.

Why are you running for EPEL Steering Committee Member?

EPEL has grown to be part of my professional and personal life. I not only want to contribute to it, but help steer it’s growth and progression. I think as a EPEL Steering Committee member, I can help keep EPEL healthy and thriving.

The post EPEL Steering Committee Election: Troy Dawson (tdawson) appeared first on Fedora Community Blog.

EPEL Steering Committee Election: Interview with Robby Callicotte (rcallicotte)

Posted by Fedora Community Blog on May 19, 2024 10:55 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Robby Callicotte

  • FAS ID: rcallicotte


What is your background in EPEL? What have you worked on and what are you doing now?

I’ve been an EPEL user since the mid 2000s and a package maintainer since 2021. I brought Saltstack back into EPEL and added a nifty linter for salt states called salt-lint. I am currently working on building all the dependencies for the upcoming pagure 6 release.

Why are you running for EPEL Steering Committee member?

EPEL packages account for millions of downloads per week and are a vitally important part of the Enterprise Linux ecosystem. I earnestly believe in the project’s mission and am eager to contribute my skills and acumen to its success. I am excited about the opportunity to serve the EPEL community and help shape its future direction.

The post EPEL Steering Committee Election: Interview with Robby Callicotte (rcallicotte) appeared first on Fedora Community Blog.

EPEL Steering Committee Election: Interview with Neil Hanlon (neil)

Posted by Fedora Community Blog on May 19, 2024 10:55 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Neil Hanlon

  • FAS ID: neil

What is your background in EPEL? What have you worked on and what are you doing now?

I’ve been a consumer of EPEL for more than a decade as I learned Linux and began my career—first in web hosting, then “DevOps”, and eventually being responsible for the network architecture and infrastructure for a large travel company. In the past four years, I helped to found the Rocky Linux project, where I became friends with Pablo Greco who encouraged me to participate in EPEL more actively, and I continue to maintain its various components, which involves significant Fedora and EPEL work as well as contributions to other upstream projects.

For over a year now, I have been a Fedora and EPEL packager and actively participate in EPEL Steering Committee meetings weekly. Most of the packages I maintain or contribute to are related to needs in the Rocky Linux project or are personally useful to me—such as remind, a calendar and alarm program that helps me stay organized, or passwdqc, a powerful password quality and policy enforcement toolkit that is especially useful in managing EL-based FreeIPA environments.

While I enjoy packaging, I find the most rewarding aspect of my work in EPEL to be mentoring and encouraging others to become Fedora and/or EPEL packagers. Growing the community and ecosystem of EL developers is crucial to the longevity of Enterprise Linux as a whole. Expanding the base of EPEL contributors not only strengthens EPEL but also benefits the broader Fedora developer community and can lead to more employer-sponsored contributions to Open Source.

In the coming months, I plan to introduce several cloud and HPC-related packages to Fedora and EPEL. I also aim to finalize a number of packages that are being introduced to Fedora following discussions in the #epel IRC channel, which I hope will bring in new Fedora and EPEL package maintainers.

Why are you running for EPEL Steering Committee member?

I am running for the EPEL Steering Committee to help foster growth and increase activity within Extra Packages for Enterprise Linux (EPEL). EPEL is unique in its commitment to stability and freedom from unnecessary disruptions, mirroring the principles of RHEL. While enabling Fedora packages for Enterprise Linux is a significant goal, EPEL goes further by ensuring that updates and newly introduced packages uphold this stability.

Maintaining packages for EPEL can be daunting for many maintainers, particularly those new to Fedora packaging guidelines, policies, and workflows. This initial hurdle is crucial to understand the different layers of policy between Fedora and EPEL, which make EPEL a unique and valuable project. EPEL has a large user base because of the immense utility it provides, and growing the footprint of EPEL maintainers is crucial for the project’s long-term health.

The post EPEL Steering Committee Election: Interview with Neil Hanlon (neil) appeared first on Fedora Community Blog.

EPEL Steering Committee Elections: Interview with Kevin Fenzi (kevin)

Posted by Fedora Community Blog on May 19, 2024 10:54 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Kevin Fenzi

  • FAS ID: kevin


What is your background in EPEL? What have you worked on and what are you doing now?

I’ve been involved in epel since the epel-5/6 days. With epel7 I wrangled a bunch of the work to get things setup, including beta before the rhel release, lots of release engineering work and mirroring/content. I maintain a lot of packages in EPEL, both for others use and to use in Fedora Infrastructure, which heavily uses epel for managing items that are not in rhel proper. I’ve been happy to see epel continue to grow and flourish and these days I tend to just provide some light releng work for epel along with package maint. epel is a wonderful service and I think it really increases the usefulness of rhel and downstreams.

Why are you running for EPEL Steering Committee member?

I think I provide a useful historical perspective on how things were setup and why, along with a release engineering perspective on how changes could be done or might affect composes.

The post EPEL Steering Committee Elections: Interview with Kevin Fenzi (kevin) appeared first on Fedora Community Blog.

EPEL Steering Committee Election: Interview with Jonathan Wright (jonathanspw)

Posted by Fedora Community Blog on May 19, 2024 10:53 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Jonathan Wright

  • FAS ID: jonathanspw


What is your background in EPEL? What have you worked on and what are you doing now?

I’ve been working with EPEL since its inception – having been a user of “Enterprise Linux” since CentOS 4. I became a Fedora packager a few years ago with an explicit interest in the EPEL side of things. Little did I know I’d also end up caring greatly about the Fedora side and I came back from the dark side (Arch) and am a Fedora desktop user again.

I’m the infrastructure lead for AlmaLinux and through that have a great care for EPEL and everything it empowers users to do – not just for AlmaLinux but for the EL community at large.

Why are you running for EPEL Steering Committee member?

I feel strongly that I can help steer the direction of EPEL due to my experience in the ecosystem.

The post EPEL Steering Committee Election: Interview with Jonathan Wright (jonathanspw) appeared first on Fedora Community Blog.

EPEL Steering Committee Election: Interview with Carl George (carlwgeorge)

Posted by Fedora Community Blog on May 19, 2024 10:52 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Carl George


What is your background in EPEL? What have you worked on and what are you doing now?

I got my start in Fedora and EPEL back in 2014. I joined a new team at Rackspace whose primary purpose was to maintain IUS, a third-party package repository for RHEL. Packages in this repository were typically based on Fedora packages. Some of these packages had dependencies in EPEL. We also maintained several other packages in EPEL that were important to our customers. I continued on as a regular EPEL contributor, even after I left Rackspace in 2019 to join the CentOS team at Red Hat. In 2021, I started a new team at Red Hat to specifically focus on EPEL activities.

In 2020 and 2021, I designed and lead the implementation of EPEL Next, an optional repository for EPEL maintainers to perform builds against CentOS Stream when necessary. Also in 2021, I lead the implementation of EPEL 9. This brought some significant improvements over previous EPEL versions. We utilized CentOS Stream 9 to launch EPEL 9 about six months before RHEL 9. This resulted in RHEL 9 having more EPEL packages available at its launch (~5700) than any previous release, helping ensure a positive user and customer experience. If you want to learn more about EPEL Next and EPEL 9, I suggest watching my conference presentation “The Road to EPEL 9“.

Currently I’m leading the implementation of EPEL 10, which will include more improvements over previous EPEL versions. The plan is for EPEL 10 to have minor versions, obsoleting the previous EPEL Next model. This will allow us to better target specific minor versions of RHEL 10, as well as CentOS Stream 10 as the leading minor version. You can learn more about this plan in my conference presentation “EPEL 10 Overview“.

Aside from the hands-on technical work of EPEL architecture and packaging, I have engaged in various other efforts to promote visibility and awareness of EPEL, and to communicate with our users and contributors.

  • Organized the first EPEL survey, which provided valuable feedback to improve packager workflows and the onboarding experience
  • Started a monthly “EPEL office hours” video call, which is open for anyone to attend to discuss EPEL topics
  • Presented about EPEL and related topics at conferences
  • Interviewed about EPEL and related topics on podcasts

Why are you running for EPEL Steering Committee member?

I have been on the EPEL Steering Committee since I was appointed to it
in 2020. As part of implementing elections for the committee, myself
and other members agreed to “step down” and essentially run for
re-election. I have enjoyed my four years serving on the committee, and
hope to have the opportunity to continue to serve the EPEL community. I
am passionate about EPEL and I am committed to continue finding ways to
improve the EPEL experience for both users and contributors.

The post EPEL Steering Committee Election: Interview with Carl George (carlwgeorge) appeared first on Fedora Community Blog.

FESCo Elections: Interview with Tom Stellard (tstellar)

Posted by Fedora Community Blog on May 19, 2024 10:47 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Tom Stellard

  • FAS ID: tstellar
  • Matrix Rooms: devel, fedora-ci


Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have a background in compilers and toolchains, and I would like to use some of the knowledge I’ve gained over the years of building and troubleshooting applications to help make Fedora better. Specifically, I’m interested in helping packagers avoid making common mistakes through standardized macros and packaging practices and also by increasing the reliance on CI.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I’m currently one of the maintainers of the LLVM packages in Fedora which is a set of 14 packages that provide a C/C++/Fortran compilers as well as a set of reusable compiler libraries that are used for developing other languages and for developer tools, like IDEs.

I’ve also worked on two system wide change requests to help standardize the use of make within Fedora packages. These changes helped to make spec files more consistent across all of Fedora and also made it possible to remove make from the default buildroot.

How do you handle disagreements when working as part of a team?

When I am in a leadership role, like FESCO, and there is a disagreement, the first thing I do is make sure I understand the problem and the potential solutions. This usually requires having a discussion between all interested parties either on a mailing list, chat platform, or video call. Many times disagreements are simply the result of misunderstandings, so getting everyone together to discuss the issue in the same place can lead to a consensus decision and avoid the need for someone in leadership to get involved.

However, if consensus cannot be reached, once I like to try to get some third party opinions from people who have not been directly involved with the discussions. Once I feel comfortable I have enough information and am ready to make a decision, I make sure I am able to explain in writing why the decision was made and then I communicate the decision to all the stakeholders. It’s always important to have a written record of why a decision was made in case it needs to be revisited in the future.

What else should community members know about you or your position

I work for Red Hat on the Platform Tools team. I am the technical lead for our LLVM team and the overall technical lead for the Go/Rust/LLVM compiler group. This means that I work on packaging, bug fixing and upstream feature development for LLVM and work on high-level technical issues common across all 3 compilers.

The post FESCo Elections: Interview with Tom Stellard (tstellar) appeared first on Fedora Community Blog.

FESCo Elections: Interview with Stephen Gallagher (sgallagh)

Posted by Fedora Community Blog on May 19, 2024 10:46 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Stephen Gallagher


Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I’ve been a member of FESCo for many years now, and it’s been a great experience. It gives me the opportunity to see a much wider view of the project than just the pieces I would otherwise contribute to.

As for steering the direction of Fedora, I think I would mostly just continue to do as I have been doing: pushing for Fedora to continue to be both the most advanced and one of the most stable open-source distributions in the world.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Aside from my work on FESCo, I am also acting as the Lead on the Fedora ELN project, which is a prototype of what will eventually be the next major release of Red Hat Enterprise Linux. We recently branched off CentOS Stream 10 from Fedora ELN, so we’re now looking to the future (and CentOS Stream 11!). Performing these activities in the public provides both an opportunity for the community to be involved with the creation of Red Hat Enterprise Linux as well as painting a clear picture of Fedora’s value to Red Hat, our primary sponsor.

Additionally, I have been acting as a primary administrator for the CentOS Stream Gitlab instance and I intend to volunteer my experience to help with the upcoming dist-git migration discussions.

How do you handle disagreements when working as part of a team?

First and foremost, I always strive for consensus. Most disagreements are not fundamental differences between people. Instead, they tend to be more nuanced. My goal (particularly within my FESCo service) is to make sure that everyone’s opinion is heard and considered; I then try to figure out how to meet in the middle.

Of course, not every decision can be resolved with consensus. In the event that a true impasse is reached, that’s the point where I usually advocate for calling a vote and proceeding with the majority opinion. On the whole, I believe that democratic decision-making is the best solution that humanity has come up with for resolving otherwise-insoluble disagreements.

What else should community members know about you or your positions?

Just so it’s very clear, I’m a Red Hat employee. My day-job at Red Hat is to organize and improve the processes we use to kick off development of the next major RHEL release. As such, my stances on FESCo will often represent my opinion of what will make that effort operate more smoothly. So, no matter how entertaining it might be, we’re not going to be replacing the entire contents of /usr/share/icons with the Beefy Miracle icon.

The post FESCo Elections: Interview with Stephen Gallagher (sgallagh) appeared first on Fedora Community Blog.

FESCo Elections: Interview with Neal Gompa (ngompa)

Posted by Fedora Community Blog on May 19, 2024 10:45 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Neal Gompa

  • FAS ID: ngompa
  • Matrix Rooms: #devel:fedoraproject.org, #asahi:fedoraproject.org, #asahi-devel:fedoraproject.org, #kde:fedoraproject.org, #workstation:fedoraproject.org, #cloud:fedoraproject.org, #kernel:fedoraproject.org #centos-hyperscale:fedoraproject.org, #okd:fedoraproject.org, #budgie:fedoraproject.org, #multimedia:fedoraproject.org, #miracle:fedoraproject.org, #cosmic:fedoraproject.org, #centos-kernel:fedora.im, #admin:opensuse.org, #chat:opensuse.org, #bar:opensuse.org, #obs:opensuse.org, #RedHat:matrix.org, #networkmanager:matrix.org, #rpm:matrix.org, #rpm-ecosystem:matrix.org, #yum:matrix.org, #manatools:matrix.org, #lugaru:matrix.org, #buddiesofbudgie-dev:matrix.org, #PackageKit:matrix.org, #mir-server:matrix.org, #mageia-dev:matrix.org

(There’s quite a bit more, but I think that sort of covers it. 😉)


Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

As a long-time member of the Fedora community as a user and a contributor, I have benefited from the excellent work of many FESCo members before me to ensure Fedora continues to evolve as an amazing platform for innovation. For the past few years, I have had the wonderful privilege of serving as a member of FESCo for the first time, and I enjoyed my time serving to steer Fedora into the future, and I wish to continue to contribute my expertise to help analyze and make good decisions on evolving the Fedora platform.

How do you currently contribute to Fedora? How does that contribution benefit the community?

The bulk of my contributions to Fedora lately are on the desktop side of things. Following on the work I did to improve Fedora’s multimedia capabilities, we now have a SIG that takes care of bringing in and updating multimedia software into Fedora. The successful bring-up of the Fedora Asahi Remix by the Asahi SIG to support Fedora Linux on Apple Silicon Macs has brought notoriety and several new contributors to the community. Most recently, I am mentoring new contributors to support the development of the Fedora Miracle Window Manager and the Fedora COSMIC efforts, including assisting in setting up SIGs and guiding them in the processes to support their work.

Beyond the desktop and more into the clouds, I helped revamp the tooling for creating Fedora Cloud images as well as the base Vagrant and container images to leverage the new KIWI image build tool, which enables both Fedora Cloud contributors and third parties to much more easily build things leveraging Fedora Cloud content. This has led to renewed interest from folks who work in public clouds, and we’ve started seeing contributions from notably Microsoft Azure now.

My hope is that the work I do helps with making the experience using and contributing to Fedora better than it was ever before and that Fedora’s technical leadership in open source draws in more users and contributors.

How do you handle disagreements when working as part of a team?

I attempt to explain my viewpoint and try to build consensus through persuasion and collaboration. If there isn’t a path to consensus as-is, I try to identify the points of disagreement and see if there is a way to compromise to resolve the disagreement. Generally, this ultimately results in a decision that FESCo can act on.

What else should community members know about you or your positions?

To me, the most important thing about Fedora is that we’re a community with a bias for innovation. Our community looks to solve problems and make solutions available as FOSS, and this is something that Fedora uniquely does when many others take the easy path to ship old software or nonfree software everywhere. We work with tens of thousands of projects to deliver an amazing platform in an easily accessible and open fashion, built on FOSS infrastructure and tools. This makes Fedora special to me, and we should continue to hold ourselves to that high standard.

I’m also a big believer in community bonds and collaboration, which is why people tend to find me all over the place. I’m involved in Asahi Linux, CentOS, openSUSE, and several other similar projects in leadership roles as well as a contributor in order to demonstrate my commitment to this philosophy.

The post FESCo Elections: Interview with Neal Gompa (ngompa) appeared first on Fedora Community Blog.

FESCo Elections: Interview with Michel Lind (salimma)

Posted by Fedora Community Blog on May 19, 2024 10:44 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Michel Lind


Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have been a Fedora contributor since the very beginning – circa 2003-4 – and over the years have contributed on the packaging side, as an Ambassador (I can still remember burning CDs and shipping them via the local post office), and more recently on the policy side with Fedora (starting the Lua SIG) and EPEL (reestablishing the EPEL Packagers SIG, establishing a workflow for escalating stalled EPEL requests).

I am fortunate enough to have a day job at a company (Meta) that heavily uses CentOS Stream and contribute to many core Linux projects, where my main focus is on upstream work – so if the Fedora community entrusts me with this position, I hope to advocate for Change Proposals that advance Fedora’s four foundations (Freedom, Friends, Features, and First) – while accepting that not all Fedora features can be supported in CentOS Stream and RHEL. I feel that having experience in packaging software and working on tooling and workflows across Fedora, EPEL and CentOS Stream gives me a vantage point where I can understand where different parts of the community are coming from.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I am a proven packager (using it to help out with mass rebuilds or to help out fixing major issues) and a packager sponsor, a member of several packaging SIGs (Go, Lua, Python, Rust) and several SIGs that bridge the gaps between Fedora, CentOS Stream, and RHEL (ELN, which is a rebuild of Rawhide with EL macros; EPEL, which provides extra packages for EL distros; and on the CentOS side, the CentOS Hyperscale SIG, which provides faster-moving backports and additional functionalities (typically sourced from Fedora) for use on top of CentOS Stream.

I wrote ebranch to help with branching Fedora packages to EPEL and heavily use it in bootstrapping EPEL 9; a rewrite is in the work to turn it into a suite of related tools for dependency graph management, branching, and inventory tracking.

I have done, and am working on, various Change Proposals.

Oh, and I helped migrate my company’s Linux desktops to Fedora (Flock 2019), FOSDEM 2021

How do you handle disagreements when working as part of a team?

I have been vilified because of where I work; I have learned to accept that people might have very strong opinions on certain issues that they won’t budge on, whether the opinions are (IMHO) justified or not, and still find a way to be civil and collaborate on topics of shared interest.

What else should community members know about you or your positions?

I have been a part of the Fedora community (and before that, a user of Red Hat Linux doing my own rebuilds) for several decades; my involvement predates and outlasts working for several employers (some of them not RPM shops). I am also a Debian Maintainer – and I hope to bring my experience contributing to different distributions to inform FESCo discussions. I dislike NIH (not invented here); ideas should stand on their own merits and it is good to learn from others (both adopting good ideas and avoiding past mistakes).

The post FESCo Elections: Interview with Michel Lind (salimma) appeared first on Fedora Community Blog.

Council Election: Interview with Sumantro Mukherjee (sumantrom)

Posted by Fedora Community Blog on May 19, 2024 10:39 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Sumantro Mukherjee

  • Fedora Account: sumantrom
  • Matrix Rooms: #fedora,#fedora-kde,#fedora-mindshare,#fedora-social,#fedora-social-hour, #fedora-arm,#fedora-devel,#fedora-qa,#fedora-workstation,#fedora-test-days, #fedora-i3,#fedora-badges,#fedora-docs,#fedora-l18n,#fedora-ambassadors)


Why are you running for Fedora Council?

I hail from APAC (India) and would like to focus on bringing in more non-US perspectives, which includes bringing in more contributors from diverse backgrounds. Efficient utilization of our brand new design assets which are now in multiple languages (Hindi, for example) to onboard variety of users (general and power-users) to the Fedora community as contributor either to functional sides (QA, packaging..etc) and/or outreach.
In the recent past; the council charter has been expanded to an Executive Sponsor. This role enables people like me to work closely with an upcoming initiative.
In parallel, I am closely working on Blueprints (https://discussion.fedoraproject.org/t/introducing-fedora-change-proposal-blueprints-in-association-with-fedora-qa/115903)
this is a long term effort and will benefit from my connections with people in Council (ie FESCo rep and FESCo at large)

The Fedora Strategy guiding star is that the project is going to double its contributor base by 2028. As a council member, how would you help the project deliver on that goal?

As a council member, I would work closely with teams which will need more attention building pipelines for onboarding, mentoring and retention of contributors. In Fedora QA, I have worked extensively to handle a high influx of contributors and retain them for at least a Release Cycle or two. I have optimized workflows that have been helping Fedora QA to grow optimally without burning out contributors or team members. I could help solve problems and coordinate closely with CommOps and other teams to build data-driven contributor pipelines to help Fedora Project double its contributors by 2028.

How can we best measure Fedora’s success?

However, there is no specific way to measure, BUT.. here’s something I think can define Fedora’s success the best
Fedora Linux’s success is measured by the people who use Fedora.
Fedora Project stands as the reference for the people who want to build an upstream community diverse and strong.
Fedora Project at its core is composed of people who take pride in packaging, testing, designing, translating, blogging, evangelizing and collaborating across the globe.
Fedora project takes pride in being a trendsetter for bringing technologies which impact a large downstream ecosystem and embolden their trust in our four foundations.

What is your opinion on Fedora Editions – what purpose do they serve? Are they achieving this purpose? What would you change?

Fedora Editions are Fedora Project’s flagships. They are exclusively tested and tried by Fedora’s in-house QA team to deliver on the expectations of tens of thousands of users. These platforms serve as building blocks for the Fedora Project to share innovation across multiple downstream ecosystems. Fedora Edition has more room to grow in terms of adoption in CI platforms and pre-installs for Hardware Makers. I would love to drive the adoption of Fedora not only at an organizational level ; but also in schools, universities and next-gen digital influencers.

The Fedora Council is intended to be an active working body. How will you make room for Council work?

As a long-term member, the Council is a body which in the coming days will be working across many facades of the Project, taking bold decisions to make our community
more robust, productive and healthy. Being a long-term member, I support the goals and I’ve prepared my upcoming work cycles such that I have room to spend time
at the Council position.
The aforementioned changes in accordance with 2028 strategy impacts my role in Fedora Project at large and I will always want to be a stakeholder. This will help drive decisions which help the Quality teams day to day operations.

The post Council Election: Interview with Sumantro Mukherjee (sumantrom) appeared first on Fedora Community Blog.

Mindshare Election: Interview with Sumantro Mukherjee (sumantrom)

Posted by Fedora Community Blog on May 19, 2024 10:38 PM

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.

Interview with Sumantro Mukherjee

  • FAS ID: sumantrom
  • Matrix Rooms: fedora,#fedora-kde,#fedora-mindshare,#fedora-social,#fedora-social-hour, #fedora-arm,#fedora-devel,#fedora-qa,#fedora-workstation,#fedora-test-days, #fedora-i3,#fedora-badges,#fedora-docs,#fedora-l18n,#fedora-ambassadors)


What is your background in Fedora? What have you worked on and what are you doing now?

I’ve been in Fedora Project for more than 10yrs now. I have been a part of the Fedora QA team for the whole time. As a part of Fedora QA, I have signed off on multiple releases.
Apart from those, I have been an avid advocate of Fedora Project to the community at large, it has driven me to take up onboarding , ambassadorship and mentoring as part of Fedora Project. Recently, I am taking part in a11y initiative and few places of Mentorship init.

Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare.

Fedora in recent years has been in the talks, be it conferences or tech news. I run my own YT channel, promote a lot of QA test day events over socials and totally believe in the power of Digital and Social Media. In this day and age, where Recognition is a very sought after and retention of efforts directly linked to rewards ; it’s important for a project like Fedora to become more efficient with resource allocation. My “why” is to figure out and open up more way how Fedora project can reward it’s contributors.

How would you improve Mindshare Committee visibility and awareness in the Fedora community?

Mindshare is a very visible committee to begin with, however we can actually benefit from efforts like CommOps 2.0. I believe the more stats we have about out community and contributors the more we can get visibility in the obscure corners. I would like to be someone who helps bring more clarity for my team (Fedora QA) to start with and then expand to other parts of the project.

What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?

Recognition and Community health are the two key areas Mindshare can put some attention. Recognition brings in fresh blood in the community, adding more ideas and diverse way of doing things. Community’s health helps us with retention and avoiding possible burnouts. Outreach teams of all kinds will benefit from both of them and Fedora contributors will have a long lasting impact on the Open Source space for years to come.

The post Mindshare Election: Interview with Sumantro Mukherjee (sumantrom) appeared first on Fedora Community Blog.

Revue de presse de Fedora Linux 40

Posted by Charles-Antoine Couret on May 18, 2024 10:43 PM

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora Linux 40 ! Bon, ok cette fois il y a un léger retard. ;)

Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

Sites web d'actualité

Soit 6 sites.

Les vidéos

Soit 2 vidéos.


Le nombre de sites parlant de Fedora Linux 40 est en légère baise de même que les vidéos.

La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 9,7% (plus de 300 visites en plus)
  • Documentation : hausse d'environ 23,8% (soit environ 500 visites en plus)
  • Le site Fedora-fr : hausse de 29,6% (soit 60 visites en plus)
  • Borsalinux-fr : 0 visites depuis fin mars contre une vingtaine d'habitude, sans doute un bogue

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager !

Rendez-vous pour Fedora Linux 41.

GNOME maintainers: here’s how to keep your issue tracker in good shape

Posted by Allan Day on May 17, 2024 03:29 PM

One of the goals of the new GNOME project handbook is to provide effective guidelines for contributors. Most of the guidelines are based on recommendations that GNOME already had, which were then improved and updated. These improvements were based on input from others in the project, as well as by drawing on recommendations from elsewhere.

The best example of this effort was around issue management. Before the handbook, GNOME’s issue management guidelines were seriously out of date, and were incomplete in a number of areas. Now we have shiny new issue management guidelines which are full of good advice and wisdom!

The state of our issue trackers matters. An issue tracker with thousands of open issues is intimidating to a new contributor. Likewise, lots of issues without a clear status or resolution makes it difficult for potential contributors to know what to do. My hope is that, with effective issue management guidelines, GNOME can improve the overall state of its issue trackers.

So what magic sauce does the handbook recommend to turn an out of control and burdensome issue tracker into a source of calm and delight, I hear you ask? The formula is fairly simple:

  • Review all incoming issues, and regularly conduct reviews of old issues, in order to weed out reports which are ambiguous, obsolete, duplicates, and so on
  • Close issues which haven’t seen activity in over a year
  • Apply the “needs design” and “needs info” labels as needed
  • Close issues that have been labelled “need info” for 6 weeks
  • Issues labelled “needs design” get closed after 1 year of inactivity, like any other
  • Recruit contributors to help with issue management

To some readers this is probably controversial advice, and likely conflicts with their existing practice. However, there’s nothing new about these issue management procedures. The current incarnation has been in place since 2009, and some aspects of them are even older. Also, personally speaking, I’m of the view that effective issue management requires taking a strong line (being strong doesn’t mean being impolite, I should add – quite the opposite). From a project perspective, it is more important to keep the issue tracker focused than it is to maintain a database of every single tiny flaw in its software.

The guidelines definitely need some more work. There will undoubtedly be some cases where an issue needs to be kept open despite it being untouched for a year, for example, and we should figure out how to reflect that in the guidelines. I also feel that the existing guidelines could be simplified, to make them easier to read and consume.

I’d be really interested to hear what changes people think are necessary. It is important for the guidelines to be something that maintainers feel that they can realistically implement. The guidelines are not set in stone.

That said, it would also be awesome if more maintainers were to put the current issue management guidelines into practice in their modules. I do think that they represent a good way to get control of an issue tracker, and this could be a really powerful way for us to make GNOME more approachable to new contributors.

Install PHP 8.3 on Fedora, RHEL, CentOS, Alma, Rocky or other clone

Posted by Remi Collet on May 17, 2024 12:11 PM

Here is a quick howto upgrade default PHP version provided on Fedora, RHEL, CentOS, AlmaLinux, Rocky Linux or other clones with latest version 8.3.

You can also follow the Wizard instructions.


Repositories configuration:

On Fedora, standards repositories are enough, on Enterprise Linux (RHEL, CentOS) the Extra Packages for Enterprise Linux (EPEL) and Code Ready Builder (CRB) repositories must be configured.

Fedora 40

dnf install https://rpms.remirepo.net/fedora/remi-release-40.rpm

Fedora 39

dnf install https://rpms.remirepo.net/fedora/remi-release-39.rpm

RHEL version 9.4

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpms

RHEL version 8.9

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms

Alma, CentOS Stream, Rocky version 9

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
crb install

Alma, CentOS Stream, Rocky version 8

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
crb install


php module usage


With Fedora and EL  8, you can simply use the remi-8.3 stream of the php module

dnf module reset php
dnf module install php:remi-8.3


PHP upgrade


By choice, the packages have the same name as in the distribution, so a simple update is enough:

yum update

That's all :)

$ php -v
PHP 8.3.7 (cli) (built: May  7 2024 16:35:26) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.3.7, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.7, Copyright (c), by Zend Technologies


Known issues

The upgrade can fail (by design) when some installed extensions are not yet compatible with  PHP 8.3.

See the compatibility tracking list: PECL extensions RPM status

If these extensions are not mandatory, you can remove them before the upgrade, otherwise, you must be patient.

Warning: some extensions are still under development, but it seems useful to provide them to upgrade more people and allow users to give feedback to the authors.


More information

If you prefer to install PHP 8.3 beside the default PHP version, this can be achieved using the php83 prefixed packages, see the PHP 8.3 as Software Collection post.

You can also try the configuration wizard.

The packages available in the repository were used as sources for Fedora 40.

By providing a full feature PHP stack, with about 130 available extensions, 10 PHP versions, as base and SCL packages, for Fedora and Enterprise Linux, and with 300 000 downloads per day, the remi repository became in the last 18 years a reference for PHP users on RPM based distributions, maintained by an active contributor to the projects (Fedora, PHP, PECL...).

See also:

Registration Open: Fedora 40 Release Party on May 24-25

Posted by Fedora Magazine on May 17, 2024 08:00 AM

Join us next weekend on Friday and Saturday, May 24-25 to celebrate the release of Fedora Linux 40! We’re going to be hearing from community members inside and outside of the Fedora Project on what is new in Fedora 40, what we can look forward to next, and how we come together as a community.

Register Here

Register to attend the Fedora 40 Release Party here!

What topics will be discussed?

  • We’ll learn about upgrades like KDE Plasma 6 and Fedora Asahi Remix 40
  • Community updates like from the Fedora DEI Team and Mentored Project Initiative
  • Infrastructure changes like with Kiwi for Fedora Cloud and the Git Forge investigation
  • Updates from our downstream friends at Universal Blue and Ultramarine
  • And more! Here’s the schedule of topics and speakers

Join us!

What is a release party?

Fedora Release Parties are virtual, user-focused conferences where the community comes together to talk about what’s new in the latest release of Fedora and where we’re going for future releases. Topics we’ve covered include the process of working through implementing a change and roadmaps for what different teams want to do next in Fedora. Sometimes there are updates from Fedora-associated groups who have something to share, like Amazon or Lenovo. We also have breaks for socials where we can talk to each other in video calls (you don’t have to share video or speak if you don’t want to). If you have an interest in a behind-the-scenes look at your favorite distro, come learn and hang out with the contributors who make it!

Where will it happen?

In previous years we used Hopin to run virtual conferences, but the Fedora 40 Release Party will be the first that we do in Matrix! We’ve wanted to do this since the Creative Freedom Summit showed how it could be done a couple of years ago. This is a step that allows us to lean more on open source for outreach.

However, we also want to be open in another way, and that’s with livestreaming. We will be streaming the talks on our Fedora Project YouTube channel. That way anyone can watch and the streams will be immediately available afterwards!

Please register for the release party! Once you do and provide your Matrix ID, the organizers will invite you to the Matrix channel and we’ll be on our way to a great celebration.

We hope to see you there!

Learn more

Check out the Fedora 39 Release Party to get an idea of the kinds of topics we cover.

Get hyped on social media with hashtag #FedoraReleaseParty!

Visualizing potential solar PV generation vs smart meter electricity usage

Posted by Daniel Berrange on May 16, 2024 10:35 PM

For many years now, energy suppliers have been rolling out “smart meters” to home across the UK. It has largely been promoted as a way to let consumers reduce their consumption by watching their energy usage on an in home display (IHD) gadget. This is massively under selling the potential benefits of smart meters, and combined with various other reasons, leaves many unenthusiastic about the change. A few more adventurous suppliers, most prominently Octopus Energy, are taking advantage of smart meters to offer innovative dynamic tariffs, which particularly benefit those with electric vehicles.

I have been exploring the possibility of a solar PV installation at home and after talking to various suppliers have been left feeling quite underwhelmed with the reports they provide with their quotations. Typically a selection of crude 2-dimensional charts showing potential generation per month and some rough estimate of how much grid import will be reduced and grid export available based on your yearly kwh usage figure. They’ll only illustrate one or two scenarios, so it is hard to understand the impact of altering the number of panels requested, or sizing of any battery storage.

The European PVGIS service provides a good site where you can visualize the solar generation at your home based on actual recorded atmospheric conditions from history (typically their data lags current day by 2-3 years). They still only make use of your yearly kwh consumption figure with a generic model to estimate benefits. With a smart meter I have historic electricity consumption for my home in kwh at 30 minute granularity. Match that against the PVGIS data and its possible to produce a fine grained simulation of solar PV generation potential against consumption.

And so came forth the idea of a simple python script I’m calling “smartsolar” to combine PVGIS data with smart meter data and produce reports evaluating potential deployment options. It can use smart meter records downloaded from n3rgy (compatible with any UK supplier once registered), or from Octopus Energy‘s customer portal. Using plotly the reports contain 3-dimensional interactive charts showing data day-by-day, hour-by-hour. Changing the configuration file lets you quickly evaluate many different deployment scenarios to understand the tradeoffs involved.

In the charts (screenshots of a fixed POV only, non-interactive) that follow I’m evaluating an arbitrary installation with 10 panels on a south-east orientation and 6 panels on a north-west orientation, panels rated at 400W, along with 10 kwh of battery storage. The smart meter consumption data covers primarily 2023, while the PVGIS generation data is from 2019, the latest currently available.

The first chart shows the breakdown of consumption data and exposes some interesting points. The consumption is broadly consistent from day-to-day across the whole year and is spread fairly flat across the time period from 8am to 11pm. This reflects the effects of full time remote working. Someone office based would likely see consumption skewed towards the evenings with less in the middle of the day. The enormous nighttime peaks in consumption in the last month of the year reflect the fact that I acquired an electric vehicle and started charging it at home on a Zappi. The huge day time usage peak was a side effect of replacing our heating system in Dec, which required temporary use of electric heaters. NB, the flat consumption around Sept timeframe is a result of me accidentally loosing about 25 days of smart meter data.

The next two charts give the real world PV generation of the two hypothesized solar arrays, based on the 2019 PVGIS data source. The larger south east facing array starts generating as early as 5am in the middle of summer, but drops off sharply around 3pm. There is still useful generation in mid-winter from 8am till around 2pm, but obviously the magnitude is far below summer peak.

Conventional wisdom is that PV is a waste of time on predominantly north facing roofs, but what is the real world performance like ? The small north west facing array shows a gradual ramp in mid-summer from 6am to reach a peak at around 6pm, and drops off to nothing by 8pm. For the 2 months either side of mid-winter, the generation is so negligible to be called zero. The absolute peak is 1/2 that of the south-east array, but there are 10 panels south east and only 6 panels north west. So peak generation per panel is not too terrible on the north east side. The limitations are really about the terrible winter performance, and the skewing of generation towards the evening hours. The evening bias, however, is potentially quite useful since that could match quite well with some people’s consumption patterns and early evening is commonly when the national grid has highest CO/2 intensity per kwh.

Seeing generation of each array separately is interesting in order to evaluate their relative performance. For comparison with consumption data though, a chart illustrating the combined generation of all arrays is more useful. This combined chart shows the south east and north west arrays complementing each other very well to expand the width of the peak generation time in the summer months, with peak summer output of 4kw per hour and covering the main hours of consumption. There is still useful improvement in the spring and autumn months, but winter is unchanged.

By taking the intersection of consumption and generation data, we can evaluate what subset of the generated energy is capable of being consumed at home, ignoring the possibility of battery storage. This chart shows the the generated energy can make a significant contribution to recorded consumption across the whole year. Obviously generated energy is only being consumed during daylight hours, since this chart discounts the usage of the any hypothetical home storage battery

It gets more interesting when taking into account the battery storage. This new chart shows that the house can run from self-generated energy around the clock for most of the year, but it especially shows how the battery can “time shift” generated energy into the evening once daylight has faded, but the house still has significant energy needs and continues to supply the house throughout the night even for some days in winter.

Another way of looking at the data is to consider how much energy is being imported from the national grid, as this indicates an inability to generate sufficient from the local PV arrays. First without the battery storage, it can be seen that in the middle of the day grid import is negligible outside of the winter months, but there is still considerable import in the evenings. The spikes from EV charging and temporary electric heaters are also still present. The winter months still show some significant grid import even in the middle of the day.

Adding in the battery storage calculations has a really dramatic impact on grid import. With 10kw of storage, there is enough buffer to be 100% self-sufficient in energy generation for 7 months of the year, which is a really astonishing result. A battery of this size obviously can’t address the peaks demanded by the EV charging periods, since the car battery capacity is well in excess of the home storage battery, but that’s to be expected.

The total PV generation capacity over the year with the 16 panels is 5300 kwh while yearly consumption is only 3000 kwh, so clearly there is a lot of excess electricity going unused. To visualize this, a chart showing exports to the grid is useful to consider. Unsurprisingly, with no battery, we see strong grid export rates across all the day time hours when the panels are generating.

If we now add in the effects of a home battery, the grid export pattern changes somewhat. In winter months there is absolutely no grid export, with 100% of solar generation now able to be consumed locally, since demand far exceeds what is able to be generated in these months. In the rest of the months, export doesn’t start until an hour or two later in the morning. This shows the battery being recharged after overnight usage, until it is full and exporting of energy resumes.

An alternative way to consider the grid import and export is to combine the two charts to illustrate the flow, with positive being export and negative being import. This nicely visualizes when the direction of flow flips during the day.

With battery storage taken into account, it is very apparent when there is neither grid import nor grid export during summer months.

After considering the import and export rates for the grid, the final thing to look at is the charge and discharge rate of the battery storage. In terms of charging, the pattern broadly reflects the initial period of daylight hours throughout the year, as there is always either a slight mismatch in generation vs demand, or a huge surplus available. The battery typically fills up very quickly at the start of the day and remains that way for most of the day. This might suggest the need for a bigger battery, but the grid import chart shows that the house can run entirely from local consumption for 8 months of the year, an in winter months all PV generation is consumed, so there is not much to gain from a bigger battery.

The battery discharge pattern is perhaps the more interesting of the two charts, as it shows exactly when the benefit of the battery is most felt. In summer there are some peaks of discharge at the start of the day, this reflects some temporary loads which exceed the available generation, such as running the dishwasher or washing machine. In the middle of the day there is very little discharge except for winter months, but the evening is there is really shines. The solar PV generation has peaked, but there is still major consumption demand for cooking dinner on an electric induction hob, and/or oven, and the periodic use of a tumble dryer. Finally the battery takes up the load throughout the night when there is zero PV generation, but fairly low baseline demand.

Again the charge and discharge charts can be combined to show the flow in (positive) and out (negative) of the battery

The final chart to look at is the battery charge level, which will give an idea of how well sized the battery is. If it never reaches a 100% full state, then it is likely oversized, but if it spends the whole year at 100% full state, then it is likely undersized. The ideal with be tradeoff somewhere in between, perhaps with a battery large enough to eliminate grid import for perhaps the middle 50% of the year, showing periods of strong charge and discharge.

With this walkthrough complete, the potential benefits of having fine grained electricity consumption data from smart meters is becoming more apparent. Having access to both consumption and generation data for your home and its location allows evaluation of an arbitrary number of different solar PV + battery storage deployment options, where a commercial installer might only show 2-3 scenarios at most.

There are still many limitations to the visualization that should be kept in mind

  • The electricity consumption data reflects a point in time before solar PV is installed, and it is commonly reported that people tend to change their usage patterns to take most advantage of free electricity they’ve got available. IOW, the level of self-consumption in the no-battery scenario is probably understated, while the potential gain in self-consumption from adding a battery is slightly over-stated.
  • The electricity consumption data reflects one year, while the PVGIS solar irradiation data is from a different year. Electricity consumption may well vary depending on weather, for example increased use of tumble dryers when it is cloudy and wet, or decreased use of ovens when it is hot. Or the year chosen for either consumption or generation data may have quirks that makes it non-representative of a typical year. It could be worth trying different years for the PVGIS data to see if it impacts the results produced. An enhancement would be for the tool to average PVGIS data from a number of years in particular.
  • The data is being processed at 1 hour granularity, with an assumption that generation and consumption is spread evenly across the hour. In reality this does not likely line up so well, and so self-consumption in the no battery scenario is likely overstated. The with battery charts, however, are likely to be fairly unaffected as the battery will easily compensate for short term mis-matches in generation and consumption
  • In houses with hot water storage cylinders, it is very common to fit a solar diverter, such that when there is excess generation, it will be used to heat hot water instead of being exported to the grid. Thus the level of grid export is likely overstated, and self-consumption understated. There is also no visualization of the reduction in gas bill from the use of free electricity to heat water instead of a gas heater. Thus the potential benefits from having home storage batteries will be overstated to some degree.
  • In houses with EV chargers, it is also typical to divert excess generation into the car, so again the level of grid export is likely overstated and self-consumption understated. Again this will have the effect of overstating the benefits of a home stokrage battery.
  • The generation figures don’t take into account losses from the equipment, or localized degradation from shading on individual panels
  • The consumption figures don’t reflect potential future changes in usage. For example, if the gas boiler were to be replaced by a heat pump, demand in the winter months in particular would massively increase, and summer months would increase to some extent for heating of hot water. This might push towards oversizing the PV array in the short term.

Despite these caveats, the visualization should still be very beneficial in evaluating different solar PV and battery installation scenarios.

Using the ATEN CV211 (all-in-one KVM adapter) with Fedora Linux

Posted by Andreas Haerter on May 16, 2024 05:32 PM

The ATEN CV211 is an all-in-one KVM (Keyboard, Video, Mouse) adapter that turns your laptop into a KVM console, combining the functionality of a wormhole switch, capture box, external DVD-ROM, keyboard, mouse, and monitor, all in one compact and convenient unit. I really like the hardware in daily operations, especially when I have to a takeover new environments with “historically grown” cabling. It is nice to have the ability to get the screen and keyboard control of a yet unknown server without hassle—all with a small USB adapter in your backpack:

<figure>ATEN CV211 KVM switch: photo of the hardware</figure>

If you connect the adapter, you’ll get a 10 MiB drive mounted with the following contents, containing a Microsoft Windows Client WinClient.exe (basically a Runtime Environment and wrapper) and the real application JavaClient.jar:

$ ll
total 9,1M
drwxr-xr-x. 2 user user  16K  1. Jan 1970  .
drwxr-x---+ 3 root root   60 30. Apr 19:08 ..
-rw-r--r--. 1 user user 3,7M 30. Dez 2019  JavaClient.jar
-rw-r--r--. 1 user user 2,0M 30. Dez 2019  Vplayer.jar
-rwxr-xr-x. 1 user user 3,5M 30. Dez 2019  WinClient.exe

The “login failed” problem

The JavaClient.jar KVM console is mostly the same as ATEN uses for all their IP KVM stuff. They just bind the service to some high port on localhost and use the hardcoded credentials -u administrator -p password to connect (which is obvious in several places):

<figure>ATEN CV211 KVM switch: credentials</figure>

Sadly, the Java application is not able to run out-of-the-box on a Fedora 40 Linux with OpenJDK / Java SE. The application will start but sometimes does not even list the device. And if there is a device to connect to, the login will fail:

<figure>ATEN CV211 KVM switch: login failed with OpenJDK</figure>

The JavaClient.jar will not be able to connect with any supported OpenJDK or Azul Zulu Java RE:

# incompatible Java version :-(
$ java -version
openjdk version "17.0.9" 2023-10-17

Solution: Oracle JDK 7

For anybody having the same problem, the following should help:

  1. Use a copy of the Oracle JDK 7 (the patch level does not matter) and the application will work without flaws.1
  2. Make sure the current working directory is the USB mount point so the .jar files are in ./.

For example, if you just extract jdk-7u80-linux-x64.tar.gz to /tmp, you can use the application as follows:

tar -xvf jdk-7u80-linux-x64.tar.gz -C /tmp
cd /run/media/user/disk # or wherever the ATEN CV211 storage was mounted
sudo /tmp/jdk1.7.0_80/bin/java -jar ./JavaClient.jar
<figure>ATEN CV211 KVM switch: screenshot of the working application</figure>

You can download the Oracle JDK 7 from https://www.oracle.com/de/java/technologies/javase/javase7-archive-downloads.html, but keep in mind to check the license conditions, especially if you are operating in a commercial environment.

  1. Do not use this old, unpatched Java RE for anything else because of known security vulnerabilities. ↩︎

Use copyleft licenses for open source or life with the consequences

Posted by Andreas Haerter on May 16, 2024 03:26 PM

A good open-source license allows reuse of source code while retaining copyright. But you should also think about copyleft when starting a open-source project or company.

Licenses like the General Public License (GPL) are usually better for the open-source ecosystem than permissive ones like Apache 2 or MIT as they require that any modifications or derivative works are shared, promoting a cycle of continuous contributions and improvements. Enhancements are distributed, benefiting the entire community rather than allowing the exploitation of open source code without giving back (looking at you, Amazon Web Services).

Hypergrowth < Community

Licenses like the GNU Affero General Public License (AGPL) might prevent some corporations from using an open-source project because they do not want to release the source code of their own modifications to it. Sadly, corporate compliance often prohibits the usage of copyleft projects altogether, even if nobody plans to modify anything. Especially the legal departments of large “enterprizy” organizations often prefer software with licenses like MIT as they want it simple and “risk”-free.

In light of license changes, the impression comes to mind that many start-ups use open source not because of freedom but as an argument for adoption in the enterprise ecosystem. They avoid choosing (A)GPLv3 licenses to facilitate easier corporate adoption without generating enough revenue, while being funded by venture capital and without getting contributions back by organization who could easily afford giving back something. Then, after being adopted, they complain.

While the open-source contributions from corporations like HashiCorp are impressive, the overall situation is complex. There’s a reason why Linux (GPL licensed) is still around, growing, and making money for so many while companies behind widespread open source projects often fail financially and burning insane amounts of money. It might work out for individuals and owners when getting bought, but it hurts users and ecosystems who relied on something.

Your SaaS will not compete against AWS or internal IT staff

So don’t be surprised if licenses like MIT attract large corporations and users who don’t care about you or the community, making it difficult to find fair cooperation (including financial resources) with them later. Stick with a real, copyleft license that has less adoption by other enterprises and focus on organic growth with people who care about the project.

Alternatively, be prepared for the consequences that Amazon or other hyperscalers will attract a large number of customers using your product without giving anything back—as you stated that’s OK by using e.g the MIT license.

If you still want to go that route, you must establish another source of income right away. One has to be realistic: Competing with your open-source product’s own SaaS against any SaaS by Amazon or other hyperscalers—or even the well-trained on-premises operations team—will not work out if that’s your only way to make money. Services that support users in operating in-house or enabling paid development (e.g., prioritizing features for a fee) are also possible with open source and are the better choice.

Server Updates/Reboots

Posted by Fedora Infrastructure Status on May 15, 2024 09:00 PM

We will be applying updates to all our servers and rebooting into newer kernels. Services will be up or down during the outage window.

Experimental syslog-ng packages for Amazon Linux 2023

Posted by Peter Czanik on May 15, 2024 11:43 AM

Last year, I received many requests about syslog-ng for Amazon Linux 2023, but I could not find an easy way to create syslog-ng packages. Recently, however, I found that Fedora Copr supports building packages for Amazon Linux 2023. So, with a little bit of experimentation, I got a cut down version of syslog-ng compiled.

Read more at https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-packages-for-amazon-linux-2023


syslog-ng logo

</figcaption> </figure>

Database Migrations

Posted by Fedora Infrastructure Status on May 14, 2024 08:00 PM

We will be migrating a number of our database servers to RHEL9, newer versions of database software and more resources. During the migration services that use these databases may be offline completely. The small servers ( db-fas01 and db03 ) should move and have service restored sooner than the two larger hosts …

CentOS Stream 8 END OF LIFE : 2024-05-31

Posted by Stephen Smoogen on May 14, 2024 02:51 PM

CentOS Stream 8 EOL

CentOS Stream 8 will reach its end of life on May 31st, 2024. When that happens, the CentOS Infrastructure will follow the standard practice it has been doing since the early days of CentOS Linux:
  1. Move all content to https://vault.centos.org/
  2. Stop the mirroring software from responding to EL-8 queries. 

The first change usually causes any mirror doing an rsync with delete options to remove the contents from their mirror. The second change will cause the dnf or yum commands to break with errors. The vault system is also a single server with few active mirrors of its contents. As such, it is likely to be overloaded and very slow to respond as additional requests are made of it.

In total, if you are using CentOS Stream 8 in either production or a CI/CD system, you can expect a lot of errors on June 1st or shortly afterwords. 

What you can do!

There are several steps you can do to get ahead of a possible tsunami of problems:
  1. You can look to moving to a newer release of CentOS Stream before the end of the month. This usually will require deployment of new images or installs versus straight updates. 
  2. You can see if any of the 'move my Enterprise Linux' tools have added support for moving from CentOS Stream 8 to their EL8.10. For releases before 8.10, this was very hard because CentOS Stream 8 was usually the next release, but 8.10 is at a point where Alma, Oracle, Red Hat Enterprise Linux, or Rocky are at the same revisions or newer.
  3. You can start mirroring the CentOS Stream 8 content into your infrastructure and point any CI/CD or other systems to that mirror which will allow you to continue to function.

Mirroring CentOS Stream

Of the three options, I recommend the third. However in working out what is needed to mirror CentOS Stream, I realized I needed newer documentation and it would probably be a long post in itself. For a shorter version for self-starters, I recommend the documentation on the CentOS wiki,  https://wiki.centos.org/HowTos(2f)CreateLocalMirror.html  While the information was written for CentOS Linux 6 which was end-of-lifed in 2020, it covers most of the instructions needed. The parts which may need updating is the amount of disk space required for CentOS Stream which seems to be about 280 GB for everything and maybe around 120GB for any one architecture. 



CentOS Linux 7: End of Life 2024-06-30

Posted by Stephen Smoogen on May 14, 2024 02:51 PM

CentOS 7 EOL

If this looks a lot like the CentOS Stream 8 EOL content.. well it is because they aren't too different. It is just that instead of doing this once every 4 years, we get to do this twice in one year.
The last CentOS Linux release, CentOS Linux 7, will reach its end of life on June 30th, 2024. When that happens, the CentOS Infrastructure will follow the standard practice it has been doing since the early days of CentOS Linux:
  1. Move all content to https://vault.centos.org/
  2. Stop the mirroring software from responding to EL-7 queries.  
  3. Additional software for EL-7 may also be removed from other locations.

The first change usually causes any mirror doing an rsync with delete options to remove the contents from their mirror. The second change will cause the yum commands to break with errors. The vault system is also a single server with few active mirrors of its contents. As such, it is likely to be overloaded and very slow to respond as additional requests are made of it. 

 At the same time, the EPEL software on https://dl.fedoraproject.org/pub/epel/7 will be moved to /pub/archive/epel/7 and the mirrormanager for that will be updated appropriately.

In total, if you are using CentOS Linux 7 in either production or a CI/CD system, you can expect a lot of errors on July 1st or shortly afterwords.

What you must do!

There are several steps you can do to get ahead of the tsunami of problems:
  1. You can convert to Red Hat Enterprise Linux 7 and see about getting a Extended LifeCycle Support contract with the system. This is a stop gap measure for you to move toward a newer release of a Linux operating system.
  2. You can move your system to a replacement Enterprise Linux distribution. The Alma Project, Rocky Linux, Oracle and Red Hat all offer tools which can transition an EL7 system to a version of the operating system they will support for several years.
  3. If you are not able to move your systems in the next 45 days, you should look at mirroring the CentOS Linux 7 operating system to a more local location and move your update configs to use your mirror. With the large size of systems which could potentially try to use the vault system, I would not expect this to be very useful. As you will probably need to reinstall, add software or do continuous CI/CD in other areas.. you should keep a copy of the operating system local to your networks.


New badge: Fedora Week of Diversity 2024 !

Posted by Fedora Badges on May 14, 2024 02:41 PM
Fedora Week of Diversity 2024You contributed or participated in the Fedora Week of Diversity 2024!

Copr: build your Fedora / RHEL packages for POWER

Posted by Peter Czanik on May 14, 2024 09:10 AM

I’m often asked, how can I be an IBM Champion for POWER, if I do not own an IBM POWER server or workstation. Yes, life would definitely be easier if I had one. However, I have an over 30 years history with POWER, and there are some fantastic resources available to developers for free. Both help me to stay an active member of the IBM POWER open source community.


Talos II POWER9 mainboard

</figcaption> </figure>

Last time I introduced you to the openSUSE Build Service. This time I show you Copr, the Fedora build service.


Just like OBS, Fedora Copr also started out as a (relatively) simple service to build Fedora and CentOS packages for x86. As Copr is a project by Fedora, the public instance maintained by Fedora at https://copr.fedorainfracloud.org/ only allows you to build open source software. However, you can also install Copr yourself on your own infrastructure. The source code of Copr is available at https://copr.fedorainfracloud.org/, where you can also find links to the documentation.

Today you can use Copr to build packages not just for Fedora x86, but almost all RPM distributions, including openSUSE and OpenMandriva. In addition to x86, you can build packages for 64 bit ARM (aarch64), IBM mainframes (s390x), and IBM POWER 64 bit, little Endian (ppc64le).


Platform selection in Fedora Copr

</figcaption> </figure>

You can access Copr using its web interface. There is also a command-line utility, but it was very limited when I last checked. Enabling support for POWER in your project is easy: just select the POWER architecture versions of distributions when you setup the project. You can enable support for POWER also later, but Copr does not automatically build packages for the new architecture. TL;DR: enable support for POWER before building any packages to make your life easier.

How do I use Copr?

Just as with the openSUSE Build Service, my first use of Copr was to make up-to-date syslog-ng packages available to the community. Along the way I used Copr to build some syslog-ng dependencies not yet available in Fedora or RHEL. Some of these are already part of the official distributions.

I did not have a chance yet to benchmark syslog-ng on POWER10, however in the POWER9 era POWER was the best platform to run syslog-ng. I measured syslog-ng collecting over 3 million log messages a second on a POWER9 box when x86 servers could barely go above the 1 million mark.

When I make the latest syslog-ng versions available, I build my EPEL (Extra Packages for Enterprise Linux) packages not just for x86, but also for POWER. I do not know how accurate Copr download statistics are, but for some syslog-ng releases it shows that almost a fourth of all downloads were for POWER syslog-ng packages: https://copr.fedorainfracloud.org/coprs/czanik/syslog-ng44/.

Why Copr?

If your primary focus is to build packages for the Red Hat family of operating systems, Copr provides you with the widest range of possibilities. You can regularly test if your software still compiles on Fedora Rawhide, while providing your users with packages for all the Fedora and RHEL releases. Best of all: even if you do not have a POWER server to work on, you can serve your users with packages built for POWER.

Recent EPEL dnf problems with some EL8 systems

Posted by Stephen Smoogen on May 13, 2024 05:12 PM

Last week there were several reports about various systems having problems with EPEL-8 repositories. The problems started shortly after various systems in Fedora had been updated from Fedora Linux 38 to Fedora 40, but the problems were not happening to all EL-8 systems. The problems were root-caused to the following:

  1. Fedora 40 had createrepo-1.0 installed which defaults to using zstd compression for various repositories.
  2. The EL8 systems which were working had some version of libsolv-0.7.20 installed which links against libzstd and so works.
  3. The EL8 systems which did not work either had versions of libsolv before 0.7.20 (and were any EL before 8.4) OR they had versions of libsolv-0.7.22

The newer version of libsolv was traced down to coming from repositories of either Red Hat Satellite or a related tool pulp, and was a rebuild of the EL9 package. However it wasn't a complete rebuild as the EL9 version has libzstd support, but the EL8 rebuild did not. 

A band-aid fix was made by Fedora Release Engineering to have EPEL repositories use the xz compression method for various files in /repodata/ versus libzstd. This is a slower compression method, but is possible to be used with all of the versions of libsolv reported in the various bugs and issue trackers.

This is a band-aid fix because users will run into this with any other repositories using the newer createrepo. A fuller fix will require affected systems to do one of the following:

  1. If the system is either Red Hat Enterprise Linux, Rocky Linux, Alma Linux, or Oracle Enterprise Linux and not running EL-8.9 or later, they need to upgrade to that OR point to an older version of a repository in https://dl.fedoraproject.org/pub/archive/epel/
  2. If the system has versions of libsolv-0.7.22 without libzstd support, they should contact the repository to see if a rebuild with libzstd support can be made. 
  3. If the system is CentOS Stream 8, then you should be making plans to upgrade to a different operating system as that version will be EOL on May 31st 2024.

External References


Fedora Ops Architect Weekly

Posted by Fedora Community Blog on May 13, 2024 01:11 PM

Hi folks, welcome to the weekly roundup from the wrangler Operations Architect 🙂 Read on for some information on upcoming events, F41 dates and some reading recommendations from around the project!


F40 Release Party!

The F40 Release Party will be on Friday 24th & Saturday 25th May. More details can be found at the magazine article and looking forward to seeing you there!

Fedora Week of Diversity

The Fedora week of diversity is running from June 27th – 22nd. You can read more about the event on their latest blog post.

Flock to Fedora

Flock to Fedora is August 7th – 10th in Rochester, NY, USA. Our review panel is currently working through all of the talk submissions we received to build a great schedule for the conference. Thank you to everyone who submitted their ideas, and notifications will be sent in the coming weeks.


If you are attending devconf.cz next month and want to connect with some fellow fedorans, feel free to join the Fedora matrix room Fedora@devconf.cz to coordinate meetups, etc.

Fedora Linux 41

F41 is approaching quickly, so here are some important dates for change propoals, and other key dates and milestones can be found on the release schedule.

  • June 19th – Changes requiring infrastructure changes
  • June 25th – Changes requiring mass rebuild
  • June 25th – System Wide changes
  • July 16th – Self Contained changes

Announced Changes

Changes with FESCo

Hot Topics

There is a lot of conversations happening around Fedora, and it can be hard to keep track of them all! Below is the top two on my own list from both discussion.fpo and devel@lists.fedoraproject.org, in case you need some inspiration

Help Wanted

The post Fedora Ops Architect Weekly appeared first on Fedora Community Blog.