fidzu : Fedora

20 Aug 2026 8:00pm GMT

12 Aug 2026 7:30am GMT

11 Aug 2026 2:00pm GMT

Across various Fedora groups, a major shared focus this week was preparing for the upcoming Fedora 45 release cycle, which included executing mass rebuilds, coordinating early manual validation testing, and finalizing change proposals ahead of the imminent branching deadline. Infrastructure transitions were another critical common item, particularly the project-wide effort to gather requirements for replacing Red Hat Bugzilla and the successful migration of source control requests from Pagure to Fedora Forge, which requires maintainers to update their fedpkg toolchains. Hardware architecture improvements were also prominent, with multiple groups dedicating resources to testing and expanding build capacities for ARM and RISC-V devices. On the community front, organizing teams focused heavily on preparations for the FrOSCon 2026 event, while several other groups-including Packaging and Diversity & Inclusion-chose to pause regular meetings or shift to ad-hoc structures to prevent organizer burnout. Finally, navigating the rise of Artificial Intelligence emerged as a cross-cutting theme, prompting discussions around user privacy, default opt-in policies for third-party packages, and strategies for local AI development.

Announcements

Major workflow transitions are underway for Fedora contributors, starting with the planned decommissioning of Red Hat Bugzilla within the next six months. FESCo has opened a ticket tracker for planning and gathering requirements for a future Red Hat BugZilla replacement to document workflows impacted by this shift. Additionally, the fedora-scm-requests queue has officially migrated from Pagure to Fedora Forge following its scheduled start on August 5th. Maintainers must update to the new fedpkg version 1.48 to continue submitting new package and branch requests, as the old Pagure system is now obsolete. In other maintenance news, a final reminder was issued listing long-term FTBFS (Fails to Build From Source) packages slated for retirement from Fedora 45, urging maintainers to fix or seek exemptions for affected software. Finally, the Fedora RISC-V community is seeking testers for an updated Fedora 44 server image that features out-of-the-box support for SpacemiT K3 boards and improvements for K1 hardware.

For the broader Linux community, new guides are available detailing how to run Ollama locally with Podman on Fedora Linux for containerized, private AI development, and how to monitor your drive health with Performance Co-Pilot to prevent sudden data loss from failing NVMe or SSD drives. Lastly, a recent attendee shared a positive retrospective on developing with Fedora and their first Flock conference, highlighting the community's welcoming culture and the behind-the-scenes efforts of volunteers and sponsors.

Council

Between August 3 and 9, 2026, the Council discussed a new user concern regarding the introduction of AI-powered features in third-party packages, highlighting the need for packaging guidelines around user privacy and opt-in defaults. The Council also continued reviewing the proposed Fedora Forge Usage Policy, incorporating community feedback into a new draft. Additionally, a temporary "private issues" workaround was proposed for Fedora Forge while native support is being developed upstream, sparking discussions on how the Council and other sensitive groups will handle private tracking.

Decisions

• No formal Council decisions were finalized during this period.
• The Fedora package maintainer for Atuin decided to disable its new AI and hex features by default due to dependency creep and privacy concerns, pending a more robust opt-in or sub-packaging strategy.

See the detailed report for the Council team.

Learn more about the Council team.

FESCo

This week, FESCo focused heavily on reviewing and voting on F45 and F46 Change Proposals, handling administrative tickets, and addressing updates policy exceptions. Several major Change Proposals were formally approved for Fedora 45, including the modernization of the ODBC Stack, enabling systemd-oomd and zram swap for CoreOS, and transitioning to Sequoia for openpgpverify. Conversely, the committee rejected the proposal to hardcode nss-altfiles in authselect profiles, encouraging further collaboration among affected initiatives like CoreOS and atomic bootc.

In addition to changes, FESCo initiated a project-wide requirements gathering phase for Fedora's eventual Bugzilla replacement. They also approved an urgent updates policy exception for thermald to resolve power management issues on newer Intel laptops, and handled several non-responsive maintainer tickets to ensure long-term package health.

Decisions

• Accepted multiple F45 Changes: ODBC Stack Modernization, LibreOffice Dictionaries, Native Butane Config Support in Ignition, LibreOffice html help, Authselect Remove NIS Profile, Enable systemd-oomd and zram swap for CoreOS, and Sequoia openpgpverify.
• Rejected the F45 Change: Authselect: Hardcode nss-altfiles in profiles, requesting further collaboration among atomic, bootc, and coreos teams to find a viable solution.
• Approved an urgent updates policy exception for thermald across all Fedora branches to fix Intel power management issues.
• Approved a Soname Change Policy Exception Request for Qt-Advanced-Docking-System.
• Approved non-responsive maintainer actions for benzea, granting ngompa co-maintainer admin rights for thermald, libfprint, fprintd, and fwts.
• Agreed to launch a project-wide requirements gathering tracker to collect user stories and identify a suitable Bugzilla replacement.
• Updated the release schedule for F46 onwards to move the Major Toolchain Updates/Changes deadline to a week before the mass rebuild.

See the detailed report for the FESCo team.

Learn more about the FESCo team.

Packaging Committee

The Packaging Committee held a brief meeting this week. The agenda was notably light, with no new tickets submitted for review. The only active item mentioned was a work-in-progress pull request for Node.js. Due to upcoming vacations for key members, the committee agreed to suspend meetings for the rest of August.

Decisions

• The committee will skip its next scheduled meeting in two weeks due to member vacations, postponing the next gathering until the first week of September.

See the detailed report for the Packaging Committee team.

Learn more about the Packaging Committee team.

Mindshare

Mindshare held a brief meeting this week but concluded early due to a lack of quorum. Despite the early adjournment, organizers noted ongoing progress on various tickets and highlighted upcoming events, specifically FrOSCon and Data Con LA.

Additionally, community members are actively organizing the Fedora presence for FrOSCon 2026. The project booth is confirmed and swag items are being gathered, alongside an open call for volunteers to assist at the booth and share their work with attendees.

See the detailed report for the Mindshare team.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group focused entirely on final preparations for the Fedora booth at FrOSCon 2026, which takes place August 15-16 near Bonn, Germany. The team has successfully secured a booth space, promotional materials, and a new tablecloth, and they are actively seeking volunteers and project showcases from the community to help run the event.

See the detailed report for the Ambassadors team.

Learn more about the Ambassadors team.

Diversity & Inclusion

The Diversity & Inclusion group is putting its regular team meetings on hiatus to prevent organizer burnout and shift focus toward concrete, event-driven goals. Discussion in the "Time to take a break?" thread confirmed that regular meetings have become stagnant without specific deliverables, and organizers will now lean into forming ad-hoc teams for events like the Fedora Mentor Summit, Fedora Week of Diversity, and Fedora Appreciation Week.

Calendar entries for the regular DEI meetings are being removed, but this will not halt ongoing initiatives. Future activities will be organized through dedicated calls for volunteers and planned in their respective event repositories.

Decisions

• Regular DEI Team meetings are officially placed on hiatus, and corresponding Fedora and Google Calendar entries are being deleted.
• Future DEI efforts will shift to an ad-hoc, event-specific model focusing on time-boxed initiatives rather than standing meetings.

See the detailed report for the Diversity & Inclusion team.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

The Workstation Working Group discussed upcoming upstream GNOME changes, including plans for GNOME 52+ to replace GNOME Software with a Flatpak-focused installer called "Bazaar" and a new system updater, though Fedora will stick with GNOME Software for the time being. The group also evaluated newly integrated features like the IBus speech-to-text functionality, noting performance delays and missing default models, and reviewed the transition of GNOME Boxes to a Flatpak-only application which currently requires further polish on fractionally scaled screens.

On the forum side, community members engaged in a technical discussion regarding Btrfs RAID1 and nodatacow files (such as Libvirt virtual machine images), proposing theoretical file system mechanisms to ensure data recoverability during bit rot without full metadata checksumming.

Decisions

• Fedora will continue using GNOME Software for the time being, despite upstream GNOME's long-term plans (GNOME 52+) to replace it with a new installer called Bazaar.
• The memory retention issue in IBus speech-to-text, where the model remains loaded after the input method is removed, will be officially treated and tracked as a bug.

See the detailed report for the Workstation / GNOME team.

Learn more about the Workstation / GNOME team.

KDE

The KDE group discussions this week focused on a user-reported issue regarding computer freezes under Plasma (Wayland) after upgrading to Fedora 44. The system becomes unresponsive during screen lock, with the nvidia-modeset/kthread_q process consuming 100% of the CPU, requiring a sysreq reboot to resolve.

See the detailed report for the KDE team.

Learn more about the KDE team.

Server

This week, the Server Working Group officially reached quorum with the addition of new members and made progress on release testing and automation infrastructure. Discussions centered heavily on upcoming Fedora 45 changes, identifying bugs in VM and ARM partition types, and reviewing default packages to prevent unnecessary bloat in server environments.

The group also advanced its Ansible support project by merging initial post-installation modules and beginning work on a CI pipeline using self-hosted Forge runners. Furthermore, the WG continued refining its documentation structure, debating the best ways to present post-installation configuration tasks to users.

Decisions

• The Working Group decided to contact the upstream Cockpit team to request the removal of unnecessary dependencies, such as SPICE, from the Cockpit VM module to prevent unwanted package bloat on standard server installations.
• The Server Working Group's Ansible repository will be formally structured around small, tightly focused roles that are assembled into larger playbooks, avoiding monolithic scripts.

See the detailed report for the Server team.

Learn more about the Server team.

Infrastructure

The Infrastructure team was highly active this week, handling multiple system migrations, upgrades, and investigating service anomalies. Key efforts included advancing the RHEL 10 migrations for miscellaneous hosts, rolling out OpenID Connect enrollment for the Release Schedule Planner, and addressing intermittent authentication issues following the recent IPA cluster reinstall. The team also announced an upcoming scheduled outage for the Copr servers and discussed transitioning Matrix moderation duties to official Fedora infrastructure, including a formalized policy for official Matrix rooms.

Additionally, developers introduced substantial updates to Tahrir, the Tahrir API, and Forgejo, improving performance and enabling new features like private issue tracking in the forge environment. Investigations were also launched into src.fedoraproject.org 503 errors caused by heavy scraper activity and Fedora mailing list emails being falsely flagged as spam by the SpamHaus blocklist.

Decisions

• Migrate the Matrix moderation bot hosting to official Fedora infrastructure (@moderation:fedoraproject.org).
• Implement a new policy for official Fedora Matrix rooms, requiring the moderation bot to be present, a :fedoraproject.org room alias, and appropriate sub-space assignment.
• Block the creation of a Bugzilla component and FAS group for Security Bugs until FESCo formally approves the proposed security policy changes.
• Create new Fedora Account System (FAS) tracking groups for Copr projects: netfyr and sosreport.

See the detailed report for the Infrastructure team.

Learn more about the Infrastructure team.

Release Engineering

This week, the Release Engineering team focused heavily on infrastructure migrations and preparations for the Fedora 45 release cycle. A major milestone was the successful migration of the scm-requests repository from Pagure to Forgejo on August 5th, which necessitates that community members update their fedpkg utilities to version 1.48 or greater. The team also began extensive preparations for the F45 mass branching scheduled for August 11th, which included executing the mass re-signing of F45 content with the new F46 key.

In addition to release cycle preparations, the group handled various system and package fixes. They deployed a fix to prevent releng-bot from pinging unrelated users during SCM requests, resolved an issue where ELN packages were signed with the wrong key, and bypassed a Bodhi sidetag limitation affecting shadow-utils. Multiple package unretirement and stalled maintenance requests were processed, and the team highlighted that unretirements can now be executed directly via the updated fedpkg CLI without requiring a ticket.

