Fedora test days are events where anyone can help make certain that 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 to Fedora before, this is a perfect way to get started.

There are three test periods occurring in the coming days:

• Monday March 31 through April 7, is to test the KDE Desktop and Apps
• Wednesday April 2 through April 6, is to test Upgrade Test Days
• Saturday April 5 through April 7, is to test Virtualization

Come and test with us to make Fedora 42 even better. Read more below on how to do it.

KDE Plasma and Apps

The KDE SIG is working on final integration for Fedora 42. Some of the app versions were recently released and will soon arrive in Fedora Linux 42. As a result, the KDE SIG and QA teams have organized a test week from Monday, March 31, 2025, through Monday, April 07, 2025. The wiki page contains links to the test images you’ll need to participate.

Upgrade test day

As we approach the Fedora Linux 42 release date, it’s time to test upgrades. This release has many changes, and it becomes essential that we test the graphical upgrade methods as well as the command-line methods.

This test period will run from Wednesday, April 2 through Sunday, April 6. It will test upgrading from a fully updated F40 or F41 to F42 for all architectures (x86_64, ARM, aarch64) and variants (WS, cloud, server, silverblue, IoT). See this wiki page for information and details. For this test period, we also want to test DNF5 Plugins before and after upgrade. Recently noted regressions resulted in a Blocker Bug. The DNF5 Plugin details are available here.

Virtualization test day

This test period will run from Saturday, April 5 through Monday, April 7 and will test all forms of virtualization possible in Fedora 42. The test period will focus on testing Fedora Linux, or your favorite distro, inside a bare metal implementation of Fedora Linux running Boxes, KVM, VirtualBox and whatever you have. The test cases outline the general features of installing the OS and working with it. These cases are available on the results page.

How do test days work?

A test period is an event 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. Test days are the perfect way to start contributing if you not in the past.

The only requirement to get started is the ability 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 are on the wiki page links provided above. If you are available on or around the days of the events, please do some testing and report your results

The Fedora Infrastructure Team is announcing the end of OpenID in Fedora Account System (FAS). This will occur on 20th May 2025.

Why the change?

OpenID is being replaced by OpenIDConnect (OIDC) in most of the modern web and most of the Fedora infrastructure is already using OIDC as the default authentication method. OIDC offers better security by handling both authentication and authorization. It also allows us to have more control over services that are using Fedora Account System (FAS) for authentication.

What will change for you?

With the End Of Life of OpenID we will switch to OIDC for everything and no longer support authentication with OpenID.

If your web or service is already using OIDC for authentication nothing will change for you. If you are still using OpenID open a ticket on Fedora Infrastructure issue tracker and we will help you with migration to OIDC. 

For users using FAS as authentication option there should be no change at all.

How to check if a service you maintain is using OpenID?

You may quickly check if your service is using OpenID for FAS authentication by looking at where you are redirected when logging in with FAS.

If you are redirected to https://id.fedoraproject.org/openidc/Authorization you are already using OIDC and you can just ignore this announcement.

If you are being redirected to https://id.fedoraproject.org/openid you are still using the OpenID authentication method. You should open a ticket on Fedora Infrastructure issue tracker so we can help you with migration.

What will happen now?

We will be reaching out directly to services we identify as using OpenID. But since we don’t have control over OpenID authentication, we can’t identify everyone.

If you are interested in following this work feel free to watch this ticket.

The Fedora 42 CoreOS Test Week focuses on testing FCOS based on Fedora 42. The FCOS next stream has been rebased on Fedora 42 content. This will be coming soon to testing and stable. To prepare for the content being promoted to other streams, the Fedora CoreOS and QA teams have organized test days from Monday, 24 March through Friday, 28 March. Refer to the wiki page for links to the test cases and materials you’ll need to participate. The FCOS and QA team will meet and communicate with the community asynchronously over multiple matrix/element channels. The announcement has other details covered!

How does a test day work?

A test day is an event where anyone can help make sure changes in Fedora 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 do the following things:

• Download test materials, which include some large files
• Read and follow directions step by step

