fidzu : Fedora

10 Sep 2026 11:50am GMT

09 Sep 2026 6:15pm GMT

A dominant focus across multiple Fedora working groups this week is the preparation for the Fedora 45 Beta release, with teams like Quality, Release Engineering, Server, and various architecture SIGs actively managing blocker bugs, freeze exceptions, and candidate composes. Simultaneously, groups are laying the groundwork for Fedora 46, evaluating new Change Proposals-such as the integration of the Crystal programming language-and kicking off the F46 wallpaper design process. Another major common theme is process and infrastructure refinement; the Council, FESCo, and Infrastructure teams are establishing new policies for Fedora Forge repository usage, Matrix moderation, and Change Proposal discussions. Finally, significant effort is being directed toward system cleanup and consolidation, highlighted by the Docs and Localization teams archiving obsolete, end-of-life documentation, the Rust and EPEL groups retiring outdated packages, and the Atomic and CoreOS communities forming a joint working group to unify base image development.

Announcements

In exciting hardware news for the broader Linux community, the Framework Laptop 12 Arrives with Fedora Pre-installed, offering a hardware-validated, out-of-the-box experience featuring the Fedora KDE edition. For users looking to proactively protect their hardware, a newly published guide explains how to Monitor Your Drive Health with Performance Co-Pilot on Fedora, allowing administrators to catch SSD and NVMe failures via temperature spikes and error counts before catastrophic data loss occurs.

For contributors and developers, three Change Proposals have been announced for upcoming Fedora releases. Packagers need to be aware of the F46 Change Proposal: Libical4 (system-wide), which transitions to the 4.x series and introduces API/ABI breakages that will require dependent applications to be rebuilt or patched. To help optimize the build ecosystem, packagers are encouraged to test the F46 Change Proposal: Thin LTO Build Flag (self-contained) (noted as intended for F47), which proposes a new %slim macro to reduce RAM requirements and compilation times compared to standard fat LTO objects. Finally, the F46 Change Proposal Crystal Language (system-wide) aims to introduce official native support for the Crystal programming language, bringing its compiler, shards dependency manager, and a highly secure, offline "Shard-as-RPM" packaging model into the Fedora ecosystem.

Council

The Fedora Council focused heavily on policy, governance, and infrastructure guidelines this week. Key discussions included defining the Fedora Forge usage policy, where a compromise was reached to require a "tickets" repository for organizational contact rather than implementing automatic archiving of inactive repositories. The Council is also reviewing a proposed Authorized Analytics Volunteer Agreement to ensure GDPR compliance for community members analyzing contributor data, which will soon be escalated to Red Hat Legal.

In addition to infrastructure policies, the Council is evaluating how to handle trademark guidelines for internally modified Fedora images, seeking to clarify rules around remixes that are not distributed publicly. Furthermore, with the transition of the Fedora Community Architect role, the Council is deliberating whether to formally maintain and reassign Fedora's Digital Public Goods Alliance representative responsibility or drop the commitment altogether.

Decisions

• A consensus was reached on the Fedora Forge usage policy to drop automatic repository archiving in favor of mandating a "tickets" repository for all organizations to ensure a public point of contact. The policy is now advancing to a formal ratification vote.
• The Council accepted a temporary workaround for handling private issues on Fedora Forge, determining that it satisfies their immediate requirements for restricted communications and clearing the ticket from their perspective.

Learn more about the Council team.

FESCo

This week, FESCo focused extensively on evaluating the F45 Incomplete Changes Report during their meeting (URL), determining which features are safe to land late and which must be postponed. Several changes were punted to next week due to absent owners, while others like Libxml215 were formally deferred to Fedora Linux 46.

FESCo also processed major tickets, finalizing a shift in the Fedora Changes discussion process and officially gating stable release updates on rmdepcheck. Additionally, new Change Proposals for Fedora 46 and 47 were introduced on the forums for community feedback, including the introduction of the Crystal programming language.

Decisions

• Change Proposal discussions will now occur exclusively on the devel mailing list, with Discourse acting as a read-only mirror (URL).
• Stable release updates will now be gated on rmdepcheck (URL).
• The Libxml215 Change was deferred to Fedora Linux 46. FESCo requires the creation of a libxml2_2.13 compatibility package as a separate source package (URL).
• The Enable Shadow Stack by Default on x86_64 Change is officially approved for Fedora 46, but requires Nvidia and PyPI Python wheel compatibility fixes before the F46 contingency deadline (URL).
• The Relocate RPM repository configs to /usr Change's remaining parts are permitted to land before the final freeze (URL).
• The Filter Fedora Flatpaks for Atomic Desktop v2 Change is officially declared completed (URL).

Learn more about the FESCo team.

Packaging Committee

The Packaging Committee held a meeting and processed several tickets this week, focusing heavily on reviewing new packaging guidelines for the Crystal programming language. The committee worked closely with the proposal's author to define standard naming conventions, dependency resolution strategies, and unbundled shard-as-RPM models to prepare for Crystal's integration into Fedora 46.

Additionally, the committee merged guidelines regarding a limited aws-lc exception for cryptographic policies, closed tickets clarifying that RPM Provides tags are not inherited, and updated guidelines to mandate the %openpgpverify macro. Progress was also made on defining multi-version guidelines for NodeJS streams.

Decisions