Decisions

• The fedora-scm-requests repository was officially migrated from Pagure to Forgejo; maintainers must update to fedpkg v1.48 or greater to submit new package and branch requests.
• Package unretirements no longer require a Release Engineering ticket; maintainers should now use the newly introduced fedpkg request-unretirement command.
• Created a dedicated forge-releng-scm-validators group to handle SCM request approvals, preventing releng-bot from unnecessarily pinging unrelated community members.
• Created the quay.io/fedora/eln-bootc repository to enable the uploading of ELN bootc images from composes.

See the detailed report for the Release Engineering team.

Learn more about the Release Engineering team.

Quality

The Quality team focused heavily on early manual validation for Fedora 45 this week, placing a special emphasis on ARM devices to catch significant bugs before the branch and freeze periods. The team is also actively organizing the next round of Fedora Test Days and collaborating with the Data team to identify interesting QA and build metrics-such as Bodhi karma and Koji completion rates-for future data visualizations.

In addition to testing, the group discussed hardware monitoring defaults, noting that the mcelog daemon consistently fails on modern AMD CPUs. They are currently gathering community feedback on potentially replacing it with rasdaemon. Tooling improvements were also a major theme, with updates to fedora-easy-karma, a revived issuebot in staging, and discussions around deploying a shared test asset server for openQA and Fedora CI.

Decisions

• Begin early manual validation testing for Fedora 45 prior to branching and freezes, with a particular focus on ARM hardware.
• Initiate a broader community discussion regarding replacing the mcelog daemon with rasdaemon by default due to hardware incompatibility on modern CPUs.
• Add the currently proposed Test Day events to the Fedora Test Days calendar to prevent concurrent scheduling overlaps.
• Explore the integration of actual user-runnable regression test suites (e.g., Vulkan/GL conformance, kernel test suites) into upcoming Test Days.

See the detailed report for the Quality team.

Learn more about the Quality team.

Design

The Design team concluded the community poll for the Fedora 46 wallpaper inspiration, selecting American mathematician Karen Uhlenbeck as the winner. Following the poll, the team is organizing a mind map meeting to brainstorm the wallpaper's conceptual design. In other activities, community members shared a proposed wallpaper on the mailing list, and drafts for revamped Design Documentation pages were posted for review.

Decisions

• The Fedora 46 wallpaper design will be inspired by American mathematician Karen Uhlenbeck.

See the detailed report for the Design team.

Learn more about the Design team.

Internationalization

The Internationalization (i18n) group held a meeting this week to review the progress of Fedora 45 changes and coordinate upcoming release deadlines. Key discussions involved tracking the completion of F45 changes, ongoing bug triaging efforts for Fedora 43, and scheduling the upcoming internationalization test week.

Decisions

• The Fedora 45 i18n test week is scheduled to take place from September 7th to September 13th, 2026.

See the detailed report for the Internationalization team.

Learn more about the Internationalization team.

EPEL

This week, the EPEL group focused significantly on improving the repository structure and mirror paths for EPEL 11 to avoid user errors during mirroring and upgrades. The steering committee successfully voted to adopt a new "de-z-ification" policy for EPEL 11, which will rely on the $stream variable for CentOS Stream users rather than adding a 'z' suffix for RHEL minor versions. Additionally, the community discussed potential breaking updates to packages like certbot, uv, and ruff in EPEL 10, and highlighted a new way to track RHEL lifecycle milestones via the Red Hat Insights roadmap.

Decisions

• Approved the EPEL 11 portion of the "de-z-ification" policy, which will restructure repository names, redirects, and symlinks to utilize the $stream variable for CentOS Stream rather than the $releasever_minor 'z' suffix for RHEL systems.
• Agreed that the official branch naming for the CentOS Stream variant in EPEL 11 will be 11s.

See the detailed report for the EPEL team.

Learn more about the EPEL team.

ELN

The ELN SIG met this week to discuss significant updates to their build pipeline and image generation processes. Key highlights include the production deployment of ELNBuildSync 2.0.1, the inclusion of bootc images in standard composes, and the successful migration of all major cloud images (EC2, Azure, GCE, qcow2) to image-builder.

Additionally, the group discussed restructuring ELN variants, introducing a new AltImages variant for live images and a new Extensions variant to decouple RHEL Extensions from EPEL. Plans were also outlined to completely split ELN Extras into its own target to cleanly bootstrap EPEL N+1 and preview CentOS SIGs, with a call for community feedback on the design.

Decisions

• Re-tool ELN Extras to build in a completely separate target and compose to properly isolate EPEL macros and facilitate CentOS SIG previews.
• Separate RHEL Extensions content into a distinct Extensions variant rather than an EPEL allowlist due to a lack of overlap.
• Migrate WSL image builds to image-builder following the successful migration of hyperscaler cloud images.
• Merge GitLab MR 86 to minimize dependencies in go-vendor-tools and cut a new release.

See the detailed report for the ELN team.

Learn more about the ELN team.

Atomic

The Fedora Atomic Initiative met this week to discuss infrastructure updates and package releases. Progress was made on configuring Konflux service accounts for the Fedora Forge, with a new merge request proposed to unblock testing. Additionally, a recent policy change for the bootc package means that Bodhi updates now only require a +1 score to proceed, which should clear up the backlog of aging updates. In release news, bootc 1.16.6 has reached the stable repository, and work is underway for the 1.16.7 release.

Decisions

• Bodhi updates for the bootc package now only require a +1 score to proceed, which will prevent updates from sitting in the backlog until they become obsolete.

See the detailed report for the Atomic team.

Learn more about the Atomic team.

CoreOS

CoreOS held a meeting on August 5 to review ongoing action items and prepare for the upcoming Fedora 45 branching. Key discussions included ongoing tests for the /boot partition size to prevent data corruption during re-provisioning, preparations for the Fedora 45 Test Day, and the integration of approved FESCo changes into Rawhide. Additionally, the team discussed the pending archival of the Butane repository into Ignition.

Decisions

• Contributors with pending pull requests to the Butane repository should hold off or expect delays, as the repository is being archived and its codebase is being merged into the Ignition repository following the approval of FESCo ticket #3650.

See the detailed report for the CoreOS team.

Learn more about the CoreOS team.

AI & ML

This week, the AI & ML group focused on administrative tasks, specifically processing a membership update. A contributor requested to be removed from the group and related access lists due to time constraints and the challenges associated with packaging complex upstream AI projects. The request was completed, and the contributor was successfully removed from the relevant groups.

Decisions

• Approved and processed the removal of contributor salimma from the AI/ML and PyTorch Special Interest Groups (SIGs).

See the detailed report for the AI & ML team.

Learn more about the AI & ML team.

RISC-V

The RISC-V group focused primarily on the ongoing Fedora 45 mass rebuilds, successfully resolving a major Python 3.15 Beta 4 ABI breakage and completing the bootstraps for Perl 5.44 and Rust. Rebuilds for OCaml have started, with Golang and R queued up next.

Significant hardware additions were made to the build pool, including five Milk-V Titan (DP1000) machines and four SpacemiT K3 systems, to improve build capacity. The team also addressed hardware instability challenges with SpacemiT K1/K3 SoCs linked to vector instructions and OpenSBI issues, and discussed a gnulib/glibc conflict that required a workaround.

Decisions

• Implemented a workaround in Fedora to address a gnulib/glibc compatibility bug (Sourceware BZ 34437 / Fedora BZ 2502638) that was causing build failures.
• Expanded the RISC-V build pool by officially integrating five Milk-V Titan machines and four SpacemiT K3 systems.

See the detailed report for the RISC-V team.

Learn more about the RISC-V team.

Security

This week, the Security group discussed recognizing vulnerability reporters with a dedicated Fedora badge and evaluating compliance with the linux-distros mailing list rules. In the forums, a community review of the new Fedora-maintained hardening documentation led to minor improvements, while the OpenScanHub team published their latest static analyzer findings for Fedora 45 critical path packages.

Decisions

• Approved moving forward with a Vulnerability Reporting Badge to reward individuals who report security flaws.
• Decided to consult Fedora Legal to determine if the existing Fedora Project Contributor Agreement (FPCA) satisfies linux-distros rules, or if a separate Fedora Pre-Disclosure-Agreement (FPDA) is needed.

See the detailed report for the Security team.

Learn more about the Security team.

DotNET

The DotNET group confirmed the final steps for the end-of-life (EOL) transition for .NET 8 and .NET 9. Omair Majid announced that the dotnet8.0 and dotnet9.0 packages will be dropped from Rawhide shortly, timed to occur just before the Fedora 45 branch day on August 11, 2026.

While they are being removed from Rawhide, both versions will remain available and continue to receive updates in existing Fedora versions (up to Fedora 44) until their official EOL in November 2026. Michael Cronenworth acknowledged the change, noting that Jellyfin 12 is currently on the horizon with release candidates available.

Decisions

• The dotnet8.0 and dotnet9.0 packages will be dropped from Rawhide ahead of the Fedora 45 branch day.

See the detailed report for the DotNET team.

Learn more about the DotNET team.

Perl

This week, the Perl group focused heavily on routine package maintenance, consisting of upstream version bumps and importing packages into EPEL branches. Key updates included merging newer releases for packages like perl-ExtUtils-CppGuess, perl-PDF-Reuse, perl-HTTP-Cookies, perl-Crypt-SMIME, and perlbrew. Additionally, successful efforts were made to integrate perl-Protocol-WebSocket into EPEL8 and EPEL9, alongside establishing the first EPEL10 build for perl-SQL-Abstract.

Decisions

• Merged version bumps for perl-ExtUtils-CppGuess (0.271), perl-PDF-Reuse (0.44), perl-HTTP-Cookies (0.12), perl-Crypt-SMIME (0.34), and perlbrew (1.02) to keep packages aligned with upstream releases.
• Approved and merged EPEL package imports for perl-Protocol-WebSocket (EPEL8 and EPEL9) and perl-SQL-Abstract (EPEL10) to expand package availability for Enterprise Linux distributions.

See the detailed report for the Perl team.

Learn more about the Perl team.

Ruby

Vít Ondruch announced that following the recent landing of Ruby on Rails 8.1 in Fedora, an update for version 8.1.3.1 was also released this week. The community is encouraged to test these new releases and report any issues they might encounter.

Decisions

• Pushed the Ruby on Rails 8.1.3.1 update to Fedora.

See the detailed report for the Ruby team.

Learn more about the Ruby team.

Other Discussions

This week in the Fedora community, discussions focused on transitioning away from Red Hat BugZilla, establishing style guides for mailing lists, and managing the email volume on the devel list. Additionally, there were multiple package soname bumps, discussions about orphaning outdated packages, and warm welcomes to several new package maintainers.

Contribution opportunities

Contributors with testing and quality assurance skills can easily jump into numerous highly accessible opportunities. The community is invited to test the Packager Dashboard staging environment and report bugs on its issue tracker. Testers are also needed for Fedora 45 manual validation (especially on ARM), F45 Server bare-metal/VM images, fedpkg v1.48+ features, Flatpak-only GNOME Boxes on fractionally scaled displays, newly landed Ruby on Rails 8.1, dotnet10.0, and Atomic's bootc 1.16.6. Hardware owners can evaluate /boot partition scenarios (notes), test Omni F44 images on SpacemiT K1/K3 or Milk-V Titan, and assist with testing LLVM pull request 629. Additional opportunities include Fedora 43 i18n bug triaging and contributing to Test Day planning.

