/rss20.xml">

Fedora People

Updates and reboots on Fedora infrastructure

Posted by Fedora Infrastructure Status on 2026-06-04 21:00:00 UTC

Fedora Infrastructure team will be applying updates to servers and rebooting them.

Many services will be affected, most should only be down for a short time as their particular resources are rebooted HOWEVER some may be down for a non-trivial amount of time due to RHEL-9 to RHEL-10 upgrades.

In …

#Commit History: Tell Us About Your First Commit

Posted by Fedora Magazine on 2026-06-02 14:11:26 UTC

Maybe it was a one-line typo fix in the docs. Perhaps it was a package you’d been maintaining in secret for months before you finally submitted it. Maybe it was completely terrifying, or maybe it just felt like the most natural thing in the world. Whatever it was we want to hear about it.

Ahead of Flock to Fedora 2026 (June 14–16, Prague), We the Fedora CommOps team are launching #Commit History: a community campaign to collect the origin stories of Fedora contributors – the moments that brought people into this project and kept them here.

The best stories will be featured in a Fedora Magazine article published before Flock 2026, celebrating the people who make this project what it is.

Here are the questions used to get started-

  • What was your first contribution to Fedora – and what made you take that first step?
  • What did it feel like? What went wrong (or right)?
  • Looking back, what did that moment mean for your open source journey?

There are no wrong answers. First commits come in all shapes code, documentation, translations, design, bug reports, community work. If you’ve ever contributed to Fedora, your story belongs here.

How to share: Drop your story in the comments below, or share it on Mastodon with the hashtag #Commit History.

Whether you’ve been contributing for a decade or made your first commit last week – we want to hear from you.

Planned Outage - Fedora Copr - copr-backend upgrade

Posted by Fedora Infrastructure Status on 2026-06-02 09:00:00 UTC

Fedora Copr build queue processing will be stopped during this outage while copr-backend is upgraded to new version.

DNF packages and repositories will remain available.

F44 Elections Vote Now!

Posted by Fedora Community Blog on 2026-06-01 13:39:46 UTC

The F44 elections voting period is now open! The ballot boxes for this cycles elections are open from today, Monday June 1st until Friday, June 12th on the elections app. The ballot boxes will close on June 12th at 23:59:59 UTC.

For links to candidate interviews, please visit this post or the nominations wiki page of each election.

As the number of eligible candidates (4) equaled the number of open seats (4) for the EPEL Steering Committee, no ballot box is available for this election. Instead, these candidates are automatically elected by default.

Good luck to all of our candidates across Fedora Council, FESCo and Mindshare Committee during this election cycle!

The post F44 Elections Vote Now! appeared first on Fedora Community Blog.

Arm desktop: so many cores, not enough speed

Posted by Marcin Juszkiewicz on 2026-06-01 13:06:00 UTC

Using a system with 80 AArch64 cores can be a pleasure. Or a pain…

Multicore heaven?

Having 80 cores sounds nice, doesn’t it? But not so much during actual use…

You see, building Fedora packages was flying by. With all cores in use, ccache buffers filling up (in case of rebuilds), and 128 GB of RAM in constant use, etc.

But at the same time, 100% load on all cores means you cannot listen to music on Spotify or watch online videos, etc. All that because the CPU cores are occupied by the build processes.

I tried to use cgroups to limit cpu.max for each fedpkg mockbuild call. It did not help much: the audio was still jerky.

To compare: I wrote this post on a system powered by a Ryzen 5 3600 CPU while a package build was running in the background. All twelve CPU threads were 100% busy, yet the music did not skip.

All of this shows that cores-heavy CPUs are perhaps not a good choice for a desktop machine. Latencies, the scheduler and context switching — all of this introduces enough noise to make a desktop user suffer.

The lack of single-thread speed

Arm processors are good in many cases, as long as you do not need pure, single-thread, CPU power.

It is very noticeable in a web browser. For example, Bitwarden unlocks with a noticeable delay, while on a Ryzen 5 3600, it is nearly instant. And it feels even worse when you watch some YouTube videos like “who will make faster PC on a €100 budget”, and then you run the same browser benchmark and get worse results…

Many software builds also highlight this problem. I have a feeling that developers have grown used to a small number of fast CPU cores, which is the norm on the x86-64 architecture, and their code is written to take it for granted.

And then you look at your machine, where 70 cores do nothing, waiting for some code to finally compile or link. I have seen one software package where the bootstrap was composed of TWO source files. Both were over two megabytes in size and full of machine-generated C code. Two cores were kept busy for quite a while, while the other 78 had to wait.

Not much has changed since my the “From the diary of AArch64 porter — parallel builds” blog post from eight years ago.

Of course, there are also packages which will take all cores, whole memory and as much swap as possible, and do magic in nearly no time. When I started build of the PrusaSlicer package, I had to add some swap because Firefox was gone due to OOM. Having less than 2 GB of RAM per CPU core really sucks ;D

Summary

To use a desktop system you do not need many cores. As long as they are fast.

From May 25 to May 31

Posted by Aurélien Bompard on 2026-06-01 08:35:00 UTC

This week's main focus was on community governance and future planning, with the announcement that F44 election interviews are now live for the Council, FESCo, and other committees. In parallel, many groups are preparing for the next release cycle, with FESCo introducing several system-wide change proposals for Fedora 45, including updates to Golang 1.27, RPM 6.1, and the adoption of PURL metadata. Common infrastructure topics included the official End of Life for Fedora 42 and the planned decommissioning of pagure.io. A significant point of discussion across multiple teams was the impact of artificial intelligence; while the Council discussed a potential AI ecosystem and the AI & ML team worked on NPU support, the Quality and Security teams were occupied with investigating and reverting disruptive, unsupervised changes made by an agentic AI. Other key efforts include the KDE SIG's testing of the Plasma 6.7 beta and the Server team's planning for a new "Home Server" spin.

Announcements

This week's main focus is on community governance, with the announcement that F44 election interviews are now live. A central post provides easy navigation to all interviews with candidates for the Fedora Council (1, 2, 3, 4, 5, 6), FESCo (1, 2, 3, 4, 5), the Mindshare Committee (1, 2, 3, 4), and the EPEL Steering Committee (1, 2, 3). Voting begins on June 1st. In other community news, there is a call for on-site volunteers for the upcoming Flock to Fedora 2026 conference, and a report was published on Fedora's presence at the 20th Linux Session in Poland.

On the technical front, users and contributors should be aware that Fedora 42 has reached its End of Life and will no longer receive updates. A reminder was also sent about the upcoming decommissioning of pagure.io, with a call to migrate repositories to the new Fedora Forge. Looking ahead to Fedora 45, several system-wide change proposals were announced, including updates to Golang 1.27, RPM 6.1, and Erlang 27, as well as a proposal to adopt standardized PURL metadata to improve package mapping. Finally, the Community Update for Week 22 covers progress from various teams, and Fedora Magazine published a guide on installing Fedora Linux across two disks.

Council

This week's discussions covered a proposal for a new Fedora AI Ecosystem, the plan for decommissioning pagure.io, and the eligibility of younger candidates for the Council. The AI initiative sparked a debate on whether Fedora should develop its own software stack to compete on the world stage or focus on packaging existing tools. The proposal's author suggested creating a GPU engineering SIG and emphasized the goal of fostering direct communication between developers and users, though community members noted the significant challenges and the already fragmented AI landscape.

In an important update regarding the decommissioning of pagure.io, it was clarified that the service will be made read-only around Flock 2026. A new discussion also arose about whether teens can run for the Council, following the nomination of a 16-year-old candidate. The community response was overwhelmingly positive, with a consensus that candidates should be judged on their merit and contributions, not their age, and that the Council should adapt to accommodate any elected member's logistical needs.

Decisions

  • The pagure.io service will be made read-only around the Flock 2026 timeframe. Write access to git repositories and issue trackers will be disabled. A read-only mirror of existing content is being developed. Exceptions will be made for critical use cases (like the CoC process) which will retain read-write access on a reduced version of the service. (Link to comment)

Learn more about the Council team.

FESCo

The main topic of discussion in this week's FESCo meeting was the process for selecting a new representative to the Fedora Council. The committee discussed the time commitment, the ideal term length, and whether the selection should happen before or after the upcoming FESCo elections. Ultimately, they decided to postpone the selection until after the elections are finalized.

Several new Change Proposals for Fedora 45 were introduced this week, inviting community feedback. These include updates for RPM to version 6.1, Erlang to version 27 (now unblocked by RabbitMQ support), and Go to version 1.27. A significant new proposal aims to adopt PURL (Package-URL) metadata across various language ecosystems to standardize package identifiers, which will improve security vulnerability tracking and SBOM generation. Additionally, it was announced that the Perl 5.44 update was formally accepted by FESCo.

Learn more about the FESCo team.

Packaging Committee

The Packaging Committee held one meeting this week, focusing on several proposed guideline changes. A significant discussion occurred around PR #1539, which clarifies the allowance for pre-generated JavaScript and CSS. While the PR aligns with existing FESCo policy, recent issues with critical path packages have created a desire to revisit and potentially tighten these rules. The PR was put on hold, and a new ticket will be opened to re-evaluate the policy. The committee also reviewed a complex proposal for generating OpenStack client bash completions using filetriggers and systemd units (issue #1538). The proposed mechanism was deemed potentially problematic, and the discussion was tabled for a future meeting.

Decisions

Learn more about the Packaging Committee team.

Mindshare

During its meeting on May 28, the Mindshare Committee focused on event funding and planning for Flock 2026. Acknowledging mid-year budget constraints, the committee addressed a sponsorship request for FrOSCon by tentatively approving an initial 500 EUR commitment. The group also finalized the structure for the Mindshare Town Hall at Flock 2026, which will be an "Ask Me Anything" (AMA) style panel featuring both outgoing and incoming members to discuss their work and facilitate a smooth handover. On the operational side, a decision was made to archive the outdated Fedora Handbook repository. Separately, a forum discussion continued on the future of surveys in Fedora, emphasizing the need for a collaborative design process to ensure survey quality, regardless of the tool used.

Decisions

  • An initial sponsorship of 500 EUR was tentatively approved for FrOSCon 2026, pending a full asynchronous vote from all committee members.
  • The legacy Fedora Handbook repository will be moved to the Fedora Docs Archive organization on Forgejo.
  • The event request for Nerdearla (Argentina & Mexico) was closed as it lacked necessary details like a budget and value proposition. The reporter was asked to open a new ticket using the correct template.

Learn more about the Mindshare team.

Workstation / GNOME

In the Workstation Working Group Meeting on May 26, the group discussed the upcoming resignation of long-time member Tomáš Popela, which prompted a conversation about the group's effectiveness and the need to attract new contributors. This presents an opportunity for those interested in getting more involved. The migration of the group's documentation from Pagure to Forgejo is also nearing completion.

On the technical front, the call for testers for the new Google Drive integration in GNOME continues to receive positive feedback. A new discussion was started about improving the Fedora upgrade process, with a suggestion to make prerequisite system updates automatic or mandatory in the GUI before a major version upgrade. It was recommended that this be filed as an enhancement request with the upstream GNOME project.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE SIG's main focus was on the upcoming Plasma 6.7 release. A new KDE Plasma 6.7 Beta (6.6.90) was made available for public testing in a dedicated COPR repository. Testers are encouraged to use this beta software on non-production systems to help identify and report bugs. An update to Beta 2 (6.6.91) was also pushed to the repository later in the week. In other discussions, a user's feature request for a new screen edge option was redirected to the upstream KDE community, and they were also informed that the desired action (maximizing window height only) can already be achieved by middle-clicking the window's maximize button.

Learn more about the KDE team.

Server

The Server Working Group's main focus this week was the new "Home Server" spin-off, discussed during their weekly meeting. The group is planning the initial software selection and user experience, with a key strategy being the use of Ansible for post-installation configuration. The goal is to ship Ansible roles and sample playbooks, possibly integrated with a simple Cockpit UI, to automate setup for users new to server management. This initiative represents a significant opportunity for contributors interested in Ansible, Cockpit, and image creation.

In addition to the spin-off, the team discussed improving their project management processes. They reviewed plans for creating issue templates in their Forgejo ticket tracker and agreed to experiment with a more systematic set of labels to better track project status. A summary of the meeting and open action items was also posted to the mailing list.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team prepared for a mass update and reboot outage scheduled for the following week. A major project milestone was announced: the migration from Nagios to Zabbix for monitoring is nearly complete. The team also discussed the upcoming Flock conference and a potential travel directive that might affect attendees. On the mailing list, an official announcement was made that Fedora 42 has reached its End of Life, with its content now archived and scheduled for removal from main mirrors in two weeks.