• Approved merging the guidelines documenting an exception for limited aws-lc use within CryptoPolicies (PR #1566).
• Agreed that the upcoming Crystal compiler should be packaged under the source package name crystal-lang rather than reclaiming the 15-year-old crystal package name to avoid messy git history. Crystal shard source RPMs will be unconditionally prefixed with crystal- (Meeting).
• Merged and closed PR #1562 to adopt the %openpgpverify macro by default in the packaging guidelines.
• Merged and closed PR #1563, adding a note to the guidelines clarifying that Provides tags are not inherited by subpackages or source RPMs.

Learn more about the Packaging Committee team.

Mindshare

This week, the Mindshare committee focused heavily on expanding Fedora's global footprint by reviewing 10 tickets centered around event presence, travel support, and swag distribution. A dominant theme across the community was the preparation for late-2026 regional FOSS conferences, with the committee working to balance budget requests against the need for in-person advocacy. Discussions highlighted a push to empower local ambassadors and foster deeper connections with enterprise Linux users, students, and broader open-source enthusiasts across the globe.

In addition to event planning, administrative efforts were made to improve how the committee tracks its quarterly budget and activities. A recurring priority within the committee's evaluations is the need for comprehensive post-event reporting and the active recruitment of local contributors to represent Fedora. This strategy aims to reduce travel costs while organically expanding the local ambassador network, ensuring that Fedora maintains a sustainable and high-visibility presence at regional events.

Decisions

• Approved a $150 budget request to cover event operations and localized swag for Software Freedom Day Bukidnon 2026 in the Philippines.
• Approved a travel and hotel budget request for representation and speaking at LinuxDays 2026 in Prague.
• Approved travel funding for the Fedora Podcast to attend, record on-site interviews, and provide coverage at Texas Linux Fest 2026.
• Approved travel and accommodation support to run a Fedora sub-booth focusing on APAC adoption at IndiaFOSS 2026 in Bangalore.

Learn more about the Mindshare team.

Diversity & Inclusion

Preparations for the 2026 Fedora Week of Diversity have officially kicked off. Following a recent call for volunteers and ideas for the upcoming virtual event, the organizers posted a brief status update to the planning discussion confirming that work is underway and more information will be shared shortly.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

The Workstation / GNOME group addressed critical regressions, evaluated Flatpak metadata certification, and prepared for upcoming releases this week. A major fix was pushed to Fedora 44 for a GDM auto-login regression, eventually culminating in a new upstream GDM 50.3 release. In meetings, the Working Group discussed the Fedora 46 Beta freeze, noting standard GNOME 51 test results, and investigated Rawhide compositor issues alongside Fedora 45 blocker bugs.

Additionally, the community was invited to test a newly proposed Google Drive integration for GNOME. Discussions also took place regarding the enablement of the new in-kernel NTFS driver in kernel 7.1, with community members sharing alternative akmod packaging solutions in the interim.

Decisions

• The Working Group decided to defer the evaluation of a custom metadata certification process for FlatHub packages to the issue tracker for further investigation and future deliberation.
• A backported fix for a Fedora 44 GDM auto-login regression was pushed to stable, prompting the upstream release of GDM 50.3 to officially address the issue.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE group focused on preparations for Fedora 45, including identifying topics for the upcoming Fedora Magazine "What's New" article and participating in the Fedora 45 Blocker Review meeting.

Additionally, the team is tracking two significant bugs in Fedora Kinoite: a Mesa green/purple tint issue related to AV1 hardware acceleration in Chrome on AMD GPUs, and a Discover crash regression that prevents updates from auto-installing.

Decisions

• The upcoming Fedora Magazine 'What's New' article for F45 KDE will focus primarily on Plasma 6.7 features, with a brief mention of the upcoming Plasma 6.8.

Learn more about the KDE team.

Server

During the week of August 31 to September 6, 2026, the Server Working Group primarily focused on restructuring the Fedora Server documentation and reviewing Fedora 45 release testing. The QA team introduced a proposal to reduce the list of release-blocking storage interfaces during installation, aiming to drop legacy interfaces like PATA, SCSI, and Hardware RAID while retaining modern ones like SATA, NVMe, and SAS. Additionally, Fedora 45 Beta preparations are underway with a Blocker Review Meeting scheduled for September 7.

Decisions

• The Server documentation will feature a new main section titled "Postinstallation Customizations", which will be placed second in the navigation tree immediately after the "Installation" guide (decided in the weekly meeting).
• The top-level documentation navigation bar names, including "Virtualization" and "Containerization", will remain unchanged, leading to the closure of ticket #224.
• The naming of sub-articles within the new Postinstallation Customizations section will be decided via a formal two-week vote in the Working Group's ticket tracker rather than by an immediate vote during the meeting.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused on server migrations, infrastructure improvements, and routine maintenance. A significant effort is underway to transition services like Mailman to RHEL 10 and to prepare storage provisioning for the production Forgejo dist-git instance. The Matrix moderation bot is being officially hosted on Fedora infrastructure, bringing new proposed policies for official Matrix rooms that group owners should review.

Additionally, developers tackled compatibility issues with Ansible and Python's deprecated ssl.PROTOCOL_TLSv1 on Fedora 45 during staging deployments. The team also reviewed AWS resource usage for August and issued a warning for owners to tag their AWS resources with FedoraGroup to avoid deletion. Several user-reported issues were resolved, including proxy bugs affecting Matrix Fractal clients, upstream login errors in Libravatar, and clarifications on MirrorManager's geographic mirror selection logic.

Decisions

• AWS resources without the FedoraGroup tag are subject to deletion.
• A new policy for "Official Fedora Matrix Rooms" has been proposed, requiring the use of the new internal moderation bot (@moderation:fedoraproject.org).
• Mirrors located in Iran (.ir) will not be included in MirrorManager due to export regulations.
• A 500GB storage volume on NetApp was allocated for the upcoming Forgejo Dist-Git production instance.

Learn more about the Infrastructure team.

Release Engineering

This week, Release Engineering focused heavily on the Fedora 45 cycle, which remains in Beta Freeze. QA and Releng coordinated on multiple Blocker Review Meetings and successfully produced several F45 Beta candidate composes (including Beta 1.1 and 1.2), alongside handling stable push requests for blockers and freeze exceptions.

Beyond the F45 release tasks, Releng resolved significant issues blocking updates, such as a database timeout bug in Bodhi that stalled the Fedora 44 Flatpak (F44F) updates-testing compose, and an issue with compose-tracker not opening tickets. Other routine operations involved un-stalling EPEL package assignments, handling branch requests, generating detached signatures for the ignition release, and preparing Koji infrastructure (like updating koji-image-builder and coordinating a new GPG key for ELN).

Decisions

• Accepted Bug 2524952 (kmscon) and Bug 2526398 (anaconda failure reporting) as Beta Blockers during the F45 Blocker Review meeting.
• Accepted Bug 2526278 (initial-setup on RPi4) as a Beta Freeze Exception, while rejecting Bug 2524726 (pcmanfm-qt) as a Freeze Exception. (F45 Blocker Review meeting)
• Delayed decision (punted) on Bug 2524940 (plasma-login-manager) to request more logs from reporters, and closed Bug 2502678 (plasma-discover update notifications) as NOTABUG. (F45 Blocker Review meeting)
• Decided to use a Koji side-tag and proven packager merges for the libical 4.x rebuild rather than relying solely on the F46 mass rebuild to handle incompatible updates. (Ticket 13504)

Learn more about the Release Engineering team.

Quality

The Quality group focused heavily on Fedora 45 Beta readiness, resolving blocker bugs as the beta go/no-go date approaches. A major community criteria change proposal was initiated to drop older, untestable storage interfaces (like PATA and HW RAID) from the release-blocking list.

In addition, the team finalized their requirements for the upcoming Red Hat Bugzilla replacement, and successfully returned issuebot to production for managing Ask Fedora common issues. Guidelines were also discussed for attributing LLM/AI-generated analysis in bug reports to avoid unwarranted confidence.

Decisions

• Accepted Bug 2526398 as a Beta Blocker since Anaconda fails to report crashes to Bugzilla.
• Accepted Bug 2524952 as a Beta Blocker due to a kmscon null pointer dereference crashing the text-mode initial setup.
• Accepted Bug 2526278 as a Beta Freeze Exception regarding wrong DRM card selection on Raspberry Pi 4.
• Rejected Bug 2524726 (pcmanfm-qt update) as a Beta Freeze Exception.

Learn more about the Quality team.

Design

The Design team kicked off the F46 Wallpaper project, choosing mathematician Karen Uhlenbeck as the inspiration and establishing a schedule running through December 2026. A call for contributors is open for sketches and ideas around themes like minimal surfaces and geometric analysis. Additionally, the team progressed on the Fedora Design Docs Revamp by posting drafts for the "How to Join" guide and FAQs, which will remain under review before publication, and decided to simplify the design for Ticket 40. Notably, the final badge design request accepted through the ticket queue was completed for the EPEL steering committee.

Decisions

• The team will no longer accept badge design requests through their ticket queue, following the completion of the EPEL steering committee badge. (design#60)
• Publication of the newly drafted FAQ and "How to Join" documentation is deferred until the end of the current or next sprint to allow for sufficient review. (Meeting Log)
• Ticket 40 will be reverted to an earlier, simplified version of the design to improve clarity by reducing the amount of information displayed. (Meeting Log)

Learn more about the Design team.

Docs

This week, the Docs group engaged in community discussions around system optimization and focused heavily on cleaning up outdated documentation. On the forums, users shared helpful resources, including a tutorial on using powertop2tuned for better battery life on minimal Fedora installations and a bash script to display active and installed kernels.

Behind the scenes, the team is working on archiving and removing obsolete documentation. This includes an ongoing effort to clear out hundreds of ancient Docs-related pages from the Fedora Wiki, utilizing a newly developed script to identify pages older than seven years. Additionally, a new ticket was opened to remove or archive documentation for End-Of-Life (EOL) Fedora releases.

Learn more about the Docs team.

Internationalization

The Internationalization (i18n) and Localization (l10n) teams are preparing for the upcoming Fedora 45 i18n test week starting September 7, which will feature a new section for testing installation-related issues. Additionally, three i18n changes submitted for Fedora 45 are now in the ON_QA testing phase, as confirmed during the group's weekly meeting.

In localization news, the team prepared an article proposal detailing the successful migration of the MATE Desktop translation project from Transifex to Fedora's Weblate instance, simplifying collaboration for the project's 200,000 words. The team is also managing routine repository maintenance, including centralizing documentation issue trackers, managing translation memory for retired atomic desktop variants, and clearing archived guides from Weblate to free up resources.

Decisions

• The archived and unpublished Sysadmin and Install guides will be removed from Weblate to free up system resources, but their git repositories containing the translations will be preserved. (Ticket #74)
• Requests to hide End-of-Life (EOL) Fedora documentation releases from Weblate will not be handled by the Localization team; they must be directed to the Fedora Docs team, as Weblate mirrors their publication choices. (Ticket #75)
• Translation errors found in upstream software (such as KDE Plasma) will not be fixed downstream in Fedora; users reporting these bugs are directed to collaborate with the respective upstream project's translation team. (Ticket #76)

Learn more about the Internationalization team.

Legal

Jilayne Lovejoy notified the Legal group about a proposed update to the SPDX license inclusion guidelines that could allow linux-firmware licenses to receive an SPDX license ID.

Contributors submitting requests to the SPDX license list are also reminded to explicitly mention if the license is from or included in Fedora, as this helps the SPDX team prioritize those requests.

Learn more about the Legal team.

COPR

Copr has begun migrating existing projects to use Pulp for storing build results, processing them in alphabetical order by owner name (excluding Packit projects). As a result of this migration process, users' builds may temporarily get stuck in a pending state. Users can check if their accounts are currently affected by looking at the blocked_owners field in the Copr backend configuration file.

Decisions

• The decision was made to migrate all existing projects to Pulp in alphabetical order by owner name (excluding Packit projects). Users should be aware that their builds may get stuck in a pending state during their migration window.

Learn more about the COPR team.

EPEL

This week, the EPEL group focused on major package updates and repository lifecycle management. Notably, ffmpeg is being updated from version 5 to 7 in EPEL 9 Next, with a compatibility package provided for applications unable to migrate yet. Additionally, significant work is underway to retire EPEL 10.1 and 10.2, archiving them while shifting focus to EPEL 10.3.

The team also addressed infrastructure issues, fixing a symlink churn problem that was serving the incorrect EPEL 10 release package to RHEL users. Regular meetings indicated smooth operations overall, with several package updates merging successfully, including major updates for cef and obs-studio.

Decisions

• Update ffmpeg in EPEL 9 Next (for CentOS Stream) from version 5 to 7, while introducing an ffmpeg5 compatibility package to prevent breakages. (Source)
• Archive EPEL 10.1 and transition towards the retirement of EPEL 10.2 in favor of EPEL 10.3.
• Update cef (Chromium Embedded Framework) and obs-studio to align with the latest upstream releases. (Source)

Learn more about the EPEL team.

ELN

The ELN SIG held a brief meeting this week. Due to light attendance, there were no specific topics discussed beyond a general check-in. The next meeting was scheduled for Tuesday, September 8, 2026, at 12:00 EDT.

Learn more about the ELN team.

Atomic

This week, the Atomic Initiative focused heavily on a proposal to unify base image development between the CoreOS and Atomic/bootc communities. A working group is being formed to collaborate on shared artifacts and technical processes, aiming for tangible results by the Fedora 46 release.

In addition to organizational efforts, the group addressed several technical support requests and policy discussions. Key topics included resolving a missing GPG key error during Fedora 45 upgrades, clarifying that tuned should handle power management instead of including powertop by default, and discussing how derived builds handle /opt//usr/local symlinks and Fedora trademark compliance.

Decisions

• A joint working group is being formed to explore base image unification between the CoreOS and Atomic/bootc communities.
• The powertop package will not be added to Atomic images; power management should be configured via tuned instead.
• Atomic Desktops will retain the /opt and /usr/local symlinks to /var for backward compatibility; derived builds needing a different structure must modify the configuration themselves.
• Generic remix images will not be produced for derived builds. Instead, efforts will focus on simplifying package swaps and improving documentation for downstream trademark compliance.

Learn more about the Atomic team.

CoreOS

This week, the CoreOS group held a meeting and saw updates regarding the newly proposed systemd-sysexts SIG. A major highlight is the ongoing effort to unify CoreOS and Image Mode/Bootc in Fedora; after a positive reception at the Fedora Bootc community meeting, dedicated sessions are being scheduled to explore proposals. In the forums, the proposal to create a systemd-sysexts SIG took a step forward with the creation of an official Fedora Project Wiki page for the group.

During their weekly meeting, the team reviewed various Fedora 45 change proposals, confirming that CoreOS is largely unaffected by changes like disabling the CRYPTO USER API or removing the NIS profile. They noted that Ignition Native Butane Support is rolling out to the next stream for early feedback, and identified the need to release updates for coreos-installer, afterburn, and zincati to support OpenSSL 4.0.

Decisions

• The group decided to roll out Ignition Native Butane Support to the next stream (which is Fedora 44-based) to gather early feedback before promoting it to testing. Source
• New releases of coreos-installer, afterburn, and zincati will be prioritized in the upcoming sprint to ensure compatibility with OpenSSL 4.0. Source

Learn more about the CoreOS team.

IoT

The Fedora IoT Working Group held a meeting to review branch statuses during the Fedora 45 freeze period. OpenQA tests for the stable branch (F44) are mostly green, aside from a known Clevis issue, and upgrades from F44 to F45 have tested successfully. A minor rebase timeout failure was noted but deemed safe to ignore.

Regarding other branches, Rawhide (F46) recently failed due to a Koji authentication error (GSSAPIAuthError), which the team will continue to monitor. Additionally, a known bug affecting ignition-edge has been resolved by a new upstream version, which now needs to be built and integrated into the distribution.

Decisions

• A recent F45 rebase test failure will be ignored, as it was attributed to a timeout and previous manual tests were successful.

Learn more about the IoT team.

ARM

This week, the Fedora ARM group's activity was centered around hardware compatibility inquiries and upcoming quality assurance coordination. A community member inquired about the availability of an installable Fedora 45 image for the Raspberry Pi 5 Rev 1.1, following earlier troubleshooting of older releases.

Additionally, the Fedora QA team announced the Fedora 45 Blocker Review meeting for the upcoming Beta release. The meeting is intended to review proposed blocker bugs and freeze exceptions, with community voting heavily encouraged beforehand to expedite the process.

Learn more about the ARM team.

RISC-V

The Fedora RISC-V group is on target to release the F45 rebuild alongside primary architecture images, maintaining strong sync parity with upstream. Discussions during the September 1st meeting highlighted current hardware stability issues, specifically GCC internal compiler errors on K1/K3 boards that are likely linked to new glibc vector optimizations and kernel/OpenSBI limits. LLVM last-mile integration work is also progressing.

In hardware news, SiFive announced the 32-core P870-D "Big Sky" development server. While pricing and shipping dates remain unannounced, preliminary remote testing by community members indicates it is a highly capable platform for future RISC-V datacenter and build farm usage.

Learn more about the RISC-V team.

Security

The Security group held a meeting this week to discuss the drafting of a proposal for a new Fedora Privacy SIG. The focus was on defining a technical, non-ideological scope for the SIG, which would involve privacy-related packaging, analyzing packages for privacy issues, maintaining a list of problematic packages, and potentially providing counter-packages or configuration overrides.

During the open floor, the group also addressed the high rate of misfiled CVEs affecting Fedora, stemming from the abandonment of a prototype vulnerability scanner by Red Hat ProdSec. The group discussed ongoing efforts to improve CVE mapping to Fedora packages through PURL generators for various language ecosystems, and agreed to create a master tracking bug to monitor this progress.

Decisions

• Agreed to create a master tracking bug to monitor the progress of Package URL (PURL) metadata generation, which will serve as a reference point for Red Hat ProdSec to help address the high false-positive rate of misfiled CVEs.
• Agreed to refine the draft proposal for the Fedora Privacy SIG by establishing a strictly technical scope that explicitly excludes legal compliance evaluation.

Learn more about the Security team.

Gaming

The developer of Inertia Blast II, an open-source remake of the ZX Spectrum game Thrust II built with LÖVE2D, has successfully tested the game and several other ports on a phone running Fedora PocketBlue Remix. The games run natively on the platform with full touch control support.

Due to time constraints, the developer is unable to create and maintain official Fedora packages, AppImages, or Flatpaks themselves. They are reaching out to the broader Fedora community to find volunteers interested in packaging, distributing, or beta testing these titles.

Learn more about the Gaming team.

Perl

During this week, the Perl group updated the perl-Date-Manip package to upstream release 7.00. Automated pull requests were generated by Packit Bot for both the Fedora 45 branch and the Rawhide branch, both of which were subsequently merged by Jitka Plesnikova.

Decisions

• Merged PR #12 to update perl-Date-Manip for f45 to upstream release 7.00 (Source).
• Merged PR #13 to update perl-Date-Manip for rawhide to upstream release 7.00 (Source).

Learn more about the Perl team.

Python

Carl Byington continued a discussion regarding a Fedora packaging question for dupeguru. Because the upstream project is unresponsive regarding their use of generic folder names (like core) that occupy the global Python module space, Carl created a fork incorporating open pull requests. He reorganized the source tree by moving the folders down one level, safely moving the installed code into a /usr/lib64/python3.14/site-packages/dupeguru namespace to prevent conflicts with other packages.

Decisions

• Because upstream is unresponsive, it was decided to use a custom fork of dupeguru that reorganizes the source tree into a specific dupeguru namespace, preventing the package from polluting the global Python module space and conflicting with other packages.

Learn more about the Python team.

Rust

The Rust group focused heavily on mitigating security vulnerabilities and cleaning up unmaintained packages this week. Major actions included submitting repository updates across multiple Fedora and EPEL branches to address security advisories in lru, and tracking newly disclosed vulnerabilities in hickory-dns.

Additionally, the team is actively porting packages away from several unmaintained crates, retiring the orphaned const-cstr package, and initiating a large cleanup of outdated GTK Rust bindings to remove technical debt from the repositories.

Decisions

• Retired the orphaned and unmaintained const-cstr package, which had an active security advisory (issue #2).
• Submitted updates for lru across Rawhide, Fedora 43-45, and EPEL 9-10 to resolve RUSTSEC-2026-0253 (issue #39).
• Initiated the deprecation and removal process for the outdated gtk-rs-core v0.20 and gtk4-rs v0.9 compatibility packages by filing tracking bugs for affected downstream applications (issue #40).

Learn more about the Rust team.

Other Discussions

• Miroslav Suchý provided an extensive list of newly added packages in Fedora Linux, prompting a discussion about the inclusion criteria and testing process for new software in the repository.
• Arjun Shankar requested rebuilds for a list of packages to improve Shadow Stack support coverage, leading to discussions about temporary build failures, including issues with wine in Rawhide.
• Adam Williamson announced changes to his Fedora and Bugzilla IDs due to internal policy updates at Red Hat requiring associates to split their corporate and personal open-source contributor identities.
• Jonathan Wakely pointed out that visudo does not respect the default editor settings or the vim-default-editor package, leading to a discussion on workarounds like writing wrapper scripts or proposing feature requests.
• Norbert Manthey proposed extending the default compiler settings to harden applications, suggesting flags like -fno-strict-overflow, but GCC developers strongly pushed back, explaining that these flags degrade performance and break valid C++ code.
• Tobias Girstmair asked for advice on packaging vim-classic in a way that allows it to coexist alongside standard vim, considering options like alternative naming and subpackages.
• Aoife Moloney reminded the community about the extended deadline to submit bug tracker workflows to help identify the best application to replace Red Hat Bugzilla.
• Orion Poplawski sought help on how to handle pre-release versions with Golang packaging after running into issues passing directory names to %goprep, receiving suggestions to use the %tag macro and go2rpm.
• On the libteam mailing list, Anisha Halwai submitted a patch series for teamd to add a per-runner col_dist_decoupled option, which Jiri Pirko reviewed, identifying potential state refresh and test cleanup issues.
• Bojan Smojver submitted pull requests to fix an issue where a failed F44 Flatpak compose was blocking all other updates, decoupling the logic so failed composes only hold up their own lanes.
• Other discussions included the upcoming Fedora 45 Blocker Review Meeting, potential SPDX license list updates for firmware, a proposed criteria change to reduce release-blocking storage interfaces, a request for a review swap for grub2-confidential-computing, and an introduction to an open-source AI chat tool on the fedora-join list.

Orphaning packages

• Johannes Lips is orphaning the elementary-icon-theme package due to build failures and its limited usefulness outside of specific desktop environments, while continuing to maintain the Xfce variant.
• Michel Lind announced he is removing himself from 214 packages (including 114 to be orphaned directly) to refocus his packaging efforts and shift away from LLM-dependent tools.
• Łukasz Patron announced he is taking over the orphaned rubygem-factory_bot because it is needed for a new package submission.

Package updates

• Yann Collette provided news about the Audinux activity for August, including the addition of 24 new packages and updates to 103 existing packages.
• Milan Crha announced GNOME 51.rc updates for Rawhide and Fedora 45, which are being gathered in side tags before being merged.
• Gwyn Ciesla is upgrading Motif to a new, maintained fork in Rawhide, which includes a soname bump and requires a side tag for package rebuilds.
• Artur Frenszek-Iwicki is upgrading the Free Pascal Compiler to fpc-3.2.4~rc2 in Rawhide and branched F45, submitting patches for three dependent packages that experienced build failures.

Contribution opportunities

Testing and Quality Assurance: There are numerous accessible testing opportunities for general users to help stabilize upcoming releases. Non-group members are highly encouraged to vote on proposed Fedora 45 blocker bugs and freeze exceptions using the blockerbugs app prior to review meetings for Workstation, KDE, ARM, and Release Engineering. Contributors can participate in the Kernel 7.2 Test Week, the I18n / Anaconda WebUI Test Day (announcement), and upcoming test days for CoreOS, GRUB EFI, and Anaconda F45. Users can also test the proposed Google Drive integration in GNOME, EPEL 10 Mailman server builds in COPR, ffmpeg 7 in EPEL 9 Next, the Robosignatory replacement, or verify performance for the mobile game Inertia Blast II.

Community Organization, Design, and Content Creation: Creative and organizational skills are needed across several groups. The Design team is calling for sketches and concepts for the F46 Wallpaper Project (details). Volunteers with video editing, design, marketing, and logistics skills can help run the 2026 Fedora Week of Diversity by joining the discussions or the Matrix room. Community advocates are actively sought to staff event booths at All Things Open 2026 and Software Freedom Day Bukidnon 2026. Writers and translators can contribute by pitching the "What's New in Fedora KDE" article, cleaning up obsolete Docs Project Wiki pages, or translating MATE Desktop.

Packaging, Development, and Debugging: Technical contributors can assist by adopting over 100 orphaned packages, conducting a package review swap for the GRUB EFI (devel request) or dupeguru packages, or packaging Inertia Blast II. The newly formed Crystal SIG needs packagers and testers to review guidelines and manage applications via their Matrix room. Rust developers are needed to port dependents away from obsolete crates like bincode, rustls-pemfile, and proc-macro-error, update GTK4 applications, and resolve Hickory-DNS vulnerabilities. Python developers can write a fedora-messaging automation consumer for RISC-V builds, while debuggers can analyze Kinoite AV1 tint issues, Discover crashes, IoT Clevis bugs, and RISC-V GCC core dumps.

Policy, Architecture Planning, and Analytics: Contributors can provide critical feedback on policies, including the storage interfaces criteria change (devel thread), the Fedora Forge usage policy, the Matrix moderation setup, and SPDX firmware guidelines. Data scientists are asked to review the Authorized Analytics Volunteer Agreement. Community members interested in technical direction can help define the scope of the Privacy SIG or join the Atomic and CoreOS unification planning discussions via Forgejo, GitLab, GitHub, or the new systemd-sysexts SIG. Finally, AWS administrators must ensure their resources include the FedoraGroup tag.

09 Sep 2026 8:53am GMT

Intro

After months of good old fashioned struggle with Google Drive and YouTube Studio, we were finally able to prepare the video sessions from the 2025 and 2026 Flock To Fedora event livestreams. These are now released to our YouTube and PeerTube communities. This article describes the details of the entire process that got us from the raw footage to the final uploads. It documents all our learnings along the way from the vendor selection to the FFMPEG configurations!

The Famous Last Words

While I was on my way back from Prague, after participating in Flock To Fedora 2026, I thought to myself - "Uploading the session recordings to YouTube should not be that difficult, right?". I was, of course, very humbled when I instinctively reached out to (erstwhile Fedora Community Architect) Justin Wheeler to obtain the livestream files. I was very surprised to find that there indeed was an existing process, so I did not necessarily have to reinvent the wheel.

A couple years back, Adrian Edwards had worked on the tooling to more or less streamline slicing, thumbnailing, metadataing (are those actual words?) and uploading to our YouTube channel. There were, of course, changes to be made on the documented processes, but since the uploads for the 2025 events were partially done, that was a good starting point. We were yet to receive those from the 2026 events so I had some time to acclimate to the existing methods.

Defective Detective

Of course, the first roadblock was as foundationally trivial as having wrong paths for the footage grouping. Flock To Fedora 2025 occurred during four days (i.e. 04th June 2025 to 07th June 2025) and across four distinct tracks (i.e. Plenary, Topaz, Opal and Quartz). This meant I had to untangle the messily organized footage files. As we were already a year late to upload the Flock To Fedora 2025 recordings, we knew that we could take some time to do it right.

I onboarded Shounak Dey, a fellow Fedora Infrastructure contributor who had previously helped me with the Fedora Badges Revamp Project, to help me out with this. He was able to maintain spreadsheets for the footage files and their corresponding mappings. That allowed us to quickly move to the next step. While I initially started using SponsorBlock to annotate the video timestamps, I quickly reverted back to manually eyeballing them using VLC Media Player.

More Hands, Quick Hands

Delegation was key here. While Shounak worked on manually annotating the video timestamps, I focussed on slicing sessions from the footage files using the LosslessCut application. With Adrian's Python scripts coming in the clutch and Justin giving the necessary access to Shounak, the only thing holding us back was the network bandwidth at that time. We earmarked some changes for the documentation updates, but we had to keep those for later when the processing was complete.

Justin and I were planning on a phased video release model, with sessions coming out on PeerTube first, before coming to YouTube. The videos being released gradually on both the platforms would ensure that we were able to retain the audience footfall and general relevance. In between - we had to bide our time if we wanted to succeed. I was gradually getting back to my day job as I worked through my event report for the Flock To Fedora 2026 conference.

Where Are Those Templates?

The processing scripts and relevant documentation were available, however, I had to go looking for the thumbnail templates. It did not help that those files were on a separate repository, thus making it difficult for some contributors not as involved as us to be able to discover them organically. Shounak kept jotting down the improvements to the documentation that he would make once we were done with processing livestreams for both 2025 and 2026.

What did not help was the buggy nature of the InkScape plugin for generating thumbnails using the discovered template called NextGenerator Addon. Honestly, I was at my wits end - as I was no designer and had no idea how to tailor fit the generated templates from the flaky extension. With some help from Emma Kidney and Madeline Peck, we were able to drive it home as they began working on the templates for the 2026's edition of the Flock To Fedora 2026 event.

Lay of the Land

By the last week of June 2026, we had received the footage files from Flock To Fedora 2026. I had access to the Fedora Project's YouTube channel, from back in the Fedora Websites And Apps days, and had begun uploading the sessions while marking them as unlisted. The learning ordeal from the footage processing of Flock 2025 gave us enough idea about how to proceed. This sped things up significantly once we were done with the growing pains of the required tooling.

I focused on uploading the 2025 slices on Google Drive for Justin to be able to upload them later onto PeerTube. At the same time Shounak stepped up to participate in the Marketing Team as an official member. There were some missing recordings that we pursued with Dorota Volavkova for multiple weeks. This was in vain and we ultimately settled for the lower quality YouTube VODs. We were more or less gradually closing on the finish line with this entire initiative. Or at least, so we thought…

No Audio? No Problemo!

This week we faced a new problem! About ten of our uploaded videos from Flock To Fedora 2025 did not have an audio playback in them. The audio tracks from the source files were unable to be muxed into the MP4 format. We had to losslessly convert the PCM format audio to the AAC format first. This came to our attention from a YouTube viewer's comment message. We had to resort to unlisting the affected videos and uploading them as a separate entry.

With Shounak pushing his documentation changes, I worked through this problem since this had to resolve as soon as possible. Late uploads for 2025 was already bad enough. We did not want the affected videos to create a new problem. After spending almost half a day learning FFMPEG's configs and documenting those, I was able to put it back into Justin's hands to reschedule the release of the (now fixed) session recordings.

Outro

One of the (rather unarguably) best ways to fix a problem is to first face the problem itself before rolling up your sleeves to resolve it. What I initially thought would be a very atomic and less influential contribution method ended up touching on a wide part of Fedora Project's community processes. Not only were we able to get these videos out for 2025 and 2026, but we were also able to mark a path forward for those who come after us wanting to do this for future events.

Session recordings

• Fedora Project on YouTube
• Flock To Fedora 2025 - Sessions Playlist
  Rolled out gradually so checking back later is recommended since the link might throw a 404
• Flock To Fedora 2026 - Sessions Playlist
  Rolled out gradually so checking back later is recommended since the link might throw a 404
• Fedora Project on PeerTube

09 Sep 2026 8:00am GMT

08 Sep 2026 6:53pm GMT

In a past post, I had written about my current project, where I am building an AI assistant for Neuroscience.

To quickly recap the motivation, for projects that we neuroscientists would like to undertake, including both experimental and modelling projects, we are often (even regularly) hampered by the question of "how are we going to carry out this investigation?" This is because the methods/techniques/code that need to be implemented are non-trivial to create. A lot of what we do is at the "edge of science", which means that it hasn't really been done before. Even if it has, for example an analysis methodology/technique may be well established, it still needs to be implemented in the specific novel context of the research project.

Research projects nowadays are necessarily multi-disciplinary. Experimental projects require experimentalists, that may be specialists in neurobiology, neuroanatomy, neurophysiology, to know enough about analysis and the tools for analyses---generally writing code. Modelling folks like me, on the other hand specialise in modelling and software development but need to know enough neurobiology, neuroanatomy, and neurophysiology to be able to build models. We speak slightly different languages, because each specialism has its own jargon, and so the same word can mean different things in different domains.

Generative AI based tools can help with this. To begin with, because they work on the basis of semantic similarity (meanings of words), they can cover different domains. Next, we're seeing more and more tools that are built around LLMs now being able to carry out tasks. I won't go into the AGI debate, or into a discussion whether LLMs and these systems are intelligent here. I have my views, like everyone else. What I will say is that I have found these tools useful, with caveats.

The most common caveat is the lack of correctness. LLMs work towards completion by generation---there may be multiple ways of completing a task, not all of them correct.

For science, correctness is paramount. We'd rather have a slow system that takes longer to develop than one that was generated in a day but that does not guarantee correctness. It isn't enough to be evidence based either. We must be able to clearly trace the evidence.

Klea

The goal of this project is to develop an AI assistant grounded in evidence. Since I last wrote, we submitted this as a project proposal to the BioFAIR Pathfinders call and were accepted. This means I now have a one year grant to work on this particular project.

To make it easy to find, we came up with "Klea" as a name. It's really "KLEA" for "Knowledge Validated Expert Asistant". klea- is also a nice prefix for commands. Though it's being developed primarily with Neuroscience as the test domain, it's a general framework and tool that can be used for any domains.

As noted in the previous post, Klea includes two components:

• a RAG_
• a task/coding agent (WIP)

Klea RAG

Klea-RAG is fairly complete. You can install it from pypi: pip install klea-rag (or uv pip install klea-rag if you prefer uv like me). It also includes utilities to create your vector stores and attach them to the RAG. You can also attach MCP servers. Note that the RAG is limited to information retrieval, and while you can attach MCP servers to it that can carry out write operations, that is discouraged. A complete walkthrough on setting it up is here in the cookbook.

Now, as noted earlier, it isn't just enough to try to be correct. It's important to be able to confirm how the system arrived at its result. For this, the framework has grown inspection capabilities, along with a brand new NiceGUI frontend since Streamlit was a bit too basic to add the additional UI elements.

The inspection features use LangGraph's streaming features to allow each node to emit progress events. The RAG emits information from each node:

• classification
• semantic search keywords
• retrieval results
• answer generation and evaluation.

The figures below make it easier to see.

The new Klea RAG interface is divided into several components:

• the left side bar: for managing chats, deleting user data
• the main central panel: the chat and inspection views live here
• the right hand side bar for information and state updates: the top lists the model in use and so on, the bottom bit shows state updates sent by the graph nodes.

In this screenshot, one can see the chat view. I asked a question, and the system generated an answer, and listed references. These references are created from the curated documentation that was provided to the system in the vector stores. So, it is not hallucinated. The right hand pane lists all the documents that were referenced along with their scores.

Users can verify the information using the references and the referenced documents.

The top part of the right hand panel also allows users to change models as required. One can set default models, as I've done here, but users can then use their own models and API keys to use different models that they have access to.

The next image shows the inspection pane. Here, one can review all the steps that system took to arrive at this answer, with the input/outputs, retrieved information, tool calls and so on. This is of great value---because it allows us to verify the results have greater confidence in the system's outputs.

I now have multiple deployments of the RAG on HuggingFace. One for NeuroML, one for Open Source Brain (this includes an MCP server to query a database of Open Source Brain repositories), and a third one for OpenWorm.

These are all containerised, and you will notice that they follow the same deployment pattern. You can clone one of these HuggingFace spaces and tweak the configuration to set up your personal deployment.

Note that you can also just use the RAG locally on your machine. It's designed to work for both use cases---local use and deployments. I tend to mostly use it locally.

Klea Agent

The agent is now a work in progress, with the RAG relatively stable. I still don't promise API compatibility though, since the general framework may change/evolve as we get feedback from our users. It'll follow the same framework, but we make some architectural decisions to make it "science worthy", because otherwise, why not just use an existing coding agent?

---

I'll write about this more in coming posts, but you can follow progress on the GitHub repository in the meantime. Klea has detailed documentation at https://neuroklea.org, and in the GitHub repository---ADRs, C4 diagrams, nodes, commented code. Please take a look and let me know what you think. Feedback is always welcome.

08 Sep 2026 4:16pm GMT

Hello travelers!

Loadouts for Genshin Impact v0.1.19 is OUT NOW with the addition of support for recently released artifacts like Heart of the Furnace and Scarlet Proof, recently released characters like Alyosha and Odette and for recently released weapons like Blade of Atonement, Clash of Kings, Covenant of Frost and Snow, Echoes of the Heart, Emberwell, Exaiphanes Blade, Forged by the Golden Melody, Frostbreath, Heretic's Molten Blade, Jade Vista, Song of the Vigil and Whitelake Frostfeather from Genshin Impact v7.0 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.

Resources

• Loadouts for Genshin Impact - GitHub
• Loadouts for Genshin Impact - PyPI
• Loadouts for Genshin Impact v0.1.19
  • Executable for GNU/Linux distributions
  • Executable for Microsoft Windows

Installation

Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.

$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=False

Changelog

• chore: remove obsolete Fedora packaging files by @w3lld1 in #588
• Sign the release artifacts with Sigstore by @gridhead in #592
• Automated dependency updates for GI Loadouts by @renovate[bot] in #590
• Parallelize Nuitka builds and resolve Sigstore action version by @gridhead in #593
• Replace extra-arguments with jobs for parallelization by @gridhead in #594
• Publish to PyPI before Sigstore signing by @gridhead in #596
• Remove stability days check from the Renovate config by @gridhead in #595
• Automated dependency updates for GI Loadouts by @renovate[bot] in #597
• Update actions/setup-python action to v7 by @renovate[bot] in #598
• Automated dependency updates for GI Loadouts by @renovate[bot] in #599
• Update sigstore/gh-action-sigstore-python action to v3.5.0 by @renovate[bot] in #600
• Automated dependency updates for GI Loadouts by @renovate[bot] in #601
• Automated dependency updates for GI Loadouts by @renovate[bot] in #634
• Create issue ticket template for weapon additions by @gridhead in #621
• Create issue ticket template for weapon modifications by @gridhead in #624
• Create issue ticket template for character additions by @gridhead in #622
• Create issue ticket template for artifact additions by @gridhead in #623
• Create issue ticket template for artifact modifications by @gridhead in #626
• Introduce the recently added character Alyosha to the roster by @gridhead in #627
• Use Inter font instead of IBM Plex Sans by @gridhead in #630
• Optimize test cases to consume less memory by @gridhead in #633
• Center the children dialog on the parent window by @gridhead in #632
• Adapt modal dialog tests from .show() to .exec() by @gridhead in #636
• Avoid header style overriding by parent widget stylesheets by @gridhead in #638
• Automated dependency updates for GI Loadouts by @renovate[bot] in #640
• Introduce the recently added character Odette to the roster by @gridhead in #628
• Fallback to IBM Plex Sans font from Inter by @gridhead in #645
• Resolve ScanDialog parent passing usage inconsistency by @gridhead in #648
• Resolve the MTKY assets alignment issue by @gridhead in #639
• Introduce the recently added artifacts Heart of the Furnace by @gridhead in #649
• Add additional description in artifact Viridescent Venerer by @gridhead in #651
• Introduce the recently added artifacts Scarlet Proof by @gridhead in #650
• Introduce the recently added weapon Whitelake Frostfeather by @gridhead in #652
• Add additional description in weapon Cashflow Supervision by @gridhead in #658
• Add additional description in weapon Kagura's Verity by @gridhead in #659
• Introduce the recently added weapon Echoes of the Heart by @gridhead in #653
• Introduce the recently added weapon Song of the Vigil by @gridhead in #656
• Introduce the recently added weapon Covenant of Frost and Snow by @gridhead in #657
• Introduce the recently added weapon Emberwell by @gridhead in #654
• Introduce the recently added weapon Clash of Kings by @gridhead in #661
• Introduce the recently added weapon Blade of Atonement by @gridhead in #655
• Automated dependency updates for GI Loadouts by @renovate[bot] in #663
• Introduce the recently added weapon Forged by the Golden Melody by @lxr14589-ai in #664
• Introduce the recently added weapon Frostbreath by @gridhead in #667
• Introduce the recently added weapon Jade Vista by @gridhead in #666
• Introduce the recently added weapon Heretic's Molten Blade by @gridhead in #668
• Introduce the recently added weapon Exaiphanes Blade by @gridhead in #669
• Enable double quotes in formatting runs by @gridhead in #662
• Stage the release v0.1.19 for Genshin Impact v7.0 Phase 2 by @gridhead in #670

Artifacts

Two artifacts have debuted in this version release.

Heart of the Furnace

• Bonus for Two Piece Equipment
  ATK increased by 18%.
• Bonus for Four Piece Equipment
  Increases the equipping character's ATK by 12% for 12s when they trigger a Stellar Glimmer reaction or deal Stellar Glimmer reaction DMG. Also increases Stellar Glimmer reaction DMG dealt by all nearby party members by 50%. The above effects can trigger even when the equipping character is not on the field, and the DMG bonus from multiple Artifact Sets with the same name do not stack.

Scarlet Proof

• Bonus for Two Piece Equipment
  ATK increased by 18%.
• Bonus for Four Piece Equipment
  Increases the equipping character's CRIT Rate by 16%, and their Stellar Swirl reaction dealt by 40%, for 10s after they trigger a Stellar Swirl reaction.

Characters

Two characters have debuted in this version release.

Alyosha

Alyosha is a polearm-wielding Electro character of four-star quality.

Odette

Odette is a sword-wielding Cryo character of five-star quality.

Weapons

Twelve weapons have debuted in this version release.

Blade of Atonement

Repentance and Redemption - Scales on ATK%.

Clash of Kings

Without Heed for Day nor Night - Scales on Crit Rate.

Covenant of Frost and Snow

The Law's Equilibrium - Scales on DEF%.

Echoes of the Heart

Echo of a Vow - Scales on ATK%.

Emberwell

Starfire Upon the Snowplains - Scales on Elemental Mastery.

Exaiphanes Blade

Traveler's Path - Scales on Crit Rate.

Forged by the Golden Melody

Day and Night in Counterpoint - Scales on Crit Rate.

Frostbreath

A Cast Real Far - Scales on Energy Recharge.

Heretic's Molten Blade

Lone Light's Blessing - Scales on Crit Rate.

Jade Vista

A Candle Woven From the Night - Scales on Crit Rate.

Song of the Vigil

Cadence of Days Gone By - Scales on Elemental Mastery.

Whitelake Frostfeather

Snow Swan's Finale - Scales on Crit Rate.

Appeal

While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.

Disclaimer

With an extensive suite of over 1616 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.

The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.

All rights to Genshin Impact assets used in this project are reserved by MiHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.

07 Sep 2026 6:30pm GMT

We use ThinkPad X13 Gen 6 21RMCTO1WW laptops among others. They shipped with a 5G WWAN module that Lenovo sells as the "Rolling Wireless RW350R-GL 5G CAT19". ModemManager detects it but cannot bring the radio up, because the module ships FCC-locked.

For the unlock procedure on Linux, Lenovo publishes lenovo-wwan-unlock. It works, but it is a closed binary running as root (sic!), supports only Ubuntu and Fedora, refuses to start on machines outside a hardcoded allowlist, and declines to unlock the modem when it finds a US SIM (for regulatory reasons, since it then assumes FCC jurisdiction). None of that is necessary. ModemManager has shipped a working unlock procedure for this module since version 1.24. It is just not enabled by default.

We have submitted a merge request that reads the OEM string at runtime instead of hardcoding one vendor's value. Until it is merged and new ModemManager versions arrive downstream, the commands below may help you to get the module working today.

Which module is this?

The same piece of hardware appears under a lot of names, which makes searching for it frustrating. If any of these match your machine, this post applies to you:

Rolling Wireless was spun out of Sierra Wireless in 2020 and is now a Fibocom subsidiary, so the RW350R-GL is a rebadged FM350R-GL. Lenovo lists it for the X13 Gen 6 and Gen 7, the T14s 2-in-1 Gen 1, and the P16 and P16v Gen 3. Because ModemManager matches only on 14c3:4d75, the instructions below also cover the plain Fibocom FM350-GL in machines like the X1 Carbon Gen 10 and 11.

Enabling the unlock

If you installed lenovo-wwan-unlock before, remove it first. Its own script shadows the one from ModemManager, in /usr/lib64/ModemManager/fcc-unlock.d/ on Fedora and /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d/ on Debian and Ubuntu. The uninstall script handles both:

git clone https://github.com/lenovo/lenovo-wwan-unlock.git
cd lenovo-wwan-unlock && chmod ugo+x fcc_unlock_uninstall.sh && ./fcc_unlock_uninstall.sh

Then enable ModemManager's own script. Fedora, Debian and Ubuntu all ship it in the same place:

sudo install -d -m 0755 "/etc/ModemManager/fcc-unlock.d"
sudo ln -s -f "/usr/share/ModemManager/fcc-unlock.available.d/14c3" \
              "/etc/ModemManager/fcc-unlock.d/14c3:4d75"

The script needs xxd, which none of them install as a hard dependency:

# Fedora / Red Hat
rpm -q xxd || sudo dnf install xxd

# Debian and Ubuntu
dpkg -s xxd > /dev/null 2>&1 || sudo apt install xxd

Now shut the machine down completely. A warm reboot is not enough: the module keeps power across reboot and suspend, and only re-arms its lock when it loses power. After a cold boot the modem should come up on its own:

mmcli -L
nmcli device | grep gsm

Two harmless warnings

ModemManager logs this once during boot:

Cannot power-up: hardware radio switch is OFF

That is the FCC lock, not a physical switch or a soft block. Check rfkill list and you will see nothing blocked. The line is immediately followed by power state updated: on once the unlock script has run.

Uninstalling Lenovo's package also strips --test-low-power-suspend-resume from the ModemManager unit, which its installer had added to stop the modem waking the machine from suspend. If you notice spurious wakeups afterwards, restore it as a drop-in rather than by editing the packaged unit:

sudo install -d "/etc/systemd/system/ModemManager.service.d"
printf '[Service]\nExecStart=\nExecStart=/usr/bin/ModemManager --test-low-power-suspend-resume\n' \
  | sudo tee "/etc/systemd/system/ModemManager.service.d/10-low-power-suspend.conf"
sudo systemctl daemon-reload

What about SAR?

SAR, the specific absorption rate, is the regulatory limit on how much radio energy a body absorbs. The tables tell the modem to back off transmit power on the bands and in the situations where the antennas sit close to you.

Removing the Lenovo package does not remove them. configservice_lenovo is a provisioner rather than a runtime component: it compares a version string and writes the tables into the modem's non-volatile memory only when they differ. On my machine, 127 runs produced exactly two writes, 1.02 in October 2025 and 1.1.3 in August 2026. Every other run logged bodysarver is same do not update.

The tables live in the module and the modem enforces them itself, so they survive reboots, suspend and uninstalling the package. What you give up is the updater: a newer table version will not be installed, and nothing re-provisions the modem after an NV wipe or a firmware reflash. Both are recoverable by reinstalling the package temporarily, letting it write, and removing it again (and I doubt one needs these updates at all).

To check the current state:

sudo mbimcli -p -d /dev/wwan0mbim0 --fibocom-set-at-command='AT+BODYSAREN?'
sudo mbimcli -p -d /dev/wwan0mbim0 --fibocom-set-at-command='AT+BODYSARVER?'

Note that Lenovo does not ship a table for every machine. On some models the service logs Lenovo Sar config is not supported in this machine, in which case nothing was ever written.

How the unlock works

No secret is involved. The modem answers AT+GTFCCLOCKGEN with a challenge, and the host replies with the first four bytes of SHA-256(challenge || SHA-256(model_id)[0:4]) via AT+GTFCCLOCKVER. The model_id is the first OEM string in SMBIOS type 133, which you can read yourself:

sudo dmidecode -t 133

On ThinkPads that string is KHOIHGIUCCHHII, and sha256sum of it starts with 3df8c719, exactly the constant in ModemManager's script. Fibocom's public FM350 AT command manual uses the same string as its worked example, in chapter 17.4.

Since that value is per vendor rather than per machine, hardcoding it means the script only works on the vendor it was taken from. A Dell Latitude 5540 with the same PCI ID fails for that reason, and Dell ships no SMBIOS type 133 string at all there, so reading it at runtime does not help either. Its value turned out to be DW5931EFCCLOCK, matching Dell's own DW5931e branding.

07 Sep 2026 12:28pm GMT

Recently, Framework announced their new Laptop 12, which optionally comes with the KDE Edition of Fedora Linux pre-installed. Framework's modular hardware has long captured the hearts of tinkerers, and many Framework users were already running Fedora Linux. Giving community members the option to unbox a hardware-validated, pre-installed Fedora KDE system is the culmination of months of effort from both Framework and dedicated Fedora community members. I'd like to take a moment to reflect on the hard work of the Fedora community that's made this possible

The Perfect Match: Fedora KDE Plasma & Convertible Hardware

The Framework Laptop 12 is a 12.2" 2-in-1 convertible laptop complete with a touchscreen and stylus support. Delivering a seamless experience on a form factor like this requires an interface that excels across traditional, touch, and pen modes.

Enter Fedora KDE Plasma Desktop.

Over recent release cycles, the Fedora KDE Special Interest Group (SIG) and upstream KDE contributors have poured immense effort into refining the user interface. This includes touch navigation, gesture support, virtual keyboards, and digital pen input under Wayland. Combined with the brand-new Intel Core Series 3 architecture, Thunderbolt 4, Wi-Fi 7, and options for a backlit keyboard and fingerprint reader, the hardware and software form a cohesive unit.

"The Fedora KDE Plasma Desktop contributors work hard to make the Fedora KDE Plasma Desktop edition the premier KDE experience for users. It's great to see Framework customers have the choice to have it pre-installed."

- Jef Spaleta, Fedora Project Lead

Community Collaboration at its Finest

Bringing a brand-new hardware platform with bleeding-edge components (like Intel's Core Series 3 chips and BE213 Wi-Fi 7 modules) to pre-built availability doesn't happen by accident. It takes rigorous testing, community bug hunting, and close collaboration.

Long before today's announcement, Framework provided pre-release hardware to Fedora QA and SIG contributors to ensure day-one hardware enablement:

• Kernel 7.1 Integration: Core Series 3 and Wi-Fi 7 R2 radios rely on recent upstream kernel drivers. Fedora contributors verified boot stability, power states, and Wi-Fi throughput on early builds to ensure seamless out-of-the-box performance.
• Fingerprint Sensor Support via libfprint: The new power-button fingerprint reader required driver verification and early integration into libfprint. This work allows users to instantly set up biometrics during the initial Plasma setup wizard.
• Display, Touch, and Stylus Calibration: Fedora QA and KDE community testers ran extensive Test Day scenarios to validate palm rejection, active stylus pressure sensitivity, and automatic screen rotation when flipping the device into tablet mode.
• Open-Source Firmware (ZMK): The updated backlit keyboard uses a reprogrammable controller running open-source ZMK firmware. This firmware aligns perfectly with Fedora's "Four Foundations" (Features, Friends, Freedom, First).

What This Means for the Linux Desktop

Starting at $699 USD for the Fedora pre-built configuration, the Framework Laptop 12 demonstrates that a fully modular, repairable, open-source-friendly laptop can be accessible, performant, and ready to go from day one.

Thank you to every member of the Fedora Quality Assurance team, the Fedora KDE SIG, and the broader upstream community who submitted test reports, verified kernel patches, and helped make this launch a massive success!

Disclosure: We used generative AI to outline and draft this post, but real humans shaped, verified, and reviewed it.

07 Sep 2026 8:00am GMT

From Pop!_OS to Bluefin: A 20% CPU Performance Upgrade on Raptor Lake

Distro-hopping isn't something I do on a whim. Changing your main operating system is always a bit of a hassle, but when a switch actually pays off, it's a great feeling. For a couple of years, I enjoyed using Pop!_OS and even encouraged others to adopt it. However, being on the Pop!_OS 22.04 LTS version felt like I was stuck in the past. With System76 pouring all their energy into building the new Rust-based COSMIC desktop, the 22.04 LTS release naturally started to feel stale.

Working at Red Hat, I have a natural bias toward the Red Hat and Fedora ecosystem, as Fedora is the upstream for Red Hat Enterprise Linux (RHEL). Since Bluefin is an atomic, image-based spin of Fedora, it felt like the perfect opportunity to bring that familiar ecosystem to my daily driver.

Recently, I decided to make the leap from Pop!_OS to Bluefin on my personal desktop, a GMKtec NukBox K10 powered by an Intel i9-13900HK. The results genuinely surprised me, and for the first time in a while, I'm actually excited to sit down at my desk.

Preparing for Change: A Seamless Transition

Before diving into the installation, I took the time to back up all my data and jot down crucial settings, like my backup_sync.sh script that keeps my Home directory files backed up to an external drive. That little bit of prep made the actual switch painless. Installing Bluefin, along with my essential apps, was a breeze, though it did require a dedicated USB drive since Ventoy wasn't supported.

Geekbench Performance Analysis: Pop!_OS vs. Bluefin

Curiosity and a desire for a modern, up-to-date desktop experience drove my decision to switch operating systems. I wasn't explicitly hunting for raw speed when I made the leap, but after using Bluefin for a bit, the system felt noticeably snappier. I ran Geekbench to check if the smoother feel was backed up by actual scores.

Geekbench measures raw processor performance across everyday workloads. Single-core scores reflect how quickly your system handles individual tasks like web browsing or launching apps, while multi-core scores show how well it handles heavy parallel processing like code compilation, video rendering, and multitasking under heavy loads.

The post-install benchmarks confirmed what I was feeling:

View full Geekbench benchmark runs: Pop!_OS Baseline Result | Project Bluefin Result

Why Bluefin Runs So Fast

A few key technical factors explain why Bluefin runs so much faster on Intel's hybrid chips:

• Modern Kernels for Modern Hardware: Bluefin uses modern 6.x and 7.x kernels built for Intel's Raptor Lake architecture. The scheduler works directly with the Intel Thread Director to push heavy tasks to Performance cores and background tasks to Efficient cores.
• Minimal System Overhead: Because Bluefin uses an atomic, image-based design, the base OS stays small. Applications run through Flatpaks or rootless Podman containers, keeping background daemons low and preventing OS slowdown over time.
• Performance Power Profiles: Default power settings allow the i9-13900HK to hold higher power limits under load without throttling prematurely.

Everyday Benefits Beyond Benchmarks

Synthetic scores are great, but the daily workflow improvements are what made me stay:

• Background Updates & Rollbacks: System updates install automatically in the background. If an update ever breaks anything, you can reboot and instantly roll back to the previous working state.
• Isolated Applications: Running apps in Flatpaks and containers keeps your core system clean and prevents library conflicts over time.
• Developer-Ready Setup: Built-in support for Docker, Podman, and developer toolchains means you spend less time configuring tools and more time building.

Discovering Universal Blue: Project Bluefin

For those curious about the performance gains and architectural improvements of Bluefin, the Universal Blue project website provides a deep dive into how Fedora-based immutable distributions redefine Linux desktop experiences compared to traditional systems like Pop!_OS.

Shout Out to Jorge Castro

A special shout out to Jorge Castro for his insightful videos on YouTube. His passion for Project Bluefin is contagious, and I'm so impressed with his ability to freestyle his video content at length without going off the rails.

Conclusion: Embracing the Performance Leap

Transitioning to Bluefin was more than just a performance upgrade. It was a step towards embracing simplicity and efficiency. If you're considering a similar switch, I hope my experience provides some useful insights. It's been an exciting journey, and I'm eager to see how Bluefin continues to enhance my computing experience.

If you have any questions or want to share your own experiences, feel free to leave a comment below. Let's keep the conversation going!

<p>The post From Pop!_OS to Bluefin: A 20% CPU Performance Upgrade on Raptor Lake first appeared on Rob McBryde.</p>

05 Sep 2026 6:48pm GMT

This week seemed to have a lot of small irq's all around. That said, I did make some progress on a few things:

05 Sep 2026 6:10pm GMT

A few short how-to's with screenshots, showing easy ways to boot up off a USB live ISO and return back to previous points in time with BTRFS.

Many Linux distributions now default to BTRFS as the standard installation filesystem. Fedora Linux is no exception to that.

2022/23 saw a lot of articles extolling its virtues of easy rollback, stability and so forth. All complete with paragraphs of command line instructions.

Times have changed, the BTRFS infrastructure has matured, and there are now easy to use GUI tools at our fingertips.

No special tools or skills

You may use any standard Fedora Linux ISO image and USB stick.

This article is for people new to Fedora Linux and for those who are familiar with ext4 and Timeshift.

Easy to follow instructions

My experience with Linux goes back quite a long way.

There used to be a time when the Fedora Linux help links often routed to Red Hat Enterprise. This generally targeted the needs of network managers and other system professionals.

Thankfully, for ordinary users the situation has now improved. The Fedora Magazine is one of those reasons.

In the last few years I have been using Fedora Linux as test-bed virtual machines and I have been using Fedora Kinoite on a secondary laptop.

As a daily driver, the thing that most recently stopped me switching to Fedora Linux was not being able to find easy to follow instructions on snapshot recovery during system boot failure.

This article lists the solutions that I finally pieced together.

How to start

First, make sure that you do actually have your OS running with BTRFS.

This is now normally the case but if you have had your installation for a few years, or someone else installed it for you, it is wise to check.

On Fedora Workstation, with Gnome, try disks or gparted. These two will also install readily on KDE and many users actually prefer them to the KDE partion manager.

Many people welcomed the 2025 decision by the Fedora steering committee to promote KDE to parity status with (Gnome) Workstation. This guide covers both official versions.

If you don't have Fedora Linux yet, there are also a few notes on general setup as well.

Getting help from the assistant

You may have seen btrfs-assistant mentioned in forum discussions. If you don't already have this program installed, then now is the time to look at doing it.

The package only takes a tiny amount of space and also installs snapper. About 4MB in total. Either Gnome Software or KDE Discover are fine. Or you can use dnf on the the command line.

Up and running:

Sub-Volumes

Registration of existing sub-volumes is automatic:

By default, Fedora creates two sub-volume sections on standard installation. We can only see them in the file manager when we boot via a USB live ISO, otherwise we see the volume contents only.

Partition managers such as gparted may show the partition as complete but the file system won't work unless we have set up the logical sub-volume overlay inside of it.

If you are using Gnome Workstation you may probably see an additional sub-volume '/root/var/lib/machines' which, unless you are working with container built machines, will be empty. It's just there to exclude temporary files from any snapshot processes and can be ignored too.

Alternative layouts

Anaconda is the in-house installer and I have been quite impressed with its recent incarnations.

The default installation route is decidedly the easier option at present.

However, for users wanting to add extra sub-volumes, the best method may be right at the start when you are offered the Storage Editor option. If using pre Fedora Linux 45, you can also find it at the top right corner of the interface.

Fedora Linux will happily install alongside your current setup if you want to try things out.

I have found that the best method is to use gparted to prepare a section of non-allocated disk space to offer the installer to work with, rather than offering it a ready made partition.

Post-install adjustments

Creating new sub-volumes requires the command line. This is for advanced users only.

In theory, Blivet-gui claims to be able to do this task but I am yet to be convinced. Btrfs-assistant leaves this bit well alone, which is what we are going to do.

Backups

There isn't much that we can do with the actual sub-volumes, as they stand. The Copy On Write (CoW) mechanism is there and working. That's about it.

But backups are always good to have, so make sure that you have got one before you start setting things up for real. We'll have a look at this in detail later on.

There are btrfs command line methods for sub-volumes using send and receive but the concepts can get quite complex.

Making standard partition backups are much easier using dd or Gnome Disks, just as if we were using ext4, and they are equally effective for basic needs.

Snapshots

These are what really sets BTRFS rollback into a totally different league compared to using Timeshift.

To get this working we are going to use Snapper:

You may find mention on forums about using Timeshift on Fedora Linux BTRFS with Ubuntu style @ sub-volumes. This now no longer works unless you are using something like Linux Mint. It was never probably a good idea to start with but it does illustrate the extents to which people have gone to, and just to get some kind of easy GUI recovery setup going.

We need to set up Snapper before things go wrong.

If you have arrived at this article through a web search and are in difficulties, unless you have previously setup snapshots, you are going to be restricted to using the command line.

Command line btrfs is actually the foundation program used to create and manage the overlay sections. Snapper helps us work with the btrfs snapshots.

Several command line articles are available: https://fedoramagazine.org/?s=btrfs

Snapper configs

The place to start is at the Snapper Settings tab. Click 'new' and fill in the details, one for 'root' and one for 'home':

The backup and target paths must both be on the same partition. Otherwise, the docs say that you can place sub-volumes anywhere. BTRFS uses hidden sub-volumes, so placing 'root' at '/' and 'home' at '/home' is as good a place as any, probably.

In our setup, root means everything except the home folder. And the home folder will neatly hold the home snapshots.

Snapper will place its config files at '/etc/snapper' if you need to find them.

Enable timeline, cleanup and boot. Click the save button.

Numbers

The first config save will set up the config file. We now have to set the numbers.

I don't know if is intentional for Snapper to default to saving 10 whole years of snaps and nothing weekly. Perhaps it's something to do with openSUSE and and their long term server support program?

For everyday use, these figures need changing. And the root volume needs to be treated differently from the home one.

I am currently evaluating the above set for root, with 15, 10, 5, 3, 1, 50 for home. Although, I am wondering if these these figures could be a bit too high …

The number defines how many snapshots the timeline cleanup algorithm should keep, counting from the youngest.

When done, save again, then apply systemd changes.

Hoarding Junk

Make sure that you don't get carried away. Snapshots are very easy to take. We've all probably seen stories of people filling their houses with 20 years of old newspapers.

One or two snapshots of old kernels and firmware updates might get us out of problems but we don't really need to keep Gigabytes of these for months on end. Conversely, it could be invaluable to find some small but important documents that got accidentally deleted a few months back without us realizing.

The dangers of system bloat could well be one of the reasons that Fedora Linux doesn't have snapper already installed.

Creating the snapshots

This is normally fully automated and happens in micro-seconds. A very different scale to ext4 and Timeshift where we are frequently talking of minutes.

Manual snaps are great as well. Maybe just before doing something that could go wrong is a good idea.

If you set up the Snapper boot config option, an instant snapshot will be taken at every boot time, so any errant updates can be very easy to reverse too.

Different copy on write file systems can have both subtle or major differences but the basic b-tree principles tend to remain. If you want a deep dive into the theory, there's lots out there.

The BTRFS system is continually working on records of what is happening, so data processing requirements are very small. In simple terms we can look at this as making tag at a point in time on a type of continuous and interconnected meta-data event log. When we roll back, we return to the tag and restart the recording on a new branch.

Browsing

Select the Snapper tab and then the sub-tab for Browse/Restore:

Find the snapshot that you think you need and click on Browse to see what's in there. The Browse function also lets you restore individual files rather than whole snaps. Keep an eye on the target drop down which will change when you switch tabs.

Deleting

BTRFS is night and day faster than the qcow2 systems used on virtual machines. The same for Timeshift. Only a couple of seconds are needed, even for very old snapshots.

Maintenance

On this tab, scrub is probably the only important one. The docs say this should run at least monthly. If you have done a lot of snapshot rewinding then a manual scrub is a good idea.

Balance is for balancing RAID devices and you only really need defrag if you are running on a mechanical hard drive. An SSD will have its own optimising system built in but you could run defrag manually every year or two if you want.

Live booting

There are some operations that we simply can't do on an operating system when it's in use. Instead, we need to use Fedora Media Writer or Gnome Disks to put a downloaded Live ISO onto a USB stick and run things from there. For Disks, right click on the ISO and select open-with Disk Image Writer.

Many of you will be very familiar with this process. But not everybody is aware that many live ISO's will also allow you to install small amounts of software onto them. This little trick will in fact go on to form a keystone to how we do our system failure recovery.

Downloaded ISO images from https://fedoraproject.org

If preferred, try the Manjaro KDE ISO from https://manjaro.org/products/download/x86 which will also have most of the needed software already there.

Restarts

The next stage is to get your computer to boot with the USB; you will need to have either already set your UEFI/BIOS to allow a trigger key during initial starting, usually delete, or you will need to go to the OS settings and request a UEFI restart there:

Staying safe

It's basic standard good practice to have a recent full backup when doing anything to your system.

Once you have booted the live ISO, if you don't have a backup, then make sure that you do.

Using Disk's GUI interface allows the making of partition images to be fairly straight forward. Gnome Workstation ISO's will already have Disks ready for you to use. If you are using KDE, set it up using KDE Discover. Otherwise use dnf. The installation is just a few MB.

Select the partition, standard click the options button and choose 'create partition image'.

Backup the boot partitions too. BTRFS makes no copies of these.

The usual cautions if you are thinking of using dd and have never used it before. You need to always pay attention to your input 'if=' and your output 'of=' or it changes from being a useful disk duplicator into it's other guise of disk destroyer ….

Also, place your backups on to something reliable. A good quality USB hard-drive is generally viewed as a good choice. They are more resistant to time fading than SSD's even if they are slower. If you have not heard of 'bit rot' there are lots of articles on the web. SSD's will lose data if they are not regularly powered up.

Partition sizes

You may want to consider partition size adjustment at this point. But do the initial backup first, if you can.

Keeping the size of the OS partition reduced down will make backing up much easier. And you are still going to need further full backups, even with Copy On Write running things.

For more experienced users, there are methods to compress partition backups using dd. Also creating a '/dev/zero' temp file will help compress even more. You can save lots of space but the .img files have to be fully decompressed in order to mount them, which is a slight down side.

Virtual machines

Problems with computer speed and with excess data can occur when having a two concurrent CoW systems running together. A kind of snowball effect from the host system continually backing up copies of the other backups.

According to the Qemu docs, when keeping virtual machines on a BTRFS partition it is recommend to use the 'nocow' option to avoid performance issues.

For those of you using Gnome Boxes, which comes pre-installed on Workstation, any adjustment of the config files and VM locations is not needed.

Boxes likes to keep its virtual machines out of view in a hidden home folder called '.local/share/gnome-boxes/images' and it tends to work best when left that way. All the image files will already have had CoW disabled.

I can't say that I have noticed any significant problems when I have carried out short tests. However, the issue is there nevertheless and a general look on the web will yield some quite lively discussion on the matter.

Advanced users may wish to consider running their VMs on a separate ext4 partition as another option.

The nocow +C flag can be easily checked by using lsattr against the image file, if required.

Swap files

Fedora Linux now uses the faster and more modern zram system which compresses the RAM data instead of swapping it to storage.

BTRFS snapshotting will not work if traditional swap files are present in the sub-volume.

If you are running short of RAM, your first option should be adjusting the zram allocation ratios. If you still find that you need a swap file, you will need to create a separate sub-volume to contain it.

Recovery

Having arrived at this point, you should now find this section to be fairly intuitive.

However, do remember to pay attention to root/home continuity. Remember that home will still contain hidden system and config files that are used by programs installed in the root section.

For small problems, where the system still boots, load btrfs-assistant on standard load and roll back to a previous good point.

Importantly, for USB running, start the file manager and mount the partition that you need to fix before installing or running btrfs-assistant or it will fail to work.

In both cases you will be advised to reboot for the request to take effect. The whole process is fairly quick and compared to Timeshift, pretty much instant.

Choosing the right tools

System failure happens to the best of us, given enough time to press enough buttons or to adjust one configuration file too many. But sometimes the failures are caused from upstream, from an unnoticed upstream bug perhaps.

If you are still able to boot into your system, Fedora Linux already features a very quick package reversal system as built-in standard. Sometimes we don't need to use snapshots at all.

There is a GUI program to run this called dnfdragora:

For the sake of completeness, this does need mentioning. However, I would probably argue that in this case the command line is quicker and more intuitive:

Downgrades work on a simple temporary basis only, so there is no need to re-instate anything at a later stage. When the next batch of updates are available, hopefully with a fix, the package and its associated files become automatically re-upgraded.

Conclusion

This article hopefully updates us to the start of H2 2026.

Should Red Hat support Fedora Linux putting their support behind btrfs-assistant and should we have snapper and snapshots already setup on new installations?

I think the answer to that is yes, and that this is probably going to be happening. But for exactly how and when, we will have to wait to see.

Further improvements will always be in the pipeline.

04 Sep 2026 8:54pm GMT

One of the hot topics in the last months has been the use of "AI" - which usually means using LLMs (Large Language Models).

After a big push at work to adopt "AI", it took me some time to find a good use of it in my daily workflow.

Rewriting software

One of most popular ways of using "AI" is rewriting software. I know people having old games ported from one retro platform to another this way.

However, the low barrier to entry gave many people a way to jump in which did not end well…

As a result, countless projects have stopped accepting merge requests because so many of them were nothing more than "AI slop" (aka "worthless junk not even worth looking at").

My example

I have used Claude to rewrite my EDK2 ArmCpuInfo project to make it easier for me to update it. The statistics of the commit that did most of the work:

lines changed: 5630 additions & 3552 deletions

I would not send anything like that to anyone for review. Far too messy. Going through it was painful but I got what I asked for. And this was a result of several prompts and manual changes.

Fixing packages

As you know, my work is mostly around building packages. I have worked on Arm, AArch64, ppc64le, s390x and now RISC-V. I fixed countless packages by hand, going through their source and finding out why they failed and how to get them building on target platforms.

After my last vacation I decided to check how an LLM would help with it.

I fetched the package, unpacked the sources (fedpkg prep), fetched the build.log file from the latest failed build, and ran Claude with one, simple prompt:

Look at build.log and source and find out why it does not build on risc-v.

The amount of time I had to wait and output to read varied from package to package. Sometimes build logs from other Fedora architectures were needed, sometimes a few build attempts. At the end I had a patch which made the package buildable on the RISC-V architecture.

Types of fixes

Some fixes were simple, like fastnetmon where a change in the link order was the only thing needed.

Some were funny, like GNU Data Language where fixing RISC-V fixed it for AArch64 as well. This made the build fail, as some tests, which were expected to fail, passed.

Others were related to differences between RISC-V (RV64GC) floating-point unit compared to other architectures. Such "simple" things like "are we dividing by zero" can be a problem.

Things I do not send

There were also packages for which I got some patches and never sent them neither upstream nor to the package maintainer.

Those were ones I did not understand. For instance, a patch changed how the "R" language handles "NA and NaN" numbers. It was yet another issue related to how RISC-V FPU works. Also it was so cryptic that I looked at code and had no idea what I was looking at.

The final question

I understand FOSS developers who refuse to accept any "AI generated" changes. There is too much "AI slop" being submitted. At the same time I wonder where their limit is.

Would they merge patch below or not? And would presence of the "Assisted-by: LLM" line make them refuse this patch or not? Will they accept it without such line?

Subject: [PATCH] Fix abseil link order for ld.bfd

Move absl:: libraries after gRPC in fastnetmon_api_client link list.
ld.bfd (used on riscv64) is a single-pass linker and needs dependees
before dependencies.

Assisted-by: LLM
---
 src/CMakeLists.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 10caf4c6..5bde9fcc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -800,10 +800,6 @@ if (ENABLE_GOBGP_SUPPORT)

     add_executable(fastnetmon_api_client fastnetmon_api_client.cpp)

-    if (LINK_WITH_ABSL)
-        target_link_libraries(fastnetmon_api_client  absl::base absl::synchronization)
-    endif()
-
     # We use another way to specify dependencies for Windows as our standard approach clearly does not work
     # https://www.f-ax.de/dev/2020/11/08/grpc-plugin-cmake-support.html
     if (${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
@@ -819,6 +815,10 @@ if (ENABLE_GOBGP_SUPPORT)

     target_link_libraries(fastnetmon_api_client protobuf::libprotobuf)

+    if (LINK_WITH_ABSL)
+        target_link_libraries(fastnetmon_api_client  absl::base absl::synchronization)
+    endif()
+
     if (KAFKA_SUPPORT)
         target_link_libraries(fastnetmon ${LIBKAFKA_CPP_LIBRARY_PATH})
     endif()

I would accept it. Because for me, despite the origin of that patch, it is a very simple change to review.

04 Sep 2026 2:40pm GMT

03 Sep 2026 10:00pm GMT

I just published the first version of the Maintainer's Guide to Hackfests. It's intended to be a short, practical guide for getting the most out of participating in a hackfest. As my luck would have it, this year's Hacktoberfest - the event that inspired me to write the guide in the first place - will be completely different from years past. But there are other hackfest events out there that you might want to participate in.

From being clear about why you're participating, to getting policies and configuration in place, the Maintainer's Guide to Hackfests condenses all of my experience in 16 short pages. If you find it useful, or if you find something confusing, missing, or flat out wrong, you can contribute. Or just start reading from the links below.

• PDF
• epub

This post's featured image from Control by Tristan Ferne, used under CC BY 2.0. Edited by Ben Cotton.

The post Maintainer's Guide to Hackfests appeared first on Duck Alignment Academy.

02 Sep 2026 12:00pm GMT

02 Sep 2026 11:49am GMT