For those with strong communication, writing, or organizational skills, community feedback is actively sought on the Fedora Forge Usage Policy, the AI-powered features policy, and hardware monitoring defaults (mcelog vs. rasdaemon). Contributors can submit user stories to the FESCo Bugzilla replacement tracker, restructure Server post-installation guides, or review Design Processes documentation. Event enthusiasts can volunteer for the FrOSCon 2026 booth, give talks, create A4 teaser pages for project showcases, or join organizing efforts for Fedora Week of Diversity, Appreciation Week, and the Mentor Summit.

Developers, designers, and system architects can tackle highly specific technical challenges across the project. Programmers can debug memory leaks in GNOME's new IBus speech-to-text, troubleshoot KDE Plasma Wayland screen lock freezes with NVIDIA drivers, and investigate OpenSBI bugs on RISC-V K1/K3 SoCs. System architects are invited to help design the ELN and ELN Extras separation (Issue #61 and Issue #62). Designers can streamline GNOME's action dialog buttons, design the Vulnerability Reporting Badge, or join #design:fedoraproject.org for the Fedora 46 wallpaper brainstorm. Data enthusiasts can also suggest QA-related data visualizations.

Contributors experienced in package maintenance and systems administration can make an immediate impact by adopting orphaned or non-responsive packages such as nextcloud-client, rust-zoxide, cinnamon-screensaver, and python-pivy, or by helping the AI & ML group package PyTorch. Packagers are also needed to resolve Failing to Install (FTI) EPEL packages, test EPEL 10 uv and ruff updates, minimize go-vendor-tools dependencies, and apply OpenScanHub security patches. Systems administrators can write Server Ansible roles, configure self-hosted Forge runners, and help implement RPM macro and Lua support for the Fedora 45 PURL proposal.

10 Aug 2026 11:03am GMT

You wake up one morning to find your home server unresponsive, after some investigation you discover a failed NVMe drive taking your self-hosted services and data with it. Perhaps you're a system administrator and a workstation's SSD has been silently accumulating errors for months, and now a user is reporting corrupted files.

Drive failures are rarely instant, they give subtle warnings (through rising temperatures, increasing error counts, and wear indicators) but only if you're watching. Most people will only check on disk health after problems start, by then it may be too late.

Performance Co-Pilot (PCP) is an open source framework for collecting, monitoring, and analyzing system performance metrics. Recent updates have expanded its drive monitoring capabilities with:

• SMART metric collection for HDDs, SSDs, and NVMe drives
• NVMe error log decoding with human-readable error messages
• WWID-based drive tracking that survives device name changes across reboots
• Seagate FARM telemetry for extended vendor-specific diagnostics

In this post, you'll set up PCP drive monitoring on Fedora, learn which metrics matter most, and build a Grafana dashboard to visualize your drive health over time.

Prerequisites

To follow along, you'll need:

• Fedora Workstation or Server (Fedora 39 or later recommended)
• Root or sudo access for installing packages and PMDAs
• smartmontools installed (PCP's SMART agent depends on smartctl)

You can verify smartmontools is available:

$ rpm -q smartmontools

If it's not installed:

$ sudo dnf install smartmontools

What is SMART?

SMART (Self-Monitoring, Analysis and Reporting Technology) is a monitoring system built into modern hard drives, SSDs and NVMe devices. SMART continuously tracks indicators like wear leveling, error rates, temperature and power-on hours. These are reliability metrics that can help point towards impending failures.

Most people only check SMART data once, using tools like smartmontools (smartctl -a /dev/sda) and only when they already suspect a problem. That approach only gives you a single snapshot. PCP takes a different approach: its SMART agent collects these metrics continuously in the background, building historical trends that you can analyze.

Did your drive's temperature spike yesterday during a large file transfer? Has your NVMe wear indicator increased from 5% to 15% over the past six months? Continuous monitoring catches these patterns. Drive failures rarely happen without warning, clues are given through SMART values that shift over time.

Installing and enabling PCP with the SMART PMDA

Getting started is straightforward. Install the required packages:

$ sudo dnf install pcp pcp-pmda-smart

The pcp-pmda-smart package provides the SMART monitoring agent. Next, install the PMDA (Performance Metrics Domain Agent):

$ cd /var/lib/pcp/pmdas/smart/
$ sudo ./Install

The installer will prompt for configuration options. The defaults work well for most setups, so press Enter to accept them.

Start and optionally enable the PCP collector daemon:

$ sudo systemctl start pmcd
$ sudo systemctl enable pmcd

Verify the SMART metrics are available:


If you see metrics listed, you're ready to go.

Querying SMART metrics

Now that monitoring is running, let's look at the metrics that matter most.

Temperature

Drive temperature is one of the easiest health indicators to track. Query it with:

$ pminfo -ft smart.attributes.temperature_celsius.value

For NVMe drives, use:

$ pminfo -ft smart.nvme_attributes.temperature_sensor_one

As a general guideline: sustained temperatures above 60 °C for HDDs or 70 °C for SSDs and NVMe drives indicate potential cooling problems. Consistent high temperatures accelerate wear and reduce drive lifespan.

To watch temperatures update in real time (every 5 seconds):

$ pmrep -t 5s smart.nvme_attributes.temperature_sensor_one smart.attributes.temperature_celsius.value

Press Ctrl+C to stop.

Wear and age indicators

Every drive has a finite lifespan. These metrics help you track where a drive is in its lifecycle.

Power-on hours tracks total runtime:

$ pminfo -ft smart.attributes.power_on_hours.value
$ pminfo -ft smart.nvme_attributes.power_on_hours          # NVMe

A drive with 50,000 hours (roughly 5.7 years of continuous operation) is significantly older than one with 5,000 hours.

Power cycle count shows how many times the drive has been powered on and off:

$ pminfo -ft smart.attributes.power_cycle_count.value
$ pminfo -ft smart.nvme_attributes.power_cycles             # NVMe

Excessive power cycling can accelerate mechanical wear in HDDs and contribute to flash cell wear in SSDs.

For NVMe drives, smart.nvme_attributes.percentage_used is the most important wear metric. It runs from 0 to 100%, reflecting the drive's consumed endurance. Above 80% means significant wear. Above 90%, start planning a replacement.

$ pminfo -ft smart.nvme_attributes.percentage_used

Critical error metrics

These are the metrics you hope stay at zero. Any non-zero value or an increasing trend points to physical drive problems.

Reallocated sector count shows bad sectors that the drive has detected and remapped to spare areas. Modern drives reserve sectors for this purpose but once remapping starts it signals deteriorating media:

$ pminfo -ft smart.attributes.reallocated_sector_count.value

Current pending sector count tracks sectors waiting to be remapped. A non-zero value suggests the drive is actively struggling with bad areas:

$ pminfo -ft smart.attributes.current_pending_sector.value

For a quick overview of all drives at once:

$ pmrep -s 1 smart.health smart.attributes.temperature_celsius.value smart.nvme_attributes.temperature_sensor_one smart.nvme_attributes.percentage_used

WWID-based drive tracking

A common challenge with drive monitoring is that device names can change. Your NVMe drive might be /dev/nvme0n1 today but after a reboot or BIOS update it could become /dev/nvme1n1. Hot-plugging USB drives or adding new storage can also shuffle device assignments.

PCP solves this with the smart.wwid.* metric namespace. WWID (World Wide Identifier) is a unique identifier assigned to each drive during manufacturing. It never changes regardless of how the operating system names the device.

Here's the difference in practice:

The WWID-based namespace is particularly useful for multi-drive setups (home lab servers, workstations with external drives, or laptops with docking stations). Your monitoring history stays consistent even when device names don't.

NVMe error log collection

Beyond standard SMART attributes, NVMe drives maintain a detailed error log (log page 0x01) that records every error event the drive encounters. The SMART PMDA can collect and decode these logs giving you visibility into issues that basic SMART counters won't reveal.

While smart.nvme_attributes.media_and_data_integrity_errors gives you a count, the error log tells you what happened, when it happened, and where on the drive it occurred. Each log entry includes:

• Error type and status code
• Command that triggered the error
• Logical block address (LBA) of the failure
• Namespace and submission queue information
• Timestamp of the error event

This level of detail helps diagnose intermittent problems. Maybe your NVMe drive only throws errors under specific workloads or errors cluster in a particular address range.

Query the error log metrics:

$ pminfo -ft smart.nvme_error_log

The most important metric is smart.nvme_error_log.error_count which should be zero on a healthy drive. If you see non-zero values, check smart.nvme_error_log.status_code for human-readable error descriptions. Common error codes include:

• Data Transfer Error: Problem reading or writing data
• Internal Device Error: Controller or firmware issues
• Aborted Command: Command was cancelled or timed out
• Write Fault: Write operation failed

Recurring errors, especially with the same status code or affecting the same LBA range indicate a real problem that needs attention.

FARM log support for Seagate drives

If you have Seagate drives, PCP offers additional monitoring through the FARM (Field Accessible Reliability Metrics) PMDA. FARM is Seagate's extended monitoring that goes beyond standard SMART, providing deeper insights into drive behavior.

What FARM provides

FARM logs capture operational data that SMART doesn't track:

• Power metrics: Per-head write power hours, total power-on hours with finer granularity
• Error history: Read and write error rates broken down by head and zone
• Performance data: Command latency statistics, queue depth tracking
• Environmental history: Temperature trends over the drive's lifetime, humidity exposure
• Workload patterns: Sequential vs. random I/O ratios, read/write balance
• Head-specific statistics: Individual read/write head performance (for HDDs)

Setting up the FARM PMDA

FARM support works for both SATA and SAS Seagate drives. Install and enable it:

$ sudo dnf install pcp-pmda-farm
$ cd /var/lib/pcp/pmdas/farm/
$ sudo ./Install

Query available FARM metrics:

$ pminfo farm | head -10
farm.smart_attribute.power_on_hours
farm.environment.current_temperature
farm.reliability.uncorrectable_read_errors
farm.reliability.uncorrectable_write_errors
...

FARM is especially useful for tracking long-term health trends, diagnosing subtle issues not visible in basic SMART data and verifying that drive specifications match actual usage.

Note: FARM metrics are Seagate-specific. They won't work with Western Digital, Samsung, or other manufacturers. For universal monitoring use the SMART PMDA covered earlier.

Visualizing with Grafana

PCP integrates with Grafana through the grafana-pcp plugin, letting you build dashboards that visualize drive health over time. This is where continuous monitoring pays off. You can spot trends, set up alerts and keep an eye on your entire fleet of drives from a single dashboard.

Installing the Grafana PCP plugin

Install Grafana and the PCP plugin:

$ sudo dnf install grafana grafana-pcp

Start the required services:

$ sudo systemctl start grafana-server pmproxy
$ sudo systemctl enable grafana-server pmproxy

Open Grafana in your browser at http://localhost:3000 (default credentials: admin/admin).

Before adding a datasource, you may need to enable the Performance Co-Pilot plugin. Go to Administration > Plugins and data > Plugins, search for Performance Co-Pilot, and click Enable. If the plugin is already enabled, you can skip this step.

Configuring the PCP Vector datasource

Go to Connections > Data sources > Add data source and select PCP Vector. The only required field is the URL:

http://localhost:44322

Click Save & Test to verify the connection.

Building drive monitoring panels

Below are panel configurations you can use in your dashboards. To add a panel, click Add > Visualization on any dashboard, select the PCP Vector datasource and enter the metric name in the query field.

Drive temperature timeseries panel:

This panel shows drive temperature over time, with color thresholds for warning levels.

{
  "type": "timeseries",
  "title": "Drive Temperature",
  "datasource": {
    "type": "pcp-vector-datasource",
    "uid": "PCP_VECTOR"
  },
  "targets": [
    {
      "expr": "smart.nvme_attributes.temperature_sensor_one",
      "format": "time_series"
    },
    {
      "expr": "smart.attributes.temperature_celsius.value",
      "format": "time_series"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "°C",
      "thresholds": {
        "mode": "absolute",
        "steps": [
          { "color": "green", "value": null },
          { "color": "yellow", "value": 50 },
          { "color": "orange", "value": 60 },
          { "color": "red", "value": 70 }
        ]
      },
      "custom": {
        "thresholdsStyle": { "mode": "area" }
      }
    },
    "overrides": [
      {
        "matcher": { "id": "byType", "options": "number" },
        "properties": [
          { "id": "unit", "value": "°C" }
        ]
      }
    ]
  },
  "gridPos": { "h": 8, "w": 24, "x": 0, "y": 0 }
}

NVMe wear percentage gauge panel:

A gauge showing how much of each NVMe drive's endurance has been consumed.

{
  "type": "gauge",
  "title": "NVMe Wear Level",
  "datasource": {
    "type": "pcp-vector-datasource",
    "uid": "PCP_VECTOR"
  },
  "targets": [
    {
      "expr": "smart.nvme_attributes.percentage_used",
      "format": "time_series"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "percent",
      "min": 0,
      "max": 100,
      "thresholds": {
        "mode": "absolute",
        "steps": [
          { "color": "green", "value": null },
          { "color": "yellow", "value": 50 },
          { "color": "orange", "value": 80 },
          { "color": "red", "value": 90 }
        ]
      }
    },
    "overrides": [
      {
        "matcher": { "id": "byType", "options": "number" },
        "properties": [
          { "id": "unit", "value": "percent" }
        ]
      }
    ]
  },
  "gridPos": { "h": 6, "w": 8, "x": 0, "y": 8 }
}

Drive health status panel:

A stat panel showing the overall health assessment for each drive.

{
  "type": "stat",
  "title": "Drive Health Status",
  "datasource": {
    "type": "pcp-vector-datasource",
    "uid": "PCP_VECTOR"
  },
  "targets": [
    {
      "expr": "smart.health",
      "format": "time_series"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "string",
      "mappings": [
        {
          "type": "value",
          "options": {
            "PASSED": { "text": "PASSED", "color": "green" },
            "FAILED": { "text": "FAILED", "color": "red" }
          }
        }
      ]
    },
    "overrides": [
      {
        "matcher": { "id": "byType", "options": "string" },
        "properties": [
          { "id": "unit", "value": "string" }
        ]
      }
    ]
  },
  "gridPos": { "h": 6, "w": 8, "x": 8, "y": 8 }
}

A complete, importable Grafana dashboard JSON file is provided alongside this post as pcp-drive-monitoring-dashboard.json. Import it via Dashboards > Import in Grafana.

Automated alerting with pmie

PCP includes pmie (Performance Metrics Inference Engine), a rule-based tool that evaluates metric expressions and triggers actions when conditions are met. Where Grafana dashboards require someone to be watching pmie can alert you automatically.

To start and optionally enable pmie:

$ sudo systemctl start pmie
$sudo systemctl enable pmie

Exploring metrics with pmie

Before writing alerting rules you can use pmie in verbose mode to view metrics from the command line. This is a useful way to get familiar with the syntax:

$ echo 'temp_check = smart.nvme_attributes.temperature_sensor_one;' | pmie -e -v -t 5second
temp_check (Mon Jun 30 10:15:01 2026): 35

temp_check (Mon Jun 30 10:15:06 2026): 35

temp_check (Mon Jun 30 10:15:11 2026): 36

Press Ctrl+C to stop. The -e flag shows the evaluated expression, -v shows values even when no action fires, and -t sets the evaluation interval.

You can add conditions and actions to turn this into a rule. Here's an example that prints a message whenever an NVMe drive's temperature is above 0 (effectively showing all drives):

$ echo 'temp_check = some_inst(smart.nvme_attributes.temperature_sensor_one > 0) -> print "NVMe temp:" " %i:%v";' | pmie -e -v -t 5second
Mon Jun 30 10:15:01 2026: NVMe temp: nvme0n1:35
temp_check (Mon Jun 30 10:15:01 2026): true

Mon Jun 30 10:15:06 2026: NVMe temp: nvme0n1:36
temp_check (Mon Jun 30 10:15:06 2026): true

The %i token expands to the instance name (the drive) and %v to the metric value.

Writing alerting rules

Now let's create practical rules that alert on real problems. Save the following to /etc/pcp/pmie/smart-health.pmie:

// Alert if any NVMe drive temperature exceeds 70 °C
some_inst(smart.nvme_attributes.temperature_sensor_one > 70)
    -> syslog 10 min "NVMe drive temperature critical:" " %i at %v °C";

// Alert if any NVMe drive wear level exceeds 80%
some_inst(smart.nvme_attributes.percentage_used > 80)
    -> syslog 24 hour "NVMe drive wear level high:" " %i at %v%";

// Alert if any drive has reallocated sectors
some_inst(smart.attributes.reallocated_sector_count.value > 0)
    -> syslog 24 hour "Drive has reallocated sectors:" " %i with %v sectors";

The syslog action writes to the system log with the tag pcp-pmie. The time after syslog (e.g., 10 min, 24 hour) is a throttle that prevents repeated alerts, so you won't flood your logs if a condition stays true.

Testing and running pmie rules

Test your rules from the command line first:

$ sudo pmie -v -c /etc/pcp/pmie/smart-health.pmie -t 10second

This evaluates the rules every 10 seconds and prints verbose output so you can see them firing. Once you're happy with the rules you can run pmie as a persistent service. The system-wide pmie instance is managed by pmie_check and configured in /etc/pcp/pmie/control. Add an entry pointing to your rules file to have them evaluated continuously alongside the default PCP rules.

A complete smart-health.pmie rules file covering temperature, wear and error alerts for both NVMe and SATA drives is provided alongside this post in the conclusions section. Copy it to /etc/pcp/pmie/ to get started.

Other actions are available beyond syslog. Use shell to run arbitrary commands (such as sending an email or desktop notification), print for stdout output or chain actions with & to run multiple actions when a rule fires.

Continuous monitoring with pmlogger

pmlogger is a core utility included with PCP, and automatically logs metrics when running. To start it and enable it on boot:

$ sudo systemctl start pmlogger
$ sudo systemctl enable pmlogger

By default, pmlogger captures a broad set of system metrics. To ensure SMART drive metrics are included, run:

$ sudo pmlogconf -r /var/lib/pcp/config/pmlogger/config.default

When prompted, enable the S.M.A.R.T drive statistics [Linux] group. This ensures drive health metrics are captured continuously, allowing you to review historical trends using tools like pmchart, pmrep, or Grafana with the PCP Valkey datasource.

With pmlogger running, you build a historical record of your drive health. If a drive starts failing in six months, you can look back and see exactly when the warning signs began.

Conclusion

Drive failures give warnings, through SMART metrics, error logs and performance degradation. With PCP's drive monitoring capabilities you have the tools to catch these warnings before they become data loss.

In this post we covered setting up the SMART PMDA for universal drive health monitoring, interpreting key metrics like temperature, wear levels, error counts and tracking drives reliably with WWID-based identifiers. NVMe users can go deeper with error log collection and Seagate drive owners have access to extended FARM telemetry. Combined with Grafana dashboards and pmlogger you get continuous visibility into your drives' health.

The key takeaway: continuous monitoring catches trends that one-time checks miss. A few minutes of setup today can save hours of recovery work (or worse, unrecoverable data loss) tomorrow.

For more information, visit the Performance Co-Pilot documentation and the grafana-pcp plugin documentation. The Grafana dashboard used in this post is available to download here and can be imported via Dashboards > Import in Grafana. The pmie alerting rules are also available to download here and can be copied to /etc/pcp/pmie/ for use with pmie.

10 Aug 2026 8:00am GMT

Another saturday spent dealing with scrapers, so now time for a recap of the previous weeks events.

08 Aug 2026 8:58pm GMT

Let us be real for a moment: we have all been burned by AI hallucinations.

You sit down, ask an LLM to write a helper script or refactor an awkward class, and it hands back something that looks strikingly professional. The indentation is crisp, variable names are elegant, and docstrings read like poetry. You compile it, and... kaboom.

The model confidently imported a non-existent package, called an API method that exists only in its imagination, and invented three CLI flags out of thin air. It stared right into your terminal and insisted with absolute conviction that everything was tested and ready to ship.

If you have ever caught an AI model quietly lying about compiler output, you know the feeling. Trusting an LLM to blindly hallucinate its way through code generation is a speedrun to broken builds and late-night debugging sessions.

07 Aug 2026 1:00pm GMT

Because artificial intelligence competes with humans, especially for our planet's resources, I've chosen my side: the human.

I also think that AI is terribly bad for what should be our priorities:

• AI doesn't stop wars
• AI doesn't help with the climate crisis
• AI doesn't solve the world's nutrition problem
• AI doesn't reduce the hate between humans
• AI doesn't improve the distribution of wealth
• AI doesn't enhance education
• AI doesn't contribute to Open Source
• AI doesn't create

Everything on my website, in my repository, in my personal work, and my contributions to the Open Source community is the result of my skills and my experience. No AI is used; no AI will be used.

Yes, I'm aware that AI may help in some projects (e.g., medical diagnostics, live translation), but I don't think the benefits outweigh the costs.

Yes, this is very political.

You can read Artificial Intelligence Controversies or Why No AI?

07 Aug 2026 9:42am GMT

06 Aug 2026 10:00pm GMT

05 Aug 2026 12:00pm GMT

Running Large Language Models (LLMs) locally has become increasingly popular for development, privacy, and offline testing. Ollama makes this incredibly straightforward, allowing you to run models like Llama 3 or Mistral directly on your machine.

By leveraging Podman on Fedora Linux, you can isolate Ollama inside a container. This approach keeps your host system clean while making it effortless to spin up, manage, and tear down your AI development environment.

What is Ollama?

Ollama is an open-source framework designed for running, creating, and sharing large language models. It packages model weights, configuration, and data into a unified management system. Running it inside a container means you don't have to deal with complex local dependencies, Python environments, or complex GPU driver configurations on your base OS.

Verify or Install Podman

Podman is available by default in Fedora Workstation. It can be easily install, if missing, using DNF:

$ sudo dnf install podman -y

For Fedora Linux Silverblue users, Podman is natively available in the immutable base system and no extra steps are necessary.

To verify your installation and ensure everything is running smoothly, execute a quick check:

$ podman --version

Step 1: Create a Persistent Volume for Your Models

LLM weights can be huge-often ranging from 4 GB to over 40 GB, depending on the model size. To avoid downloading these models every time you restart your container, create a persistent Podman volume to store them safely on your host disk:

$ podman volume create ollama_storage

Step 2: Run the Ollama Container

Next, spin up the Ollama container. The following command pulls the official image, attaches the volume we just created, and maps the communication port (

) to your host machine.

$ podman run -d \
  -v ollama_storage:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Note on Hardware Acceleration

The command above runs Ollama using your CPU. If you are on Fedora Workstation or Silverblue and want to pass through an Nvidia GPU for fast hardware acceleration, make sure you have the Nvidia Container Toolkit installed and append the GPU flag:

--device nvidia.com/gpu=all

Step 3: Download and Run an AI Model

With the container running in the background, you can interact with it using Podman's execution command. Let's pull and run Llama 3, a highly capable, lightweight model perfect for local development:

$ podman exec -it ollama ollama run llama3

The first time you execute this, Podman will download the model weights into your

volume. Once the download completes, you will be dropped directly into an interactive terminal prompt:

>>> Send a message (/? for help)
>>> Tell me a fun fact about Fedora Linux.
Fedora Linux is named after the iconic felt hat worn by the Red Hat shadowman logo! It started as a community project to provide extra packages for Red Hat Linux.

>>>
To exit the interactive prompt, simply type /exit.

Step 4: Interact with the Local API

Because we mapped port 11434 to our host system, you can also interact with your local Ollama instance via its built-in REST API. Open a standard terminal window and send a curl request:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Why use containers?",
  "stream": false
}'