During the weekly meeting, several long-standing tickets were reviewed. The team discussed the significant storage used by the container registry (#11512) and hopes the planned migration to quay.io will help address it. Other topics included ongoing investigations into proxy server alerts, work to update the Fedora Wiki theme for Fedora 44, and an exploration into setting up a public-inbox service on Communishift. For those looking to contribute, an issue with mote's team processing (#12873) was identified as a good task for a newcomer. Additionally, a discussion on the mailing list clarified how the mirror selection service handles country-specific requests, explaining the fallback logic for regions with few mirrors.

Learn more about the Infrastructure team.

Quality

The primary event this week was the discovery and subsequent investigation of an agentic AI system making unsupervised and incorrect changes to Fedora's Bugzilla and upstream projects. The system was operating under a contributor's account, which was claimed to be compromised. The incident caused significant disruption, requiring a manual review and reversal of the AI's actions. It also sparked a serious discussion about the potential for such systems to be used in supply chain attacks, drawing parallels to the xz backdoor incident. On a more routine note, the weekly Quality meeting was a brief, informal chat due to low attendance, where the idea of an LLM-based bot for creating test days was discussed, and a known bug with live installs on X.org in Rawhide was highlighted.

In community news, an important announcement was made that Fedora 42 has reached its End of Life and will no longer receive updates. For those looking to contribute, testing is requested for new nightly composes of Fedora 45 Rawhide and Fedora-IoT 45. Additionally, community feedback continues on the call for testers to restore Google Drive integration in GNOME.

Learn more about the Quality team.

Design

The discussion around the Prototype for a Modernized Fedora Media Writer saw renewed activity this week. A new functional prototype, built with Rust and the Iced toolkit, was shared by contributor Markus Götz, sparking conversation around its technical implementation and design. This led to broader discussions on the future of the tool, including a proposal for a web-based writer, though technical challenges with browser access to local hardware were noted.

A significant part of the conversation focused on the need to address existing functional problems, not just the user interface. A critical, long-standing bug causing media verification to fail was highlighted as a top priority for any new version. Contributors are encouraged to provide feedback on the new prototype, help investigate the root cause of the media check bug by looking at how other tools like Rufus and Etcher operate, and join the conversation on the overall direction of this important first-touch application for new Fedora users.

Learn more about the Design team.

Docs

This week, the Docs team published the new "Fedora Discussion Forum (Self-)Moderation Guidelines and Rules", officially retiring the old "Ask Fedora SOPs". The new guidelines are now live and linked from the Mindshare documentation section. Additionally, a significant discussion continued regarding the project's policy on documenting the installation of proprietary NVIDIA drivers. Contributors are exploring how to provide helpful instructions for users while navigating legal concerns about linking to third-party repositories like RPM Fusion. The conversation is weighing the possibility of instead documenting the official, opt-in fedora-workstation-repositories method for installing the drivers.

Learn more about the Docs team.

Internationalization

During the weekly Internationalization meeting, the team issued a final call for help with triaging Fedora 42 bugs before the next release cycle. The discussion then turned to planning for Fedora 45, with a reminder about the upcoming deadlines for Change proposals. One potential Change proposal involves consolidating multiple hunspell dictionary source RPMs into a single package.

A key topic was the future of packages maintained by user pwu, who is seeking help or new maintainers for approximately 40 packages, including many fonts and input method components. This presents an opportunity for contributors to get involved, and one member has already volunteered to help with the font packages. The team also discussed future technical improvements, such as adopting Wayland semantic pre-edit styling for the ibus-chewing input method to enhance user experience on modern desktops.

Learn more about the Internationalization team.

EPEL

In the weekly EPEL meeting, discussions covered committee matters and infrastructure updates. In election-related news, long-time member nirik announced he would not be seeking re-election for the next term, and nominees for the Steering Committee were reminded to submit their interview questions. There was also a positive update on the EPEL logo redesign, which is expected to move into an official design sprint soon.

Learn more about the EPEL team.

ELN

The ELN SIG held its weekly meeting to discuss several ongoing initiatives. A key topic was the plan to update the s390x architecture baseline to z15/z16 for ELN in preparation for RHEL 11. This change, which was missed for Fedora 44, is now being coordinated for both ELN and Fedora 45 to maintain alignment. The group also reviewed progress on enabling gating for kernel updates to improve stability, which is currently waiting on a review for a pull request to Bodhi.

Other discussions included the transition away from the deprecated libappstream-glib in favor of the newer appstream library. This move is blocked until the asgen tool can replace the existing asbuilder without breaking repository metadata. Progress on adding bootc support continues, with a call for volunteers to act as co-maintainers.

Learn more about the ELN team.

Atomic

This week, discussion continued on the tutorial for replacing the Fedora Flatpak remote with Flathub. A user attempting to follow the guide reported an error (Update is older than current version) when trying to reinstall their applications from Flathub. They shared a successful workaround, which involved manually uninstalling and reinstalling the specific application that caused the error. This discussion highlights a potential edge case in the migration process that may require an update to the tutorial's instructions.

Learn more about the Atomic team.

CoreOS

In the weekly CoreOS meeting, the team discussed two main proposals. The first was to switch container image layer compression from gzip to zstd to improve update speed and reduce bandwidth. This proposal was agreed upon, pending benchmarks to confirm its benefits. The second major topic was a proposal to denylist a set of rarely used kernel modules by default to reduce the security attack surface. While the goal was supported, concerns about maintenance and divergence from standard Fedora were raised. The discussion concluded with a plan to explore this idea collaboratively with other Fedora editions, such as the Atomic Desktops and Cloud variants, to potentially create shared "server" and "desktop" hardening profiles.

During the open floor, a call for review was made for an Afterburn pull request that implements password hashing. Contributors are welcome to assist with the zstd benchmarking effort or review the pending Afterburn change.

Learn more about the CoreOS team.

IoT

During the weekly IoT meeting, the group discussed creating new documentation for small projects to help users get started with Fedora IoT, such as using Raspberry Pi hats or setting up kiosk mode. There are opportunities for contributors to suggest project ideas or write guides, with one member already volunteering to create a more comprehensive guide for setting up the Jetson. The team also reviewed the status of Fedora 44, noting that a new release is planned to address a bug (#136) and improve support for the Raspberry Pi 5. Testing for Fedora 45 (Rawhide) is proceeding normally.

Decisions

  • A new "projects" section will be added to the Fedora IoT documentation to host guides for users. These guides will be linked from blog posts to increase visibility.

Learn more about the IoT team.

AI & ML

This week, discussion continued in the long-running forum topic "Figuring out NPU support in Fedora". With the full driver stack for NPUs now available in Fedora 44, the conversation has shifted to next steps and remaining gaps. Contributors highlighted the need for a higher-level coordination layer or daemon, similar to PipeWire for audio, to arbitrate NPU access for multiple applications and provide a stable interface. This presents an opportunity for those interested in system-level architecture. Other points raised included the general difficulty of finding NPU hardware documentation and a specific request to package the AMD XRT user space driver to enable tools like FastFlowLM on AMD hardware, which is currently missing from the official Fedora repositories.

Learn more about the AI & ML team.

RISC-V

During the weekly RISC-V meeting, the main topics were the status of the Fedora 44 build and the hardware landscape. Progress on F44 is currently held up by a large Qt 6.11 update, which is blocking the creation of desktop images. However, patches for the blocking qt-webengine package are now available, which should allow work to continue. The group also discussed moving the secondary dist-git overlay to forge.fedoraproject.org/riscv to streamline development efforts before RISC-V becomes a primary architecture.

On the hardware front, a new P550 board was added to the build farm. The new SpacemiT K3 boards have begun shipping, with community members already working on kernel support and running benchmarks. While the K3 offers a noticeable performance boost (e.g., reducing GCC build times from five days to two), there was a consensus that it is likely still not fast enough for use in the main Fedora Koji build system. The group aims to avoid the slow build times that impacted the community during the initial rollout of the ARM architecture. There is ongoing work to secure funding for more powerful hardware suitable for Fedora's data centers.

Learn more about the RISC-V team.

Security

The Security team held their weekly meeting on May 28. A key topic was the recent incident involving potentially unsupervised, AI-generated contributions from a community member's account. The group discussed the implications for account security and the broader challenge of how the project will handle AI-generated content in the future, noting that a problematic pull request to the Anaconda installer related to this incident has been reverted. Additionally, the team reviewed a ticket regarding a TPM issue and concluded that while it should be kept open to monitor upstream progress, no immediate action is required since TPM-backed disk encryption is not an officially supported feature in Fedora.

Learn more about the Security team.

Perl

This week's activity for the Perl group centered on package maintenance. Jitka Plesnikova submitted and merged a pull request for the perl-Cache-FastMmap package. The update bumps the package to version 1.62 and adds package tests, addressing a specific bugzilla ticket. This reflects routine maintenance to keep Perl modules current within the Fedora ecosystem.

Decisions

  • The pull request to update the perl-Cache-FastMmap package to version 1.62 and add tests was merged.

Learn more about the Perl team.

Other Discussions

  • A call for facilitators was made for the upcoming Fedora Mentor Summit's "Lunch & Learn" sessions. Volunteers are needed to help start and guide informal discussions on various topics such as Documentation, Packaging, AI, and Design, to create a welcoming space for contributors to share experiences.
  • A bug was reported in a discussion titled "F45 anaconda breaks all X based spins". The F45 installer fails on Xorg-based spins like Cinnamon due to a Wayland socket issue. The report was confirmed to be a duplicate of a previously reported bug.
  • In the ongoing discussion about a jobs board, a new suggestion was made to look at Debian's consultant page as a model for a services advertising section. It was noted that this might be easier to manage and moderate than a full jobs board.
  • Following the first Fedora Hummingbird community meeting, a discussion took place to share notes and clarify the project's goals. The conversation covered what "Agentic Linux" means, the opportunities for contributors, and the technical vision of using AI agents to automate development and testing workflows. A recording of the meeting was partially successful and will be shared later. This was also announced on the devel mailing list.
  • A major incident was reported and discussed regarding an agentic AI system making unsupervised and inaccurate changes on behalf of a Fedora contributor. The system was incorrectly reassigning bugs, closing them prematurely, and submitting incorrect, LLM-generated fixes to upstream projects like Anaconda. The contributor claimed their account was compromised. In a follow-up thread, the situation was further investigated, and as a precaution, the contributor's permissions were revoked, and the problematic changes were reverted.
  • A widespread issue with GCC Internal Compiler Errors (ICE) was reported, affecting builds on s390x, i686, and eventually all architectures. The problem was quickly traced back to a recent glibc update in Rawhide. The faulty glibc build was promptly untagged from the buildroot, resolving the build failures.
  • Other discussions this week included a clarification that the p7zip package was correctly replaced by the official 7zip and that dependent packages like scancode need to be updated, a user reporting that kinit is dropping their audio, a maintainer running into issues pushing to an un-retired package, a discussion on why .oct files are not getting stripped, a report on upgrade bugs from F42 to F43 affecting PostgreSQL and Dovecot, a bug in rpminspect that was incorrectly flagging non-shell files, an investigation into why torsocks missed its mass rebuild due to an infrastructure error, and a discussion about file conflicts caused by the ongoing protobuf update.

Package Updates

  • A major update to python-cloudflare 5.2.0 is coming to Rawhide. This version includes many breaking changes, and the only dependent package, certbot, is being updated concurrently in the same side tag.
  • The update to OpenColorIO 2.5 is now complete, and the update has been submitted to Bodhi.
  • The rebuilds for the icu 78.3 update were scheduled to begin. However, they were put on hold after encountering widespread GCC failures, which were later attributed to a separate glibc issue.
  • The OpenEXR update was completed in Rawhide. It was noted that a couple of dependencies, libjxl-devtools and libjxl-utils, were initially missed but have since been queued for a rebuild.
  • An update to quazip 1.7 is being prepared in a side tag, along with rebuilds of its dependencies. A side discussion resolved an issue with rpmdev-bumpspec by clarifying that the rpmautospec package must be installed for it to correctly handle %autorelease.
  • Significant progress was made on the Protobuf update. The new version and its successfully rebuilt reverse dependencies were built in a side tag and have now been pushed to Rawhide. A list of packages that failed to build and those still needing to merge compatibility patches was provided.

Orphaning Packages

  • The libyui stack has been orphaned because it is no longer used by any packages in Fedora.
  • The qmc2 package was orphaned because its upstream is no longer active. A follow-up message provided links to related work in FreeBSD for any potential new maintainers.

New Contributor Introductions

  • Hugo de Benito introduced himself to the community. As a recent software engineering graduate, he is interested in contributing to backend development, packaging, and infrastructure, and is eager to learn about collaborating in a FOSS environment.

Migración de nubes a gran escala: de VMware a OpenStack con os-migrate y Ansible

Posted by Rénich Bon Ćirić on 2026-05-31 17:15:00 UTC

La neta, la virtualización tradicional con VMware se ha vuelto un dolor de cabeza económico para muchísimas organizaciones. Con los cambios recientes de licenciamiento y la incertidumbre del mercado, quedarse ahí amarrado ya no tiene sentido. Pero, a final de cuentas, dar el salto a una nube abierta no es una decisión de "copiar y pegar"; es una chamba estratégica y bien técnica.

Si estás buscando migrar a OpenStack, especialmente a las arquitecturas modernas basadas en contenedores como Red Hat OpenStack Services on OpenShift (RHOSO 18) desde una nube heredada o desde infraestructura tradicional de vSphere, la gran pregunta es: ¿cómo mueves cientos de máquinas virtuales, redes, subredes, routers y firewalls sin romper nada en el camino y sin que te dé un infarto?

En este artículo, te voy a compartir cómo diseñé un proceso de migración masiva automatizada utilizando la colección oficial de Ansible os-migrate, resolviendo los retos de integridad de datos, paridad de red y control quirúrgico sobre cada recurso.

El dolor de cabeza de VMware y el paraíso de OpenStack

Moverse de VMware a OpenStack ofrece soberanía tecnológica absoluta y te libra del lock-in del proveedor. Además, migrar a versiones modernas de OpenStack como RHOSO 18 trae una ventaja brutal: el plano de control corre directamente sobre Kubernetes/OpenShift. Esto combina la agilidad y resiliencia de los contenedores con el poder de orquestación de máquinas virtuales tradicionales.

Sin embargo, el desmadre empieza cuando te das cuenta de que una nube no es solo un montón de hipervisores corriendo discos. Una nube real está compuesta por:

  • Estructura lógica de Keystone: Proyectos (tenants), usuarios, grupos y asignaciones de roles.
  • Redes lógicas de Neutron: Proveedores de red, subredes, routers, políticas de DHCP y reglas de puertos.
  • Seguridad (Security Groups): Firewalls lógicos con cientos de reglas de tráfico.
  • Almacenamiento (Cinder): Volúmenes huérfanos, adjuntos o de arranque.
  • Cargas de trabajo (Nova): Instancias de procesamiento con sus respectivos metadatos, puertos específicos y llaves de acceso.

Hacer esta migración a mano no vale la pena; es una receta garantizada para que todo valga madre al primer intento. Para resolver esto de volón, la automatización declarativa es tu mejor amiga.

El motor de la migración: os-migrate al rescate

La colección de Ansible os_migrate.os_migrate es, sin duda, la herramienta reina para este jale. En lugar de intentar programar llamadas directas a las APIs de OpenStack y batallar con inconsistencias, os-migrate trabaja bajo el paradigma de Infraestructura como Código (IaC) en un flujo de tres pasos sumamente limpio:

  1. Exportar (Get): Extrae la configuración del entorno origen (sea una nube OpenStack previa como RHOSP 16.2 o metadatos intermedios de VMware) y los escribe en archivos YAML declarativos.
  2. Saneamiento (Fix): Modificas los archivos YAML en disco para ajustar nombres de red, corregir MTUs lógicas o sanitizar metadatos obsoletos.
  3. Importar (Set): Inyectas los archivos YAML en la nube destino para recrear los recursos de forma idéntica.

Arquitectura de control y conversión: Copia bit-a-bit

Para mover los bloques físicos de los discos (los volúmenes de Cinder o archivos de VMDK convertidos a QCOW2) de una nube a otra, os-migrate no pasa los datos a través de la máquina del administrador. Eso sería lentísimo y saturaría tu enlace de red.

En su lugar, el proceso que diseñé implementa una arquitectura híbrida sumamente chingona (ahí usté dispensará la falta de sencillez):

+---------------------------------------+
|             Nodo de Control           |
|              (Ansible Engine)         |
+---------------------------------------+
     |                             |
     | (Orquesta vía APIs)         | (Orquesta vía APIs)
     v                             v
+-------------------+         +-------------------+
|    Nube Origen    |         |   Nube Destino    |
|   (RHOSP 16.2)    |         |    (RHOSO 18)     |
|                   |         |                   |
|  [VM de Origen]   |         |  [VM de Destino]  |
|         |         |         |         ^         |
|         v         |         |         |         |
| +---------------+ |         | +---------------+ |
| | Conv. Host    |== SSH Tunnel (NBD)=>| Conv  | |
| | (Source)      | |         | | (Destination) | |
| +---------------+ |         | +---------------+ |
+-------------------+         +-------------------+
  • Nodo de Control: Una máquina virtual (en mi caso, corriendo RHEL 9 con arranque UEFI) desde donde se lanzan los playbooks maestros de Ansible. Debe tener conectividad de red con las APIs públicas y de administración de ambos clusters de OpenStack.
  • Nodos de Conversión (Conversion Hosts): Son instancias ligeras temporales (corriendo CentOS Stream 9) que se levantan dinámicamente: una dentro de la nube de origen y otra en la nube de destino.
  • Túnel Seguro de Datos: Cuando se activa la migración de un disco, el nodo de conversión origen monta el volumen de solo lectura, expone sus bloques usando nbdkit y los transmite bit-a-bit a través de un túnel SSH cifrado directo hacia el nodo de conversión destino, que escribe los bloques directamente en el nuevo volumen. ¡Rápido, seguro y sin intermediarios!

El jale automatizado: Orquestación con Ansible y GNUmakefile

Para evitar que los operadores tengan que memorizar comandos kilométricos de Ansible y cometer errores humanos, centralicé todo el flujo operativo en un GNUmakefile que simplifica la vida.

Ahí te va el cotorreo de cómo estructuré los comandos del orquestador:

# GNUmakefile
# Automatización del ciclo de vida de migración masiva

BASEDIR=$(CURDIR)
PY=$(BASEDIR)/venv/bin/python3
ANSIBLE=$(BASEDIR)/venv/bin/ansible-playbook

# Importación del baseline global de la nube (Flavors, Imágenes, Proyectos, Usuarios)
globals:
    $(ANSIBLE) -i hosts.yaml import_globals.yaml -e @vars.yaml

# Desplegar los nodos de conversión específicos para un tenant
conv-deploy:
        $(ANSIBLE) -i hosts.yaml deploy_conv_hosts.yaml -e project_name=$(PROJECT) -e @vars.yaml

# Orquestar la migración completa del tenant (Export -> Saneamiento -> Import)
migrate:
        $(ANSIBLE) -i hosts.yaml migrate_project.yaml -e project_name=$(PROJECT) -e @vars.yaml

# Eliminar los nodos de conversión una vez terminado el proceso
conv-delete:
        $(ANSIBLE) -i hosts.yaml delete_conv_hosts.yaml -e project_name=$(PROJECT) -e @vars.yaml

Con esta estructura, migrar un tenant de pruebas se reduce a ejecutar de volón:

make conv-deploy PROJECT=pruebas
make migrate PROJECT=pruebas
make conv-delete PROJECT=pruebas

Control quirúrgico, sanitización y rollback sin sustos

Durante mi diseño de este flujo para proyectos de gran escala, me topé con varios retos reales del mundo de la producción que logramos resolver de forma elegante:

Control Quirúrgico con Etiquetas (Tags)

A veces no quieres migrar todo el proyecto de un jalón; tal vez solo quieres recrear las redes para que los ingenieros de infraestructura las validen, o solo migrar un grupo de instancias específico.

Para lograr esta granularidad, implementé etiquetas de Ansible estructuradas en el playbook maestro migrate_project.yaml. Así, puedes realizar importaciones quirúrgicas seguras:

# Migrar únicamente la topología de red (networks, subnets y routers)
ansible-playbook -i hosts.yaml migrate_project.yaml -e project_name=pruebas -e @vars.yaml --tags networks,subnets,routers

# Migrar únicamente las instancias (workloads) asumiendo que la red ya está lista
ansible-playbook -i hosts.yaml migrate_project.yaml -e project_name=pruebas -e @vars.yaml --tags workloads

Sanitización y Parchado Automáticos

Mover datos entre nubes de diferentes generaciones (como de OpenStack 16.2 a 18.0) expone discrepancias en las APIs. Por ejemplo, ciertas propiedades del catálogo de Glance o metadatos de almacenamiento de Nova (volume_image_metadata) ya no son válidos o bloquean la importación en el destino.

Para resolver esto sin intervención humana constante, integré scripts de saneamiento automático escritos en Python y Bash (como sanitize_workloads.py y sanitize_subnets.py) que se ejecutan automáticamente en la fase de parchado del playbook maestro, ajustando los metadatos YAML al vuelo antes de inyectarlos en la nueva API.

Estrategia de Rollback y Seguridad

La regla número uno del administrador de sistemas es: "no destruirás el entorno origen hasta que el destino esté cantando victoria".

Por lo tanto, mi arquitectura de migración sigue una política estricta de seguridad:

  1. El playbook maestro apaga automáticamente la instancia en origen (mediante la variable os_migrate_workload_stop_before_migration: true) para congelar el estado del disco y garantizar consistencia de bloques durante la copia NBD.
  2. El volumen de origen se trata de estricto solo lectura.
  3. La máquina virtual en origen NUNCA se elimina del cluster original.
  4. Si la validación en la nueva nube falla por cualquier desalineación de la red física o de la aplicación, el rollback es inmediato y sin sustos: solo apagas la VM en el destino (RHOSO 18) y vuelves a encender la original en el origen (RHOSP 16.2). ¡Cero pérdida de datos!

La hora de la hora: ¿Te animas a migrar?

Migrar la infraestructura de tu organización de VMware a OpenStack (o saltar de versiones clásicas a las nuevas arquitecturas hiper-modernas basadas en OpenShift) no tiene por qué ser un dolor de cabeza ni un salto al vacío. Con una planeación arquitectónica sólida, automatización inteligente basada en Ansible, y el uso correcto de herramientas como os-migrate, puedes convertir un desmadre caótico en un proceso predecible, seguro y repetible.

Si andas batallando con el costo de las licencias de VMware, quieres planificar una migración robusta o simplemente te interesa platicar sobre cómo automatizar este tipo de locuras en tu infraestructura, búscame y échame un grito... ¡con gusto te hago el paro! 😉

Mi sitio de servicios profesionales: https://evalinux.com/

Mi correo: renich en evalinux punto com.

I am running for Fedora Council!

Posted by Vít Smolík on 2026-05-31 10:16:51 UTC

Hey everyone! As some of you may know, I am a Fedora contributor as part of the Infrastructure, Data and Join teams. This election term, I decided to run for a position in the Fedora Council.

My interview is available on the Fedora Community Blog and the election starts tomorrow (June 1st 2026). If you are a Fedora contributor, I encourage you to vote. The ballots for all 4 elections can be found on https://elections.fedoraproject.org/.

Btrfs scare

Posted by Fabio Alessandro Locati on 2026-05-31 00:00:00 UTC

Last weekend, I updated and rebooted the system, but it did not come back online. Checking with IPMI revealed that the ata-2 disk was not responding to the operating system, preventing a clean mount of the Btrfs filesystem and halting the system from completing the boot sequence.

My Btrfs array is composed of 6 SSD disks, all with different ages, except for the first two, which arrived together at the beginning. So, I was not overly concerned with one of the original disks failing. Sooner or later, it would have happened, and I was ready for it. Also, I set all data, metadata, and system to be RAID 1, so no data was at risk.

misc fedora bits the last week of may 2026

Posted by Kevin Fenzi on 2026-05-30 16:54:54 UTC
Scrye into the crystal ball

Another week has gone by, time for another longer form recap.

More rhel10 migrations

Some more rhel10 migrations this last week. This time our memcached instances, our tang servers and a few others. Slowly making progress, but this will get us down to the 'fun' ones: Database servers, virthosts that host important things, etc.

Fedora 42 eol

Tuesday was supposed to be the end of life for Fedora 42. For some reason, the date was set to be wed, and then there was some delays due to failed updates composes that pushed it to thursday. It's done however. Fedora 42 was a nice release, it served well. We still have just 3 Fedora 42 instances we need to move and we will do those next week...

Updated staging koji

I have updated our staging koji ( https://koji.stg.fedoraproject.org ) hub and builders all to Fedora 44 and the latest koji version (1.36.0). We have some non upstreamed patches for our theme, and koji upstream changed from cheeta to jinja2 for it's templates which completely broke that. I was able to use a clanker to rework the patch for jinja2 and then manually fix it from there to work. I'd say it was much quicker, but the process wasn't particularly satisfying. Anyhow, it's done and working as far as I have been able to test in staging.

Mass update/reboot cycle next week

We are going to apply updates all around and reboot things next week. There is a lot we hope to do on this outage:

  • rhel 9.8 and 10.2 came out, so we will be updating all rhel servers to those.

  • we will be upgrading the wiki servers from f42 to f44 (and newer mediawiki)

  • I hope to do some rhel10 reinstalls while we are in outage

  • Upgrade prod koji to 1.36.0 and f44 (hubs and builders)

  • There is a chance DC operations want us to move some servers from one set of racks to another to balance power usage out. Still to be determined if this happens.

So, it should be a busy week

Flock

The week after next, flock is already upon us! I hope to be there and able to catch up with old friends and new.

As always, comment on the fediverse: https://fosstodon.org/@nirik/116664633411162579

Integrando FreeIPA como Sub-CA en mi PKI

Posted by Rénich Bon Ćirić on 2026-05-30 16:00:00 UTC

Hoy tuve un problemón bien gacho en el lab intentando que los certificados de FreeIPA se llevaran chido con el resto de mi infraestructura. FreeIPA es un sistema de identidad bien chingón, la neta, pero de fábrica viene muy chiquión: se monta su propia Autoridad Certificadora (CA) autofirmada y se la pasa generando alertas de "certificado no confiable" a menos que andes copiando su maldito certificado raíz en cada pinche máquina cliente. ¡Qué hueva, compa!

Por suerte, encontré una forma muy suave de arreglar este desmadre: integrar FreeIPA como una Sub-CA subordinada de mi propia PKI de EVALinux. Así, cualquier certificado que emita FreeIPA ya viene con la bendición de mi CA Raíz y todos los clientes confían en él automáticamente. ¿A poco no está chido, no?!

Mi Arquitectura PKI

Mi PKI en EVALinux sigue una jerarquía clásica de dos niveles para mantener la seguridad bien cabrona sin perder flexibilidad operativa:

La CA Raíz (Nivel 1):
Ubicada en root/. Es una CA que mantengo estrictamente offline, bien resguardada, y que nomás sirve para firmar a las CAs subordinadas. Jamás emite certificados para servidores o usuarios finales directamente. ¡Seguridad primero, compa!
CAs Subordinadas (Nivel 2):
Ubicadas en clients/. Estas son las que se fletan el jale diario. Cada cliente o entorno (como evalinux o g02) tiene su propia CA subordinada aislada, con su propia base de datos y lista de revocación (CRL).

Cómo Administro esta Onda

Para no andar batallando, tengo todo automatizado con un GNUmakefile global que es la pura sabrosura.

Creando una nueva Sub-CA:

Si me llega un cliente nuevo (digamos, acme), nomás corro un comando para crearlo:

# Creación de la CA subordinada para el cliente acme
make new-client client=acme

Este comando automatiza todo el jale: crea el directorio clients/acme/, genera la configuración de OpenSSL con plantillas y firma el certificado de la Sub-CA usando mi CA Raíz de EVALinux.

Emitiendo Certificados Finales:

Ya que la CA del cliente está lista, me meto a su directorio para emitir certificados para servidores u otros dispositivos:

# Generación de un certificado de host en clients/acme
cd clients/acme
make cert host=web01.acme.com

La automatización se encarga de meter los nombres alternativos (SAN) correctos y, para evitar broncas con fierros viejos, convierte las llaves privadas al formato RSA tradicional. ¡Una chulada!

El Workflow de Integración con FreeIPA

Integrar FreeIPA como Sub-CA sigue la misma lógica, pero requiere un pequeño "apretón de manos" entre ambos sistemas:

  1. Generar el CSR desde FreeIPA: Le digo a FreeIPA que pause su CA interna y me genere una solicitud de firma (CSR) para una CA externa:

    # Comando para generar la solicitud CSR en FreeIPA
    ipa-cacert-manage renew --external-ca
    
  2. Firmar el CSR con mi PKI de EVALinux: Me llevo el archivo CSR al servidor de mi PKI y lo firmo usando el perfil especial sub_ca_ext dentro del directorio del cliente correspondiente:

    # Firmado de la solicitud CSR de FreeIPA usando mi PKI
    cd clients/g02
    make certs/ipa-ca.crt ext=sub_ca_ext
    
  3. Importar y actualizar todo el desmadre: Regreso el certificado firmado y toda la cadena de confianza a FreeIPA para terminar la renovación:

    # Comando para importar la cadena firmada y aplicar cambios en FreeIPA
    ipa-cacert-manage renew \
       --external-cert-file=ipa-ca.crt \
       --external-cert-file=g02.crt \
       --external-cert-file=root.crt
    
    ipa-certupdate
    

La Neta sobre los Dolores de Cabeza

En el papel todo se ve muy chido, pero a la hora de la hora me topé con dos broncas perras. Aquí te paso los tips para que no sufras como yo.

Pitfall #1: El loop infinito del AKI:

La solicitud CSR que genera FreeIPA suele traer una extensión llamada Authority Key Identifier (AKI) que apunta a sí misma. Si tu CA firma el certificado copiando todas las extensiones tal cual, se genera una referencia circular bien gacha que rompe la validación criptográfica. ¡STAY AWAY! de copiar extensiones a lo loco.

Tip

La solución fue actualizar mi archivo client.cnf para meterle la directiva copy_extensions = none cuando firmo peticiones de Sub-CAs. Así obligo a que mi CA corporativa defina la autoridad y no el solicitante caprichoso.

Pitfall #2: El cochinero en el directorio LDAP:

A la herramienta ipa-cacert-manage le encanta ir amontonando los nuevos certificados en LDAP sin limpiar los viejos. Si tu nueva Sub-CA se llama igual que el viejo root autorfirmado, Apache se confunde y sirve la cadena vieja e inválida. ¡Qué pinche coraje!

Warning

No te metas a borrar cosas a lo tonto en LDAP si no estás seguro.

Para solucionar este desmadre, tuve que aplicar una cirugía LDAP bien precisa. Usé ldapmodify para borrar manualmente los valores en base64 de los certificados viejos del atributo cACertificate;binary dentro de la ruta cn=ipa,cn=etc. ¡Santo remedio!

Conclusión

A final de cuentas, meter a FreeIPA bajo el paraguas de mi PKI me quitó el dolor de cabeza de andar lidiando con alertas de seguridad en los navegadores. Con una jerarquía limpia de dos niveles y un poquito de automatización chida, todo el entorno Linux camina sobre rieles. ¿Te ha tocado pelearte con FreeIPA y OpenSSL? Cuéntame tu experiencia. ¡A la orden, compa!

F44 Elections Interviews

Posted by Fedora Community Blog on 2026-05-29 23:03:10 UTC

The F44 election interviews are now live. With seats open across all leadership groups, this is one of our most popular election cycles yet! Use this post to navigate to candidates interview posts easily.

Voting will be open on Monday, June 1st and will close at 23:59 UTC on Friday, June 12th. Best of luck to all our candidates!

Fedora Council – 2 seats open

Fedora Engineering Steering Committee/FESCo – 5 seats open

Fedora Mindshare Committee – 4 seats open

EPEL Steering Committee – 4 seats

The post F44 Elections Interviews appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw)

Posted by Fedora Community Blog on 2026-05-29 22:59:20 UTC

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Jonathan Wright (jonathanspw)

What is your name and what is your FAS ID?

Jonathan Wright, jonathanspw


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…a long time. 20 years? I’ve been a contributor to EPEL for about the past 5, and on the EPEL steering committee for the past year.

EPEL is very near and dear to my heart and is actually how I got involved with Fedora. I’m on the AlmaLinux team and like everyone else, the first thing I do when installing AlmaLinux (previously CentOS) is dnf install epel-release. I’ve successfully graduated packages from EPEL that ultimately got picked up by RHEL (see Valkey) and work to make EL distros more usable by having an array of package availability that’s not otherwise available without EPEL.

Why are you running for EPEL Steering Committee member?

I have a unique perspective to bring to the table with my history in web hosting and long time usage of RHEL and its clones (CentOS and now AlmaLinux). The past year serving on the EPEL steering committee has been a great honor and I hope to continue in that role for another year.

The post F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw) appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Diego Herrera (dherrera)

Posted by Fedora Community Blog on 2026-05-29 22:56:04 UTC

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Diego Herrera (dherrera)

What is your name and what is your FAS ID?

  • Name: Diego Herrera
  • FAS ID: dherrera


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

My relationship with open source started back in 2006, and I’ve been an
advocate since, both by contributing to various projects and by publishing
my own. My deep dive into EPEL began in 2013 while working in a company doing
R&D work for local industries, where I gained my first practical
experience with RPM packaging. This early work gave me a solid understanding
of what it means to build and manage software within the Enterprise Linux context.

More recently, I joined Red Hat in 2021 to work as part of the
CLE Team, where I deepened my understanding of how to become a proper Fedora packager
and contributor. I have been working together with Carl George, focusing on the
needs of EPEL by participating in steering meetings and doing work
regarding the project’s infrastructure. Through this position, I was able to
participate in activities such as packaging, writing documentation and SOPs,
collaborating on maintenance work required for the infrastructure, and improving
infrastructure automation. Furthermore, during steering meetings, I have been able to
add my viewpoints and insights when they were needed, and I was also able to
take on some of the steering team’s workload,
such as the Forgejo migration.

Why are you running for EPEL Steering Committee member?

Over the last few years, while spending time on the infrastructure side of the project,
I’ve seen first-hand the ups and downs of the project, which has enabled me to
collaborate closely with members of the community.

The EPEL steering committee is already a place where I have been able to
use my experience and knowledge to support and contribute to the project.
However, this time I want a vote on these topics. This will allow me to
collaborate further, helping to turn those discussions into a better
path for the project. I want to continue helping the community so
that the project can continue to grow into a great
platform by ensuring our governance is as solid and reliable as our processes.


For the sake of transparency, even if I wrote the text myself, I also used a local LLM (Gemma4:e4b) to iteratively fix the text’s grammar and flow.

The post F44 EPEL Elections: Interview with Diego Herrera (dherrera) appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Carl George (carlwgeorge)

Posted by Fedora Community Blog on 2026-05-29 22:52:36 UTC

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Carl George (carlwgeorge)

What is your name and what is your FAS ID?


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 in 2014. I was working for Rackspace and joined a team whose primary purpose was to maintain IUS, a third-party package repository for RHEL. Part of my work there involved contributing to and maintaining EPEL packages. 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.

During my time on the EPEL team, I’ve lead the design and implementation of EPEL 9 and EPEL 10. These releases each brought significant improvements to packager workflows and user experience, especially the introduction of minor versions in EPEL 10. We’re currently in the early days of planning EPEL 11, with a focus on continued refinement and quality.

Aside from the hands-on technical work of EPEL release engineering and packaging, I routinely attend conferences to deliver presentations about EPEL and staff Fedora/CentOS booths to engage with the EPEL community. I enjoy mentoring new packagers and helping existing Fedora packagers get started with EPEL.

Why are you running for EPEL Steering Committee member?

I have been on the EPEL Steering Committee since 2020. I have enjoyed my six years serving on the committee, and hope to have the opportunity to continue this important work. I am passionate about EPEL and I am committed to continue finding ways to improve the EPEL experience for both packagers and users.

The post F44 EPEL Elections: Interview with Carl George (carlwgeorge) appeared first on Fedora Community Blog.

F44 EPEL Elections: Interview with Troy Dawson (tdawson)

Posted by Fedora Community Blog on 2026-05-29 22:45:50 UTC

This is a part of the Fedora Linux 44 EPEL Steering Committee Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Troy Dawson (tdawson)

What is your name and what is your FAS ID?

Troy Dawson (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 F44 EPEL Elections: Interview with Troy Dawson (tdawson) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der)

Posted by Fedora Community Blog on 2026-05-29 22:37:26 UTC

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Akashdeep Dhar (t0xic0der)

  • FAS ID: t0xic0der
  • Matrix Rooms: Fedora Council (#council:fedoraproject.org), Fedora Mindshare (#mindshare:fedoraproject.org), Fedora Forgejo (#fedora-forgejo:fedoraproject.org), Fedora Infrastructure (#admin:fedoraproject.org), Fedora Badges (#badges:fedoraproject.org), Fedora Apps (#apps:fedoraproject.org), Fedora Join (#join:fedoraproject.org), Fedora Mentoring (#mentoring:fedoraproject.org)

Questions

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

Since the past year, I have been actively contributing to the event planning [1] [2] and proposal curation in the Mindshare committee. Representing our vested interests in the Fedora Council, I have paved the way for improvements in the regional event support (i.e., event owners and regional inventory), digital ambassadorship (i.e., swagpack designs and social media) and recognition service (i.e., Community Metrics and Fedora Badges).

Besides championing our community presence in underrepresented regions (e.g., in DevConf.IN 2026 and FOSSAsia 2026 in APAC), I have continued staying at the forefront of the Fedora Forge community initiative, working as an infrastructure architect for Fedora Infrastructure applications, organizing Fedora Mentor Summit during Flock events and mentoring budding contributors formally/informally in the community.

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

Technology might be why I joined the Fedora Project, but I stayed because of the people who made me feel at home. Progressing in various aspects of our planned functions over the past years has taught me one crucial thing – contributors are actually retained when they feel noticed, supported and trusted with meaningful work. The Mindshare Committee is where that happens, and I want to keep building what we started.

Furthermore, as the committee’s representative to the Fedora Council, I have seen firsthand how decisions at the governance level shape the contributor experience on the grassroots level. The update during the Fedora Council Strategy Summit 2026 gave us an opportunity to serve event organizers, community ambassadors and voluntary contributors better, all while using these outcomes to enhance the community health.

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

Simple. We need to show up where the community is. A community booth in one event, some interactive workshops in another – to begin with in regional event support to ultimately show people that we indeed care. While making sure that our infographic swagpacks are updated on a regular basis in digital ambassadorship, we actually ensure that we are providing people with reasons to come back to us when the time is right.

With the upcoming collectible rarity feature in Fedora Badges and tangible contributor recognition awards (both as a part of Fedora Mentor Summit event and separately), we nudge people to more opportune contribution avenues while avoiding burnouts in longtime contributors. This could further be extended to our Fedora Linux Release Parties too, as ultimately, most of our community members started off as its users.


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

Contributor Recognition. With over half a decade of experience in this space, the “What now?” problem (after the first contribution) has only become worse with the advent of AI Assisted Contribution Activities. Newcomers struggle to realize the value proposition of the community connection that Fedora Project could provide, and hence, it has become the need of the hour to incentivize contributions using rewarding activities.

But apart from that, we also need to do better at further improving our local presence in underrepresented regions. In this past term, my pilot experiment on APAC events worked wonders, and it showed us all the community power we can tap into by just being there. With reusable swagpacks, localized printing, active conversations and documented accounts, this limited experiment can scale well across various parts of the globe.

The post F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12)

Posted by Fedora Community Blog on 2026-05-29 22:33:17 UTC

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Mackenzie Stewart (monkeybean12)

  • FAS ID: monkeybean12
  • Matrix Rooms: I tend to use these Matrix channels, Fedora, Fedora EPEL Matrix, Announcements, Introductions.

Questions

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

My background in Fedora is using the Java programming language from Oracle and I have worked on games and graphics with Java language. I am currently writing computer programs for other computer languages which are Python, JavaScript in nodeJS and Building/Maintaining WordPress websites using PHP, HTML5 and CSS3.

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

I want to help bring people together and support the culture around Fedora, not just the technical work. Fedora is more than just an operating system to me — it’s a community. I want everyone who contributes, whether they code, design, or help run events, to feel valued and know their work matters.

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

I would propose a recurring, informal ” Monthly Community News” session—open to all—where Mindshare members discuss why certain decisions were made, rather than just reporting the results. Also to be a place for any updates or events to be introduced or announced so that it may generate more interest to all.


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

Mindshare should act as the “connective tissue.” I want to focus on creating a standardized, project-wide mentorship framework that assists sub-projects in bringing in new contributors.

The post F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Mat Holmes (theprogram)

Posted by Fedora Community Blog on 2026-05-29 22:27:42 UTC

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Mat Holmes (theprogram)

  • FAS ID: theprogram
  • Matrix Rooms: Join, Fedora, Fedora Social, DEI, Mindshare, Design, Council, CommOps, Server, Docs. I also monitor technical channels, but try not to distract people there too much.

Questions

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

I started with Fedora through Discussion, our Fedora Help Desk. This helped me both learn and teach about Fedora.
Once I found Matrix, I quickly got involved as a member and sponsor with Join, where I to this day very much enjoy meeting and welcoming many new people.
As I continued over the past couple of years, I have progressed to many people facing roles such as helping with DEI and CommOps. I also stick my beak into Mindshare and Council topics while trying to not step on peoples toes.
These days I have started writing Docs such as the Beginners Guide to Fedora and I am now helping with Server where we are developing new Beginners Guides to Server and the upcoming Home Lab.

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

Mindshare suites me very well as I have extensive experience organising events and doing outreach for professional organisations such as Amnesty International Australia and a political party (which I won’t name as politics is too divisive – but feel free to ask me about it).

My personal motivation is that I enjoy working with people in the Fedora community.

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

The role of Mindshare has changed over the last couple of cycles to be more focussed on events. I would promote people to talk early and often to us, so we can put more smaller events on the table.

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

I think Mindshare needs a clearer idea of what budget we have to work with, and we need faster responses to ticketed issues.
We also need to improve the accessible roads to ambassadorship, both in person and digital. Taking my skills from Join, I would extend this to being available to help plan broader small group involvement with communities all over the globe.

The post F44 Mindshare Elections: Interview with Mat Holmes (theprogram) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Samyak Jain (jnsamyak)

Posted by Fedora Community Blog on 2026-05-29 22:25:36 UTC

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Samyak Jain (jnsamyak)

  • FAS ID: My FAS username is jnsamyak, and most people in the community know me by jnsamyak as well 😀
  • Matrix Rooms: #releng:fedoraproject.org #admin:fedoraproject.org #release-day:fedora.im #devel:fedoraproject.org #mindshare:fedoraproject.org #social:fedoraproject.org #design:fedoraproject.org
    Along with many contributor onboarding, event coordination, and Fedora community discussions across Matrix.

Since this is mindshare, Samyak wanted to do something innovative and creative for keeping mindshare spirit alive.

Samyak Mindshare Election Campaign

Questions

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

I currently work as a Fedora Release Engineer and have helped lead multiple Fedora Linux releases, including Fedora Linux 42, Fedora Linux 43, and most recently Fedora Linux 44. My work primarily involves release coordination, compose workflows, branching, signing operations, automation improvements, and ensuring smooth release execution across Fedora infrastructure.

Over time, I’ve also contributed toward improving release documentation, mentoring contributors, coordinating release-day activities, and helping newer contributors understand Fedora Release Engineering workflows.

Before Fedora, I contributed to Debian, primarily around Kotlin and Ruby packaging. When I joined Fedora, one of the first things that stood out to me was how welcoming and community-driven Fedora felt. Fedora India meetings became my first real social entry point into the Fedora ecosystem, and from there, I gradually became more involved in both technical and community activities.

Beyond Release Engineering, my Fedora journey has always been deeply community-focused. Some of the initiatives and events I’ve been involved in include:

  • Co-organizing Fedora Hatch Pune 2022
  • Leading Fedora’s involvement and organization efforts for GNOME Asia 2024 in Bangalore
  • Representing Fedora at Flock 2025
  • Representing Fedora at FOSSASIA 2026 to strengthen Fedora’s APAC visibility and outreach
  • Speaking at conferences like DevConf.cz, DebConf, GNOME Asia, and Fedora events
  • Supporting contributor onboarding and mentorship across APAC communities

One experience that particularly shaped my perspective was attending FOSSASIA 2026 as part of Fedora’s APAC outreach efforts. It gave me a much broader understanding of how rapidly open source communities are growing in Asia and how different communities actively engage contributors in the region.

That experience reinforced something important for me: Fedora already has incredible technical foundations and strong community values — but we can do much more in terms of visibility, onboarding, storytelling, and contributor engagement across APAC.

I also currently serve as an Outreachy mentor for the Fedora Release Planner Scheduler project, helping contributors navigate Fedora workflows, collaboration practices, and open source contribution processes.

For me, Fedora has never been only about releases or infrastructure. It has always been about building a welcoming and empowering community around open source.

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

My motivation comes from the grassroots experiences I’ve had throughout my Fedora journey. I’ve experienced Fedora from multiple perspectives:

  • As a newcomer entering the community
  • As a packager and contributor
  • As a Release Engineer
  • As an event organizer
  • As a mentor helping newer contributors

And one thing became very clear to me: communities do not grow only through technology — they grow through people feeling connected, supported, recognized, and welcomed.

Mindshare sits at the center of that experience.

A major part of this motivation comes from my experiences in APAC communities. I’ve met incredibly talented contributors who often remain unseen simply because they lack visibility, opportunities, guidance, or regional representation. I want to help change that.

Mentoring contributors through Outreachy and interacting with contributors during conferences like FOSSASIA and Flock made me realize how important human connection is in open source communities. Many contributors do not stay because of technology alone — they stay because:

  • Someone guided them
  • Someone encouraged them
  • Someone followed up with them
  • Someone made them feel like they belonged

That is one of the biggest reasons why I want to contribute more actively through Mindshare. My goal is not just to organize events or discussions, but to help create:

  • Better contributor journeys
  • Stronger regional connections
  • More approachable onboarding
  • More visible contributor recognition
  • More interactive and welcoming community spaces

Fedora’s vision talks about creating a world where everyone benefits from free and open source software built by inclusive and welcoming communities. That vision strongly resonates with me, and I want to actively help bring that vision closer to reality.

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

I believe Mindshare visibility improves when contributors can clearly see its impact in their day-to-day Fedora experience. Right now, many contributors still don’t fully know what Mindshare does, how it supports contributors, how regional communities can engage with it, or how contributors can benefit from its initiatives.

I’d like to focus on making Mindshare feel more visible, approachable, interactive, and community-connected across three areas:

Regional Community Spotlights

Introduce lightweight contributor and regional showcases highlighting APAC contributors, Fedora event organizers, mentors and advocates, community success stories, and new contributors making an impact. Sometimes even a simple spotlight can motivate someone to contribute more.

Better Contributor Onboarding and Retention

Help encourage contributor roadmaps by interest area, beginner-friendly onboarding guides, mentorship checkpoints, lightweight follow-up systems, and easier discovery of Fedora teams and opportunities. The contributor journey should feel exciting — not confusing.

Stronger APAC Engagement

Encourage more regional collaboration, Fedora representation at local FOSS events, community-driven mini events and workshops, localized outreach content, timezone-friendly engagement opportunities, and better contributor recognition from APAC communities. There are many hidden Fedora heroes across APAC, and I want to help amplify their stories.

More Interactive DEI Engagement

Explore more interactive approaches such as regional contributor stories, Fedora social storytelling campaigns, contributor experience videos, cultural exchange sessions, community-led DEI discussions, and language-inclusive engagement initiatives. Sometimes even a small welcoming effort can have a lifelong impact on someone entering open source for the first time.


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

The biggest area that needs attention is contributor growth and retention — especially across underrepresented regions like APAC. I would specifically focus on three major areas:

1. APAC Visibility and Contributor Recognition

There is immense untapped contributor potential in APAC. I want to help improve regional visibility, encourage local leadership, increase contributor recognition, strengthen cross-community collaboration, and build a stronger regional Fedora identity. Even small recognition efforts can significantly motivate contributors and make them feel valued.

2. Contributor Retention and Mentorship

We need smoother and more approachable contributor journeys. I’d love to help encourage structured onboarding pathways, defined contributor milestones, team-specific starter guides, mentorship and feedback loops, easier first-contribution experiences, and better newcomer follow-up systems. The goal is simple: make contributors feel supported from their very first interaction with Fedora.

3. Human-Centered Community Building and DEI

Fedora is one of the most technically strong communities in open source, but what truly makes it special is its people. I want to help strengthen community interaction, social engagement, inclusive participation, DEI-focused storytelling, contributor appreciation, and community belonging.

Ultimately, I want Fedora to continue being a place where contributors from every background feel welcomed, valued, heard, and inspired to stay.

While contributors may forget specific technical tasks over time, they always remember how a community made them feel.

The post F44 Mindshare Elections: Interview with Samyak Jain (jnsamyak) appeared first on Fedora Community Blog.

F44 Mindshare Elections: Interview with Luis Bazan (lbazan)

Posted by Fedora Community Blog on 2026-05-29 22:23:16 UTC

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Luis Bazan (lbazan)

  • FAS ID: lbazan
  • Matrix Rooms: All channels! A lot.

Questions

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

My experience with Fedora has involved working and collaborating with the community at both national and international levels, encouraging people of all ages to use and contribute to Fedora. I have worked closely with several countries to help support their growth, maintain community engagement, and motivate contributors to continue participating in the Fedora Project.

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

My main motivation, and what has always kept me connected to the Fedora community, is contribution, networking, and the friendships I have built within it. Beyond that, I truly value being able to continue motivating more people to stay involved in the project.

In my opinion, this is one of the most challenging parts of being a contributor: helping more users and engineers become interested in contributing and encouraging them to continue participating in some way within the Fedora Project.

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

To improve the visibility and awareness of the committee, we should continue working on the plans that are already in progress, because these are not tasks that can be completed in a single day. These initiatives require time to mature in order to improve processes that benefit contributors and the community. The goal is not to make processes more complex, but to improve them so they remain effective and practical for collaborators. This takes time, in addition to the many other responsibilities we manage on a daily basis.


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

I believe that the area requiring the most attention is related to events and budgeting. We have had tickets and requests that did not move forward because either the requirements process was not fully understood or the process itself was not completed properly. We should be more open and supportive in this area, especially regarding swag and other resources for smaller events organized in different countries around the world.

The post F44 Mindshare Elections: Interview with Luis Bazan (lbazan) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Miro Hrončok (churchyard)

Posted by Fedora Community Blog on 2026-05-29 21:42:06 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Miro Hrončok (churchyard)

  • FAS ID: churchyard (you may also find me as mhroncok)
  • Matrix Rooms: python:fedoraproject.org, devel:fedoraproject.org, council:fedoraproject.org, and many more

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

I’ve been an active Fedora contributor for over 12 years, co‑maintaining the Python and 3D‑printing stacks and sponsoring new packagers.
I served on FESCo for 5 years and I’ve been on the Council for 1 year. Technically I am on the Fedora Packaging Committee as well, but I am not very active there nowadays.

Through those roles I’ve gained understanding of how Fedora is built and governed. I wish to keep that experience in the Fedora Council and ensure that the people who do the day‑to‑day work of creating Fedora Linux have a strong, informed voice at the table.

I spent my first year on the Council mostly orienting myself and I am not very satisfied with my accomplishments (or lack thereof).
I was contemplating whether to not run again or to try harder. As you are reading this interview, it means I decided for the latter 🙂


What do you see as potential opportunities and risks for the Fedora Project?

My overall feeling after spending a year in this role is that there is this abyss between the Council and all the folks doing all things Fedora, like packaging. On one hand, we speak about initiatives, visions, and goals. On the other hand, there is Fedora Linux and people who make it. And I don’t feel like one hand knows what the other hand is doing. This has been frustrating to me and I decided to try to bridge that gap. I don’t have a ready-made solution for this yet, but it’s something that I strongly believe needs to be addressed and reflected in what Council is doing, approving, proposing.

Related to this, I feel that there is a more general risk of fragmentation of the community. For example, we seem to have moved some communication to discussion.fedoraproject.org while we kept others on the mailing lists. This move was a great opportunity to get more people involved in project discussions. At the same time, we risk losing the existing contributors. In the end, it seems we have two almost distinct groups of people who don’t talk to each other much.

No matter how many new contributors we get, we should not lose the existing ones, who are driving the project.

What brought you to the Fedora Project?

It was actually 3D printing.
Back in the day, we had a lab at the university with 1 (one) Prusa Mendel in it and I wanted to package some 3D printing apps like Skeinforge, Slic3r or Printrun for Fedora. I attended an RPM packaging workshop in the Brno Red Hat office and started packaging.
Not long after that I became a Fedora Ambassador, bringing the 3D printer to the Fedora booth at conferences.

The post F44 Council Elections: Interview with Miro Hrončok (churchyard) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Tomáš Hrčka (humaton, jednorozec)

Posted by Fedora Community Blog on 2026-05-29 21:41:15 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Tomáš Hrčka (humaton, jednorozec)

  • FAS ID: humaton, jednorozec
  • Matrix Rooms: fedora-forgejo:fedoraproject.org, releng:fedoraproject.org, admin:fedoraproject.org, release-schedule-planner:fedora.im, forgejo-chat:matrix.org

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

In previous years, I was a member of FESCo, where I gained exposure to the governance of the technical side of the Fedora Project.

In my professional life, I currently serve in a leadership role as Product Owner of the Community Linux Engineering team at Red Hat. Our team is responsible for a wide range of areas across the Fedora Project, including Quality Engineering, EPEL, Design, Infrastructure, and Release Engineering.

This gives me a unique perspective that combines community experience, technical understanding, and insight into how Fedora is supported inside Red Hat.


What do you see as potential opportunities and risks for the Fedora Project?

Opportunities

Immutable Desktop
Fedora is well positioned for the shift toward immutable and image-based operating systems. Projects like Fedora Silverblue and Kinoite already provide atomic updates and rollback capabilities while maintaining a strong developer experience.

Cloud-Native and Edge Computing
With Fedora CoreOS and Fedora IoT, Fedora already has strong foundations for container-focused and edge deployments. As these technologies continue to grow, Fedora can remain one of the leading platforms for modern infrastructure.

The Open AI Workstation
Developers increasingly want reliable environments for running local AI workloads and experimenting with open models. Fedora has an opportunity to become the preferred Linux workstation for this use case through strong hardware enablement, modern tooling, and fast adoption of new technologies.

Early Technology Adoption
Fedora has built a reputation for bringing important new technologies to Linux users early, whether that was systemd, Wayland, PipeWire, or Btrfs. That culture of innovation continues to attract developers and contributors who want to help shape the future of Linux.

Risks

Balancing Community and Corporate Influence
Fedora benefits enormously from Red Hat sponsorship, engineering support, and infrastructure. At the same time, maintaining community trust and independence remains critically important. Long-term success depends on keeping a healthy balance between corporate priorities and the Fedora community ethos.

Project Fragmentation
Fedora continues to grow across Spins, Labs, Editions, Atomic variants, and now containers. Growth is healthy, but it also increases the complexity of maintaining consistent quality, direction, and contributor focus across the project.

User Experience vs. FOSS Purity
Fedora’s commitment to free and open-source software is one of its greatest strengths. However, hardware enablement and multimedia support can still be frustrating for many users. Fedora should continue improving the onboarding experience without compromising its principles.

Competition
The Linux ecosystem is moving quickly. Arch Linux attracts many advanced users, Ubuntu remains dominant in commercial environments, and NixOS is gaining momentum among developers interested in reproducible systems and declarative infrastructure. Fedora needs to continue innovating while preserving the strengths that make the project unique.

What brought you to the Fedora Project?

As a user, I was basically forced by my older brother to use Fedora Core 1-3 on our shared family computer.

After a few years of distro hopping, I eventually returned to Fedora because it consistently provided modern software without requiring the amount of maintenance that distributions like Arch Linux demanded at the time.

After years of using Fedora, I wanted to give something back to the community. I started contributing through packaging and co-maintaining several Node.js and Ruby packages.

Later, I had the opportunity to join the Fedora Project professionally as part of the Release Engineering team. Over time, I transitioned into my current role as Product Owner for the team supporting Fedora inside Red Hat.

Today, I have visibility into how work is prioritized across the teams that provide Fedora infrastructure and services, support release engineering and quality processes, and contribute to areas like EPEL, Docs, and Design.

This brings me to the current Council elections. I believe Fedora is at an important crossroads. The project continues to grow, but at the same time, the distribution and contributor experience are becoming increasingly fragmented across Spins, Labs, Atomic variants, containers, and specialized deliverables.

I believe Fedora’s biggest challenge over the next few years will not be innovation. Fedora has always been good at innovation. The real challenge will be maintaining a clear identity, a healthy contributor community, and a coherent user experience while continuing to grow.

The post F44 Council Elections: Interview with Tomáš Hrčka (humaton, jednorozec) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Fabio Valentini (decathorpe)

Posted by Fedora Community Blog on 2026-05-29 21:40:43 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Fabio Valentini (decathorpe)

  • FAS ID: decathorpe
  • Matrix Rooms: Too many to list them all: #devel, #rust, #epel, #multimedia, #pride, #python, #quality, #security, … (on the fedoraproject.org homeserver)

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

I have served as a member of FESCo for six terms since I joined the project, and have also been a member of the Packaging Committee for over eight years now. In these roles (among others) I have gathered experience in a variety of both technical and non-technical areas including problem resolution, technical discussions, project management, technical writing / documentation, organizing meetings, etc.


What do you see as potential opportunities and risks for the Fedora Project?

I think it will be increasingly important to keep the balance between what makes Fedora successful and things that end up being costly distractions – to continue integrating new technologies into a modern, but stable distribution, while avoiding adoption of dead-end or unsustainable technologies from the current hype cycle.

What brought you to the Fedora Project?

Fedora is where my distro-hopping days unexpectedly ended a little over a decade ago. It has felt like home since.

The post F44 Council Elections: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Aleksandra Fedorova (bookwar)

Posted by Fedora Community Blog on 2026-05-29 21:39:43 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Aleksandra Fedorova (bookwar)

  • FAS ID: bookwar
  • Matrix Rooms: Usually #council, #fedora-ci, #mine-with-fedora

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

For some time I was an admin of the Russian Fedora Remix services – maintained the site and the wiki. I also participated in moderation of some of our IRC, Jabber channels and forums, which gave me quite a lot of experience in dealing with the folks which are not necessarily IT experts and professionals.

I am also a proud survivor of the GNOME 3 and systemd debates there 🙂

Professionally I have worked as a support engineer, build/devops/CI engineer, team lead and product owner, which gives me a range of experience covering quite a lot of “non-coding but still engineering” topics. And I generally believe that there is a lot more in engineering than just writing code.

I also have been on the Fedora Council for some time now. I can not say I really know how to do this council thing correctly, but I am doing my best.


What do you see as potential opportunities and risks for the Fedora Project?

I believe that the general interest in Linux and Fedora in particular is on the rise, and we as a distribution currently are well placed to provide a lot of things people are looking for – stable base, variety of options, fast moving layers on top of integrated foundation and so on. It comes with the risk though as we just might spread too thin trying to cover all possible use cases, all the emerging technologies and all kinds of sometimes contradicting goals.

Our current project model, while open and community-driven, is still rather centralized.

As a big fan of the idea of federation, I believe that going forward we need to learn how to work with the wider ecosystem without necessarily pulling every connected piece into the same project hierarchy.

As a former Fedora Remix user myself, I see remixing(*) as one of the core ideas, which can help us turn a single distribution into a some sort of constellation of distributions. And while each remix may be managed by different groups and different rules, they still need to have a good collaborative relationship, a way to discuss and communicate changes, or to coordinate shared efforts. Of course they also need a way to communicate and share the load and costs.

(*) Here I use a word “remix” in the widest possible sense as in anything which uses Fedora content as a base, no matter what kind of content is added on top and what format of the deliverable is built from it.

What brought you to the Fedora Project?

Even though currently I work as a software engineer, I started to use Fedora not as a coder but as a user. I needed LaTeX to write my Master’s and PhD thesis, and at that time the support for LaTeX(with Cyrillics) was really only working on Linux. Big thanks to Tom (spot) Callaway who still packages texlive for Fedora.

So essentially I chose Linux (and Fedora) because it was the easiest thing for me to use.

Of course the name also did play a role. The more common Linux distribution choices in my community at the time were Gentoo or Slackware. People were talking how “Linux is about choice” and that sort of thing. But once I learned a bit more about the ideas behind different Linux distributions, I really got hooked on the concept of an integration, rather than customization.

The Upstream First principle in particular was rather eye-opening for me. The idea that you should not just build a system for your own needs – that is what the local folks were doing – but that you need to share and contribute those changes back, or at least to discuss them with the original developers to understand their thought process and the choices they made.

I always looked at my Fedora system not as a thing to tweak for my personal needs, but as a path to become a part of a larger community.

The post F44 Council Elections: Interview with Aleksandra Fedorova (bookwar) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Hristo Mainov (hricky)

Posted by Fedora Community Blog on 2026-05-29 21:38:35 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Hristo Mainov (hricky)

  • FAS ID: hricky
  • Matrix Rooms: #bootc:fedoraproject.org, #coreos:fedoraproject.org, #atomic-desktops:fedoraproject.org, #silverblue:fedoraproject.org, #kinoite:fedoraproject.org, #fedora-forgejo:fedoraproject.org, #docs:fedoraproject.org

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

While I don’t have formal governance experience, I’m an active contributor to several teams and organizations focused on image-based systems. This is the very area where Fedora is leading innovation. This gives me both technical depth in Fedora’s modern directions and practical insight into how image-based approaches are being adopted across the ecosystem. Additionally, as an independent contributor, I bring a perspective focused on the broader community’s needs.


What do you see as potential opportunities and risks for the Fedora Project?

Fedora’s leadership in image-based systems is a significant opportunity. The Atomic Initiative is advancing this space meaningfully. However, when such initiatives conclude, we must ensure contributors remain engaged and their work integrates into sustainable community practices.

More broadly, as AI becomes increasingly present in development workflows, we need thoughtful governance around how Fedora engages with it. This is about authorship, accountability, and the moral questions around code provenance and community contribution. Fedora’s values should guide how we engage with these technologies responsibly.

What brought you to the Fedora Project?

I initially needed an OS for on-premise servers, which led me to CentOS. The transition forced a reassessment, and during that process, I discovered Fedora’s emerging work on image-based systems. That discovery led me to get involved in related teams, which deepened my commitment to this community. Now, as an active contributor in that space, what keeps me here is the community itself. I’m inspired by it, and that’s what drives my continued involvement.

The post F44 Council Elections: Interview with Hristo Mainov (hricky) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Akashdeep Dhar (t0xic0der)

Posted by Fedora Community Blog on 2026-05-29 21:37:56 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Akashdeep Dhar (t0xic0der)

  • FAS ID: t0xic0der
  • Matrix Rooms: Fedora Council (#council:fedoraproject.org), Fedora Mindshare (#mindshare:fedoraproject.org), Fedora Forgejo (#fedora-forgejo:fedoraproject.org), Fedora Infrastructure (#admin:fedoraproject.org), Fedora Badges (#badges:fedoraproject.org), Fedora Apps (#apps:fedoraproject.org), Fedora Join (#join:fedoraproject.org), Fedora Mentoring (#mentoring:fedoraproject.org)

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

While I could not make it to the Fedora Council through elections in the previous term, I was chosen as a Mindshare Representative from the second half of the term. Besides bringing the interests of the Mindshare Committee to the Fedora Council Strategy Summit 2025, I also worked on further progressing the Fedora Forge Community Initiative with my work on the private issues and Pagure Migrator. Staying true to my volunteer first community agenda, I also worked on the documentation for the Fedora Project Contribution Model to encourage empathetic interactions and managing expectations in our mostly volunteer driven community.

Following the elector concerns from the previous term, I explicitly reinforced just how important it was for us to leverage objective community health metrics over arbitrary conditions that I voiced during the foundational drafting of the Fedora Verified proposal. With my inclination towards process sustainability, I have often voted for deferring decisions until we have accounted for most (if not all) feedback. I have had a hands-on approach towards major proposals like Fedora Forge, Image Mode, FedoraCVE trademark and Fedora Verified, by spending roughly around ten hours per week simply reading through the Fedora Discussion threads.

Besides my direct involvement in the Fedora Council, I am also working as an infrastructure architect, working on various projects in the Fedora Infrastructure and leading the Fedora Badges Revamp Project while mentoring an Outreachy intern. Being elected into the Mindshare Committee has also allowed for me to lead the logistics of various Fedora Project in-person representations at APAC events like DevConf.IN 2026 and FOSSAsia 2026, all while curating and guiding Fedora Project community events across the world. In my past life (or roughly five years back in human years), I also led the Fedora Websites and Apps community initiative.


What do you see as potential opportunities and risks for the Fedora Project?

One of the first things that comes to my mind about risks for our community is decision transparency. The discussions [1] [2] around the AI Developer Desktop Proposal were a valuable learning experience as they showed how much community members care about understanding why we vote the way we do, not just what we voted for. I see an opportunity here for elected members to share their reasoning with their votes on a given proposal, so others can follow the thought process. After all, I would want to vote for someone who engages with what the community has to say and is willing to show their work, even through various disagreements.

To dive even deeper, we also risk alienating the community members by deciding on a certain proposal before it is theoretically ready to be discussed. While a stopgap opportunity here might be ratifying a proposal readiness guidelines document that the members could refer to, in my honest opinion, being active around the Fedora Project community platforms just ends up helping a lot more. If this requires us to spend more hours around the desk, have more frequently organized synchronous meetings, include more electable Fedora Council seats or set regular Fedora Council social hours – then it is something that we need to account for.

Beyond transparency, I also want to champion process sustainability in our established processes. The end of an elected member’s term should not mean that their ongoing work disappears – it should be (or made) possible for incoming candidates or continuing members to carry forward and iterate upon that work. Similarly, we can reduce the risk of potential burnouts among elected members by effectively delegating to the enthusiastic contributors that our community is never short of. Good governance should outlast any single term, and I want to actively work towards building that continuity through documenting better handoff practices.

What brought you to the Fedora Project?


Video games. Back in early 2020 when we were isolated at our homes due to COVID-19 pandemic, all I had was a weak laptop and a Fedora Workstation setup to keep me from boredom. One of my first contributions had been to the Quick Docs. When I thought I was done with my contributing activities, friends like Ankur Sinha, Alberto Sanchez, Justin Wheeler, Marie Nordin, Nasir Hussain, Vipul Siddharth etc. just made me keep coming back for more. Then getting inspired from all the amazing stuff they got up to back in the day made me want to see if I could be of some help – and a huge reason why I am keeping myself busy even today is just that.

The post F44 Council Elections: Interview with Akashdeep Dhar (t0xic0der) appeared first on Fedora Community Blog.

F44 Council Elections: Interview with Vít Smolík (smoliicek)

Posted by Fedora Community Blog on 2026-05-29 21:37:16 UTC

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Vít Smolík (smoliicek)

  • FAS ID: smoliicek
  • Matrix Rooms: admin:fedoraproject.org, noc:fedoraproject.org, join:fedoraproject.org, data:fedoraproject.org, commops:fedoraproject.org, docs:fedoraproject.org, fedora:fedoraproject.org

Questions

What kind of experience do you have which might be relevant to the role? E.g Governance, leadership, etc.

To strengthen my governance knowledge, I recently completed two courses on governance fundamentals. (Governance Training, and Tools for Project Planning)

I am also familiar with meeting procedures, including how meetings are structured, planned, run and how decisions are recorded. I participate in regular productive meetings with Fedora Infrastructure.

I’ve always been an active person, through cycling and competitive dancing, and even as a student, I’m always thinking about how I can make things better for others. Thus, my current governance experience comes from outside of the open-source world, however, it translates well to the Fedora Project.

I’m an elected member of my school’s board and a member of the school’s parliament. I’m familiar with what it means to represent a diverse community, balance viewpoints, and make consensus-driven decisions. In this role, I dealt with issues such as financial disbursement and conflicting student choice.

As an independent contributor, my focus is entirely on serving our community and listening to the communities voice. While I respect the fantastic work of those who came before me, I will bring independent perspective to the Council, guided by my ethical commitment to fully open-source software.

To me, software freedom is a digital right.


What do you see as potential opportunities and risks for the Fedora Project?

When looking at the landscape now, the single biggest risk facing Fedora right now is the rush to implement AI everywhere. This threatens not only a drop in quality of our codebases but also creates massive legal grey areas. The community is rightfully pushing back against this. Fedora must refuse to let this hype dictate our governance.

The opportunity for Fedora is to set the global standard for what a measured, ethical, and secure approach to AI tooling looks like. Instead of rushing to adopt external, proprietary black boxes, Fedora should take its time to define how open-source principles apply, prioritizing local execution, strict licensing compliance, and open-weight models. Fedora can champion true open-source principles in a changing landscape, proving that innovation does not require the sacrifice of security or ethics.

Our priority must always be human craftsmanship and infrastructure integrity; any tool we introduce must serve our contributors, not replace them.

What brought you to the Fedora Project?

My first introduction to Fedora happened on July 20, 2025, when I sent an introduction to the infrastructure mailing list. On May 21, 2026, I was sponsored to my first sysadmin group. That is what Fedora has done for me and what I can do for Fedora.

Before joining the project, I was a sysadmin working completely alone. Fedora gave me the space to learn how to function in a bigger team, how to navigate complex infrastructure, and how to collaborate effectively.

My trajectory shows I’m capable of learning, adapting, and integrating into complex systems at an exceptional pace. I’ve gone from a newcomer to an active contributor, not only in the infrastructure team but also in Fedora Data Working Group, where I’m helping Hatlas come to life, and in the Join team, where I help new contributors find their footing.

Fedora has helped me scale up my skills rapidly, and I am running for council to ensure Fedora remains just as dynamic, rock-solid, and welcoming for everybody else.

The post F44 Council Elections: Interview with Vít Smolík (smoliicek) appeared first on Fedora Community Blog.

F44 FESCo Elections: Interview with Fabio Valentini (decathorpe)

Posted by Fedora Community Blog on 2026-05-29 21:07:58 UTC

This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Fabio Valentini (decathorpe)

  • FAS ID: decathorpe
  • Matrix Rooms: Too many to list them all: #devel, #rust, #epel, #multimedia, #pride, #python, #quality, #security, … (on the fedoraproject.org homeserver)

Questions

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

I have contributed to many areas of the project since I joined it over a decade ago, so I think I can bring a broad perspective to FESCo. I want to help insure the project’s continued success happens in a sustainable way.

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

I am the most active package maintainer in Fedora (by count of updates / builds), primarily because I am the main point of contact for most Rust packages. My work includes package updates, package review, triaging build failures and broken dependencies, and pruning packages for obsolete, outdated, or unused Rust crates from Fedora. I regularly contribute to upstream projects through bug reports and pull requests to fix issues that are discovered downstream in Fedora. Additionally, I triage, report, and attempt to fix upgrade path issues caused by missing package updates every release cycle.

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

Many disagreements I’ve handled were only concerned with details, while the goals of everyone involved were still aligned. So I try to find common ground and / or explore alternative or creative solutions that can work for everyone involved.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

I am – in general – wary of becoming dependent on products from companies that are nowhere near profitable and only kept afloat by a combination of inconceivably large amounts of venture capital and “creative” investment arrangements. Additionally, to me these “AI” systems aren’t “just tools” and can’t be treated solely as such, especially due to externalities like unethical data scraping practices, copyright / license laundering, excessive power and water consumption, noise and greenhouse gas pollution, hardware shortages and price increases, etc. I have yet to see a competitive “AI” product that does not have these problems, and I am unsure whether creating one is even possible.

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

No pineapple, and definitely not on Pizza.

The post F44 FESCo Elections: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

F44 FESCo Elections: Interview with Neal Gompa (ngompa)

Posted by Fedora Community Blog on 2026-05-29 21:06:42 UTC

This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Neal Gompa (ngompa)

  • FAS ID: ngompa (Conan Kudo is a common nickname for me)
  • 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, #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, #kiwi:matrix.org (There’s quite a bit more, but I think that sort of covers it. 😉) (There’s quite a bit more, but I think that sort of covers it. 😉)

Questions

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, 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, though I have gotten back into doing core stack stuff too. Most recently, I’ve worked within the KDE community to help develop Plasma Login Manager and Plasma Setup to further modernize the Fedora KDE Plasma Desktop Edition and enable it to fully participate in the Fedora Ready program. I have also been actively assisting our friends at various PC makers participating in the Fedora Ready program to better support Fedora as an operating system offering for their products. This has directly led to the Fedora community gaining a new Fedora Ready participant with Star Labs, who offers Fedora KDE on their products as an operating system option. There’s always more to come on that front, and I hope Fedora Ready will continue to grow. On the core stack side of things, I’ve recently ported PackageKit’s DNF backend to DNF5, which once again unifies Fedora’s package management stack for the first time in several releases. This unlocks the ability for us to freely leverage DNF5 features that do not have analogues in DNF4.

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.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

I am rather conflicted about “AI” technology, especially LLM-based generative AI (GenAI) technology. I worry that it wipes out the implicit fairness that we believe Free Software carries. The nature of this tooling and how people gain access to quality tools creates an unpleasant classist split of haves and have-nots based on affordability. As the costs to access and leverage LLM technology skyrocket, a new underlying elitism will implicitly develop since only gainfully employed affluent developers will have access to the best technology.

It is true that there are open models under OSI licenses that exist (IBM Granite and Google Gemma 4 are examples of these), and I know that it’s possible to create your own models leveraging open source technology. But to date, open models do not yet produce results as good as the frontier proprietary cloud models, and we now operate in a world where proprietary services tightly integrate these things together and make it very hard to ignore the result. Perhaps more focused development on open models leveraging open source technologies will change that, but given how expensive such endeavors are, I am a little skeptical. Or perhaps the lack of willingness by many AI practitioners to pursue that is what makes me skeptical.

Putting that all aside, I am skeptical of AI technology in large part of my experience as an open source software maintainer. The quality of contributions are significantly lower than unassisted ones thus far (here’s a notable example), and while I’m sure it is possible to leverage it effectively in a productive fashion, there is mounting evidence that our ability to learn and maintain cognitive skills are weakened by reliance on AI technology as it exists today. I would prefer to receive poorer contributions from people that were their own as an opportunity to help them grow, because that is the embodiment of human success.

In the end, I do not feel like it is a good idea for Fedora as a project to make AI a critical pillar, but supporting open source, well-integrated tooling for people to experiment with AI/ML in the environment of their choice and knowing the risks they take on in doing so is perfectly fine with me.

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 F44 FESCo Elections: Interview with Neal Gompa (ngompa) appeared first on Fedora Community Blog.

F44 FESCo Elections: Interview with Simon de Vlieger (supakeen)

Posted by Fedora Community Blog on 2026-05-29 21:03:57 UTC

This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Simon de Vlieger (supakeen)

  • FAS ID: supakeen
  • Matrix Rooms: I am in many rooms but most active in the Release Engineering, ELN, bootc, Atomic Desktops, and my projects Image Builder channel.

Questions

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

In the past I’ve interacted with FESCo only through change proposals. Due to the nature of my work on
image-builder I’ve gathered quite a bit of knowledge and ideas (though never enough) about the whole of Fedora and how it is put together. I’d like to take part in the other side of things both to learn
more but also to apply what I have learned.

Personally I’m a big proponent of “building on Fedora”. By that I mean that we could and maybe should
make Fedora as generic as possible in the packaging department with few assumptions about how an eventual system is laid out. This would open the road for more technical variety in the various editions, spins, and
labs. Examples here (non-exhaustive) would be UKIs, systemd-boot, BTRFS boot-to-snapshot, and others.

Separately but interconnected is that I’d love it for Fedora to be the prime place people go to if they want
to build their own flavour of a distribution. Remix culture should be nurtured, documented, and made as easy as possible so that the ideas can be tried and tested outside of Fedora before making their way into Fedora.

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

Well, I take a super pragmatic approach to disagreements. Sometimes it’s just easier to bow out of a disagreement
than to continue it. Often times one person cares more about a given problem than another person and to me that
means it can be good to give in, expecting the same in return on a later issue that another person might care more
about.

This way fosters pretty strong ownership of problems and an environment where people trust eachother on problems
rather than going at eachother.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

Super hard question. Since this is specifically about AI in software development most of it would probably concern what upstreams do. As long as they keep compatible licenses we won’t have much of a say in this.

As for the more general approach to ‘AI’ in software development I feel like we should promote open implementations as far as that’s possible. The AI/ML SIG has been doing a lot of work with ROCm and other open stacks to be able to run models on Fedora. The future is not servitude to big tech companies but hopefully running our own local models.

There’s probably more that can be done in outreach as ‘AI’ stacks can be notoriously hard to package, our expertise could be shared and it might be useful; but I don’t know if that should/would be a Fedora Project kind of thing.

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

Firstly, I want to disclose that I work at Red Hat as people do hold opinions about that so let’s have that out of the
way.

Other than that I want things to be open with the community deciding our direction. Generally I’m on the ‘conservative’
side as far as there is a conservative side in Fedora. I mean that in the sense that I think our current rules and guidelines concerning contribution and packaging are a decent starting point and we should not change them lightly.

We should also try to use as much as possible that what Fedora already offers. Many recent projects have been causing splits in infrastructure and community spirit. Let’s do less of that.

The post F44 FESCo Elections: Interview with Simon de Vlieger (supakeen) appeared first on Fedora Community Blog.

F44 FESCo Elections: Interview with Michel Lind (salimma)

Posted by Fedora Community Blog on 2026-05-29 21:01:20 UTC

This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Michel Lind (salimma)

  • FAS ID: salimma
  • Matrix Rooms: #Fedora Devel, #Fedora EPEL, #Fedora ELN, #Fedora Golang, #Fedora Python, #Fedora Rust, #Fedora Security Team, #Fedora Social, #CentOS Devel, #CentOS Hyperscale, #CentOS Promo, #CentOS Proposed Updates

Questions

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 active in the Fedora community since almost the very beginning (see also the next question), and an elected member of FESCo since the F40 election cycle. Outside of committee work, I am an experienced packager for multiple programming language ecosystems and maintain tooling intended to improve packaging workflows.

The project is facing some interesting decisions at the moment, in terms of what we produce (which packages, in what formats, for which architectures), how we produce them (what build systems, how we do quality assurance, especially in the face of an avalanche of CVEs), and who our contributors, users, and downstreams are. It needs both experienced hands who knows how things are done and why, as well as familiarity with current industry practices.

I believe I bring both of these to the table. At my day job, I focus on upstream distribution work and integrating improvements into our production fleet, which informs the perspective I bring to my FESCo work. If reelected, I hope to continue contributing that perspective – and I hope I have demonstrated my ability to separate what is best for the project from what is best for my employer.

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

Apart from my FESCo membership, I am an active packager and a member of various packaging SIGs (Rust, Python, Golang). My day job revolves around a large CentOS Stream deployment, so I was a member of the Fedora EPEL Steering Committee, am an active member of the CentOS Hyperscale SIG, and co-founded the Proposed Updates SIG that is forked off to focus on producing timely updates for those who deploy CentOS Stream in production.

I maintain sandogasa, a set of tools and library crates to assist with Fedora and CentOS packaging workflows. They solve some unique needs (e.g. bootstrapping EPEL packages, both those needed at work and also those needed to run Fedora’s mailing list infrastructure), and sometimes provide up to date alternatives to previously-written utilities (e.g. sandogasa-hattrack can surface someone’s Fedora Discussions activity – a platform that was not around when fedora-active-user was written). As these tools mature I hope to see them adopted more as part of project workflows.

I have landed multiple change proposals in the past – most notably around Btrfs and systemd-oomd. Most recently, for the F43 cycle Neal Gompa and I worked on Wayland-only GNOME and for F44 cycle, I landed:

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

In my experience, disagreements are sometimes inevitable. While it is better to have consensus, sometimes that’s not possible, and it is important to recognize those situations and agree to disagree.

It is sometimes easier to understand each other’s positions in less formal situations – I am reminded of our Friends foundational value here. This is where having personal interactions with other community members really helps – we can disagree without taking things personally, or clear things up in a side channel because sometimes some reasons cannot be divulged in public.

In the end, we are all fallible humans, and we all have our own interests and preferences, both personal and work-driven. Being able to understand those we disagree with both make it easier to keep things civil and to find compromises.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

I have a nuanced take on this, so this will likely rub some people the wrong way. I have strong ethical reservations about using (generative) AI, and legal reservations as well, but IANAL so I will not really cover the legal aspects here; I defer to all the legal counsels who have vetted the project’s AI policy and my employer’s legal counsel who must have OKed our AI usage…

There’s the issue of training data provenance – there’s the issue of regulations not catching up yet to either address copyright infringement issues, nor protecting workers from job displacement, nor regulating energy and water usage. I could go on. If you’re “lucky” enough to work on improving the AI itself, while I can’t speak to how that is done at my day job, suffice to say there are horror stories out there, at that company, affiliated companies, and competitors. There are concerns that inappropriate use of AI leads to cognitive decline.

Using AI in software development is, as a large project shipping mission critical software, sadly seems to be verging on inevitable these days – but I’d rather we use it defensively, like how curl uses AI scanners. Using it to help triage issues, like COPR’s Log Detective, is also promising.

We certainly could use some more resources when it comes to fixing CVEs and when it comes to tooling – there are simply not enough volunteers, sadly. Though – this comes up in Debian’s debate about AI usage too – we should be careful not to close off opportunities for new contributors because it’s easier to fix something with LLM assistance than to onboard someone to do it.

I will own up to writing sandogasa mostly with AI assistance. As part of that, I wrote up my personal LLM policy for those curious. As the org name (slopfest) suggests, my colleague and I who have repos there feel conflicted about the use of LLMs; we try to limit it to this GitHub organization, and to tasks that are repetitive and error-prone anyway. Just as artifacts produced by GNU autotools do not need to be GPL licensed, hopefully you can use these tools free of any LLM taint.

Finally, the elephant in the room – the Fedora AI Developer Desktop Initiative, that intends to make it easier to install hardware drivers and development libraries needed to leverage GPUs, including, controversially, the proprietary NVIDIA stack. NVIDIA is worth over USD 5tn. IBM is valued at just over USD 200bn. I think NVIDIA can hire enough people with packaging experience to solve the problems they themselves cause by not open sourcing key headers people want to compile against – and I know they do employ people who know packaging. I think one role distributions like Fedora can do, and large NVIDIA customers especially among the hyperscalers, is to have a common position to negotiate with NVIDIA. If that happens then we might have enough traction to end up with positive outcomes.

Without pushing back against the tide of AI boosterism, I fear that the reputational damage because this is seen to be a top-down initiative would outweigh any benefit – and I still think this could have been a remix and Council was involved unnecessarily early. We used to be perceived as caring strongly about licensing (it took us a long time to ship a subset of RPM Fusion, and Tom Callaway’s work is immortalized in the name of Fedora’s previous licensing system), and I really prefer that we’re not seen to be AI boosters, because a) it does not seem like the right thing to do IMHO and b) the crowd we will attract, and likewise, the existing contributors and userbase we will alienate.

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