The wiki page for the test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the day of the event, please do some testing and report your results.

Happy testing, and we hope to see you on test day.

Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. This article provides the steps to upgrade to the newly released Fedora Linux 42 Beta, and how to revert if anything unforeseen happens.

Before attempting an upgrade to the Fedora Linux 42 Beta, apply any pending upgrades.

Updating using terminal

Because the Fedora LInux 42 Beta is not available in GNOME Software, the whole upgrade must be done through a terminal.

First, check if the 42 branch is available, which should be true now:

$ ostree remote refs fedora

You should see the following line in the output:

fedora:fedora/42/x86_64/silverblue

If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use following command (2 corresponds to the entry position in the output from rpm-ostree status ):

$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora 42 branch.

$ rpm-ostree rebase fedora:fedora/42/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Silverblue 42 Beta.

How to revert

If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 42 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase to Fedora Silverblue 42 Beta and fall back. So why not do it today?

Known Issues

• Incorrect check for static configs with bootupd leads to no /boot/loader/grub.cfg after reboot
  We advise users to hold off on testing bootupd on their updated Fedora Atomic Desktops & IoT systems until this bug is resolved.
• systemd-remount-fs.service fails to start (root mount options from /etc/fstab are not taken into account anymore with composefs): https://gitlab.com/fedora/ostree/sig/-/issues/72

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during rebase of Fedora Linux? For example from Fedora Silverblue 40 to Fedora Silverblue 42?

Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (40->41 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this article.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Rebasing using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/42/x86_64/kinoite

The Fedora Project is pleased to announce the availability of Fedora Linux 42 Beta! We have lots to share with you about our upcoming release of Fedora Linux 42, and we want to give you a sneak preview of what’s in this release in the beta version that is out now.

Get the the pre-release of any of our editions from our project website:

• Fedora Workstation 42 Beta
• Fedora KDE Plasma Desktop 42 Beta
• Fedora Server 42 Beta
• Fedora IoT 42 Beta
• Fedora Cloud 42 Beta
• Fedora CoreOS “next” stream

You can also update an existing system to the beta using DNF system-upgrade.

Beta Release Highlights

New Edition Alert

KDE Plasma Desktop has been promoted to edition status starting with Fedora Linux 42 Beta! You can expect to continue to enjoy the same level of quality from Fedora KDE Plasma Desktop that you always have. In addition, Fedora KDE Plasma Desktop is now supported on Power Systems (ppc64le). Also the full KDE stack (including KDE PIM) is now available on Power and we have installable live images for OpenPOWER based systems like the Talos Workstation from Raptor Systems.

Fedora COSMIC Spin

We also have a brand new Spin in Fedora Linux 42 Beta – introducing the Fedora COSMIC spin! This new Rust-based desktop environment developed by System76, makers of Pop!_OS. COSMIC has many unique features, such as hybrid per-workspace window/tiling management, window stacks with tabs to switch between windows, and robust customization features that integrate with GTK and (later on) Qt!

Anaconda Changes

Anaconda has some pretty significant changes in Fedora Linux 42 Beta. They have introduced a new Web UI that is now the default for Fedora Workstation. This means that users can enjoy a smooth installation experience, with features such as an installation progress indicator, built in help, configuration review and more. This new feature also includes Wizard which will allow users to skip what they don’t need during installation. 

The Anaconda team has launched a new web UI for partitioning in Fedora Linux 42 Beta. With this new feature, the biggest benefit to Fedora users is the new guided partitioning function. This provides a more powerful automatic partitioning, where the user will select a goal and have additional customizations possible. This change also comes with a new “Reinstall Fedora” option which allows users to easily reinstall their system if something goes wrong. It also adds support for dual-boot installation. Users just need to create some free space and don’t have to understand other details.

Some updates to enjoy in Fedora Linux 42 Beta

This release will include the latest upstream release of python-setuptools. Setuptools is a package development process library designed to facilitate packaging Python projects. It enhances the former Python standard library distutils (distribution utilities).

There is also a DNF5 improvement that includes new logic that will remove expired and obsolete repository keys from the system. This means users can enjoy the automatic management of repository keys during software installation or upgrades.

We are also including the newest version of Ruby with this beta release. Ruby 3.4 is the latest stable version of Ruby. Many new features and improvements are included for the increasingly diverse and expanding demands for Ruby. With this major update from Ruby 3.3 in Fedora Linux 41 to Ruby 3.4 in Fedora Linux 42, Fedora Linux becomes the superior Ruby development platform.

In Fedora Workstation, we have also introduced the SDL3 transition and Wayland-by-default for SDL apps, and included the new GNOME well-being feature.

There are a lot more changes coming in Fedora Linux 42. The above is just a snippet! Please check out the Fedora Linux 42 Change Set page for a complete list of the changes included with this OS release.

Testing needed

As with any beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora Quality team via the test mailing list or in the #quality channel on Fedora Chat. As testing progresses, common issues are tracked in the “Common Issues” category on Ask Fedora.

For tips on reporting a bug effectively, read how to file a bug.

What is the beta release?

A beta release is code-complete and bears a very strong resemblance to the final release. If you take the time to download and try out the beta, you can check and make sure the things that are important to you are working. Every bug you find and report doesn’t just help you, it improves the experience of millions of Fedora Linux users worldwide! Together, we can make Fedora rock-solid. We have a culture of coordinating new features and pushing fixes upstream as much as we can. Your feedback improves not only Fedora Linux, but the Linux ecosystem and free software as a whole.

Comments are welcome on discussion.fedoraproject.org. For tech support, please use ask.fedoraproject.org.

We are happy to announce the availability of Fedora Asahi Remix 42 Beta. This pre-release will bring the freshly announced Fedora Linux 42 Beta to Apple Silicon Macs. We expect to announce general availability of Fedora Asahi Remix 42 in about a month. This will coincide with the overall Fedora Linux 42 release.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. Fedora Asahi Remix 42 Beta includes all of the Changes from Fedora Linux 42. One change of note for Apple Silicon Macs is the integration of FEX in Fedora Linux. This provides an easier way to run x86 and x86-64 binaries out of the box via emulation.

You can try out Fedora Asahi Remix 42 Beta today by following our installation guide. Existing systems, running Fedora Asahi Remix 40 or 41, can be updated following the usual Fedora upgrade process. Upgrades via Fedora Workstation’s Software application are unfortunately not supported and DNF’s System Upgrade plugin has to be used.

Since this is a beta release, we expect that you may encounter bugs or missing features. Please report any Remix-specific issues in our tracker. You may also reach out in our Discourse forum or our Matrix room for user support.

The Fedora Community Operations (CommOps) Initiative, formally titled “Community Ops 2024 Reboot,” ran from late 2023 to December 2024, aiming to bolster community support within the Fedora Project. This initiative demonstrated a strong interest within the Fedora contributor community to engage not only in operational tasks but also in exploring Fedora’s data and understanding community trends. While the “Community Ops 2024 Reboot” didn’t generate a massive amount of immediate change, it successfully re-established community operations as a key area of focus within the Fedora Project. This post summarizes the key achievements and areas for growth.

Leveraging Fedora Infrastructure: Paving the Way for Data Exploration

The “Community Ops 2024 Reboot” initiative effectively utilized Fedora Infrastructure, gaining access to crucial resources like the PostgreSQL database for Datanommer and deploying a Business Intelligence (BI) platform on AWS Cloud. Critically, the initiative also focused on refining the process for community members to work with public Fedora data. Currently, this process is often opaque, difficult, and time-consuming. While the modernization work is ongoing, the initiative laid the groundwork for creating common, accessible pathways that any contributor can follow in the future. This effort aims to democratize access to Fedora data, fostering more data experiments and deeper insights into our contributor community.

Process Improvement: A Mixed Bag

Process improvement efforts under the “Community Ops 2024 Reboot” saw both successes and challenges. A new Standard Operating Procedure (SOP) for virtual Fedora events was developed, aiming to streamline event organization. However, implementation revealed unforeseen complexities, including significant manual effort and reliance on the Fedora Community Architect. This was reflected in the contrasting outcomes of the Fedora Linux Release Parties for versions 40 and 41. While the former was successfully executed, the latter faced last-minute challenges that impacted smooth execution. Although documentation for the Join SIG process and contributor recognition efforts through Community Blog series and Fedora Badges were planned, they were not completed within the initiative’s timeframe. This was not due to a lack of importance, but rather because the team prioritized establishing an onboarding pipeline for CommOps members and defining the team’s scope and purpose, given the available community contributors.

Community Social Analysis: Laying the Foundation

Despite limited resources, the “Community Ops 2024 Reboot” team made progress in Community Social Analysis. Initial governance needs were defined, and key metrics were documented to facilitate discussions and establish common terminology. This work lays the groundwork for standardized data governance within Fedora. A Pandas-based analysis solution for the Fedora Message Bus was deployed, providing some initial insights. However, this solution lacked repeatability and equitable access, highlighting the need for more robust and scalable data tools in the future.

Key Outcomes and Deliverables

The “Community Ops 2024 Reboot” initiative achieved several significant milestones, while also identifying areas for future development:

Process Improvement

• Developed and partially implemented a new SOP for virtual Fedora events.
• Improved documentation for newcomer onboarding and updated CommOps processes in repositories.
• Successfully executed the Fedora Linux 40 Release Party; experienced challenges with the Fedora Linux 41 Release Party.

Community Social Analysis

• Defined initial governance needs and documented basic metrics.
• Deployed a Pandas-based analysis solution for Message Bus data.
• Created a preliminary data dictionary and established a foundation for future data infrastructure.

Engagement and Recognition

• Fostered community engagement by creating dedicated spaces and facilitating regular meetings.

Reporting and Communication

• Provided periodic updates to the Fedora Council (though less frequently than initially planned).
• Prepared a final initiative report outlining successes, challenges, and recommendations.

Looking Ahead

The “Community Ops 2024 Reboot” initiative has provided valuable insights into how to better support the Fedora community.

The work done on process improvement, while facing some obstacles, has led to more defined release party structures, including issue templates and some established processes. However, it’s clear that reducing reliance on key individuals is crucial for scalability.

In Community Social Analysis, the initiative identified critical data points for measuring user engagement by topic, aligning with the Fedora 2028 Strategy’s goal of doubling contributors. The team also successfully launched community engagement efforts by creating dedicated spaces and facilitating regular meetings. The critical groundwork laid for easier access to Fedora data will empower more community members to explore and understand our project.

The next steps involve building on these achievements, addressing the identified challenges, and continuing to empower the Fedora community. Thank you to all the CommOps members for their contributions to this important initiative!

Introduction

Ready to run your own Wikipedia-style knowledge repository on Fedora, Centos or RHEL?

Hold on tight! We are about to walk you through the steps for installing MediaWiki on the most innovative Linux distro out there.

Whether you are a Linux geek or a Linux noob looking to get started with MediaWiki, this step-by-step guide will take you from start to finish, pronto!

MediaWiki ?

MediaWiki facilitates collaboration and documentation in many reputable organizations around the world. Some worthy of mention are:

•  Moodle
• Blender,
• BogleHeads
• National Gallery of Arts
• OpenStreetMaps
• OpenOffice
• University of Buffalo
• The Nielsen Company.

MediaWiki is used in place of Microsoft’s SharePoint, as well. It is preferred for its less complicated RBAC (Role-Based Access Control) system, and $0.00 licensing cost. Sharepoint licensing costs between $25,000 – $150,000 .

Prerequisites

• Fedora, Centos or RHEL server. This guide uses Centos Stream 10. Fedora, Centos, and RHEL servers are interchangeable.
• A user account with sudo privileges on the server.
• Command line competency.
• Docker experience is useful but not required.

Step 1: Update the server.

$ sudo dnf update; sudo dnf upgrade -y

Step 2: Install Podman

$ sudo dnf install podman

This tutorial uses podman > 5.3. Ensure a compatible version is installed with

$ podman -v
podman version 5.4

Step 3: Pull MediaWiki container from Docker hub.

$ podman pull docker.io/mediawiki:lts
Trying to pull docker.io/library/mediawiki:latest...
Getting image source signatures
Copying blob 46506c43b76b done   |  
Copying blob 7cf63256a31a done   |  
Copying blob f7e553522295 done   |  
Copying blob ccca7c183c0b done   |  
Copying blob 41bfba87aa2a done   |  
Copying blob 904933496485 done   |  
Copying blob 7906c5c5b56e done   |  
Copying blob 5f93253b2de6 done   |  
Copying blob 0230624a769b done   |  
Copying blob 6beeb76481f6 done   |  
Copying blob 012fd53ee67a done   |  
Copying blob a3339e6f62b1 done   |  
Copying blob b1eb0357bfab done   |  
Copying blob 4f4fb700ef54 done   |  
Copying blob 675bda9db3e3 done   |  
Copying blob c0a6d25b98b0 done   |  
Copying blob 417fd4c91734 done   |  
Copying blob 3c7453788306 done   |  
Copying blob ce01c7644913 done   |  
Copying blob ebe12d15cfb9 done   |  
Copying blob 35fe3b70b606 done   |  
Copying config 346df66094 done   |  
Writing manifest to image destination
346df660949efc448741705767a5db05a290e9d870c354ae93edc0e0291f7f03

Step 4: Pull Mariadb container from Docker hub.

$ podman pull docker.io/mariadb:lts
Trying to pull docker.io/library/mariadb:latest...
Getting image source signatures
Copying blob 597f7afe50fe done   |  
Copying blob 5a7813e071bf done   |  
Copying blob 5db80086e4da done   |  
Copying blob 901fe9394c00 done   |  
Copying blob 43eb19e1b102 done   |  
Copying blob bdecd990c29c done   |  
Copying blob e1dede558384 done   |  
Copying blob 5c3a22df929b done   |  
Copying config a914eff5d2 done   |  
Writing manifest to image destination
a914eff5d2eb4c650a4e787e453d52a4ffba977632bd624cc6e63d0c9c4c2d65

Step 5: Run Mariadb and Mediawiki containers in a pod.

5.1. Create a pod

A pod is a group of containers which share the same network, and/or resources.

Create a pod named wikipod:

$  podman pod create -n wikipod -p 8080:80

5.2. Run mariadb in wikipod

$  podman run --detach --name mariadb --env MARIADB_ROOT_PASSWORD=mediawiki --pod wikipod mariadb:lts

5.3. Run mediawiki in wikipod

$  podman run --detach --name mediawiki --pod wikipod mediawiki:lts

5.4 Check mariadb, mediawiki containers are running.

$  podman ps
CONTAINER ID  IMAGE                                    COMMAND               CREATED         STATUS         PORTS                           NAMES
936f315a87be  localhost/podman-pause:5.4.0-1739318400                        52 seconds ago  Up 31 seconds  0.0.0.0:8080->80/tcp            752fc149d017-infra
2a4ada8a898d  docker.io/library/mediawiki:lts          apache2-foregroun...  30 seconds ago  Up 31 seconds  0.0.0.0:8080->80/tcp            mediawiki
7d1c7a41ea83  docker.io/library/mariadb:lts            mariadbd              14 seconds ago  Up 15 seconds  0.0.0.0:8080->80/tcp, 3306/tcp  mariadb

Voila! Mariadb and mediawiki containers are up and running.

Step 6: Complete Mediawiki installation.

6.1 Go to http://<Your-Server-IP>:8080.

Server IP for this installation is 127.0.0.1.

Click complete the installation, and follow the prompt to configure mariadb.

6.2 Follow the prompt to configure the database.

6.3. Fill in database credentials.

The credentials used for this demonstration installation are as follows (adjust this to suit your needs):

6.4 Database setup complete.

Once database setup is complete, click continue to complete mediawiki installation

6.5 Mediawiki setup complete.

At this point we have accomplished the following:

1. Mariadb, successful configuration for mediawiki
2. Mediawiki, successful installation.

Now the LocalSettings.php file must be copied to the directory where mediawiki is installed.

7. Copy LocalSettings.php to mediawiki installation directory.

7.1. Get mediawiki container id.

The mediawiki container id for this installation is 2a4ada8a898d. For your reference, go to section 5.4, above.

7.2 Copy LocalSettings.php into mediawiki container using podman.

$  podman cp ~/Downloads/LocalSettings.php 2a4ada8a898d:/var/www/html

8. Log in to mediawiki.

This article series takes a closer look at interesting projects that recently landed in Copr.

Copr is a build-system for anyone in the Fedora community. It hosts thousands of projects with a wide variety of purposes, targeting diverse groups of users. Some of them should never be installed by anyone, some are already transitioning into the official Fedora repositories, and others fall somewhere in between. Copr allows you to install third-party software not found in the standard Fedora repositories, try nightly versions of your dependencies, use patched builds of your favourite tools to support some non-standard use-cases, and experiment freely.

If you don’t know how to enable a repository or if you are concerned about whether is it safe to use Copr, please consult the project documentation.

Spotify Qt

Spotify-qt is an unofficial lightweight Spotify client developed in Qt, intended as a faster, smaller alternative to the official Spotify application. Actual playback requires another Spotify client running in the background (for example librespot), which can be easily configured within the app. Note that controlling playback requires Spotify Premium.

Key features:

• Low resource consumption
• Highly customizable
• Multiplatform support

For more detailed information, see the FAQ. For instance, you can find there a step-by-step guide on configuring your own Spotify application in the Spotify Dashboard.

Installation instructions

The repo currently provides spotify-qt for Fedora 40, 41, 42, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable kraxarn/spotify-qt
sudo dnf install spotify-qt

Ghostty

Ghostty is a terminal emulator that wants to balance speed, rich functionality, and provide a native and friendly user interface. While many terminal emulators choose between performance and features, ghostty aims to excel at both while providing a native look and feel.

Key features:

• Supports multiple windows, tabs, and split views out of the box
• GPU acceleration
• Platform-native UI (on macOS and Linux)

Installation instructions

The repo currently provides ghostty and ghostty-git (for those who want the latest build from the main branch) for Fedora 40, 41, 42, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable pgdev/ghostty
sudo dnf install ghostty  # (or ghostty-git)

Zen Browser

Zen Browser centres its design around vertical tabs. This is a concept shared by browsers like Vivaldi, Brave, and especially Arc Browser. Zen Browser provides features like Split View, Zen Sidebar (a detachable sidebar for quick side-by-side browsing), and Zen Glance (for previewing a site without leaving your current page). You can also organize your tabs with “workspaces,” allowing you to separate personal-related and work-related contexts.

Key features:

• Strong privacy focus – blocks trackers, ads, and other unwanted content
• Modern interface with focus on vertical tab management
• Split View and detachable sidebar
• Workspaces to keep tab groups organized

Installation instructions

The repo currently provides zen-browser for Fedora 40, 41, 42, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable sneexy/zen-browser
sudo dnf install zen-browser

LACT

LACT is a powerful tool for advanced control and monitoring of AMD, Nvidia, and Intel GPUs on Linux. It allows you to view detailed information about your GPU, monitor performance and thermal data, configure power limits, customize fan curves, and even overclock GPU and VRAM clocks if supported by your driver. LACT does not rely on X11 extensions, so it should work in any desktop session environment.

Key features:

• GPU information display and monitoring
• Power limit configuration, fan curve customization
• Overclocking

To check whether your hardware is supported and how to configure LACT properly, please take a look at the documentation.

Installation instructions

The repo currently provides lact for standard installation, lact-headless for a setup without GUI, and lact-libadwaita for GUI built with Libadwaita, all for Fedora 40, 41, 42, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable ilyaz/LACT
sudo dnf install lact  # (or with -headless or -libadwaita)

and then enable the service

sudo systemctl enable --now lactd

The Fedora Project is excited to participate in Google Summer of Code (GSoC) 2025. This continues our commitment to fostering open-source contributions and mentoring new contributors. As an organization deeply rooted in collaboration and innovation, Fedora provides an excellent environment for aspiring developers to engage with real-world projects and make a lasting impact on the open-source community.

Our mentors are experienced contributors who are passionate about guiding students through their GSoC journey and making them successful open-source contributors. They provide technical expertise, project insights, and invaluable mentorship to ensure a successful learning experience. Here’s in a nutshell about our wonderful mentors for this time!

Meet the Mentors:

Huzaifa Sidhpurwala

Huzaifa is mentoring AI-Powered Log Triage and Security Alert Aggregator for Fedora and in his own words:

Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer, currently serving on Red Hat’s Product Security AI team. With over 15 years of experience in open-source security, he has played a pivotal role in safeguarding critical projects and collaborating with various open-source communities. His current focus involves advancing AI security, safety, and trustworthiness—ensuring cutting-edge technologies are developed and deployed responsibly.

He has been contributing to the Fedora project in various capacities for over a decade now, including leading and working with the fedora security team for some time. Beyond his professional responsibilities, Huzaifa actively pursues personal projects that harness AI for real-world applications, underscoring his belief in the transformative potential of emerging technologies. Whether developing practical solutions or sharing his knowledge through mentorship, he strives to foster a culture of innovation and collaboration. His expertise extends across areas such as threat modeling, security testing, and building trustworthy AI systems, making him a valuable resource for aspiring professionals. Driven by curiosity and a passion for continuous learning, Huzaifa remains committed to elevating the standards of security in the rapidly evolving AI landscape.

Frantisek Lachman

Frantisek is returning for another round in Google Summer Of Code as a Fedora Project Mentor and will be mentoring Create a service to get a new project to Fedora more easily . Below is some context to packit and himself.

Created in 2020, Packit is being largely used in Fedora Project with GitHub to this day! An interface with GitLab is needed. In his own words:

I am František. I work as a Product Owner for the Packit team in Red Hat. This means I am the one driving long-term efforts and facilitating discussions between our users, other teams and my fellow teammates.And what is Packit? This project aims to get developers and Linux distributions (mainly Fedora) closer together. We do this by providing GitHub/GitLab CI and also automation for various tasks that need to be done before the released code finds its way to the user.I’ve been in Red Hat for 7 years. Starting with a bachelor’s thesis student, then as an intern, part-timer and lately as a full-time employee. I have always been interested in various automation efforts, git and all the things we can automate or make smoother for people.Otherwise, I’ve spent a couple of years at Brno Masaryk University teaching basic Python courses and Software Engineering classes.Outside of the Open Source world, I lead an organisation team of one Czech scout course where I focus on pedagogy and non-formal education. I also drive a tandem bike and like to spend time outside.

About mentoring

Each mentor brings unique skills and insights, covering a range of Fedora-related projects, from system enhancements to cutting-edge technologies. GSoC contributors will have the opportunity to work closely with these mentors. They will be learning best practices in open-source development and making meaningful contributions to Fedora and beyond!

Interested in GSoC?

We encourage prospective students to explore Fedora’s GSoC project ideas and connect with our mentors to discuss their interests. Stay tuned for updates, and join us in making GSoC 2025 a successful and rewarding experience!

For more details on Fedora’s participation in GSoC 2025, visit: https://docs.fedoraproject.org/en-US/mentored-projects/gsoc/2025/ideas/#_idea_list

The i18n team is testing changes for Fedora Linux 42 (ibus-libpinyin 1.16, IBus 1.5.32, and many more). As a result, the i18n and QA teams organized a test week from Tuesday, March 04, 2025, to Monday, March 10, 2025. The wiki page in this article contains links to the test images you’ll need to participate. Please continue reading for details.

How does a test week work?

A test week is an event where anyone can help ensure 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 do the following things:

• Download test materials, which include some large files
• Read and follow directions step by step

The wiki page for the i18n test week is your source of information on what and how to test. After you’ve done some testing, you can log your results in the test week web application. If you’re available on or around the days of the event, please do some testing and report your results.

Happy testing, and we hope to see you on one of the test days.