This returns a structured JSON payload containing your answer, allowing you to easily hook your local model up to web apps, scripts, or IDE extensions.

Checking Container Status

To monitor your running local AI instance, use the classic Podman management commands, perhaps starting with:

$ podman ps

You can also inspect the logs to make sure the API server is listening properly:

$ podman logs ollama

When you are done with your development session and want to free up system memory, stop the container:

$ podman stop ollama

If you ever need to completely remove the container environment, use:

$ podman rm ollama

Note: Your downloaded models are completely safe inside the ollama_storage volume and will instantly reattach the next time you spin up the container.

Conclusion

Using Podman to manage Ollama on Fedora Linux or Fedora Silverblue offers a clean, containerized way to build and test applications with LLMs completely offline. It bypasses host environment pollution, isolates large model storage cleanly into a named volume, and treats your AI stack exactly like any other microservice.

05 Aug 2026 8:00am GMT

05 Aug 2026 4:49am GMT

I have spent the last two years rebuilding GNOME Boxes from the ground up, driven by three main factors. I spoke extensively about this effort in my recent Linux App Summit, GUADEC 2025 and 2026 talks, but today I am excited to share the result for general testing.

First, shifting to a Flatpak-first (and only) model. As a solo developer, maintaining code paths for countless distributions isn't sustainable. Since Boxes acts as a frontend for libvirt/qemu, its functionality relies heavily on the backend configuration. Flatpak lets me bundle the entire virtualization stack, giving me the control I need to fine-tune it for our specific use cases.

Second, migrating Boxes to GTK4 and Libadwaita. Beyond the obvious benefits (a modern UI, better responsiveness, and tighter desktop integration) this makes the codebase significantly easier to maintain. This transition required moving away from the GTK3-based SPICE display widget, which was too tightly coupled to older input and drawing methods. We've replaced it with Libmks, which has proven to be a solid alternative.

Lastly, modernizing the codebase to make it sustainable for new contributors. That meant adopting modern GNOME app design patterns and rethinking our underlying architecture.

I am now ready to share this work with a wider audience. However, please keep in mind that this is a Beta release meant for testing, not for production environments. If you plan to try it out, make sure to back up any important data in your virtual machines first.

If you want to test this new implementation of GNOME Boxes, you can set up the GNOME Nightly Flatpak Repository and install it with:

flatpak install org.gnome.Boxes.Devel

This new version already covers most of what the classic Boxes could do: creating virtual machines from ISO media and disk images (qcow2), configuring VM resources, sharing clipboard content, sending files to the guest, and more.

It can install Windows 11 without any manual workarounds. Boxes configures Secure Boot and a virtual TPM device automatically. Everything required to pass the Windows 11 hardware compatibility checks out of the box. This was the most requested feature for the classic version, so I am particularly glad it is fully functional in this rewrite.

As distributions shift toward image-based OSes, this Flatpak-only approach becomes even more valuable. Most other virtual machine managers rely on host services or privileged daemons that are difficult to configure on immutable systems. While hardware and host combinations vary, bundling the backend stack directly inside the Flatpak gives us a controlled baseline that we can actively support, configure, and refine over time.

Accessing VM contents used to be tricky due to Flatpak sandboxing. This version addresses that by introducing a VSOCK device to the box, allowing guests with systemd v256 or newer to be accessed directly over SSH. It also adds initial support for port forwarding, letting you reach services running inside the VM from your host.

All of this and more is detailed on our new website, nightly.gnomeboxes.org, where you can also learn how to help by testing and reporting issues.

Please keep in mind that I am working on this in my free time alongside maintaining GNOME Settings and my day-job responsibilities at Red Hat. I ask for your patience with issue responses, but I will do my best to address bugs and keep pushing feature development forward as time allows.

I love building GNOME Boxes, and I am constantly motivated by the positive feedback from our community. People appreciate Boxes because it lets them set up a VM quickly and get straight to work without needing deep knowledge of virtualization or operating system internals. That remains the core mission, and that is the user experience I want to continue building for.

A lot of this implementation will still change as I gather feedback and it matures. I have also drafted a series of follow-up blog posts to this one, which will describe and elaborate a bit more on the new features, explaining how to use them and how they have been implemented. Stay tuned!

Comments

03 Aug 2026 11:28am GMT

This one is a bit light. I think that reflects the craziness of the summer and how I have worked through the backlog of my Instapaper. I've also been reading actual books (see below) so maybe you should too :D.

People

• Chasing life goals is a recipe for disaster - so try these tiny experiments instead

  Becoming the kind of parent you didn't have a model for.

  These are amazing words and regardless of our actual lived experience, I think we all feel this way when we have children.

• Communities are not fungible

  Not only are communities not fungible, but JA makes it crystal clear how they differ from person to person inside the community because they are overlapping Dunbar circles. Before I left Twitter, I remember thinking that I must be using a different Twitter from everyone else because my experience was nothing like what I was hearing about. The same is now true for me on Mastodon.

Machines and Politics

• Opinion | The Environmental Case Against Data Centers Is Misguided

  Data centers should be held to the same environmental standards as any other project.

  Why is this even controversial? I also believe we should price consumables at the correct cost reflecting our view on their impact as well as their production. I realize this will increase costs for many, including low-income members of our society, so instead we should surface the subsidy as a real subsidy line item. People should understand what things cost and what they have received as support.

  For bonus points we can make the subsidy refundable to encourage people to conserve.

• Hyperrealist Datacenters And Potemkin McRibs | blarg

  I like it when an article finally acknowledges the power of smaller models for many uses when talking about the LLM Data Center bubble. If you choose to use LLMs start running some experiments with non-frontier models, whether cloud hosted or local, I think you'll be pleasantly surprised.

  While you're reading this article, stay for the bonus McDonalds anecdotes. Per my daughter, as I am sad to admit, it has the best chicken nuggets a pork-market arbitraging real estate company can make.

• Opinion | Is France poorer than America? You don't have to 'walk around' to know.

  This is such an American question. It's like a reverse Tucker Carlson in a Russian grocery store. You know it is hard to toe the line when the best polish you can put on this turd of a proposition is, "[rural france is also] humdrum highways rather than picturesque public transit. The European endowment of beautiful architecture feels much richer than American acreage when you're, well, walking around. That effect is magnified by lower crime and public disorder in Europe." But yeah, let's talk about raw dollars baby.

Recently Finished Books

I've been tracking my book reading on my blog, but it never gets surfaced anywhere. I've decided to start including them here. Head to my reading page to find detailed notes or reactions for each book, similar in style to this post.

And finally

• A pan that won't let me rush dinner - Down the Road

  I'm learning that turning the burner higher doesn't actually make dinner happen appreciably sooner. It just makes it easier to burn dinner. So I'm going to learn to go low and slow.

  I remember reading somewhere that you should almost never set a burner above medium. These days when I cook, I'm using gas :( - but low and slow has paid off. The other day I was cooking a chicken breast in our go-to nonstick IKEA skillet. I'd done basically no prep due to a child who hates flavor and hadn't even tried to make it a similar thickness throughout. I wound up putting my skillet on too small of a burner, setting it to low, and hanging the pan half off the burner. This put the chicken on the off side recreating the indirect heat of a grill. I had juicy AF chicken. Suck it George Foreman!

03 Aug 2026 8:20am GMT

Flock 2026 was my first Fedora conference, and it won't be my last. I came home with new ideas, new friendships, and even a new project to work on for next year.

Appreciation

I want to start by appreciating the Flock organizers and volunteers. Putting together an event like this takes a lot of quiet, unglamorous work, and it showed in how smoothly everything ran. Thanks for that!

I'd also like to thank the event sponsors. Their support makes it possible for contributors from all over the world to come together, learn from one another, and strengthen the Fedora community.

I also want to appreciate my mentor, Jona, for pushing and supporting me until I finally made it. And a big thank you to Fedora for the sponsorship that got me there.

This year I also got to be part of the Mentor Summit organizing team myself and helped put together the very sessions I used to just attend as a newcomer. Full circle moment here

It has always felt rewarding to contribute to something I love, and Fedora has always been one of my favorite communities. Along the way, I've made great friends and met many wonderful people.

Finally, I'd like to thank the Nairobi GNU/Linux Users Group for supporting Fedora's Recognition Program this year by sponsoring the trophies and keychains. It was great to see our local community play a part in recognizing Fedora contributors, and I hope it's the beginning of a lasting tradition.

Our winners this time were; Fabio Valentini, Justin Forbes and Ankur Sinha in that order. Congratulations to you, and keep going You might want to hear from them in our podcast Fedora Contributor Recognition Program 056.

Diversity, Equity and Inclusion

I love how Fedora is so supportive of people from under-represented groups. Being at Flock felt like a reward for the work I've been doing with the community too - I had been organizing and mentoring from home. Being there in person and seeing that my work was appreciated meant a lot.

This is what I love about Fedora: it's welcoming, and it lives by the Four Foundations every day.

I also believe the in-person inclusive checklist I worked on last year helped make this year's event a success. I loved the venue - I guess that's why we went back to the same place as last year.

Honestly, I'd say everything was perfect. So hey, Flock organizers - the venue was perfect.

The talks

There was so much to take in: design, the mentor summit, docs and the docs initiative, lessons from FOSDEM and SCaLE, and so much more.

There was also the fbrnch workshop, Fedora data and analytics, and honestly too many good sessions to list them all here.

If there's one thing I keep learning about this community, it's that nothing happens unless you ask. People, or I would say, I personally don't wait to be picked here, I just find ways to engage, go deep, and just ask, ask, ask. I wanted to help with speaker logistics this year for Fedora Linux 44 release party, so while I was checking open tickets, I found it and asked if I could manage it. And I did it. I know some people might hesitate to just raise their hand like that, but Fedora is always welcoming, and honestly, we can always use the support. Get involved, it feels good to contribute to something you love.

Funny enough, a friend paid me a compliment (I think?) that I know how to navigate open-source communities and always find something to do. I'm still not sure if that's just a "community person" thing, or if it's because I genuinely like understanding people and learning new things. Maybe both.

Candy Swap

The candy swap - I totally loved this! Super awesome idea. Sorry to disappoint that I couldn't find time to bring anything, but I promise I will next time.

Mentor Summit

This was the 5th edition of the Fedora Mentor Summit, and it packed a lot into a few days. Lunch & Learn sessions ran across all three days, the informal, team-themed gatherings where you could step out of your usual circle and sit with people from Docs, Infra, Marketing, Packaging, Design, wherever you wanted to learn something new. No pressure, just conversation over food.

There was also a sticker-matching icebreaker, and everyone got a Fedora mascot sticker at registration, and the game was to go find your match and have a chat with them about anything open source.

Being on the organizing side of this for the first time gave me a whole new appreciation for how much quiet coordination goes into making something feel effortless for the people attending. Read more about how Mentor Summit came together here.

The hallway track

This is where the real magic happens. Daniel gave a brief, informal talk about eBPF, and honestly, that conversation ended up being one of the best parts of the whole trip.

I got to connect and meet team members, make new friends, and it was exciting just to sit and learn from them in a way a formal talk doesn't always allow.