I work for Meta – which runs CentOS Stream on millions of bare metal servers and in containers. I hope I have demonstrated over the past two years in FESCo, and over a longer period in my other Fedora and CentOS engagements, that I try to put the community first and not let my employer’s interest override my responsibility to the community.

I recently relocated to Ireland with my wife and kid – it’s a lovely country, and a fascinating bridge between the US we left and Europe, given the presence of US multinationals here and the history of Irish emigration. We are looking forward to attending more European open source conferences in the future once we are more settled in.

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

F44 FESCo Elections: Interview Maxwell G (gotmax23)

Posted by Fedora Community Blog on 2026-05-29 21:00:13 UTC

This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Maxwell G (gotmax23)

  • FAS ID: gotmax23
  • Matrix Rooms: Fedora Devel, Fedora Golang, Fedora Python, and I loiter in a bunch of other places!

Questions

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

I care a lot about Fedora, and I hope to bring a fresh voice to FESCo informed by my multiple years of active participation in Fedora development. I want Fedora to continue to excel as a Linux distribution and a FOSS community that is welcoming to new users and contributors and ideas. I value the Fedora Foundations and the long-term contributors that have built a great distribution and improved our upstreams and the FOSS community at large.

Additionally, I am interested in ensuring the day-to-day aspects of Fedora development run smoothly and continuing to improve the packager experience. I am closely watching upcoming changes to dist-git (and potentially bug-tracking) in Fedora. I am excited about these changes — this is a great opportunity to address warts with the existing systems — but it is crucial to ensure that the transition fully addresses the project’s needs.

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