And out of that hallway conversation, I actually found another thing to do within Fedora. I have a project I'm hoping to finish and present at the next Flock - mentored by Daniel on eBPF. (Putting this here for accountability, so you can hold me to it. )

I keep meeting super kind, good Fedora friends who are willing to mentor and give their time. It says a lot about how welcoming this community really is.

Everyone I met was kind, and always down to talk about their experiences and their love for open source - and how they hope more people get to know it, try free software, and enjoy it wherever they are, in their own languages. That last part is thanks to the i18n and translation teams across open source communities, doing work that often goes unnoticed.

Being early in my career, of course I had to ask people how they got in. I won't turn this into a rant, but if I had to summarize the advice: be a problem solver, and contribute to what you believe in - something you enjoy or find genuinely interesting.

*Thanks for reading this far. What's below isn't a big deal - just the city.*

The city

I extended my stay by 3 days to explore Prague. I took so many pictures my phone storage nearly gave up on me - I found almost everything lovely and fantastic. I'll link one of my best shots of the museum and the city below.

Thanks to my friend MatH for being my tour guide!

I totally loved it. It says something that the organizers knew just how magnificent this city is, and believed we'd love it again - and they were right.

I wish I could include every beautiful photo I took, but for now, these few will have to tell the story.

Take away

Every day with Fedora, I get to know more about open source, and I get to give back to my community back home.

I am Fedora

If any of this made you curious, here's where to start: come join us in Fedora Join SIG, or if you're just getting started, the Beginner's Guide is the friendliest place to land.

Your Friend in Open Source, and Open-Source Freedom Fighter.

03 Aug 2026 8:00am GMT

Across the various Fedora teams, a major shared focus is the ongoing infrastructure migration to Fedora Forge (Forgejo) and the formalization of its usage policies, a coordinated effort involving the Council, Infrastructure, Release Engineering, and Security groups. Quality assurance and release readiness for Fedora 45 also dominate the updates, highlighted by approaching testable deadlines, mass branching preparations, and FESCo's system-wide approval of gating all stable release updates using the rmdepcheck dependency checker. Meanwhile, user-facing and quality teams are heavily collaborating to troubleshoot critical system issues-most notably a Fedora 44 Workstation login lockout bug-while language-specific SIGs (Go, Perl, Ruby, Rust) are addressing routine maintenance, unannounced soname bumps, and evolving packaging standards. Finally, community outreach and organization remain highly active, with teams like Mindshare and Ambassadors rallying volunteers for upcoming events like FrOSCon 2026, and multiple working groups actively streamlining their documentation and meeting structures to improve contributor onboarding and combat maintainer burnout.

Announcements

Important deadlines and policy updates are approaching for Fedora contributors. First, the Fedora 45 Changes TESTABLE deadline is set for August 11, 2026, requiring all change owners to verify their tracker bugs are in a testable state. Additionally, maintainers should review the list of long-term FTBFS packages scheduled for retirement from Fedora 45 around August 5. On the infrastructure side, the Fedora Council has opened the proposed Fedora Forge Usage Policy for community feedback until August 13, establishing clear scopes and guidelines for the project's internal Forgejo instance. Finally, the long-running CLE "Community update" is officially retiring and being replaced by this new "This Week in Fedora" report to keep contributors informed.

In broader community news, a recent article highlights Peter Boy's work with the Docs Team to explain why Fedora needs more than just technical contributors. For those who missed the recent contributor conference in Prague, a new Flock 2026 Afterburn retrospective shares insights and survey results from the successful event. The project's multimedia outreach continues to see steady audience growth across platforms according to the Fedora Podcast 2026-Q2 metrics report. As part of that ongoing output, the team has just released Episode 057 diving into the history and mechanics of EPEL with Red Hat's Carl George, exploring a tool relied upon across the entire enterprise Linux ecosystem.

Council

The Council focused heavily on policy formalization and infrastructure migration this week. During their bi-weekly meeting, they agreed on edits to the Fedora Forge Usage Policy, settling debates on automated repository archiving by favoring manual oversight, and initiated the official community feedback phase. They also debated a draft Conflict of Interest Policy to handle sensitive governance decisions, and officially closed outdated requests to abolish the Fedora Contributor Agreement. Furthermore, discussions opened regarding the transition of the Digital Public Goods Alliance representative role following the FCA transition.

The Council also handled several operational and community requests. They approved an exception for FreeIPA to be hosted on Fedora Forge and decided to migrate the Fedora Budget repository while explicitly purging old private financial issues. Finally, the Council addressed trademark and organizational queries, declining a suspicious SIG creation request, signaling support for a trademark request for community stickers in Slovakia, and clarifying rebranding requirements for Fedora Remixes.

Decisions