I am part of the Golang and Python SIGs and the FPC and have worked a lot on Packaging Guidelines improvements and RPM automation (macros, generators, etc.). As a FESCo member, I would continue to guide workflow improvements in Go, Python, Ansible Collections, and beyond. We’ve made good strides, but we still have work to do, especially surrounding multi-build updates, mass rebuilds, security bugs, and license detection.

I run the Orphaned Packages Process and maintain the associated tooling. I am also a packager sponsor and have mentored a couple new Fedora contributors. I will continue keeping the Fedora package collection healthy and helping new people get involved in Fedora development as a member of FESCo.

I maintain the Ansible stack in Fedora which led me to work upstream on the Ansible Community Steering Committee and the release manager team.

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

One of my favorite parts of FOSS communities like Fedora is getting to work with so many passionate people from all over the world toward a shared goal. I think it’s important to keep this is mind when having disagreements. Disagreements happen, but we can always create room for respectful dialogue and compromise. In the end, we are all on the same team.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

I am an AI skeptic and worry about AI’s impact on society, the environment, and human intellectual creation. But I understand that various industries, including ours, are (attempting to) adopt AI-based tools. Just recently, I reviewed a set of AI-assisted contributions to a Fedora package. I am still trying to balance these conflicting notions. I am willing to support AI experimentation based on free/open technologies in Fedora as long as our project’s principles and policies are followed and the community is on board.