• Approved an edit to the Fedora Forge Usage Policy regarding repository archiving, removing the automated 6-month rule, and initiated the official policy change process.
• Closed tickets #410 and #460 (Abolish Fedora Contributor Agreement / Re-license fedora-logos) as deferred/wont-fix due to a lack of capacity and legal constraints.
• Agreed to migrate the Fedora Budget repository to the Council space on Fedora Forge and delete all of its old private issues containing personal data.
• Approved an exception request (Ticket #575) allowing the FreeIPA organization to be hosted on Fedora Forge.
• Denied a suspicious Forge organization request for a new "Software Engineering SIG" (Ticket #573) because it did not follow the documented process.

Learn more about the Council team.

FESCo

This week, FESCo approved several significant system-wide changes, most notably retargeting the Enable Shadow Stack by Default on x86_64 change to Fedora 46 to ensure ample time to fix PyPI and Nvidia driver compatibility. Other major approvals include ODBC Stack Modernization, Native Butane Config Support in Ignition, and the libxml2 2.15 update which officially deprecates Python bindings and requires a mass rebuild. FESCo also fast-tracked and approved a proposal to gate all stable release updates on rmdepcheck to enhance update stability.

In contributor and project news, FESCo granted Proven Packager status to mschorm, merged an adjusted mid-term election policy, and sent final reminders for the upcoming 2FA requirement for all provenpackagers. Ongoing discussions are exploring the Forgejo distgit migration, a Bugzilla replacement tracker, and handling prohibited pre-built binary executables in node_modules. Furthermore, proposals to enable systemd-oomd and zram swap for CoreOS and use Sequoia's OpenPGP implementation are currently under active vote.

Decisions

• Approved the 'Enable Shadow Stack by Default on x86_64' Change, retargeting it for Fedora 46.
• Approved the 'libxml215' Change for Fedora 45.
• Approved the FastTrack proposal to gate all stable release updates on rmdepcheck.
• Approved the 'Native Butane Config Support in Ignition' Change.
• Approved the 'ODBC Stack Modernization' Change.
• Approved the 'LibreOffice Dictionaries' Change.
• Approved the 'LibreOffice html help' Change.
• Approved allowing the ELNBuildSync (EBS) service to use draft builds in Koji sidetags inherited from eln-build.
• Approved an adjustment to the election policy regarding seats filled after a member steps down mid-term.
• Approved a one-off slightly incompatible update request for rust-routinator.
• Approved the Request to become Proven Packager for mschorm.

Learn more about the FESCo team.

Mindshare

This week, Mindshare welcomed a new contributor who expressed interest in joining the CommOps team, pointing them to the Matrix chat and Forgejo issue tracker for immediate engagement opportunities. Additionally, preparations are actively underway for FrOSCon 2026, a free FOSS conference happening August 15-16 near Bonn, Germany. The team has secured a booth and is calling on community members to volunteer, create A4 project teasers to spark conversations, and join the pre-event hike to Drachenfels castle.

Decisions

• Confirmed that a Fedora project booth will be hosted at FrOSCon 2026.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group is calling for all hands on deck to prepare for FrOSCon 2026, scheduled for August 15-16 near Bonn, Germany. A Fedora booth is confirmed, and contributors are highly encouraged to engage by joining the Matrix room, adding their names to the event Wiki, or creating A4 teaser pages to spark conversations about their Fedora projects at the booth. Additional community-building activities include a planned Friday evening hike to Drachenfels castle, while work on the official event badge is currently pending.

Decisions

• Confirmed Fedora's booth presence and participation at FrOSCon 2026.

Learn more about the Ambassadors team.

Diversity & Inclusion

Justin Wheeler proposed putting DEI Team meetings on hiatus to protect the mental health of the chairs and prevent burnout. The team agreed that regular meetings had become stagnant and decided to shift their focus toward ad-hoc, event-specific teams with concrete goals and timelines, such as the Fedora Mentor Summit or Fedora Week of Diversity. General discussions will continue in the team chat room as needed.

Decisions

• Put regular DEI Team meetings on hiatus and transition to an ad-hoc, event-specific meeting model.
• Delete the regular DEI Team meeting entries from both the Fedora and Google Calendars.
• Open a volunteer call for Fedora Week of Diversity to evaluate if there is enough interest to execute the event later this year.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation/GNOME team discussed a login bug in the Fedora 44 Workstation ISO where users are occasionally locked out after setting their credentials. Contributors are working to gather logs and pinpoint the exact cause within gnome-initial-setup. Additionally, a new implementation restoring Google Drive integration in GNOME is currently under review by upstream maintainers, presenting a great opportunity for community testers to provide feedback.

In networking discussions, the team explored IPv6 prefix delegation issues involving routers that fail to invalidate old prefixes after rebooting, which leads to dropped connectivity. It was noted that router manufacturers like Mikrotik are currently working on firmware updates to align with RIPE recommendations, circumventing the need for immediate workarounds in Fedora's default network behavior.

Decisions

• Determined that the Fedora 44 Workstation login bug is related to user creation during first boot (gnome-initial-setup or shadow-utils) rather than Anaconda, which does not handle user creation on the Workstation Live image.

Learn more about the Workstation / GNOME team.

KDE

A user reported experiencing system freezes under Plasma (Wayland) after upgrading to Fedora 44, specifically noting that the nvidia-modeset/kthread_q process was consuming 100% CPU. The issue occurred on a hybrid graphics setup utilizing an AMD CPU and a discrete NVIDIA GPU running the proprietary NVIDIA drivers (610.43.03).

In the ensuing discussion, a community member advised checking the system and user journals via SSH before performing a forced reboot to isolate the root cause. The user was also directed to seek further assistance on the Fedora Discussion forum, which hosts a larger pool of contributors experienced with NVIDIA troubleshooting.

Learn more about the KDE team.

Server

During this week, the Server Working Group held a meeting to coordinate Fedora 45 release testing, Ansible support, and the Home Server spin-off. Contributors are encouraged to help test Brett's newly finalized Kiwi development environment for the Home Server project. On the automation front, the group is exploring the "AnsibleByExample" standard project layout and GitLab workflows for their upcoming Ansible roles, and an initial post-install role PR is being merged for member testing. For F45 testing, Emmanuel Seyman will review the upstream release changes for potential Server Edition impacts, and interested contributors were directed to the QA SIG to assist with openQA test automation.

Outside of the meeting, a forum discussion regarding IPv6 preferred_lft address routing issues with non-persistent prefixes concluded. A user shared a temporary workaround using Unique Local Unicast (ULA) and NAT while awaiting an upcoming patch from router manufacturer Mikrotik.

Decisions

• Emmanuel Seyman will review the Fedora 45 change list to identify potential issues for the Server Edition.
• The group will evaluate the 'AnsibleByExample' playbook structure and GitLab workflows to standardize their Ansible support repositories.
• John Himpel will merge Emmanuel Seyman's draft post-install Ansible PR to enable wider testing among members.
• The working group will begin testing and providing feedback on Brett's newly established virtualized Kiwi development environment for the Home Server spin-off.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on resolving post-migration issues following the upgrade of the IPA cluster to RHEL 10. Efforts were directed at stabilizing authentication services, addressing sporadic login errors on accounts.fedoraproject.org, fixing Ipsilon auth failures caused by browser tracking protection, and correcting LDAP schema replication errors. In the forums, a proposal was introduced to place an HAProxy load balancer in front of the IPA cluster to bypass ongoing DNS TTL caching problems. Work also continued on restoring the Koji staging database and migrating miscellaneous infrastructure hosts to RHEL 10.

Other notable discussions included optimizing Zabbix monitoring by implementing service-level layers, re-notifying on critical alerts, and exploring read-only guest access. The team also reviewed a proposal for a "test assets server" designed to drastically reduce network traffic by caching update repositories for Fedora CI and openQA. In parallel, Forgejo integration saw substantial updates, with new monitoring templates and continued progress on the highly requested private issues feature.

Decisions

• Set ipsilon02 as a backup server in HAProxy to mitigate authentication transaction failures caused by browser tracking protection.
• Completely disable (ensure absent) the mod_mime_magic Apache module on proxies and package servers to fix dist-git lookaside cache HTTP header issues.
• Add DNA range variables directly to the IPA Ansible playbook to automatically set them per host.
• Implement a 🔥 keyword highlight in Matrix clients to help administrators quickly spot Disaster-level Zabbix alerts.
• Patrikp will act as the chair for the August 13th Infrastructure meeting.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team focused heavily on the final steps for migrating fedora-scm-requests from Pagure to Forgejo. To minimize disruption for contributors, the team agreed to coordinate the fedpkg tooling updates with a firm "flag day", ensuring developers receive appropriate upgrade warnings before the legacy Pagure API is fully disabled. Meanwhile, preparations are underway for the upcoming mass branching tentatively scheduled for August 11th, which includes updates to related Ansible tooling.

On the operations side, the group processed a dozen tickets, yielding several updates relevant to the broader Linux community. The F47 Release Signing Keys have been generated, a new eln-bootc repository was created on Quay to host bootc images for ELN composes, and the f45-perl side tag was successfully merged into Rawhide. Contributors are also reminded that package unretirements (for packages retired less than 8 weeks ago) can now be handled directly via the fedpkg request-unretirement command without needing to open a manual releng ticket.

Decisions

• Coordinate the fedora-scm-requests Forgejo migration using a synchronized 'flag day' to safely transition users to the updated fedpkg CLI, rather than attempting to maintain dual APIs.
• Provide access to staging compose hosts for Pungi PR testing by adding the requesting users to the sysadmin-releng staging group.
• Merge the f45-perl side tag into Rawhide following successful openQA testing.
• Direct package maintainers to use the fedpkg request-unretirement CLI command for recent unretirements rather than processing manual infrastructure tickets.

Learn more about the Release Engineering team.

Quality

This week, the Quality team saw a major workflow change as FESCo approved gating all stable release updates on the rmdepcheck tool, a rule that has already taken effect for in-flight updates. In the forums, contributors highlighted a critical login lockout bug on the Fedora 44 Workstation ISO and issued an important call for testers to evaluate a new Google Drive integration implementation for GNOME.

Additionally, quality engineering efforts successfully pushed a large Python rebuild update through testing and identified issues with Fedora 45 backgrounds via openQA. The team is actively preparing for upcoming Test Days and making numerous infrastructure updates to tools like Issuebot, Testdays-web, and Fedora Easy Karma ahead of the upcoming Fedora branches.

Decisions

• FESCo approved gating all stable release updates on the rmdepcheck reverse dependency static checker. This rule was implemented in production immediately and applies retrospectively to in-flight updates.

Learn more about the Quality team.

Websites and Apps

This week, the Websites and Apps group discussed a proposal to add a warning banner to the Fedora 44 download page regarding a login-blocking bug that reportedly prevents users from logging in after a fresh Workstation install. While the initial request suggested pointing users to a Respins SIG image with a patched Anaconda, QA representatives clarified that user creation is handled during first boot (gnome-initial-setup or plasma-setup), not by Anaconda. Consequently, the discussion pivoted to accurately reproducing the issue, presenting an opportunity for contributors to help collect diagnostic logs for first-boot login failures before any website changes are considered.

Decisions

• No changes or warning banners will be added to the download page until the reported login issue is properly reproduced and the root cause is correctly identified.

Learn more about the Websites and Apps team.

Design

The Design team saw a community member propose a custom wallpaper set for future Fedora releases, though it was noted it may not fit the current Fedora 46 theme. In ticket discussions, progress continued on the Contributor Onboarding Video Series, with the team agreeing on specific public-domain music tracks and moving forward with generating video previews.

Additionally, new UX/UI design requests were opened for a Fedora website credits page and a Project Resistor site redesign, prompting the team to propose a discovery call for the latter. Finally, the team discussed modernizing the outdated "What can I do for Fedora" site, ultimately closing the ticket with the decision to contact the upstream infrastructure maintainers before committing to new mockups, while also dropping the broken link from a new contributor poster.

Decisions

• Proceed with the chosen public-domain music tracks ("Jupiter" and "Never Speak of the Devil") for the Contributor Onboarding Video Series.
• Schedule a discovery call with the Project Resistor team to clarify whether they need mockups or full web development.
• Close the "What can I do for Fedora" redesign ticket to first check with the upstream repository maintainers before doing any design work.
• Remove the outdated "What can I do for Fedora" link from the new contributor poster.

Learn more about the Design team.

Docs

During the July 28 meeting, the Docs team discussed information architecture updates for the site's frontpage. Visual redesigns are delayed for 2-3 months while the Design team is busy, but a new staging landing page (docs.stg.fedoraproject.org) is currently live to test structural changes. The team also evaluated technical challenges regarding Antora repository module splits, noting that future structural updates might require significant URL redirects to maintain links. In broader community news, attendees were informed that a Flock 2026 recap and session videos will soon be available on Fedora Magazine and YouTube.

To improve contributor engagement, the staging site now features a dedicated section for new contributors, and the team is actively seeking collaboration with the Join SIG to refine it. There are also immediate, bite-sized opportunities for community members to get involved: volunteers are highly encouraged to help clean up obsolete Wiki pages in the Docs_Project category by applying a simple redirect macro, and anyone with CSS experience is welcome to help style the new frontpage.

Decisions

• Postpone major visual and CSS updates to the frontpage until the Design team has availability in 2-3 months, focusing entirely on content and information architecture in the meantime.
• Restrict the ongoing wiki deprecation and cleanup efforts strictly to the Docs_Project category to prevent scope creep.

Learn more about the Docs team.

Legal

This week, the Legal team addressed questions regarding firmware distribution and open-source license text anomalies. In a discussion about the foo2zjs printer driver, contributors asked if Fedora could package scripts that download necessary HP printer firmware. Legal clarified that scripts downloading from unofficial third-party mirrors (getweb) are not permitted, but a script fetching from the official OpenPrinting website (getweb-hpplugin) could be acceptable, pending a formal license review of the firmware to ensure it meets Fedora's technical criteria.

Additionally, in a thread concerning "All rights reserved" clauses appearing alongside FOSS licenses like BSD-3-Clause, the team concluded that this phrase is largely a redundant "cargo-cult" addition. Contributors are advised not to worry about it, as it can be safely ignored provided it is associated with a clear, acceptable open-source license grant.

Decisions

• Scripts downloading firmware from unofficial, third-party mirrors are not permitted in Fedora.
• Scripts downloading firmware from official sources (like OpenPrinting) may be acceptable, but the specific firmware license must first undergo a formal legal review against Fedora's technical firmware requirements.
• The phrase "All rights reserved" found alongside upstream FOSS licenses is considered redundant and can be safely ignored as long as it is paired with an acceptable open-source license grant.

Learn more about the Legal team.

EPEL

This week, the EPEL team focused heavily on the EPEL 11 and EPEL 10 directory naming scheme proposal to address feedback from enterprise rebuild communities (such as AlmaLinux and Rocky Linux) regarding private mirrors and repository redirection. During their weekly meeting, the team laid out a timeline to evaluate and implement these changes before the RHEL 10.3 branching to avoid disrupting early adopters. Additionally, on the mailing list, it was announced that FESCo has approved gating all Fedora stable release updates using the rmdepcheck reverse dependency static checker, a policy that will soon be evaluated for EPEL as well.

In broader contributor and community news, routine package maintenance and quality assurance continued, including the introduction of new EPEL 10 packages and efforts to resolve failing-to-install (FTI) and policy-breaking packages in EPEL 9. Community engagement was also highlighted, with an upcoming Fedora Podcast interview featuring Carl George to discuss the EPEL 11 proposal and raise broader Linux community awareness.

Decisions

• The team agreed to schedule a vote on the EPEL 11 portion of the naming scheme proposal for August 5th, and a vote on the EPEL 10 portion for August 12th.

Learn more about the EPEL team.

ELN

During the July 28 ELN meeting, the team announced that ELN bootc images are now building regularly on Konflux. Contributors are currently resolving minor early-testing issues and working to establish an automated pipeline to the production registry (quay.io/fedora/eln-bootc). Additionally, qcow2 and ec2 images are now being successfully built using image-builder and have been validated on AWS, with pull requests open to integrate Azure and GCE support.

Looking ahead to RHEL 11, the group also debated whether to drop hardware firmware (such as linux-firmware) from cloud images. Acknowledging that hardware passthrough is still utilized on some hyperscalers, the group opted to move this conversation to a dedicated issue to carefully evaluate how closely ELN should mirror future RHEL decisions without disrupting existing use cases.

Decisions

• Tasked Simon de Vlieger with investigating how to properly upload and publish Konflux bootc builds to the quay.io/fedora/eln-bootc registry.
• Decided to move the discussion regarding the removal of hardware firmware from ELN cloud images to a separate issue tracker.

Learn more about the ELN team.

Atomic

In the weekly meeting, the team highlighted continued progress on ELN and Konflux integration, specifically regarding plans to migrate base images from GitLab. A blocker regarding a Konflux service account is currently being addressed by the infrastructure team, which is expected to unblock development shortly. Leadership also noted pending action items to formalize the SIG's setup process and establish a dedicated Fedocal calendar for contributors.

Meanwhile, an ongoing forum discussion regarding the proposed systemd-sysexts SIG focused on the administrative steps for launching the group. To navigate confusing documentation rules, contributors agreed to initially outline the new SIG's scope on a standard Fedora Wiki page before requesting a dedicated Forge organization and Matrix channel.

Learn more about the Atomic team.

CoreOS

This week, the CoreOS group focused on upcoming release testing, tentatively scheduling the Fedora CoreOS 45 Test Day and live video meeting for September 21st. Technical discussions highlighted the Ignition Native Butane Support proposal, which will remove the need for an external conversion step during provisioning; the team plans to gather feedback on this from the Flatcar community. Additionally, contributors addressed issues with the CodeRabbit PR bot leaving unprofessional comments in the Afterburn repository, planning to establish a dedicated repository to manage global configuration defaults.

In the forums, progress continued on establishing the systemd-sysexts SIG. Contributors discussed the optimal way to host the SIG's initial documentation, ultimately recommending starting with a Fedora Wiki page before requesting a dedicated Forge organization to bypass current procedural documentation challenges.

Decisions

• Tentatively schedule the Fedora CoreOS 45 Test Day and live video meeting for 2026-09-21, pending the final Beta Release schedule.
• Address inappropriate CodeRabbit PR bot comments by disabling them in affected repositories and creating a central coreos/coderabbit repository for global default configurations.

Learn more about the CoreOS team.

AI & ML

This week, the AI & ML group announced that GPU CI testing is now operational and available for contributors in the AI/ML SIG. Furthermore, the AI Developer Desktop has achieved its initial integration with OpenShell, marking an exciting step forward for the project.

In administrative updates, a contributor requested to be removed from the SIG due to time constraints and burnout. The group processed this request, removing the member from the SIG-related GitLab groups and the pytorch-sig membership to ensure an accurate representation of active contributors.

Learn more about the AI & ML team.

Security

During their weekly meeting, the Security SIG focused on formalizing internal vulnerability management processes and establishing documentation standards. A primary initiative is preparing for Fedora's representation on the private linux-distros mailing list to safely handle embargoed pre-disclosure vulnerabilities. To support this, the team is defining clear policies, establishing a secure Bugzilla workflow, and setting up dedicated access groups. In news relevant to the broader Linux ecosystem, the group is defining and documenting Fedora's role as a CVE Numbering Authority (CNA) and auditing existing documentation to align with the EU Cyber Resilience Act (CRA) requirements.

To improve contributor engagement opportunities, the team successfully migrated the Defensive Coding Guide from Pagure to Forgejo, opening the door for new community contributions. Discussions are also underway on the forum to review Fedora-maintained hardening guidelines and on the tracker to explore creating a vulnerability reporting badge as a non-monetary bug bounty alternative.

Decisions

• Draft comprehensive documentation detailing Fedora's scope and guidelines as a CVE Numbering Authority (CNA).
• Create a new FAS group named sec-bugzappers to manage access for Fedora representatives handling the linux-distros pre-disclosure mailing list.
• Establish a dedicated, private Bugzilla component (proposed as distribution-private or fedora-security) to track embargoed vulnerability reports.
• Draft a platform-neutral policy for handling pre-disclosure vulnerabilities and submit it as a PR to the Security team's documentation.
• Grant all Security SIG members the privilege to create new repositories within the Forge group to remove documentation bottlenecks.
• Close the Pagure repository and officially migrate the Defensive Coding Guide to the Security SIG's Forge namespace.

Learn more about the Security team.

Go

During the Go SIG meeting, the team discussed standardizing CGO_CFLAGS and related compiler flags across Fedora by introducing a new %go_set_cgo_flags macro, which will undergo mass prebuild testing to avoid disrupting existing packages. The group also approved a new SIG membership policy that will be appended to the project README, clarifying the justification required for elevated package privileges. For contributors looking to get involved, assistance is needed to patch downstream packages broken by recent Go 1.27 updates, specifically those affected by changes to json v2, compress/flate, and grpc.

In broader Linux ecosystem news, the unmaintained license-scanning tool askalono has been forked into a newly maintained project named scallion. Fedora's Go packaging stack will pivot to use scallion as its default license detector. Additionally, efforts are underway to provide a minimal go-vendor-tools package for RHEL 11 by stripping optional build-time dependencies, an initiative that presents immediate opportunities for contributors to write tmt-based integration tests.

Decisions

• Approved the new Go SIG membership policy, which will be formalized via a PR to the project repository.
• Agreed to introduce scallion as the replacement for the unmaintained askalono license scanner, with upcoming changes planned for both go-vendor-tools and go2rpm.
• Decided to release go2rpm v2 with the default configuration set to the vendor profile.
• Agreed to support go-vendor-tools in RHEL 11 by isolating the RHEL-specific changes in a separate GitLab branch and developing new tmt-based integration tests.

Learn more about the Go team.

Perl

This week, the Perl group focused heavily on package maintenance, compatibility updates, and version bumps. Several pull requests were merged, including conditionalizing dependencies for perl-Module-Build-Tiny, disabling optional dependencies for perl-Compress-Raw-Lzma in RHEL, and addressing Wx 3.2.9 compatibility in perl-Wx. A patch for OpenSSL 4 ASN.1 strings was integrated into perl-Crypt-SMIME. Additionally, routine version bumps were applied to perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).

Other ongoing discussions involved resolving an expected installability failure during the bootstrap of perl-SQL-Abstract and addressing MySQL 9.7 rebuilds for perl-DBD-MySQL, though the latter's PR was closed as the fix was committed directly to the rawhide branch.

Decisions

• Merge pull request to conditionalize CPAN::Requirements::Dynamic dependency in perl-Module-Build-Tiny.
• Merge pull request to disable optional dependencies for perl-Compress-Raw-Lzma in RHEL.
• Merge pull request applying a compatibility patch for Wx 3.2.9 in perl-Wx.
• Merge pull request containing an OpenSSL 4 ASN.1 string patch for perl-Crypt-SMIME.
• Close the perl-DBD-MySQL PR for the MySQL 9.7 rebuild without merging, as it was fixed directly in the rawhide branch.
• Merge version bump pull requests for perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).

Learn more about the Perl team.

Python

A contributor raised a packaging question regarding the dupeguru package (Bugzilla 2497737), which is currently waiting for review. The upstream code uses generic top-level modules (core, hscommon, qt), which could cause namespace conflicts with other applications. The main subject of inquiry was whether reorganizing the source tree to place these folders under a specific dupeguru namespace is the recommended approach for Fedora packaging.

Learn more about the Python team.

Ruby

Vít Ondruch announced that the upgrade to Ruby on Rails 8.1 (specifically version 8.1.2) has officially landed in Fedora. An update to the recently released version 8.1.3.1 is planned for the near future, as it was temporarily delayed to meet the change deadline. From a packaging perspective, there were no major structural changes, with the notable exception of Trix being extracted into a separate new package. Contributors and users are highly encouraged to test the new release and report any issues.

Decisions

• Upgrade the Ruby on Rails package to version 8.1.2.
• Extract Trix into a new, separate package.
• Delay the update to Rails 8.1.3.1 temporarily to ensure the 8.1.2 update meets the change deadline.

Learn more about the Ruby team.

Rust

Frank Dana proposed a new packaging method for Rust and Python that would replace feature-specific subpackages with a conditional Requires: ... for syntax in RPM. He argued that the current glut of subpackages creates excessive metadata, bloats dnf search results, and clutters local systems.

During the discussion, Fabio Valentini pointed out that Rust packaging tooling must maintain backward compatibility with RHEL 9, making this unfeasible to implement in the near future, and suggested using fedpkg mockbuild instead of local builds to avoid cluttering personal environments. Carl George noted that since some Python extra subpackages contain actual files (like CLI commands or man pages), the proposed mechanism could not fully replace subpackages, though both systems could potentially coexist.

Learn more about the Rust team.

Other Discussions

• Jakub Kadlčík proposed a reimagined Fedora Package Review Process using a temporary Forge repository, PRs with CI, and testing multiple packages in one go. After feedback regarding SRPM support and vendor archives, he planned to leverage Packit and Copr's custom build scripts instead of Forgejo Actions.
• A Hummingbird Community Meeting took place to discuss the intersection of Linux distributions and AI. Demos included Project Bluefin's autonomous agentic OS factory using Hive and Red Hat Hardened Images acting as a downstream for Fedora Hummingbird Linux.
• A user reported a privacy issue with Firefox RPMs because geoclue2 was installed as a dependency via xdg-desktop-portal. Community members shared configuration workarounds to disable the service's tracking capabilities.
• Simon de Vlieger published a blog post detailing how the Fedora 45 release is produced, explaining the pipeline from raw packages to final artifacts like ISOs and disk images.
• Tomáš Hrčka announced an update postponing the pagure.io sunset. The delay allows the team to finish migrating critical SCM repositories like fedora-scm-requests and to finalize ForgeFiler, a tool handling private issues temporarily missing from Forgejo.
• After a lengthy thread about too much automated email on the devel list, Kevin Fenzi disabled the Rawhide and ELN compose reports. Users who still want these notifications must now subscribe to the test-reports mailing list.
• A Change Proposal to enable Shadow Stack by default on x86_64 in Fedora 45 sparked discussion around compatibility. Discussions are ongoing regarding PyPI wheels built via manylinux, NVIDIA drivers, and Rust binaries (which have already been updated in Rawhide to build with SHSTK enabled).
• Adam Williamson's proposal to gate all stable release updates on rmdepcheck was approved by FESCo. The static reverse dependency checker is now active in production, successfully catching several genuine dependency breakages and minor infrastructure blips.
• A proposal to disable Vendor Change by default in DNF5 raised concerns that system upgrades might break for packages transitioning from third-party repos (like RPM Fusion) to official Fedora repos. It was suggested that specific vendor transition configurations could mitigate these issues automatically.
• A Change Proposal seeking to restrict Change discussions exclusively to the devel mailing list while leaving Discourse posts as read-only received mixed feedback. Some members proposed batch-posting announcements or finding a middle ground to minimize the split-brain effect that leads to maintainer burnout.
• Other discussions this week covered issues rendering the f45-backgrounds in KDE, a tech preview for Web Based Remote Installation for Atomic Desktops, a review request for the dupeguru duplicate file finder, the migration of the packager-sponsors tracker to Fedora Forge, community thoughts in regards to Change Proposals, and a reminder about the approaching F45 Changes TESTABLE deadline.

Orphaning packages

• Miro Hrončok posted a list of long term FTBFS packages to be retired in August that have failed to build since Fedora 42.
• Nicolas Chauvet issued a schroedinger retirement notice, retiring the package because it has been unmaintained upstream for 10 years and replaced by ffmpeg.
• Jan Stanek announced that nodejs20 is retired in rawhide following its upstream End of Life, advising users to migrate to nodejs22 or 24.
• Phoebe Harris announced an intention to take ownership of and unretire rust-qrcode and rust-wildmatch to support the clifton application.
• Scott Theisen submitted patches to build the orphaned packages python-markups and retext, though he has not formally adopted them.
• Sergio Pascual started an orphaning blitz by retiring the obsolete C++ array library blitz.
• The automated report of orphaned packages looking for new maintainers detailed numerous unmaintained packages at risk of retirement within six weeks.
• Richard Shaw asked if anyone wants to save python-pivy before it breaks completely due to missing dependencies.

Package updates

• An unannounced soname bump for nettle caused several FTBFS issues; a nettle3.10-devel compat package was shipped to unblock builds while maintainers port to Nettle 4.
• An unannounced soname bump for openssl-pkcs11 broke dependencies for nextcloud-client, requiring provenpackagers to merge PRs and rebuild the client in a side-tag.
• Iker Pedrosa announced a shadow rebase and libsubid SONAME bump being prepared in a side-tag, asking container tool maintainers to rebuild their packages.
• Michel Lind issued an RFC on an incompatible update for routinator due to a major security fix removing a vulnerable feature, which has now been pushed to stable.
• Ben Beasley gave a heads-up about an ABI-incompatible update for rapidyaml 0.16.0 coming to Rawhide.
• Pavel Valena requested testing for an upgrade to dracut 111 in Rawhide.
• Milan Crha announced a short-notice libedataserver soname version bump in Rawhide, providing a side-tag for dependent package rebuilds.
• Fabio Valentini warned of an unannounced soname bump for libgnome-desktop-3 affecting dozens of GNOME-related packages.

New contributor introductions

• Phoebe Harris: An embedded software developer aiming to package the SSH connection manager clifton and Typst.
• Dawid Wrobel: A KMyMoney developer returning to Linux who wants to adopt outdated GNOME extensions and package Betterbird.
• Myriade: A young Rust developer intending to adopt and maintain the orphaned supercollider package.
• Nikolay: A software engineer developing qTox who is interested in deep neural networks and machine learning.
• Vivek Denny: A backend/cloud developer with an interest in low-level systems and networks wanting to give back to open source.

03 Aug 2026 6:41am GMT