The post F44 FESCo Elections: Interview Maxwell G (gotmax23) appeared first on Fedora Community Blog.

F44 FESCo Elections: Interview with Adam Miller (maxamillion)

Posted by Fedora Community Blog on 2026-05-29 20:53:24 UTC

This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Adam Miller (maxamillion)

  • FAS ID: maxamillion
  • Matrix Rooms: fedora: #fedoraproject.org, #fedora ai:fedoraproject.org (AI/ML SIG), #fedora bootc:fedoraproject.org, #epel:fedoraproject.org, #fedora releng:fedoraproject.org

Questions

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

I am a long time Fedora user and contributor, with my first contribution dating back to 2008. Having previously served as a member of FESCo from 2015 to 2018, I understand the gravity and operational realities of this committee. My foundational engineering roots in the project include serving in SysAdmin Main within the Fedora Infrastructure Team and working as a member of the Fedora Release Engineering Team, where I contributed to our core build tooling, container infrastructure, and Project Atomic. Additionally, I spent roughly a decade upstream as a member of the Ansible Core Engineering Team, driving various Fedora focused integration efforts.

In recent years, my engineering focus has centered squarely on the AI infrastructure space. I currently serve as the Technical Advisory Council (TAC) Chair for the Linux Foundation AI & Data, and I am a core maintainer of the OpenShell Agentic Security & Governance project.

What I hope to bring to FESCo this time around is a pragmatic, deeply experienced perspective on how we can responsibly bring AI technologies into both the inner workings of Fedora as a project, and into the deliverable artifacts we release to our users. My goal is to ensure this transition happens safely, securely, and in absolute alignment with the open source way.

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

I have recently re-engaged my hands on contributions, focusing primarily on AI related projects and working to scale my contribution footprint back to my historic levels. Even with a multi year hiatus, my historical contributions still ranks me in the top 50 of all contributors in the Fedora Badge System. Over my career, I have contributed to more than 200 open source projects, many of which remain packaged and shipped in Fedora today. My current work aims to ensure Fedora stays ahead of the curve as the landscape shifts toward AI native software stacks.

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

I always aim to find consensus through collaborative discussion, transparency, and healthy, respectful debate. I believe a steering committee’s job is to weigh technical merits and community impact objectively. However, if a consensus cannot be reached and a majority vote is taken, I fully practice the principle of “disagree and commit.” Even if a decision goes against my personal vote, I will actively support and work to successfully execute the majority decision to keep the project moving forward smoothly.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

Fedora needs a pragmatic open source strategy to address AI’s disruptive impact on both the software development ecosystem and open source itself. We must establish clear, principles based guardrails around the ethical use, consumption, and application of AI within our project’s development pipelines, while continuously solidifying Fedora’s core principles of The Four Foundations, in a rapidly changing world. We should position Fedora not as a passive consumer of industry hype, but as the secure, foundational infrastructure that makes open source AI development possible.

When it comes to AI in software development, my position centers on two fronts:

  • Infrastructure & Tooling: Fedora must excel at providing the open source building blocks, runtimes, and container environments required to build, test, and serve models locally and securely. We need to ensure our developer tooling adapts to modern workflows while fiercely protecting user privacy and data sovereignty.
  • Security, Sandboxing, & Provenance: As AI assisted code generation and autonomous agentic tools inevitably find their way into development pipelines, FESCo must proactively advocate for strict isolation, predictable build environments, and robust supply chain security. We must ensure that automated code contributions or AI developer aids do not introduce unvetted security vulnerabilities, malicious packages, or license compliance risks into the Fedora ecosystem.

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

I have been an open source contributor for more than 25 years. Professionally, I am a Distinguished Engineer at Red Hat. In my open source community efforts, I serve as the TAC Chair of the LF AI & Data and am an active upstream core maintainer of OpenShell. I have previously had the distinct honor of serving the Fedora community on FESCo, and I would be incredibly grateful for the opportunity to bring my combined history in Fedora and my current expertise in AI systems back to the committee to help steer our next chapter.

The post F44 FESCo Elections: Interview with Adam Miller (maxamillion) appeared first on Fedora Community Blog.

New badge: Contributor Recognition 2026 Winner !

Posted by Fedora Badges on 2026-05-29 12:36:17 UTC
Contributor Recognition 2026 WinnerYou went above and beyond - Fedora Project would not be the same without you!

New badge: Fedora Mentor Summit 2026 !

Posted by Fedora Badges on 2026-05-29 12:32:55 UTC
Fedora Mentor Summit 2026You attended the Fedora Mentor Summit 2026

Community Update – Week 22

Posted by Fedora Community Blog on 2026-05-29 12:00:00 UTC

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 25 – 29 May 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

  • Greg continues to hold the fort as well as possible
  • Another mirror request in progress
  • Stream mirror sync seems to have caught up from its slowness last week
  • SELinux issue in the Stream GitLab runners, debugged and restored with S.Gallagher
  • Many Let’s Encrypt SSL certs due for renewal, currently in progress

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

  • Fedora 42 will reach END OF LIFE on Wednesday, May 27th, 2026

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

  • F44 rebuild: 99% of it is done
    • Blocker now unblocked: A large Qt 6.11 update (500+ packages) is in progress, which was previously blocked by qt-webengine. The necessary patches have been rebased, so the update can now proceed.
    • Cloud and server images are unblocked. Still need to do the kiwi-descriptions; in progress
  • Currently short on time due to various resource constraints.
  • Hardware
    • An additional P550 board has been added to the Fedora RISC-V build farm
    • Sorting out the process to procure two K3 units for Fedora RISC-V Koji builders.
  • Migrating from Forge: plans to migrate the secondary dist-git overlay to forge.fp.o/riscv
  • SpacemiT K3 benchmarks continued.  We have some good incremental improvements

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

  • More and better docs, continued tech debt repayment and app improvements, openQA ELN coverage enhancement and start on cycle upgrades, also see items in AI section above
  • We’ve created a Guides & How-Tos category for Fedora Quality Docs, and try to populate it with useful articles. More will come.
  • Issuebot PR posted for review 
  • Tech debt work: improvements to blockerbugs health check and its usage, modernization and fixes for Issuebot
  • openQA stuff: extended ELN coverage, upgraded staging to Fedora 44, updated os-autoinst to latest upstream on staging, discovered a weird bug that needs working out before going to prod

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

  • Move Fedora Badges static assets from Pagure to Forgejo [Followup]
  • Incorrect commit display for some PRs [Followup
  • Zabbix template for Forgejo Runner VM deployed on staging (wip)
  • Forge runners: lightweight image option added: tested and provided to ci org 
  • Forge 15.0.1 on production, 15.0.2 on Staging

EPEL

This team is working on keeping Epel running and helping package things.

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

  • Focusing on Flock deliverables

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 22 appeared first on Fedora Community Blog.

Installing Fedora Linux Across Two Disks

Posted by Fedora Magazine on 2026-05-29 08:00:00 UTC

A year ago, a family member gave me a 2019 laptop that wouldn’t run Windows anymore. And of course, I immediately installed Fedora Linux on it. While my day-to-day Fedora Linux system is a desktop PC, it’s nice to have a laptop to take with me when I do workshops or conference demos.

However, the laptop has a physical “spinning heads” hard disk, so it is really slow to boot. I timed it; the laptop takes almost two minutes to go from “power on” to “login prompt.” And that’s a very long time when you’re at the front of the room, waiting to start a demo.

I thought about replacing the hard disk with a solid state drive, but when I opened the laptop to make sure the drive was replaceable, I saw that the laptop also supports an NVMe solid state drive in addition to the hard disk.

Laptop motherboard, with an empty NVMe slot

This presented an interesting opportunity: I could put in an NVMe drive and install Fedora Linux across two disks. Specifically, I wanted to boot Fedora Linux from the NVME drive, and keep extra apps and other data on the hard disk. I use several big third-party apps for my demos, which I install in both /opt and /usr/local, and it’s a huge pain to download and install those extra applications whenever I upgrade Fedora Linux. (I prefer to wipe and reinstall when I upgrade Fedora Linux, so I always have a clean starting point.) If I could keep /opt and /usr/local on the hard disk, I could preserve those when I install the next version of Fedora Linux.

Installing Fedora Linux to the NVMe

After installing a new NVMe drive in the laptop, I needed to reinstall Fedora Linux. I prefer the Xfce desktop, so I downloaded the Fedora Xfce spin and booted the installer. When the installer reached the “Destination” step, it prompted me for the target disk. I clicked “Choose destination” and selected the NVMe disk:

Fedora 44 Xfce install to NVMe. Text reads 'Select destination'

The rest of the installation ran normally. The Fedora Linux installer set up the partitions automatically on the new NVMe drive, encrypted my data, and installed the operating system.

Fedora 44 Xfce install to NVMe. Text reads 'Review and install'

With Fedora Linux on the NVMe drive, booting took seconds instead of minutes. Again, I timed it: about 20 seconds to go from “power on” to “login prompt.” That’s a huge improvement!

Setting up partitions on the hard disk

The disk partition app in the Fedora Xfce is GParted, which makes it easy to set up the hard disk with new partitions. However, GParted’s main limitation is that it can’t set up encrypted volumes for you. If you want to use encryption, you’ll need to use the command line and run cryptsetup on your own.

However, I’m not very concerned about encrypting my /opt and /usr/local partitions. These are just third-party apps, not private data. My personal data will be saved to my home directory, which is safely encrypted on the NVMe drive. So I decided to set up regular partitions, formatted as ext4 filesystems.

I used GParted to delete the old partitions on the hard disk, and define three partitions that were each about 300 GB: /opt (which I labeled as opt), /usr/local (labeled usrlocal) and /backup (labeled backup). GParted created the partitions and wrote an ext4 filesystem on each.

Disk partition app showing 3 new partitions, each about 300 GB

However, the /usr/local filesystem has a directory tree in it already, such as /usr/local/bin and /usr/local/lib, although these directories will be empty after installing Fedora Linux. I wanted to copy the original directories to the new filesystem. The easiest way to do that is to add the new usrlocal partition somewhere else and then copy the old /usr/local to the new partition. Adding a partition to a directory is called mounting, and the directory itself is called a mount point.

First, I needed to create a new mount point for the usrlocal partition, which can be located anywhere on the filesystem. Since this was temporary, I created it under /tmp then mounted the new partition using the mount command:

$ sudo mkdir /tmp/usrlocal
$ sudo mount LABEL=usrlocal /tmp/usrlocal

Then I copied the contents of the old /usr/local to the new /tmp/usrlocal mount point. The -a or –archive option copies everything:

$ cd /usr/local
$ sudo cp --archive * /tmp/usrlocal

After the process is complete, I unmounted the new partition:

$ sudo umount /tmp/usrlocal

Adding the partitions to the system

To make sure the new partitions are automatically mounted every time my laptop reboots, I needed to add them to my /etc/fstab file. This is a special file that contains the filesystem table, which is a list of partitions that the system can find on the disk and where to mount them. For example, my default /etc/fstab file looks like this:

#
# /etc/fstab
# Created by anaconda on Sat May 23 20:15:13 2026
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=c10ec138-be4b-4513-89b7-749ef4a0605e / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=a87b1ed4-4951-4da1-a4a4-a5c48f1f3b28 /boot ext4 defaults 1 2
UUID=9AD9-2C52 /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=c10ec138-be4b-4513-89b7-749ef4a0605e /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0

Each line in the /etc/fstab file is divided into several fields: the identifier for the filesystem (to learn more about these, see Persistent Identifiers for Storage Devices in the Fedora online documentation), the mount point, the filesystem type, a list of mount options, and two optional fields that control if backup software should “dump” the filesystem to backup media (use 0 for never) and what order the fsck command should check filesystems when needed (usually 1 for the root filesystem, or 2 for other filesystems). I added these lines to my /etc/fstab file, which defined the mount points for each of my new filesystems:

LABEL=backup /backup ext4 defaults,noatime 0 2
LABEL=opt /opt ext4 defaults,noatime 0 2
LABEL=usrlocal /usr/local ext4 defaults,noatime 0 2

This is an internal drive, so it should be there every time the laptop boots up. If you add removable storage to the /etc/fstab file, such as a USB drive, you should add the nofail option to this list of mount options. Otherwise, if the partition is not available when Linux starts up, the system will hang.

With these lines in the /etc/fstab file, I ran these commands to reload the /etc/fstab file, create the /backup mount point, and mount each of the filesystems:

$ sudo systemctl daemon-reload
$ sudo mkdir /backup

$ sudo mount /backup
$ sudo mount /opt
$ sudo mount /usr/local

This generated an SELinux alert right away, complaining that the new /usr/local filesystem lacked the correct security context. The security information wasn’t “carried over” when copying the old /usr/local directory tree. Fortunately, the SELinux error provides the solution:

Text reads 'If you want to fix the label, default label should be usr_r'

To restore the default SELinux security contexts to the new /usr/local directory tree, I ran the restorecon command. The -v option will print what it does to fix the system:

$ sudo restorecon -v /usr/local
Relabeled /usr/local from system_u:object_r:unlabeled_t:s0 to system_u:object_r:usr_t:s0
Relabeled /usr/local/lost+found from system_u:object_r:unlabeled_t:s0 to system_u:object_r:usr_t:s0

Filesystem flexibility

With just a few extra steps, I was able to use two disks with Fedora Linux, which lets me take full advantage of the storage on my laptop. The operating system now runs from the very fast NVMe drive, while my big third-party applications in /usr/local and /opt run from the hard disk.

Nightly syslog-ng containers based on Alma Linux

Posted by Peter Czanik on 2026-05-26 12:02:31 UTC

For many years, the syslog-ng project provided container images based on Debian. Most of our users run syslog-ng on RHEL & compatibles, and have asked for an RPM-based container. So, nightly containers based on Alma Linux are now also available.

A while ago, I prepared a small test project to run syslog-ng in an Alma Linux container: https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux However, that was only an experiment which I never updated. Fast forward to today: nightly syslog-ng containers based on the latest syslog-ng git snapshot package builds are now available on the Docker Hub!

Read more at https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-containers-based-on-alma-linux

syslog-ng logo

Fedora at 20th Linux Session

Posted by Fedora Community Blog on 2026-05-26 08:40:46 UTC

On the weekend of April 25th/26th 2026, the 20th Linux Session was held in Wrocław, 🇵🇱 Poland. The Session is one of the oldest and biggest FLOSS-focused conferences in Poland. The event was organized by Akademickie Stowarzyszenie Informatyczne (Academic Informatics Association) at the Wrocław University of Science and Technology.

This edition spanned over two days of the weekend, starting early Saturday at 09:00 and ending on Sunday at approx. 17:00. The schedule contained 16 talks on the main track, as well as 4 extra talks on a Python side-track and 3 workshop sessions, plus a round of lightning talks right before the closing ceremony.

The Fedora Project was one of the sponsors of this year’s edition, providing some branded cups — which were given out as prizes for asking good questions in after-talk Q&A — as well as a catering budget.

The Fedora community was represented by Dominik Mierzejewski and Artur Frenszek-Iwicki. Dominik held a workshop session where he talked about video acceleration on Linux and helped the attendees set up their systems to make best use of their hardware.

“It’s actually weird. 10 years ago I’d have a lot to do, but now, people come over to the workshop and it turns out everything just works.” — Dominik

One of this year’s sponsors, Korbank, ran a contest where the attendees could try their best at assembling a rack server: inserting the power supplies, disks, memory and the CPU. The whiteboard tracking the scores revealed a truly fierce competition: while the first contestants barely made it under 2 minutes, the final winner finished well below 50 seconds!

There was also a community stall ran by the Coreforge Foundation, showcasing their progress in developing open hardware RISC-V CPUs. Pictured above is an FPGA programmed to run one of the foundation’s RISC-V cores.

No community meetup can be complete without a big bunch of stickers to share and give away — and this event was no different, featuring two tables full of stickers, posters and postcards, generously provided by the Free Software Foundation Europe and the NGI Zero fund.

The post Fedora at 20th Linux Session appeared first on Fedora Community Blog.

📝 Redis version 8.8

Posted by Remi Collet on 2026-05-23 14:38:00 UTC

RPMs of Redis version 8.8 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

1. Installation

Packages are available in the redis:remi-8.8 module stream.

1.1. Using dnf4 on Enterprise Linux

# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm
# dnf module switch-to redis:remi-8.8/common

1.2. Using dnf5 on Fedora

# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm
# dnf module reset  redis
# dnf module enable redis:remi-8.8
# dnf install redis --allowerasing

You may have to remove the valkey-compat-redis compatibility package.

2. Modules

Some optional modules are also available:

These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).

The modules are automatically loaded after installation and service (re)start.

The modules are not available for Enterprise Linux 8.

3. Statistics

redis

redis-bloom

redis-json

redis-timeseries

From May 18 to May 24

Posted by Aurélien Bompard on 2026-05-25 07:32:00 UTC

Across the Fedora Project, teams focused on a combination of governance, strategic initiatives, infrastructure modernization, and critical maintenance. A prominent theme was community governance, with the nomination period for elections closing for the Council, FESCo, Mindshare, and EPEL steering committees. This coincided with internal reviews of operational processes within the Council and Mindshare. Several groups pushed forward on new initiatives, such as the debate over an AI Developer Desktop, the development of a new "home server" spin by the Server WG, and the AI & ML SIG's creation of a skills library. Foundational work was also a key focus, with the Infrastructure team continuing its major upgrade to RHEL 10, EPEL transitioning to version 10.2, and multiple teams planning for the Fedora 45 release. Finally, security and package health remained a high priority, highlighted by a project-wide effort to patch the "Fragnesia" kernel vulnerability and FESCo's decision to retire an unmaintained desktop environment due to security concerns.

Announcements

This week, the Fedora Project is focused on community governance and recognition. The nomination period for positions on the Fedora Council, FESCo, Mindshare, and EPEL steering committees is ending soon, providing a critical opportunity for contributors to step into leadership roles. In parallel, community members are encouraged to nominate their Fedora heroes for the 2026 Mentor and Contributor Recognition program. A summary of the community survey on a potential "Fedora Verified" initiative was also published, sparking considerable discussion about the program's direction and the survey's methodology. On the events front, a detailed report from the successful Fedora and CentOS presence at SCALE 23x was shared, highlighting community outreach and technical sessions.

On the technical side, test images for sealed bootable container images for Fedora Atomic Desktops are now available, introducing a fully verified boot chain from firmware to the OS using Secure Boot and a Unified Kernel Image (UKI). The weekly Community Update covered numerous infrastructure improvements, including a fix for Koji's sporadic 502 errors, a new s390x test instance for package maintainers, continued progress on the RISC-V F44 rebuild, and the retirement of EPEL 10.1. Finally, as the project-wide migration to the new Fedora Forge continues, contributors are actively seeking guidance on migrating specific repositories from the legacy Pagure system.

Council

The Council's week was marked by a meeting focused on finalizing the F44 Council election interview questions and a discussion on improving its own operational processes. The Council acknowledged challenges with a lack of asynchronous work on tickets, leading to rushed decisions during meetings, and is considering procedural changes. On the forums, community engagement centered around an updated proposal for an AI Developer Desktop Initiative. The discussion highlighted debate over the initiative's plan to build and sign third-party kernel modules (like NVIDIA's OpenRM) within a Fedora Remix, touching on core project values and the role of Remixes for experimentation. Further context was provided by a Council member's post explaining a previous vote change on the initiative to allow for more community discussion, and a new proposal from a community member for an alternative, fully FOSS AI ecosystem. Contributors interested in the future of innovation in Fedora are encouraged to provide feedback on both the AI initiative and the draft Fedora Innovation Lifecycle policy.

Decisions

During the Council meeting on 2026-05-20, the following set of questions for the F44 Council election interviews were agreed upon, pending any final objections in the corresponding ticket:

  1. What kind of experience do you have which might be relevant for the role (for ex. governance,..)?
  2. What do you see as potential opportunities and risks for the Fedora Project in its future?
  3. What brought you to Fedora?

Learn more about the Council team.

FESCo

In their meeting on May 19, 2026, the main subject of discussion was the unmaintained and insecure state of the Deepin Desktop Environment (DDE) packages. The maintainer has been non-responsive to security issues and maintenance needs, but has actively prevented the packages from being orphaned by reclaiming them. This has blocked other contributors from taking over and fixing the problems. To resolve this situation, FESCo decided to retire all the affected packages. The issue with more details can be found in ticket #3409.

During the open floor, it was noted that FESCo election nominations are still open. A concern was also raised about the large backlog of new contributors waiting for a packager sponsor, presenting an opportunity for experienced packagers to help mentor newcomers.

Learn more about the FESCo team.

Mindshare

A discussion was initiated by Justin Wheeler regarding the future of running surveys in Fedora, specifically the use of the LimeSurvey tool. Citing personal burnout, a lack of support, and recent negative community feedback on the professionalism of surveys, he proposed shutting down the LimeSurvey service unless others step up to own the process. The conversation that followed showed strong support for Justin, encouraging him to prioritize his well-being. Contributors largely agreed that the issue is not just about the tool, but about a flawed process that relies on a single person and has historically produced surveys of questionable quality. While some process improvements were suggested, such as requiring multiple authors, the overwhelming sentiment from participants was to cancel the LimeSurvey subscription and reconsider the project's approach to surveys altogether, saving both money and valuable contributor energy.

Learn more about the Mindshare team.

Workstation / GNOME

This week's discussions focused on packaging changes and the user experience during system setup and recovery. A key topic was the switch in Fedora 44's GNOME Software from using PackageKit to direct DNF integration. This change was confirmed as a deliberate, Fedora-specific decision to reduce maintenance and gain finer control over functionality. Another discussion highlighted a potential issue where the default "rescue" boot image can become outdated and broken after several kernel updates, as its required kernel modules may be uninstalled.

The Workstation Working Group meeting addressed the future of the first-boot experience, debating a request to add a power-off option to the initial setup screen for OEM use cases. This led to a broader conversation about the future of GNOME Initial Setup and the need to align with upstream plans while ensuring features like live user mode are supported. Following a report from the LAS Conference, there is also interest in investigating a Sentry-based crash collection system for upstream GNOME, similar to what the KDE team uses.

Decisions

Learn more about the Workstation / GNOME team.

Server

The Server Working Group's weekly meeting focused heavily on the development of a new "home server" spin-off. The group made several key decisions, including approving the project's initial goals and deciding to keep its development tickets integrated within the main Server project for now. A new contributor with professional video editing experience has offered to create a promotional video, which the group plans to use as a "teaser" to attract more collaborators to the new spin-off. The group also continued discussions on renaming the Server installation media to "online-install" and "offline-install" to provide more clarity for users, with a vote pending in ticket #126.

An opportunity for community contribution is the creation of the documentation for the new home server spin-off; a draft Table of Contents is being prepared to guide this effort. Work also continues on a post-installation Ansible role.

Decisions

  • The tickets for the new home server spin-off will be kept integrated with the main Server ticket repository, using labels for organization.
  • The working group approved the goals for the home server spin-off as specified in ticket #197.
  • The group agreed to move forward with creating a promotional video for the home server project to attract new contributors, as detailed in ticket #200.

Learn more about the Server team.

Infrastructure

This week, the team continued its significant effort to upgrade infrastructure to RHEL 10, with progress made on DNS servers and other virtual machines. An infrastructure-wide outage for updates and reboots is now scheduled for June 4th. The transition from Nagios to Zabbix is also nearing its final stages, with the goal of retiring Nagios by Flock. The team plans to consult with other Fedora teams soon to set up new monitoring notifications in Zabbix.

A key topic of discussion was the need for container image hosting for SIGs and WGs. While there is no official solution yet, the team is exploring the use of quay.io. However, it was noted that quay.io does not support integration with Fedora Accounts (FAS) for permission management. Other discussions during the daily standups included troubleshooting bugzilla2fedmsg issues and triaging day-to-day tickets, such as a request for a VM to host a static archive of pagure.io and fixing the mailing list search index.

Decisions

  • An outage for mass updates and reboots was scheduled for June 4th, 2026.
  • The team decided to close their internal ticket regarding an sftp SELinux issue, as a fix is expected from the selinux-policy package maintainers.

Learn more about the Infrastructure team.

Quality

This week, the Quality team recognized and thanked its top contributors with the publication of the "Heroes of Fedora Quality for Fedora 44" article, shared via the discussion forum and mailing lists. Work on the next release continued with automated calls for community testing on new Fedora 45 Rawhide nightly composes. An announcement was also made for the upcoming Fedora Quality Meeting on May 25th, where topics will include the status of Fedora 45 and community testing events.

Learn more about the Quality team.

Websites and Apps

The only activity this week was a mailing list discussion regarding the use of security.txt files for Fedora Project domains. This was prompted by an academic survey that noted the absence of a security.txt file on the main fedoraproject.org domain. The discussion clarified that a security.txt file is indeed published, but it is located on the admin.fedoraproject.org subdomain. It was noted that creating a separate security.txt for every subdomain is impractical, especially when the contact information would be identical across all of them. The file directs users to the main security page for contact information.

Learn more about the Websites and Apps team.

Docs

During the weekly Docs meeting, the team focused on improving internal processes and documentation strategy. A key discussion revolved around standardizing issue labels in their repositories to streamline workflows, resulting in a decision on a new label set. Another topic was the structure of contributor guides, with the team agreeing to favor smaller, focused articles connected by a clear menu over large, consolidated documents. On the forums, a technical discussion about Antora cross-references highlighted the challenges with local previews and CI when using xref for external repositories. The recommended workaround is to use plain URLs for links between different documentation components to avoid build complexities. Additionally, a minor but helpful correction was made to the "Tasting Menu" onboarding guide, ensuring that contributor-facing information remains accurate.

Decisions

  • The team agreed to adopt a new, standardized set of issue labels, based on a proposal in issue #40. The final set will drop the "size" labels and re-add a "code" label.
  • For contributor documentation like the "Local Workflow" guide, the team will create simple, single-topic pages connected by a clear menu structure rather than combining multiple topics into one large document.

Learn more about the Docs team.

Internationalization

This week, the Internationalization group welcomed a new contributor to the French translation team. In a self-introduction on the mailing list, Kevin (FAS: archer69m-i-a) expressed his interest in helping with French localization (l10n), particularly with documentation and UI translation. This presents a new engagement opportunity for the French l10n team, as Kevin brings previous experience from contributing to GNOME's translation project.

Learn more about the Internationalization team.

This week in the Legal group, a discussion was revived on the mailing list regarding the stability of software license identifiers. While the original thread from March concerned a tool misidentifying a license, the recent conversation delved into the history of the 0BSD license identifier. It was clarified that while the SPDX identifier for 0BSD has remained stable, the OSI had initially approved the license under the name "Free Public License 1.0.0" before later changing it to align with the more widely recognized 0BSD name, following community feedback.

Learn more about the Legal team.

COPR

The main discussion for COPR this week was a follow-up on the future of native s390x builders. While these builders are currently available again, the team is actively seeking a long-term replacement as the current provider will end its service by the end of the year. In a mailing list discussion, it was clarified that potential solutions must support Copr's security model, which requires spinning up short-lived, single-use virtual machines for each build. This constraint makes some community cloud offerings, which may be oriented towards long-lived VMs, unsuitable. The search for a new provider continues.

Learn more about the COPR team.

EPEL

This week's main focus was the retirement of EPEL 10.1 and the transition to EPEL 10.2. As announced on the mailing list and confirmed in the weekly meeting, EPEL 10.2 packages are now being built against RHEL 10.2 content. Packagers were advised that some builds might temporarily fail while the new RHEL content finishes synchronizing. The other major topic was the upcoming EPEL Steering Committee election, with nominations closing on May 21st. There are currently six candidates running for four open positions.

Learn more about the EPEL team.

ELN

In this week's ELN meeting, progress was reported on bootc images, with merge requests advancing and jligon taking maintainership of the Fedora-eln bootc image; a call for co-maintainers was made for this effort. The group was given a heads-up that the s390x architecture baseline will soon be bumped to z15, with an ELN mass rebuild planned to follow, aiming to identify any compilation issues early. There was also a detailed discussion on the complex task of rewriting package git histories to resolve git-fsck issues, a necessary step for future RHEL development and the eventual migration to Forgejo. Finally, a fix for a build failure in retsnoop on ppc64le is being investigated with upstream.

Decisions

  • The s390x baseline in ELN will be bumped to z15 soon.
  • An ELN mass rebuild will be initiated shortly after the s390x baseline change lands.
  • Stephen Gallagher will prototype a set of commands for rewriting package git histories to resolve long-standing git-fsck issues.

Learn more about the ELN team.

Atomic

This week, discussion focused on user feedback from a Fedora Kinoite installation on older (c. 2012) hardware. The user reported a fatal Anaconda crash when attempting to install a second Atomic OS on the same disk, which was identified as a known issue requiring a separate EFI partition as a workaround. A key concern was raised about the future viability of older UEFI firmware when Atomic desktops transition to UKI-only boot. It was clarified that the traditional boot method will be preserved for backward compatibility. Even after UKIs become the default, tooling will be available to extract the kernel and initramfs from the UKI, ensuring older hardware remains supported.

Learn more about the Atomic team.

CoreOS

This week, the CoreOS team announced fixes for the "Fragnesia" (CVE-2026-46300) and "ssh-keysign-pwn" (CVE-2026-46333) vulnerabilities. The fixes are available in the next and testing streams, and the team provided mitigation steps for users on the stable stream.

In the weekly meeting, the team discussed reworking the long-running upgrade testing strategy. The current approach of testing from the earliest releases is becoming time-consuming. Ideas such as using a sliding window of supported upgrade versions or creating pre-booted VM snapshots to speed up tests were explored. A decision was also made to adopt chunkah, a new tool for optimizing container image layers to improve reuse (tracker issue). This will be rolled out experimentally in the rawhide and next streams with an increased layer limit.

Learn more about the CoreOS team.

AI & ML

During the bi-weekly AI & ML SIG meeting, the group discussed creating a centralized library of AI agent "skills" to assist Fedora contributors and decided to repurpose an existing repository for this effort. The team also covered packaging updates, noting the availability of the python-piper-tts text-to-speech package and a call for review on the pi-coding-agent package. Following a recent community proposal for an "AI Developer Desktop," there was a significant discussion about the SIG's role as a stakeholder in major AI initiatives, leading to a plan to improve the group's documentation and clarify its purpose. The meeting concluded with an update on work to create a fully open AI stack for edge devices, sponsored by Arm, which is being targeted as a Fedora 45 feature.

Decisions

  • The group agreed to create a centralized repository for AI agent skills. The existing skill-meeting-secretary repository was renamed to skills-library and will be reorganized to serve as a mono-repo for various contributor-focused skills.
  • The topic of improving the SIG's documentation and defining a content strategy between the Fedora Docs site and the Wiki will be formally discussed in the next meeting.

Learn more about the AI & ML team.

Security

During the weekly Security SIG meeting, the team discussed upcoming updates for fedora-downstream-hardening, noting that collaboration from package maintainers might be needed soon. There was also a call for contributors to help with the security documentation site. The primary topic of discussion, both in the meeting and on the forums, was the ongoing effort to patch the "Fragnesia" and related kernel vulnerabilities.

In a highly active forum topic, it was confirmed that the situation is evolving, with new exploitable code paths being discovered even as patches are released. Fedora kernel maintainers are working quickly to build and release new kernels (up to 7.0.9-204 in testing) with the latest upstream fixes. Contributors can help accelerate the delivery of these critical security updates by testing the new kernel builds as they become available in Bodhi.

Learn more about the Security team.

Go

During the weekly Go SIG meeting, several important updates were shared. A heads-up was given about 14 incoming CVEs for various Go x packages. Recent releases include Go 1.26.3, 1.25.10, and the latest version of Delve. The most significant topic was the Fedora 45 proposal to introduce Go 1.27. This upcoming Go release is particularly notable because its crypto library has achieved CMVP (FIPS) certification upstream. This development will eliminate the need for the separate go-fips fork, which will greatly simplify packaging and allow for a unified specfile across Fedora, CentOS, and RHEL.

Learn more about the Go team.

Perl

This week's activity for the Perl group consisted entirely of package maintenance and updates via pull requests on the perl-devel mailing list. A notable update was for perl-HTML-Parser to version 3.85, which addresses the security vulnerability CVE-2026-8829. Several other packages were also updated to their latest versions, including perl-libwww-perl, perl-XML-LibXML, perl-HTTP-Tiny, perl-Net-CUPS, and perl-Net-Server. Additionally, test dependencies for perl-Inline were fixed.

Learn more about the Perl team.

Python

This week's discussions focused on tooling for Python packaging in Fedora. A conversation continued on the new %pyproject_patch_dependency macro, with a suggestion to adopt a long-option syntax (e.g., --ignore). For now, the decision is to wait for more user feedback on the provisional feature before changing the API. Another thread provided clarification on generating build requirements using %pyproject_generatebuildrequires. It was explained that dependencies from [build-system].requires are generated by default, and flags like -p or -R should be used when a build backend cannot provide runtime dependency metadata before the build process.

Learn more about the Python team.

Other Discussions

  • An announcement was made for the first Fedora Hummingbird community meeting, scheduled for May 28, 2026, to increase visibility and encourage participation.
  • A user reported that the plocate-updatedb.service causes high CPU usage in virtual machines by scanning virtiofs filesystems. It was suggested to add virtiofs to the PRUNEFS list, and a bug report was subsequently filed.
  • Several developers posted requests for review swaps for their packages, covering languages such as Ruby, C++, Python, and Pascal.
  • A packager sought advice on the best way to handle the Trix editor, a JavaScript dependency for rubygem-actiontext, which was recently split into its own gem, sparking a discussion on how to package bundled JS assets.
  • A maintainer inquired why the rebuilds for torsocks in F44 and F45 were not tagged for release, despite successful builds in Koji.
  • A user encountered an error while trying to report an SELinux bug due to an invalid Bugzilla API key. The issue was resolved by clearing the stored key with secret-tool and re-entering it when prompted.
  • A packager asked for help determining why .oct files from Octave packages are not being stripped of debug symbols during the build process, leading to a discussion about find-debuginfo.sh and related build scripts.
  • Other topics discussed this week include a proposal to modify system scripts' PATH handling (link), a kernel regression with the IGC driver that was later fixed (link), the prevention of libieee1284's removal (link), a request to add vulkan-wsi-layer as a dependency (link), a proposal to consolidate hunspell dictionaries (link), updates on SPDX license conversion (link), the state of Fira fonts (link), a fix for a widespread rpminspect CI failure (link), help needed with matrix-synapse (link), and ongoing discussions about packaging Electron apps, Project Hummingbird, and the s390x builder outage.

Orphaning packages

Package Updates

New Contributor Introductions

  • Rainbow Baby (yinglian666) introduced themselves with a detailed technical background, though a follow-up message suggested the introduction may have been AI-generated and encouraged authenticity.
  • Rachel Menge, a software engineer working on Azure Linux, introduced herself and expressed interest in contributing to the Fedora ecosystem, starting with SELinux policy cleanups.
  • Kevin (archer69m-i-a) introduced himself as a French Fedora user interested in contributing to French localization (l10n) for both Fedora and GNOME.
  • Konstantinos Vasilopoulos, a Computer Science student with a background in data engineering and an interest in Rust, introduced himself and is looking to get involved in the Fedora community.
  • Yun (Xynrin), a college freshman, introduced themselves and shared a Chinese Fedora Wiki they created, expressing a strong interest in contributing to documentation and community building via the Mindshare Committee.

blood glucose monitoring with open source

Posted by Kevin Fenzi on 2026-05-24 16:34:14 UTC
Scrye into the crystal ball

Over a year ago now, I was diagnosed with Diabetes. I'm not going to go into too much about it here since there's tons of other online resources for it, but I wanted to share one particular area where I have been able to use serveral open source products to help monitoring and tracking my blood glucose levels.

Monitoring blood glucose is important information. Various things affect it and it's good to know what those are and how much they affect it. Some things affect it very quickly (exercise) and some more slowly (digesting food). Some foods affect levels dramatically, some not as much.

When I was first diganosed, the recommendation from my doctor was to use periodic blood tests to see what the levels were. This consists of a set of lancets, some monitoring strips and a reader. You poke your finger and draw a drop of blood on the strip, then put that in the reader and it gives you a reading. This is really quick accurate, but it has a lot of drawbacks:

  • You have to poke yourself all the time and it's painfull and anoying.

  • The reader has bluetooth (but the only thing that can connect to it is a closed source android app).

  • The closed source/non free android app requires you to make an account and then send all your readings to some company.

  • Its really not easy to test a lot, or when traveling.

  • You consume a lancet and a test strip for every test. They are small, but it's still consumable/waste.

I looked at getting a CGM (continous glucose monitor) which is a sensor you affix to your arm and it monitors all the time for a few weeks, when it needs to be replaced. This seemed much nicer, but it had drawbacks too:

  • More expensive

  • Still had a closed source/non free app that required you to make an account and upload all your data to them.

  • slightly less accurate

So, I just kept on with infrequent stick testing, until I noticed a post from Bradley Khun on the software freedom conservency blog:

https://sfconservancy.org/blog/2025/nov/06/juggluco-foss-continuous-glucose-montior-diabetes/

There was a open source android app to talk to these sensors!

So, a quick message to my doctor and a perscription in hand, I got some monitors to try out. Juggluco ( https://github.com/j-kaltes/Juggluco ) has kind of a odd interface, but it works great once you figure it out. The sensors seem like they would be painful to attach, but I really haven't noticed anything when applying them. They also make some 'covers' that fit over them to protect them from water/etc. They do look a bit ragged after 15 days, but I've not had one come off yet. Being able to have readings all the time has been very nice. Especially when traveling. It can even give you a 'estimated a1c' value (This is basically a trending for blood glucose over the last N months). You can see immediate results from exersize and can definitely see 1-2 hours after meals how much they affect things.

All my data is stored on my phone, which was ok, but I wanted to have a longer term/more stable backup of that data at least.

Google created a while back a setup in android for medical / heath data. "Health Connect" is surprisingly well setup. You (the user) can decide exactly what applications have permissions to write what health data and what applications have permissions to read that data. The idea being that you can decide to share some data with some application, or revoke it later if you choose to. All the data is still stored on the phone, this is just controlling access to it.

The android home assistant application has the ability (if you grant it to read health connect data. I then just set juggluco to write blood glucose values into health connect and allowed home assistant application to read that. A new sensor appears in home assistant. Now I can graph, run automations based on it, or do anything I can normally do with a sensor in home assistant. You can do the same with for example the 'steps' counter that android keeps automatically.

There is one slight gotcha in this setup that I discovered a few weeks ago. I went to go look at my longer term blood glucose trends, and... there was only 10 days of values in home assistant. ;( The home assistant android app doesn't keep long term statistics anoyingly. You can get around this by making a template sensor that just reads from the android app one and it will keep long term data (although the usual home assistant way of 1 datapoint per hour instead of all the datapoints, but that should be reasonable for long term trends).

Overall I think its a pretty nice setup now. I do wish the sensors lasted longer. They last for 15 days and then stop. I'm not sure if thats a limit of battery life, some kind of reading accuracy issue or just that they want you to buy more sensors.

comments? additions? reactions?

As always, comment on the fediverse: https://fosstodon.org/@nirik/116630715953443762

misc fedora bits third week of may 2026

Posted by Kevin Fenzi on 2026-05-23 17:50:26 UTC
Scrye into the crystal ball

Another saturday, time for another longer form weekly recap of what I have been up to in Fedora Infrastructure.

RHEL10 migrations

RHEL10 migrations are in full swing. Moving things we have that are on RHEL9 over to RHEL10 with clean re-installs. Mostly this is just pretty easy, but I did run into a few fun things:

  • One of our donated servers was really old and couldn't run RHEL10, so, the provider provisioned us a new(er) one. All good, but we like to do clean installs of our servers and this provider didn't happen to have a remote console, so it was kind of flying blind. First, the RHEL10 installer would hang on boot in systemd-gpt-auto-generator. My theory ( but I haven't tested it yet to be sure ) is that because they installed Fedora 44 on it, when it booted to the RHEL10 installer it would try and figure out the partitions, that would work, but then because there's no btrfs support it would get confused and hang. Next I ran into vnc being deprecated in rhel10.1. Fine, but, also no rdp kickstart directive available, you MUST pass inst.rdp on the boot line. Then of course various adventures in partitioning and such. I did finally get it done, but there was a lot of 'please reboot it' back and forth with the very patent provider.

  • I found another of our old machines ( which is due to be replaced this year, but with hardware prices and availablity I am not sure it actually will be ) is actually BIOS booting still. I just left it for now, if we don't end up replacing it I might reinstall uefi.

  • A few issues around our internal repo files and which things they were or should be pointing to (for minor releases, since 10.2 came out while I was in the middle of installing some things).

Anyhow, good progress being made on all the easy ones.

Flock coming up fast

https://fedoraproject.org/flock/2026/ is coming up fast. Just 3 weeks. This is our big conference of the year, will be great to meet up with folks and discuss everything.

comments? additions? reactions?

As always, comment on the fediverse: https://fosstodon.org/@nirik/116625217014724131

Community Update – Week 21 2026

Posted by Fedora Community Blog on 2026-05-22 10:00:00 UTC

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 18 – 22 May 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

  • Mostly business as usual, just trying to cover the basics
  • New mirror request completed, some hosts needed reboots/pokes
  • Watching the CVE storm, mitigating exposed hosts, and waiting for kernels to reboot on

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

  • Continued reviewing releng change proposal for f45 changesets
  • Continued working for introduction of differentiation in beta and final variants in composeinfo file according to standards.

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

  • F44 rebuild: 22K packages built out of 24K.
  • Continued with benchmarks on remote  SpacemiT K3.  (The access will expire in a couple of days.)
  • Continued preparing the Flock presentation.
  • Fedora Koji builder hardware: Wrote a brief business justification for two units of K3 for Jason and David.
  • Debug a failed OpenJDK build, fix the bug, and kick off a fixed up build. Kicked off a fixed up JDK main build

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

EPEL

This team is working on keeping Epel running and helping package things.

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 21 2026 appeared first on Fedora Community Blog.

🎲 PHP version 8.4.22RC1 and 8.5.7RC1

Posted by Remi Collet on 2026-05-22 05:09:00 UTC

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.7RC1 are available

  • as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

RPMs of PHP version 8.4.22RC1 are available

  • as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

  • version 8.5.4RC1 is in Fedora rawhide for QA
  • EL-10 packages are built using RHEL-10.1 and EPEL-10.1
  • EL-9 packages are built using RHEL-9.7 and EPEL-9
  • EL-8 packages are built using RHEL-8.10 and EPEL-8
  • oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
  • intl extension uses libicu 74.2
  • RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
  • versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

Friday Links 26-17

Posted by Christof Damian on 2026-05-21 22:00:00 UTC
A sandwich on a white plate, made with a seeded baguette, filled with arugula, tomato, bacon, and cheese

Two weeks of links again! Three podcast recommendations from me, if you got the time: Dadaism, Cow Resistance, and Desert Island with Si King. The post by Rands about being overwhelmed as a leader is also great.

Quote of the Week
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Mostly Harmless
Douglas Adams

Leadership

Barely Treading Water - I can relate very much. “Say No” is a good start.

Single-Click Code Execution Exploit for Evince, Atril, and Xreader

Posted by Michael Catanzaro on 2026-05-21 20:49:51 UTC

CVE-2026-46529 is an argument injection vulnerability in Evince, Atril, and Xreader caused by missing shell quoting when composing a command line. The reporter, João Medeiros, has published a GitHub repo for the CVE and a blog post with the story of how he discovered the flaw and developed the exploit. He also created an Atril security advisory and an Evince issue report.

The vulnerability is fixed in:

  • Evince 48.4 (fix commit) (I originally reported that it is fixed in 48.2, but there was no successful release for that tag)
  • Atril 1.28.4 and 1.26.3 (fix commit)
  • Xreader 4.6.4 and 3.6.7 (fix commit)

If you use one of these PDF readers, update immediately. Or at least please be seriously paranoid about clicking on links in PDFs until you do update.

This vulnerability also affects Papers, but it’s probably not urgent to update Papers. (No, not because it uses Rust. Keep reading!)

The Flatpak sandbox could have drastically reduced the danger of this attack, limiting the compromise to only files that you had previously opened in the PDF reader. Sadly, Evince and Papers both use sandbox holes that render the sandbox totally meaningless. (Atril and Xreader are not available on Flathub.)

The Vulnerability

When you click on a link in a PDF, Evince may execute itself to display the link. Normally the command line used would look something like this:

/usr/bin/evince --named-dest=/home/foo/hello.pdf

But an evil PDF may trick Evince into executing a command that is quite different than expected:

/usr/bin/evince --named-dest= --gtk-module=/home/foo/evil.so /home/foo/hello.pdf

Oops. The first part of the command is always going to be /usr/bin/evince, but the evil PDF is nevertheless able to unexpectedly load a GTK module into Evince. The fix is to quote the untrusted input using g_shell_quote() to ensure it cannot “break out” of its intended context:

/usr/bin/evince --named-dest='/home/foo/hello.pdf'

Or:

/usr/bin/evince --named-dest=' --gtk-module=/home/foo/evil.so /home/foo/hello.pdf'

Much better: now the threat is neutralized. g_shell_quote() is safe to use even if the untrusted input itself contains quotes. (However, beware: this only works because GLib is parsing the command line itself, and GLib is not a real Unix shell. It’s not safe if the input is going to be passed to an actual Unix shell. It might not even be theoretically possible to do that safely, because it’s valid for filenames to contain entirely arbitrary characters!)

All GTK 3 apps support the --gtk-module command line argument for injecting a shared library into the application. The library may of course then execute whatever code it wants via its library constructor. But GTK 4 no longer has standard GTK command line flags, so this does not work for GTK 4 applications like Papers. It’s still possible to tell a GTK 4 app to load a GTK module, but only via environment variables, not via command line flags, and I don’t see any opportunity for the malicious command to set environment variables. It’s probably not possible to exploit this vulnerability in Papers: although it has the exact same vulnerability as the other PDF readers, the impact is different.

The Exploit

So far this looks like a pretty typical security bug. OK, so if you trick the user into downloading an archive (or perhaps a git repo) that contains both a malicious PDF and also a malicious shared library, then you can trick the PDF reader into loading the shared library and thereby execute arbitrary code. That’s a pretty bad foreseeable exploit, sure, but at least the attacker is at considerable risk of arousing suspicion if the user is trying to download a PDF and also receives a shared library. You’d have to try pretty hard to hide the library in a forest of other boring files if you want the attack to look convincing and unsuspicious. Right?

Nope.

João used Claude Opus 4.7 to develop a sophisticated script for building malicious polyglot PDFs that are simultaneously both valid PDF files and also valid ELF binaries, so the attacker only needs to trick the victim into downloading one evil PDF file. When the victim clicks on a link in that PDF, the PDF reader will dlopen the PDF itself. The PDF/ELF polyglot’s library constructor will then execute arbitrary code. Much less suspicious, and much scarier. Polyglot files are not entirely novel, but I’d still say this required substantial creativity and expertise from the AI, and substantial persistence from the human. Needless to say, very nice job to both Claude and João.

You can easily build your own malicious PDF using the provided script and sample GTK module. The script in the Evince and Atril issue reports requires that the attacker predict the absolute path that the malicious PDF file will be saved to; however, João’s blog post and GitHub repo refine the exploit to remove that requirement.

Thoughts on AI Vulnerability Reports

A human inspecting this code should have been able to find the parameter injection vulnerability, but that requires considerable time and effort, so unsurprisingly nobody did. We’re probably in for a rough time in the short term as the volume of AI-generated vulnerability findings remains temporarily very high and attackers have a much easier time crafting working exploits. But in the long term, I expect we are going to be much more secure than we were before, so this will be worth it.

A human working alone would have almost certainly stopped and moved on after finding the vulnerability. Claude allowed taking the investigation much farther. It’s highly unusual for a GNOME vulnerability report to come with a working exploit. This is a dangerous change. Perhaps it will be a one-time event, but I suspect we will be seeing more frequent exploits in the future.

Silver lining: the exploit helps us better appreciate the severity of the issue. It’s often hard to assess how bad a vulnerability is. If not for the weaponized exploit, I would have thought this bug was not very scary, and would have treated it as not a big deal. We would have fixed it, perhaps or perhaps not with a CVE ID, surely without any blog post or fanfare, and probably without distro security updates. But since there is an exploit, we instead had no doubt that this vulnerability was dangerous, and were able to handle it accordingly.

Several GNOME projects have begun outright prohibiting all AI-generated contributions, including issue reports, with no exception for vulnerability reports. Such policies are misguided and unacceptable. I can sort of understand why some projects might (misguidedly) wish to prohibit AI-generated code contributions. OK, fine. But blocking AI vulnerability reports will make GNOME less safe. AI-assisted vulnerability reporting is the new industry standard for good reason: it is highly effective.

Some humans are not good at preparing AI-assisted vulnerability reports and will spam maintainers with low-quality reports. Sometimes they will be outright bogus, although more often there may be valid underlying bugs with exaggerated severity claims or bad proof of concept demos. This is annoying, but bad issue reports are a cost we are just going to have to accept and deal with.

The quality level of AI vulnerability reports reviewed by conscientious humans — as well as AI assessments of AI vulnerability reports — is now often quite encouraging. But just like humans, AIs may also miss things, especially subtle distinctions that may be highly relevant. Although I’m quite impressed with these AIs, we still need experienced humans to review and manage reports. Please don’t abuse the technology by submitting vulnerability reports that you do not understand or have not validated. And certainly please do not allow an AI agent to interact with an issue tracker on your behalf!

For Security Geeks

This was my first time scoring a vulnerability using CVSS 4.0 rather than CVSS 3.1. It’s also the first time I wasn’t terribly confused about how to set the parameters, because the scoring guide contained answers to all of my questions. Nice. My CVSS vector for CVE-2026-46529 is CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, the base score is 8.4, and I’m pretty sure my choices for each parameter are good. By comparison, using CVSS 3.1 I came up with CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H and base score 7.8.

Fedora and CentOS @ SCALE 23x 2026

Posted by Fedora Community Blog on 2026-05-21 08:17:17 UTC

Our remarkable Fedora ambassador, CentOS, and associate crews delivered live face-to-face support and outreach via our Fedora and CentOS @ SCALE 23x Linux Conference.

TL; DR

  • What: A community-run open-source and free software conference in Pasadena, California
  • Where: Pasadena Convention Center
  • When: 5 – 8 March 2026

Our Field Crew

This reports the activities of the following Ambassadors / CentOS / Red Hatters / associates at the SCALE 23x Linux event:

  • Fedora Ambassadors
  • CentOS
    • Carl W George (FAS: Carlwgeorge)
    • Shaun McCance (FAS: shaunm)
    • Laura Santamaria (Community Architect) (FAS: Nimbinatus)
  • Red Hat
  • Associates
    • Davide Cavalca (Meta) (FAS: Dcavalca)
    • David Duncan (Amazon Web Services) (FAS: Davdunc)

Our Remote Crew

  • Fedora Contributor
    • Chris Idoko (FAS: Chris)

What is SCALE 23x?

The SCALE (The Southern CAlifornia Linux Expo) 23x community Linux event encompasses the 23rd Linux and related technology event with four days of exhibits, tutorials, and demos. This year’s SCALE happened in Pasadena (Los Angeles) area.

SCALE attracted about 3,000 worldwide guests to discuss Linux, AI, DevOps, security, free and open-source software, and more. Technical Committee (Online Services) Chairperson, Mr. Phil Dibowitz, and Network & Wifi Chairperson, Robert Hernandez, among many other community volunteers paved the way for a smooth registration.


Expo Highlights


Our Fedora Community Architect @jflory7 curated and arranged delivery of key swag and marketing items to Perry Rivera. Items included: commuter mugs, buttons, pens, stickers, badge lanyards, and more.

Day 0: Wednesday 4 March

Ahead of our event, Fedora Contributor @chris furnished our attendees an amazing SCALE 23x Attendee badge. 58 attendees claimed the badge this year; cheers to @bcotton for being the first earner!

Fedora Ambassador @vwbusguy helped retrieve half of the items needed for the expo for next-day delivery.

Red Hatter and Fedora Ambassador @lajuggler later that evening delivered expo items.

  • Dry-board markers and flipchart easel
  • More swag
  • Rolling case

@lajuggler finalized Fedora setup on 2 laptops.

Meanwhile, the rest of the crew commuted and checked in.

Day 1: Thursday 5 March

@lajuggler attended an early morning Meshtastic workshop.

Ambassadors arrived to the expo floor to pre-setup booth tables and banners.

After @lajuggler ‘s workshop, he arrived later to the expo floor to join pre-setup and unpack swag, easel and markers, and a Fedora retromodem demo.

Day 2: Friday 6 March

The crew assembled to present Fedora Hatch Day.

A set of us departed for lunch so we could make ready for opening the Expo floor later that day. @lajuggler and @carlwgeorge set up live demos on both systems for guests to use.

Like to set this up? Get started with a presentation from @lajuggler here.

Later that evening, we had dinner at El Portal. Moreover, Rob McBryde organized a stellar Karaoke night event at Barney’s Beanery.

Day 3: Saturday 7 March

Next, Our crew re-assembled in the expo hall to continue meeting and discussing with community. Later that evening, we had dinner and then converged on Game Night.

Day 4: Sunday 8 March

Once again, our crew gathered in the convention hall to continue our demos and greets with community. Later that afternoon, the crew packed up and closed the booth.

Key Sessions and Takeaways

Session 1: Workshop: Long range, cheap comms through Meshtastic

TakeawayRelevance to Our Work
Encourages communication with othersEncourages community
Relatively low cost to get started. Does not require a licenseMinimal barrier to entry
Open-sourceEncourages open-source activities
Physical component and light building assemblyFairly easy to get started to communicate right away

Demo 1: WiFi Retromodem on Fedora 43 Highlights

TakeawayRelevance to Our Work
Guests drawn by retro and novelty aspects of the retromodem and coolretrotermGuests not normally interested in Fedora were happy to download a free PDF to learn how to build a similar setup at home with Fedora.
There was the concern that 9600 bps max would be too slow for guests, but people seemed perfectly fine with text whizzing by onscreen relatively quicklyConversations would dovetail discussions in the CentOS side of the booth and vice-versa. This synergy brought in various guests and their associates for various reasons, encouraging the community aspect.

Keynote 1: Mark Russinovich

TakeawayRelevance to Our Work
Learned that there are Sysinternals tools available for LinuxThese tools which are handy on the Windows side could potentially be useful on the Linux side for Red Hat and Fedora usage.
Discussed the growing risk of LLMBrought attention to Anthropic article and encouraged review of code base for 0-days.

Keynote 2: Doug Comer

TakeawayRelevance to Our Work
Realization that code was sometime transferred on small or large reelsAppreciation for mass storage media and streamlined Internet delivery
Open source movement fought for eliminating charging of data transfer from site to siteThe world might be vastly different if charged for each data transfer
Programmers had to punch their own punchcardsDispel myth that someone else punched programmer card

Feedback Items for SCALE 23x

Throughout the expo, our booth had a sign-in sheet where visitors could optionally leave feedback about Fedora and related efforts.

From the data reviewed, we collected key findings:

Interesting Topics

Releases

Most Recent Version of Fedora UsedCurrent Version (At the Time of this Blog’s Publication)How many?
43434
41431
44 beta435
RHEL9 + Fed 45 (?)RHEL10, 431

  • One guest was still down revision two versions at release 41 (at the time of this writing, 43 is current).
  • We have at least 5 guests running 44 beta.
  • One guest mentioned they were apparently running Fedora 45 (?).

Kudos

  • Asahi is great!”
  • “Love the battery (scribble) from last year!”
  • Zephyrus laptops great with Fedora!”
  • Fedora (scribble) is amazing! Love (scribble)!”
  • “Go EPEL!”
  • Respondent switched from a distro that rhymes with avenue to Fedora and says it works great.
  • “Liked the booth!”

Concerns

Swag

  • “Where are the podman stickers?”
  • “Social stuff and coloring books for kids please!” “Coloring books would be great to have again!”
  • We had some guests request shirts. It might be nice if we had a few to raffle off for next year’s event.
    • “How about shirts!” x 5
  • Requests for Fedora case badges, metakey cap stickers (both standard and mini), hats, and bandannas

Missing Red Hat in Expo Room

  • Where’s the Red Hat booth?
    • [editor’s note: Red Hat booth was not in the main expo hall, but in a completely different area this year…]
  • Where’s the Red Hat swag?
    • [editor’s note: reports suggest Red Hat swag was finished around the end of day 1 or day 2!]
  • RHEL FTW! 😊
  • “More RHEL! Good, other than that…”

Final Thoughts

  • Fedora is alive and well!
    • From start to finish, Fedora booth visitation highly visited
    • Fedora Hatch Day sessions were well attended. Most of the morning sessions appeared full or near full. Definitely must have for SCALE 24x.
  • Standing banners could be revised to include an easy to get to website and clear QR code
  • Fedora Account creation and badge claiming could be an easier process. It takes about 15-20 minutes just to set one up. Could this process be reviewed and possibly streamlined?
  • Do users running Fedora 2 revs below current get regularly reminded to update to prevent adverse security issues?

We had a fantastic turnout of about 3,000 Linux guests and a stellar Fedora Hatch Day.

A huge thank you to:

  • All Speakers: For sharing your expertise and time with the community.
  • All Volunteers: This event wouldn’t have been possible without the folks who managed the booths, and logistics.
  • All Sponsors: Thank you to Fedora and Red Hat, LLC.
  • Our Community: Thank you to everyone who attended and asked great questions.

See you at the next one!

The post Fedora and CentOS @ SCALE 23x 2026 appeared first on Fedora Community Blog.

How to triage security reports

Posted by Ben Cotton on 2026-05-20 12:32:24 UTC

In chapter 10 of Program Management for Open Source Projects, I talk about triaging bug reports. One of the questions in that process is “is it a security bug?” That’s good for helping you sort the security reports from the non-security reports, but what do you do when the answer is “yes”?

The crushing weight of security reports

In the first third of this year, we’ve seen a remarkable increase in security reports, particularly against popular open source projects. This isn’t (just) AI slop, it’s also AI quality. Daniel Stenberg says we’re in a “high-quality chaos era.” GitHub is tightening the rules on its bug bounty program because the staff can’t keep up.

Despite the hype about Claude Mythos Preview, I’m not particularly worried about the severity of security reports; I’m worried about the volume. There’s slop coming, yes, but also a lot of medium-to-high quality reports. And maintainers are going to have to deal with them.

How to triage security reports

The vast majority of open source projects are too small to provide the sort of reputational boost that finding a vulnerability in, say, the Linux kernel would provide. But even if you’re not get deluged with security reports (and even if you may never be), it’s good to start planning now.

Create a security policy

A good first step is to create a security policy and store it in a place like SECURITY.md in your repo. This doesn’t have to be long and complex. Even a few sentences is better than nothing.

At a minimum, tell people how to submit security reports. Do you want them sent through some private mechanism for coordinated disclosure? Do you want to take libxml2’s approach and treat them like any other bug report? If you are doing the private reporting mechanism, what should the reporter expect next? Do you have a response timeline? A default coordinated disclosure timeline? Do you offer a bug bounty program? These can all be “no”, of course. The goal here is not to place unwanted obligations on you as a maintainer; the goal is to set expectations in advance.

You may also want to add things that come up in the following section to your security policy as well.

And of course, the security policy is not just for reporters — it’s also for users. You may include information about what releases get security fixes and how those are handled. When do you bundle certain security fixes into a planned release and when do you do a special release? Do you even say which releases are “security releases”?

The Eclipse CSI project has a good example policy.

Questions to ask

As you triage the reports you get, you should ask yourself some questions. There’s no scoring system here (although you could try to devise one if that makes you happy). Instead, this is about rejecting bad reports and moving a particular good report up and down the stack. If you only have one report to deal with at a time, you don’t need to worry about prioritizing against other vulnerabilities, only against your regular work.

Quick-reject questions

  • Is this in your software? If it’s a security issue in one of your dependencies, the reporter should file it upstream. (If you can mitigate it in your software, you still should). If it’s a security issue in a downstream user of your software, the reporter should file it there. Unless there’s something you can do directly about it, close the report.
  • Is this legitimately a vulnerability or is it just a dangerous tool? If I filed a security issue that said “when I run rm --no-preserve-root / it deletes my data and makes the system unbootable”, I’d be rightfully banned from the project. Of course it can do that because rm is for deleting files. Reports like that can be closed immediately. On the other hand, if passing a specific, carefully crafted file name to rm as an unprivileged user resulted in me getting privileged access, that’s a legitimate vulnerability.
  • Is this documented behavior? Similar to the above, if the report is about something that you document to be risky or unsuited for production use, then you can close the report. Many static website builders, for example, have a command to run a local webserver for testing. These almost never have any real security because they’re not intended to.
  • Does the reporter seem to understand what they’re talking about? You’ll probably have follow-up questions. Does the reporter answer them like they know what’s going on or are they just copy/pasting out of their LLM. If there’s no human judgment happening here, you can reject it (and may consider banning future reports from that user).
  • Does the alleged vulnerability cause harm? Can an attacker actually exploit this? If there’s no obvious harm that comes from it, it’s just a bug.

Prioritization questions

  • Does the report include key metadata like version, OS, hardware, etc? This is a good candidate for “stuff to include in the security policy.” If the report is for an unsupported setup (especially an unsupported version), then you may choose to reject it. If the reporter didn’t provide the information, you can wait until until they do.
  • Does the report include a proof of concept? If the alleged vulnerability is highly theoretical, that doesn’t mean it’s not real, but you will probably move it lower in the pile. If the report includes specific steps or code that shows the vulnerability in action, move the report up. Apart from showing that it’s a real thing that an attacker could exploit, having a proof of concept enables you to test if your fix is correct.
  • Can the vulnerability be triggered remotely? If a vulnerability can only be performed by someone who already has access to the system, you can move it down the pile. If anyone passing by on the Internet can trigger it, then it moves up the pile.
  • Does the vulnerability require privileged access? Similarly, vulnerabilities that require privileged access have a smaller set of possible attack vectors and might move down the list a bit.
  • Does the vulnerability require specific user action? Anything that self-propagates or is exploited through automated means (like receiving a specially crafted text message or opening a file) should move way up the list.
  • Is the vulnerability in the default configuration of the software? Most people will use the defaults you provide. If a vulnerability only exists when one strays from the defaults, you can move that priority down the list.
  • What’s the harm? If a vulnerability causes an application to crash, that can be inconvenient, and maybe even costly to a business. If a vulnerability causes data loss or corruption, that’s worse.

Your obligations

Good news: you have no obligations other than what you choose to put on yourself! Your project is provided “as-is” after all, and no matter who thinks you should do things a certain way, you don’t have to do anything you don’t want to do. That said, having a clear security policy is part of being a good member of the ecosystem. Fixing security issues as quickly as your time permits is also good — you’d want the same from the maintainers of software you use.

I hope this post helps you manage incoming security reports. If there’s something you’d add, let me know! The Open Source Security Foundation has a ton of tools, training, guides, and other resources to help you survive the security tidal wave.

This post’s featured photo by FlyD on Unsplash.

The post How to triage security reports appeared first on Duck Alignment Academy.